ธุรกิจของฉันคือแฟรนไชส์ การให้คะแนน เรื่องราวความสำเร็จ ไอเดีย การทำงานและการศึกษา
ค้นหาไซต์

GOST คำอธิบายสำหรับโครงการ ข้อความอธิบายสำหรับโครงการด้านเทคนิค

ตามคำสั่งของคณะกรรมการมาตรฐานแห่งรัฐของคณะรัฐมนตรีของสหภาพโซเวียตลงวันที่ 28 กุมภาพันธ์ พ.ศ. 2516 ฉบับที่ 502 จึงมีการกำหนดวันแนะนำ

ตั้งแต่วันที่ 01/01/74

มาตรฐานนี้กำหนดข้อกำหนดสำหรับการดำเนินการออกแบบทางเทคนิคสำหรับผลิตภัณฑ์จากทุกอุตสาหกรรม

1. บทบัญญัติทั่วไป

1.1. โครงการทางเทคนิคได้รับการพัฒนาหากมีระบุไว้ในข้อกำหนดทางเทคนิค ระเบียบการสำหรับการทบทวนข้อเสนอทางเทคนิคหรือการออกแบบเบื้องต้น โครงการทางเทคนิคได้รับการพัฒนาโดยมีวัตถุประสงค์เพื่อระบุวิธีแก้ปัญหาทางเทคนิคขั้นสุดท้ายที่ให้ความเข้าใจที่สมบูรณ์เกี่ยวกับการออกแบบของ ผลิตภัณฑ์ เมื่อแนะนำให้ทำเช่นนี้ก่อนการพัฒนาเอกสารการทำงาน หากจำเป็น โครงการด้านเทคนิคอาจรวมถึงการพัฒนาตัวเลือกสำหรับแต่ละส่วนประกอบของผลิตภัณฑ์ ในกรณีเหล่านี้ ทางเลือกของตัวเลือกที่เหมาะสมที่สุดจะขึ้นอยู่กับผลการทดสอบ ของต้นแบบผลิตภัณฑ์ 1.2. เมื่อพัฒนาโครงการทางเทคนิคพวกเขาจะดำเนินงานที่จำเป็นเพื่อให้เป็นไปตามข้อกำหนดของผลิตภัณฑ์และช่วยให้พวกเขามีความเข้าใจอย่างสมบูรณ์เกี่ยวกับการออกแบบผลิตภัณฑ์ที่ได้รับการพัฒนาประเมินการปฏิบัติตามข้อกำหนดของข้อกำหนดทางเทคนิคความสามารถในการผลิตระดับ ความซับซ้อนของการผลิต, วิธีการบรรจุภัณฑ์, ความเป็นไปได้ในการขนส่งและการติดตั้ง ณ สถานที่ใช้งาน, ความสะดวกในการใช้งาน, ความเป็นไปได้และความเป็นไปได้ในการซ่อมแซม ฯลฯ รายการงานที่จำเป็นจะถูกกำหนดโดยผู้พัฒนาขึ้นอยู่กับลักษณะและวัตถุประสงค์ของผลิตภัณฑ์ และตกลงกับลูกค้าหากผลิตภัณฑ์ได้รับการพัฒนาตามคำสั่งของกระทรวงกลาโหม รายการงานโดยประมาณสำหรับผลิตภัณฑ์เพื่อวัตถุประสงค์ทางเศรษฐกิจของประเทศมีระบุไว้ในภาคผนวก บันทึก. ในขั้นตอนโครงการทางเทคนิค งานที่ดำเนินการในขั้นตอนก่อนหน้าจะไม่ทำซ้ำหากไม่สามารถให้ข้อมูลเพิ่มเติมได้ ในกรณีนี้ผลงานที่เสร็จสมบูรณ์ก่อนหน้านี้จะแสดงอยู่ในหมายเหตุอธิบาย (ฉบับแก้ไข แก้ไขครั้งที่ 4) การจำลองวัสดุควรได้รับการออกแบบเพื่อตรวจสอบ (หากจำเป็น ที่ไซต์ของลูกค้าหรือผู้บริโภค) การออกแบบและการแก้ปัญหาวงจรของผลิตภัณฑ์ที่ได้รับการพัฒนาและ (หรือ) ส่วนประกอบของผลิตภัณฑ์ ตลอดจนเพื่อยืนยันการตัดสินใจขั้นสุดท้าย การทดสอบการจำลองจะต้องดำเนินการตามโปรแกรมและวิธีการทดสอบที่พัฒนาขึ้นตาม GOST 2.106-96 องค์กรพัฒนาจำเป็นต้องจัดทำแบบจำลองและปริมาณ (หากจำเป็น จะต้องร่วมกับลูกค้า) (ฉบับแก้ไข แก้ไขครั้งที่ 5) การออกแบบทางเทคนิครวมถึงเอกสารการออกแบบตาม GOST 2.102-68 ซึ่งจัดทำโดยข้อกำหนดทางเทคนิคและโปรโตคอลสำหรับการทบทวนข้อเสนอทางเทคนิคและการออกแบบเบื้องต้น เมื่อดำเนินการเอกสารในรูปแบบอิเล็กทรอนิกส์ โครงสร้างอิเล็กทรอนิกส์ของผลิตภัณฑ์และแบบจำลองอิเล็กทรอนิกส์ของผลิตภัณฑ์ (หน่วยประกอบที่ซับซ้อน) จะดำเนินการโดยมีระดับรายละเอียดที่สอดคล้องกับขั้นตอนของโครงการทางเทคนิค เมื่อพัฒนาโครงการด้านเทคนิค สามารถใช้เอกสารแต่ละฉบับที่พัฒนาในขั้นตอนก่อนหน้าได้หากเอกสารเหล่านี้เป็นไปตามข้อกำหนดสำหรับเอกสารโครงการด้านเทคนิคหรือหากมีการเปลี่ยนแปลงเพื่อให้มั่นใจว่าเป็นไปตามข้อกำหนดดังกล่าว เอกสารที่ใช้มีการกำหนดตัวอักษร "T" เอกสารการออกแบบที่พัฒนาขึ้นสำหรับการผลิตแบบจำลองวัสดุไม่รวมอยู่ในชุดเอกสารการออกแบบทางเทคนิค (ฉบับแก้ไข แก้ไขครั้งที่ 5) สำเนาเอกสารการออกแบบทางเทคนิคที่รวบรวมตาม GOST 2.106-96 จะถูกส่งเพื่อตรวจสอบอนุมัติและอนุมัติ ได้รับอนุญาตตามข้อตกลงกับลูกค้าในการส่งเอกสารการออกแบบทางเทคนิคต้นฉบับ 1.6. รูปแบบการนำเสนอเอกสารการออกแบบทางเทคนิค (กระดาษหรืออิเล็กทรอนิกส์) หากไม่ได้ระบุไว้ในข้อกำหนดทางเทคนิคหรือโปรโตคอลเพื่อประกอบการพิจารณาข้อเสนอทางเทคนิคหรือการออกแบบเบื้องต้น จะถูกกำหนดโดยนักพัฒนาตามข้อตกลงกับลูกค้า อนุญาตให้รวมเอกสารในรูปแบบการนำเสนอต่างๆ ไว้ในชุดเอกสารการออกแบบทางเทคนิค (แนะนำเพิ่มเติม แก้ไขครั้งที่ 5)

2. ข้อกำหนดสำหรับการกรอกเอกสาร

2.1. การวาดภาพมุมมองทั่วไปหรือแบบจำลองอิเล็กทรอนิกส์ที่เทียบเท่าของชุดประกอบสำหรับโครงการทางเทคนิคดำเนินการตาม GOST 2.119-73 นอกจากนี้ ในการวาดภาพมุมมองทั่วไป (หรือแบบจำลองอิเล็กทรอนิกส์ที่เทียบเท่าของชุดประกอบ) หากจำเป็น ให้จัดเตรียม: คำแนะนำเกี่ยวกับขนาดที่พอดีของชิ้นส่วนที่เลือก (ขนาดและการเบี่ยงเบนสูงสุดของพื้นผิวผสมพันธุ์ระบุไว้ตาม GOST 2.307-68) ข้อกำหนดทางเทคนิคสำหรับผลิตภัณฑ์เช่นการใช้การเคลือบบางอย่างวิธีการเคลือบขดลวดวิธีการเชื่อมที่ให้ความมั่นใจในคุณภาพที่ต้องการของผลิตภัณฑ์ (ต้องคำนึงถึงข้อกำหนดเหล่านี้ในการพัฒนาเอกสารการทำงานในภายหลัง) ลักษณะทางเทคนิคของผลิตภัณฑ์ที่จำเป็นสำหรับการพัฒนาแบบร่างหรือรุ่นอิเล็กทรอนิกส์ที่เทียบเท่าในภายหลัง (ฉบับแก้ไข แก้ไขครั้งที่ 5) เอกสารการออกแบบทั้งหมดที่รวมอยู่ในโครงการทางเทคนิคจะถูกบันทึกไว้ในแผ่นออกแบบทางเทคนิคในลักษณะที่กำหนดโดย GOST 2.106-96 อนุญาตให้รวมไว้ในชุดเอกสารโครงการด้านเทคนิคในรูปแบบการนำเสนอต่างๆ (ในรูปแบบกระดาษหรืออิเล็กทรอนิกส์) ในขณะที่แนะนำให้ระบุรูปแบบการนำเสนอในคอลัมน์ "หมายเหตุ" (ฉบับเปลี่ยนแปลง แก้ไขครั้งที่ 5) 2.3. บันทึกอธิบายของโครงการทางเทคนิคดำเนินการตาม GOST 2.106-96 โดยคำนึงถึงข้อกำหนดพื้นฐานต่อไปนี้สำหรับเนื้อหาของส่วนต่างๆ: ก) ในส่วน "บทนำ" ระบุชื่อหมายเลขและวันที่อนุมัติ ข้อกำหนดทางเทคนิค หากการพัฒนาโครงการด้านเทคนิคไม่ได้จัดทำขึ้นโดยข้อกำหนดทางเทคนิค แต่โดยระเบียบการสำหรับการพิจารณาข้อเสนอด้านเทคนิคหรือการออกแบบร่าง ให้เขียนข้อความเช่น: “การพัฒนาโครงการทางเทคนิคจัดทำขึ้นโดยการออกแบบร่าง” .. ” และระบุหมายเลขและวันที่ของโปรโตคอลเพื่อพิจารณาการออกแบบร่าง b) ในส่วน "วัตถุประสงค์และขอบเขตการใช้งานของผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนา" ระบุ: คำอธิบายโดยย่อของพื้นที่และเงื่อนไขการใช้งานของผลิตภัณฑ์ ลักษณะทั่วไปของผลิตภัณฑ์ที่ตั้งใจไว้ (ถ้าจำเป็น) ข้อมูลพื้นฐานที่ควรมั่นใจในความเสถียรของตัวบ่งชี้คุณภาพของผลิตภัณฑ์ภายใต้สภาวะการทำงาน c) ในส่วน " คุณลักษณะทางเทคนิค" ให้: ลักษณะทางเทคนิคหลักของ ผลิตภัณฑ์ (กำลัง, ความเร็ว, ผลผลิต, ปริมาณการใช้ไฟฟ้า, เชื้อเพลิง, ประสิทธิภาพและพารามิเตอร์อื่น ๆ ที่แสดงลักษณะของผลิตภัณฑ์) ข้อมูลเกี่ยวกับการปฏิบัติตามหรือการเบี่ยงเบนจากข้อกำหนดที่กำหนดโดยข้อกำหนดทางเทคนิคและขั้นตอนการพัฒนาก่อนหน้าหากดำเนินการด้วย เหตุผลสำหรับการเบี่ยงเบน d) ในส่วน "คำอธิบายและเหตุผลของการออกแบบที่เลือก" ให้ไว้: คำอธิบายและเหตุผลของการออกแบบไดอะแกรมบรรจุภัณฑ์ที่เลือก (หากมีให้) และวิธีแก้ปัญหาทางเทคนิคอื่น ๆ ที่นำมาใช้และทดสอบในขั้นตอนของการพัฒนา ของโครงการด้านเทคนิค หากจำเป็น ให้จัดเตรียมภาพประกอบ ข้อมูลเปรียบเทียบคุณลักษณะทางเทคนิคหลักของผลิตภัณฑ์กับคุณลักษณะของแอนะล็อก (ในประเทศหรือต่างประเทศ) หรือจัดให้มีลิงก์ไปยังแผนที่ระดับทางเทคนิคและคุณภาพ การประเมินความสามารถในการผลิตของผลิตภัณฑ์ รวมถึงเหตุผล ความจำเป็นในการพัฒนาหรือซื้ออุปกรณ์ใหม่ การประเมินโซลูชันทางเทคนิคขั้นสุดท้ายสำหรับข้อกำหนดการปฏิบัติตามข้อกำหนดเพื่อรับรองความบริสุทธิ์ของสิทธิบัตรและความสามารถในการแข่งขัน ข้อมูลเกี่ยวกับสิ่งประดิษฐ์ที่ใช้ (จำนวนใบรับรองลิขสิทธิ์หรือจำนวนคำขอสำหรับการประดิษฐ์ที่ระบุวันที่มีความสำคัญ) ต้นแบบ (หากผลิต) ต้นแบบอิเล็กทรอนิกส์ (หากได้รับการพัฒนา) และข้อมูลเกี่ยวกับการประเมินความสอดคล้องของโครงร่างข้อกำหนดที่ระบุ รวมถึงการยศาสตร์และความสวยงามทางเทคนิค หากจำเป็น ให้จัดเตรียมรูปถ่ายของแบบจำลองวัสดุ สำหรับการอ้างอิง อนุญาตให้ระบุการกำหนดเอกสารการออกแบบหลักตามการจำลองวัสดุ หมายเลขและวันที่ของรายงาน (หรือ) รายงานการทดสอบ ฯลฯ ข้อมูลเกี่ยวกับการปฏิบัติตามข้อกำหนดของการยืม (ก่อนหน้า พัฒนาแล้ว) ส่วนประกอบที่ใช้ในผลิตภัณฑ์ ผลิตภัณฑ์และวัสดุที่ซื้อมาได้รับการพัฒนาตามลักษณะทางเทคนิค โหมดการทำงาน ระยะเวลาการรับประกัน เงื่อนไขการใช้งาน เหตุผลสำหรับความจำเป็นในการใช้ข้อมูลผลิตภัณฑ์และวัสดุที่หายากในการขนส่งและการเก็บรักษา การปฏิบัติตามข้อกำหนดด้านความปลอดภัยและสุขาภิบาลอุตสาหกรรมของผลิตภัณฑ์ e) ในส่วน "การคำนวณยืนยันการทำงานและความน่าเชื่อถือของการออกแบบ" ให้: การคำนวณยืนยันประสิทธิภาพของผลิตภัณฑ์ (จลน์ศาสตร์ ไฟฟ้า ความร้อน การคำนวณระบบไฮดรอลิกและนิวแมติก ฯลฯ .); การคำนวณยืนยันความน่าเชื่อถือของผลิตภัณฑ์ (การคำนวณตัวบ่งชี้ความทนทาน, การบำรุงรักษา, ความสามารถในการจัดเก็บ ฯลฯ ); สำหรับการคำนวณแต่ละประเภท จะมีการระบุซอฟต์แวร์และข้อมูลเครื่องมือสนับสนุนสำหรับระบบอัตโนมัติ (หากใช้ในการคำนวณ) ข้อมูลเกี่ยวกับความปลอดภัยของผลิตภัณฑ์และผลกระทบต่อสิ่งแวดล้อม ข้อมูลเกี่ยวกับการกำจัดผลิตภัณฑ์” หากปริมาณการชำระเงินมีขนาดใหญ่สามารถออกในรูปแบบของเอกสารแยกต่างหาก ในเวลาเดียวกันในส่วนนี้จะได้รับเฉพาะผลลัพธ์ของการคำนวณ e) ในส่วน "คำอธิบายของการจัดระเบียบงานโดยใช้ผลิตภัณฑ์ที่กำลังพัฒนา" มีข้อมูลเกี่ยวกับการจัดระเบียบการทำงานกับผลิตภัณฑ์ที่ไซต์ของ การดำเนินงานรวมถึง: คำอธิบายเทคนิคเฉพาะและวิธีการทำงานกับผลิตภัณฑ์ในรูปแบบและเงื่อนไขที่กำหนดไว้ในข้อกำหนดทางเทคนิค คำอธิบายขั้นตอนและวิธีการขนส่งการติดตั้งและการจัดเก็บผลิตภัณฑ์และการว่าจ้าง ณ สถานที่ปฏิบัติงาน ; การประเมินข้อมูลการปฏิบัติงานของผลิตภัณฑ์ (ความสามารถในการสับเปลี่ยน ความง่ายในการบำรุงรักษา การบำรุงรักษา ความต้านทานต่ออิทธิพลของสภาพแวดล้อม และความสามารถในการกำจัดความล้มเหลวอย่างรวดเร็ว) ข้อมูลเกี่ยวกับคุณสมบัติและจำนวนบุคลากรในการบำรุงรักษา g) ในส่วน "ทางเทคนิคและเศรษฐกิจที่คาดหวัง" ตัวชี้วัด” มีดังต่อไปนี้: ตัวชี้วัดทางเศรษฐกิจ, การคำนวณที่จำเป็น, การคำนวณโดยประมาณของราคาของผลิตภัณฑ์ทดลองและอนุกรมและต้นทุนในการจัดการการผลิตและการดำเนินงาน; h) ในส่วน "ระดับของมาตรฐานและการรวม" พวกเขาให้: ข้อมูลเกี่ยวกับหน่วยประกอบมาตรฐานหน่วยรวมและยืมและชิ้นส่วนที่ใช้ในการพัฒนาผลิตภัณฑ์ตลอดจนตัวบ่งชี้ระดับของการรวมและมาตรฐานของผลิตภัณฑ์ การออกแบบ เหตุผลสำหรับความเป็นไปได้ในการพัฒนามาตรฐานของรัฐและอุตสาหกรรมสำหรับการกำหนดมาตรฐานวัตถุที่เกี่ยวข้องกับการพัฒนาผลิตภัณฑ์นี้ส่วนประกอบและวัสดุใหม่ (ฉบับแก้ไข แก้ไขครั้งที่ 1, 5) .2.4. ภาคผนวกของหมายเหตุอธิบายประกอบด้วย: สำเนาข้อกำหนดทางเทคนิค ตลอดจนข้อมูล (ข้อกำหนดทางเทคนิค กฎการยอมรับ วิธีการควบคุม และข้อมูลอื่น ๆ หากจำเป็น) ที่จะรวมอยู่ในข้อกำหนดทางเทคนิค หากข้อกำหนดหลังไม่ได้ระบุไว้ พัฒนาในขั้นตอนนี้ วัสดุการศึกษาศิลปะและการออกแบบที่ไม่ใช่เอกสารการออกแบบ รายการงานที่ควรดำเนินการในขั้นตอนการพัฒนาเอกสารการทำงาน การชี้แจงหรือการพัฒนาตารางเครือข่ายสำหรับการพัฒนาและการดำเนินการต่อไป ผลิตภัณฑ์ที่ได้รับการพัฒนาไปสู่การผลิตทางอุตสาหกรรม รายการวรรณกรรมที่ใช้ ฯลฯ รายชื่อเอกสารที่ใช้ในการพัฒนาโครงการทางเทคนิคและได้รับโดยผู้พัฒนาผลิตภัณฑ์จากองค์กรและองค์กรอื่น ๆ (ใบรับรองของนักประดิษฐ์ ความคิดเห็นของผู้เชี่ยวชาญเกี่ยวกับความบริสุทธิ์ของสิทธิบัตร ใบรับรองผู้บริโภคเกี่ยวกับปริมาณการผลิตที่ต้องการ ผลิตภัณฑ์ที่ได้รับการพัฒนาและอื่น ๆ ) ; ในกรณีนี้ เอกสารจะไม่รวมอยู่ในภาคผนวกของบันทึกอธิบาย แต่บันทึกอธิบายอาจมีข้อมูลที่จำเป็นจากเอกสารเหล่านี้ (เช่น หัวข้อของการประดิษฐ์ ปริมาณผลิตภัณฑ์ที่ต้องการสำหรับไตรมาส สำหรับ ปี เป็นระยะเวลาห้าปี) รวมทั้งหมายเลขและวันที่ของเอกสารหรือจดหมายปะหน้า รายการซอฟต์แวร์และข้อมูลเครื่องมือสนับสนุนสำหรับระบบอัตโนมัติที่ใช้ในการพัฒนาโครงการด้านเทคนิค (ฉบับเปลี่ยนแปลง แก้ไขครั้งที่ 5)

แอปพลิเคชัน

รายการงานที่ดำเนินการระหว่างการพัฒนาโครงการด้านเทคนิค

ในกรณีทั่วไป เมื่อพัฒนาโครงการทางเทคนิค งานต่อไปนี้จะดำเนินการ: ก) การพัฒนาโซลูชันการออกแบบสำหรับผลิตภัณฑ์และส่วนประกอบหลัก b) ดำเนินการคำนวณที่จำเป็น รวมถึงการยืนยันตัวบ่งชี้ทางเทคนิคและเศรษฐกิจที่กำหนดโดยทางเทคนิค ข้อมูลจำเพาะ c) คุณทำไดอะแกรมวงจรที่จำเป็น ไดอะแกรมการเชื่อมต่อ ฯลฯ ให้เสร็จสิ้น; d) การพัฒนาและเหตุผลของโซลูชันทางเทคนิคที่รับรองตัวบ่งชี้ความน่าเชื่อถือที่กำหนดโดยข้อกำหนดทางเทคนิคและขั้นตอนการพัฒนาก่อนหน้า (หากขั้นตอนเหล่านี้ได้รับการพัฒนา) e) การวิเคราะห์การออกแบบผลิตภัณฑ์เพื่อความสามารถในการผลิตโดยคำนึงถึงข้อเสนอแนะจากผู้ผลิตในอุตสาหกรรมในแง่ของการรับรองความสามารถในการผลิตในเงื่อนไขของการผลิตเฉพาะนี้รวมถึงการใช้อุปกรณ์ที่มีอยู่ในองค์กรรวมถึงการคำนึงถึงในโครงการนี้ ข้อกำหนดของเอกสารด้านกฎระเบียบและทางเทคนิคที่บังคับใช้ในองค์กร - ผู้ผลิต การระบุอุปกรณ์ใหม่ที่จำเป็นสำหรับการผลิตผลิตภัณฑ์ (เหตุผลในการพัฒนาหรือได้มา) การพัฒนาการสนับสนุนทางมาตรวิทยา (การเลือกวิธีการและวิธีการวัด) f) การผลิตและการทดสอบแบบจำลองวัสดุและ (หรือ) การพัฒนาและการวิเคราะห์แบบจำลองอิเล็กทรอนิกส์ g) การประเมินผลิตภัณฑ์ที่เกี่ยวข้องกับการปฏิบัติตามข้อกำหนดด้านเศรษฐศาสตร์และความสวยงามทางเทคนิค h) การประเมินความเป็นไปได้ในการขนส่ง การจัดเก็บ และการติดตั้งผลิตภัณฑ์ ณ สถานที่ที่ใช้งาน i) การประเมินข้อมูลการปฏิบัติงานของผลิตภัณฑ์ (ความสามารถในการเปลี่ยนแทนกัน ความง่ายในการบำรุงรักษา การบำรุงรักษา ความต้านทานต่ออิทธิพลของสิ่งแวดล้อม ความสามารถในการ ขจัดความล้มเหลวอย่างรวดเร็ว การควบคุมคุณภาพของผลิตภัณฑ์ การจัดหาการควบคุมหมายถึงเงื่อนไขทางเทคนิค ฯลฯ) j) การสรุปการใช้งานสำหรับการพัฒนาและการผลิตผลิตภัณฑ์ใหม่ (รวมถึงเครื่องมือวัด) และวัสดุที่ใช้ในผลิตภัณฑ์ที่กำลังพัฒนา k) การดำเนินการตามมาตรการเพื่อให้แน่ใจว่าระดับของมาตรฐานและการรวมกันของผลิตภัณฑ์ที่ระบุไว้ในข้อกำหนดทางเทคนิค ฏ) การตรวจสอบผลิตภัณฑ์เพื่อความบริสุทธิ์และความสามารถในการแข่งขันของสิทธิบัตร การยื่นคำขอสิ่งประดิษฐ์ m) การระบุช่วงของผลิตภัณฑ์ที่จัดซื้อ การประสานงานการใช้ผลิตภัณฑ์ที่จัดซื้อ o) การตกลงเกี่ยวกับมิติโดยรวม การติดตั้ง และการเชื่อมต่อกับลูกค้าหรือผู้บริโภคหลัก ฑ) การประเมินระดับเทคนิคและคุณภาพของผลิตภัณฑ์ p) การพัฒนาแบบร่างของชุดประกอบและชิ้นส่วนหากเกิดจากความจำเป็นในการเร่งรัดการมอบหมายงานเพื่อพัฒนาอุปกรณ์เฉพาะสำหรับการผลิต c) การตรวจสอบการปฏิบัติตามการตัดสินใจเกี่ยวกับข้อกำหนดด้านความปลอดภัยและสุขอนามัยในโรงงาน ) รวบรวมรายการงานที่ควรดำเนินการในขั้นตอนการพัฒนาและเอกสารการทำงานเพิ่มเติมและ (หรือ) การชี้แจงงานที่ให้ไว้ในแง่ของการอ้างอิงข้อเสนอทางเทคนิคและการออกแบบเบื้องต้น y) การเตรียมข้อเสนอสำหรับ การพัฒนามาตรฐาน (การแก้ไขหรือแก้ไขมาตรฐานที่มีอยู่) ที่กำหนดไว้ในเงื่อนไขการอ้างอิงในขั้นตอนนี้ 4 (แนะนำเพิ่มเติม การเปลี่ยนแปลง ลำดับที่ 4) t) การจัดทำข้อเสนอสำหรับการใช้ซอฟต์แวร์และการสนับสนุนข้อมูลสำหรับระบบอัตโนมัติในการพัฒนาเอกสารการออกแบบการทำงาน (แนะนำเพิ่มเติม การแก้ไขครั้งที่ 5)

ชื่อเอกสาร:
หมายเลขเอกสาร: 1.16-78
ประเภทเอกสาร: GOST
อำนาจรับ: มาตรฐานแห่งรัฐของสหภาพโซเวียต
สถานะ: ไม่ได้ใช้งาน
ที่ตีพิมพ์:
วันที่รับ: 30 พฤศจิกายน 2521
วันที่เริ่มต้น: 01 กรกฎาคม 2522
วันหมดอายุ: 01 มกราคม 1987
วันที่แก้ไข: 01 มกราคม 1983

GOST 1.16-78

กลุ่ม T50

มาตรฐานสถานะของสหภาพโซเวียต

ระบบมาตรฐานของรัฐ

หมายเหตุอธิบายร่างมาตรฐาน การก่อสร้าง เนื้อหา การนำเสนอ และการออกแบบ

ระบบมาตรฐานของรัฐ หมายเหตุอธิบายร่างมาตรฐาน เค้าโครง เนื้อหา ข้อความ และการนำเสนออย่างเป็นทางการ

วันที่แนะนำ 1979-07-01

ตามคำสั่งของคณะกรรมการมาตรฐานแห่งรัฐสหภาพโซเวียตลงวันที่ 30 พฤศจิกายน พ.ศ. 2521 N 3205 กำหนดวันแนะนำตั้งแต่ 07/01/79

ออกใหม่โดยมีการเปลี่ยนแปลงครั้งที่ 1 ได้รับการอนุมัติในเดือนพฤศจิกายน พ.ศ. 2524 (IUS 3-82)


มาตรฐานนี้กำหนดข้อกำหนดสำหรับการก่อสร้าง เนื้อหา การนำเสนอ และการดำเนินการของบันทึกอธิบายสำหรับร่างมาตรฐานของรัฐ อุตสาหกรรม สาธารณรัฐ และมาตรฐานขององค์กรทุกประเภท

1. บทบัญญัติทั่วไป

1. บทบัญญัติทั่วไป

1.1. หมายเหตุอธิบายเกี่ยวกับร่างมาตรฐานนั้นจัดทำขึ้นสำหรับการแก้ไขร่างแต่ละครั้งที่ส่งเพื่อตรวจสอบ ส่งเพื่อขออนุมัติ และส่งเพื่อขออนุมัติ

1.2. หมายเหตุอธิบายเกี่ยวกับร่างมาตรฐานจะต้องจัดทำโดยองค์กร (องค์กร) ที่พัฒนามาตรฐาน

หากมีนักพัฒนาหลายราย องค์กรชั้นนำ (องค์กร) - นักพัฒนาจะจัดทำบันทึกอธิบายเกี่ยวกับร่างมาตรฐาน

1.3. มีการจัดทำบันทึกคำอธิบายที่เป็นอิสระสำหรับแต่ละมาตรฐานที่กำลังพัฒนา

ได้รับอนุญาตให้จัดทำบันทึกอธิบายหนึ่งฉบับในระหว่างการพัฒนาพร้อมกันการเตรียมการสำหรับการประสานงานและการอนุมัติมาตรฐานที่สัมพันธ์กันของหมวดหมู่เดียวกันสำหรับวัตถุมาตรฐานที่เป็นเนื้อเดียวกัน

2. ข้อกำหนดสำหรับการก่อสร้างเนื้อหาและการนำเสนอบันทึกคำอธิบาย

2.1. ชื่อเรื่องของหมายเหตุอธิบายระบุถึงหมวดหมู่และชื่อเต็มของมาตรฐาน หมายเลขซีเรียลของฉบับแก้ไขมาตรฐานฉบับร่าง และ (หรือ) ข้อมูลเกี่ยวกับขั้นตอนการพัฒนามาตรฐาน

ตัวอย่างเช่น:

หมายเหตุอธิบาย

สู่ร่างมาตรฐานของรัฐ "ด้ายเย็บจากไหมธรรมชาติ เงื่อนไขทางเทคนิค" (ฉบับตีพิมพ์ครั้งแรกถูกส่งไปตรวจสอบ)

หมายเหตุอธิบาย

สู่ร่างมาตรฐานของรัฐ "อุปกรณ์การทำแผนที่ ข้อกำหนดและคำจำกัดความ" (ฉบับสุดท้ายที่ส่งเพื่อขออนุมัติ)

2.2. หมายเหตุอธิบายของร่างมาตรฐานควรประกอบด้วยส่วนที่มีหมายเลขตามลำดับตลอดทั้งบันทึกอธิบาย และกำหนดเป็นเลขอารบิคโดยมีจุดอยู่ที่ท้ายตัวเลข ส่วนหัวของส่วนควรเป็นตัวพิมพ์ใหญ่

หากจำเป็น คำอธิบายสามารถแบ่งออกเป็นส่วนย่อย ย่อหน้า และย่อหน้าย่อยตามข้อกำหนดที่กำหนดใน GOST 1.5-68 * สำหรับมาตรฐาน
________________
* เอกสารไม่ถูกต้องในอาณาเขตของสหพันธรัฐรัสเซีย แทนที่ด้วย GOST 1.5-85 (ยกเลิกโดยไม่มีการเปลี่ยน) ซึ่งต่อไปนี้จะอยู่ในข้อความ

2.3. หมายเหตุอธิบายควรประกอบด้วยส่วนที่จัดเรียงตามลำดับต่อไปนี้:

พื้นฐานในการพัฒนามาตรฐาน

เป้าหมายและวัตถุประสงค์ของการพัฒนามาตรฐาน

ข้อมูลเกี่ยวกับการกำหนดมาตรฐานของวัตถุในช่วงเริ่มต้นของการพัฒนาร่างมาตรฐาน

ลักษณะของวัตถุมาตรฐาน

ระดับวิทยาศาสตร์และเทคนิคของวัตถุมาตรฐาน

ประสิทธิภาพทางเทคนิคและเศรษฐกิจจากการนำมาตรฐานไปใช้

วันที่คาดว่าจะนำมาตรฐานไปใช้และระยะเวลาที่คาดว่าจะมีผลใช้บังคับ

ความสัมพันธ์กับมาตรฐานอื่น

ข้อมูลเกี่ยวกับการแจกจ่ายข้อเสนอแนะ (สำหรับร่างมาตรฐานทุกรุ่น ยกเว้นฉบับแรก)

ข้อมูลเกี่ยวกับการอนุมัติ (เฉพาะร่างมาตรฐานฉบับสุดท้ายที่ส่งเพื่อขออนุมัติ)

แหล่งข้อมูล

ข้อมูลเพิ่มเติม

เมื่อรวบรวมบันทึกอธิบายสำหรับฉบับร่างมาตรฐานฉบับที่สองและครั้งต่อไป (ยกเว้นขั้นสุดท้าย) ไม่อนุญาตให้รวมส่วนต่างๆ ในบันทึกอธิบายเหล่านี้ซึ่งเนื้อหาไม่มีการเปลี่ยนแปลง

2.4. คำอธิบายสำหรับร่างมาตรฐานแต่ละฉบับนั้นจัดทำขึ้นโดยอิงตามตัวบ่งชี้ บรรทัดฐาน คุณลักษณะ ข้อกำหนดที่รวมอยู่ในฉบับนี้ พร้อมเหตุผลในการเปลี่ยนแปลง

2.5. ในส่วน "พื้นฐานสำหรับการพัฒนามาตรฐาน" คุณควรระบุหมายเลขหัวข้อตามแผนที่ได้รับอนุมัติ วันที่และชื่อขององค์กรที่อนุมัติเงื่อนไขการอ้างอิง

ในกรณีของการพัฒนาร่างมาตรฐานที่ไม่รวมอยู่ในแผนการมาตรฐาน (หัวข้อที่ไม่ได้วางแผนไว้) ควรระบุเอกสารคำสั่งของหน่วยงานระดับสูงบนพื้นฐานของมาตรฐานที่กำลังได้รับการพัฒนา

ควรระบุตามโปรแกรมมาตรฐานที่ครอบคลุม (ถ้ามี) มาตรฐานที่กำลังได้รับการพัฒนา

2.6. ในส่วน "เป้าหมายและวัตถุประสงค์ของการพัฒนามาตรฐาน" คุณควรระบุผลลัพธ์สุดท้ายที่จะบรรลุผลสำเร็จโดยใช้มาตรฐาน และงานที่จะแก้ไขในระหว่างการพัฒนามาตรฐาน

2.7. ในส่วน “ข้อมูลเกี่ยวกับการกำหนดมาตรฐานของวัตถุโดยเริ่มการพัฒนาร่างมาตรฐาน” ระบุข้อมูลที่ว่ามีการพัฒนามาตรฐานเป็นครั้งแรก หรือข้อมูลเกี่ยวกับมาตรฐานปัจจุบัน ข้อกำหนดทางเทคนิค คำแนะนำ และเอกสารอื่น ๆ ที่มีผลบังคับใช้ในช่วงเริ่มต้นของการพัฒนาร่างมาตรฐานสำหรับวัตถุมาตรฐานนี้

2.8. ในส่วน "ลักษณะของวัตถุมาตรฐาน" ขึ้นอยู่กับวัตถุที่เป็นมาตรฐาน (ผลิตภัณฑ์ ตัวบ่งชี้ บรรทัดฐาน คุณลักษณะ ข้อกำหนดขององค์กร วิธีการ และลักษณะทางเทคนิคทั่วไป) หมวดหมู่และประเภทของมาตรฐาน ระบุตัวบ่งชี้หลัก บรรทัดฐาน คุณลักษณะ ข้อกำหนดของร่างมาตรฐานที่กำหนดระดับทางวิทยาศาสตร์และเทคนิคของวัตถุมาตรฐาน และการศึกษาความเป็นไปได้

ตัวชี้วัดหลักบรรทัดฐานลักษณะข้อกำหนดของร่างมาตรฐานอาจเป็นข้อกำหนดของทิศทางหลักของการพัฒนาเศรษฐกิจของประเทศสหภาพโซเวียตตัวชี้วัดของแผนมาตรฐานและข้อกำหนดทางเทคนิคสำหรับการพัฒนามาตรฐานและตัวชี้วัดการใช้วัสดุ ทรัพยากร.

ในส่วนนี้ให้ข้อมูลจากรายงานผลการวิจัยและพัฒนาที่ดำเนินการหรือลิงก์ไปยังรายงานที่ระบุตำแหน่งของรายงานตลอดจนข้อมูลเกี่ยวกับผลการวิจัยสิทธิบัตรในเรื่องการกำหนดมาตรฐานการค้นพบในประเทศและต่างประเทศที่ได้รับการพิสูจน์แล้วและ สิ่งประดิษฐ์ที่ตีพิมพ์ในช่วงสิบปีที่ผ่านมาก่อนที่จะได้รับอนุมัติจากมาตรฐานและข้อสรุปในการทดสอบต้นแบบหรือชุดนำร่องของผลิตภัณฑ์ที่ได้รับมาตรฐาน

2.9. ในส่วน "ระดับทางวิทยาศาสตร์และเทคนิคของวัตถุมาตรฐาน" จะมีการวิเคราะห์เปรียบเทียบตัวบ่งชี้ บรรทัดฐาน คุณลักษณะ ข้อกำหนดที่กำหนดโดยร่างมาตรฐาน

พร้อมตัวบ่งชี้ บรรทัดฐาน คุณลักษณะ ข้อกำหนดของมาตรฐาน (คำแนะนำ) ของ CMEA, ISO, IEC และองค์กรระหว่างประเทศอื่น ๆ

พร้อมตัวบ่งชี้บรรทัดฐานลักษณะข้อกำหนดของมาตรฐานในประเทศและต่างประเทศ

พร้อมตัวอย่างอุปกรณ์และสินค้าที่ดีที่สุดของการผลิตในประเทศและบริษัทต่างประเทศ

ด้วยความสำเร็จอันทันสมัยสูงสุดในด้านวิทยาศาสตร์ เทคโนโลยี ประสบการณ์ขั้นสูงทั้งในประเทศและต่างประเทศในสาขานี้

เนื้อหาในส่วนนี้ควรสะท้อนถึงการปฏิบัติตามตัวบ่งชี้ บรรทัดฐาน คุณลักษณะ และข้อกำหนดของร่างมาตรฐาน:

งานที่กำหนดไว้ในทิศทางหลักของการพัฒนาเศรษฐกิจของประเทศสหภาพโซเวียต

โปรแกรมทางวิทยาศาสตร์และเทคนิคที่ซับซ้อน รวมถึงวัตถุประสงค์ของการกำหนดมาตรฐาน

โปรแกรมมาตรฐานที่ครอบคลุม

ในส่วนนี้ ตามข้อมูลข้างต้น มีการให้ข้อสรุปทั่วไปเกี่ยวกับระดับทางวิทยาศาสตร์และเทคนิคของตัวบ่งชี้ บรรทัดฐาน ลักษณะ และข้อกำหนดของวัตถุมาตรฐาน

หากส่งตารางเปรียบเทียบตัวบ่งชี้หรือแผนที่ระดับทางเทคนิคและคุณภาพของผลิตภัณฑ์ตาม GOST 2.116-71* ฉบับสุดท้ายเพื่อขออนุมัติแยกกัน จากนั้นหมายเหตุอธิบายสำหรับฉบับนี้จะระบุเพียงเท่านั้น ผลลัพธ์ของการวิเคราะห์เปรียบเทียบและให้ข้อสรุปทั่วไปเกี่ยวกับระดับทางวิทยาศาสตร์และทางเทคนิคของตัวบ่งชี้ บรรทัดฐาน ลักษณะ ข้อกำหนดของวัตถุมาตรฐาน
________________
GOST 2.116-84 - หมายเหตุของผู้ผลิตฐานข้อมูล

2.10. ในส่วน "ประสิทธิภาพทางเทคนิคและเศรษฐศาสตร์จากการนำมาตรฐานไปใช้" คุณควรระบุประสิทธิภาพทางเศรษฐกิจที่คาดหวัง ข้อได้เปรียบทางเศรษฐกิจของวัตถุมาตรฐาน และแหล่งที่มาหลักของการได้รับผลกระทบทางเศรษฐกิจ

หากเป็นไปไม่ได้ที่จะคำนวณประสิทธิภาพทางเศรษฐกิจของการนำมาตรฐานไปใช้ ควรให้เหตุผลที่จำเป็น เนื้อหาในส่วนนี้จะกล่าวถึงตัวชี้วัดประสิทธิภาพทางสังคมจากการนำมาตรฐานไปปฏิบัติ (ถ้ามี)

2.11. ในส่วน “วันที่ประมาณวันที่มาตรฐานมีผลใช้บังคับและระยะเวลาที่คาดว่าจะมีผลบังคับใช้” ควรระบุสิ่งต่อไปนี้:

เหตุผลของกรอบเวลาที่คาดหวังสำหรับการแนะนำมาตรฐานโดยคำนึงถึงเวลาที่จำเป็นในการดำเนินกิจกรรมเพื่อนำมาตรฐานไปใช้

เหตุผลของกิจกรรมหลักสำหรับการนำมาตรฐานไปใช้รวมถึงเหตุผลของความเป็นไปได้ในการจัดการการผลิตผลิตภัณฑ์แบบรวมศูนย์ (เฉพาะทาง)

เหตุผลในการอนุมัติร่างมาตรฐานโดยไม่มีการจำกัดระยะเวลาที่มีผลใช้ได้หรือการให้เหตุผลสำหรับระยะเวลาที่มีผลใช้บังคับที่คาดหวังของมาตรฐาน

2.12. ในส่วน "ความสัมพันธ์กับมาตรฐานอื่น" คุณควรระบุ:

เป็นของร่างมาตรฐานของชุดมาตรฐานที่รวมอยู่ในระบบ

ข้อมูลเกี่ยวกับความสัมพันธ์ของร่างมาตรฐานกับมาตรฐานอื่นๆ ตลอดจนมาตรฐานและข้อเสนอแนะของ CMEA และองค์กรระหว่างประเทศอื่นๆ

ข้อเสนอที่สมเหตุสมผลเกี่ยวกับความจำเป็นในการแก้ไข พัฒนาการเปลี่ยนแปลง หรือยกเลิกมาตรฐานที่เกี่ยวข้องกันที่มีอยู่

ในกรณีที่มีการแก้ไขมาตรฐานผลิตภัณฑ์ จะมีการให้ข้อมูลเกี่ยวกับความสามารถในการสับเปลี่ยนของผลิตภัณฑ์ได้ตามมาตรฐานและมาตรการที่พัฒนาและปัจจุบันเพื่อให้แน่ใจว่าการทำงานและการซ่อมแซมผลิตภัณฑ์ที่ผลิตตามมาตรฐานปัจจุบัน

2.13. ในส่วน "ข้อมูลเกี่ยวกับการส่งบทวิจารณ์ทางไปรษณีย์" คุณควรระบุ:

จำนวนองค์กร (องค์กร) ที่ส่งร่างมาตรฐานไปให้

จำนวนองค์กร (องค์กร) ที่ส่งบทวิจารณ์

คำอธิบายทั่วไปโดยย่อของบทวิจารณ์

ผลลัพธ์ของการทบทวนบทวิจารณ์

2.14. ในส่วน "ข้อมูลเกี่ยวกับการอนุมัติ" คุณควรให้ข้อมูลเกี่ยวกับการอนุมัติร่างมาตรฐานกับองค์กรที่สนใจ (องค์กร) การจัดประชุมประนีประนอม ให้คำอธิบายสั้น ๆ เกี่ยวกับประเด็นที่หารือ ระบุถึงความขัดแย้งที่ยังคงอยู่ระหว่างการพัฒนาร่างมาตรฐาน

หากร่างมาตรฐานไม่จำเป็นต้องได้รับการอนุมัติ หมายเหตุอธิบายควรระบุว่ามาตรฐานนั้นไม่อยู่ภายใต้การอนุมัติ

2.15. ในส่วน "แหล่งข้อมูล" คุณควรระบุแหล่งที่มาของข้อมูลที่ใช้ในการพัฒนาร่างมาตรฐาน ได้แก่ :

การกระทำเชิงบรรทัดฐานของกฎหมายปัจจุบัน

ข้อบังคับของกระทรวง กรม สมาคม และรัฐวิสาหกิจ

มาตรฐานภายในประเทศและข้อกำหนดทางเทคนิค (การกำหนด)

มาตรฐานต่างประเทศและระหว่างประเทศและเอกสารอื่น ๆ ขององค์กรระหว่างประเทศ (การกำหนดและชื่อ)

รายงานการวิจัยสิทธิบัตร

รายงานผลงานวิจัยและพัฒนาที่เสร็จสมบูรณ์และอื่นๆ

2.16. ในส่วน "ข้อมูลเพิ่มเติม" หากจำเป็น คุณสามารถรวม:

ตัวเลือกสำหรับการแก้ไขปัญหาบางประการและ (หรือ) คำถามส่วนบุคคลเกี่ยวกับร่างมาตรฐานพร้อมคำขอไปยังองค์กร (องค์กร) ที่ส่งร่างมาตรฐานเพื่อตรวจสอบเพื่อแสดงความคิดเห็น

และคำถามอื่นๆ

2.17. ควรนำเสนอคำอธิบายประกอบตามข้อกำหนดที่กำหนดใน GOST 1.5-68 ส่วนที่ 1 สำหรับมาตรฐาน

3. ข้อกำหนดสำหรับการกรอกบันทึกคำอธิบาย

3.1. หมายเหตุอธิบายเกี่ยวกับร่างมาตรฐานควรพิมพ์ตามข้อกำหนดของ GOST 6.38-72*
________________
* เอกสารไม่ถูกต้องในอาณาเขตของสหพันธรัฐรัสเซีย GOST R 6.30-2003 ถูกต้อง - หมายเหตุของผู้ผลิตฐานข้อมูล

3.2. หมายเหตุอธิบายร่างรัฐ อุตสาหกรรม มาตรฐานรีพับลิกันจะต้องลงนามโดยหัวหน้า (รองหัวหน้า) ขององค์กรชั้นนำ (องค์กร) - ผู้พัฒนา หัวหน้าฝ่ายบริการมาตรฐาน หัวหน้าฝ่ายพัฒนา (หัวข้อ) และนักแสดง

หมายเหตุอธิบายร่างมาตรฐานองค์กรจะต้องลงนามโดยหัวหน้าแผนกพัฒนา (แผนก) หัวหน้าฝ่ายพัฒนา (หัวข้อ) และนักแสดง

ลายเซ็นจะอยู่ที่หน้าสุดท้ายของบันทึกอธิบายมาตรฐานฉบับร่าง

3.3. หมายเหตุอธิบายมาตรฐานฉบับร่างต้องมีการกำหนดหมายเลขหน้าเป็นอิสระและไม่มีหน้าปก

ข้อความเอกสารอิเล็กทรอนิกส์
จัดทำโดย Kodeks JSC และตรวจสอบกับ:
สิ่งพิมพ์อย่างเป็นทางการ
ระบบของรัฐ
การทำให้เป็นมาตรฐาน: การรวบรวม GOST -
อ.: สำนักพิมพ์มาตรฐาน, 2526

GOST 1.16-78 GSS หมายเหตุอธิบายร่างมาตรฐาน การก่อสร้าง เนื้อหา การนำเสนอ และการออกแบบ (พร้อมการเปลี่ยนแปลงครั้งที่ 1)

ชื่อเอกสาร: GOST 1.16-78 GSS หมายเหตุอธิบายร่างมาตรฐาน การก่อสร้าง เนื้อหา การนำเสนอ และการออกแบบ (พร้อมการเปลี่ยนแปลงครั้งที่ 1)
หมายเลขเอกสาร: 1.16-78
ประเภทเอกสาร: GOST
อำนาจรับ: มาตรฐานแห่งรัฐของสหภาพโซเวียต
สถานะ: ไม่ได้ใช้งาน
ที่ตีพิมพ์: สิ่งพิมพ์อย่างเป็นทางการ ระบบมาตรฐานของรัฐ: การรวบรวม GOST - อ.: สำนักพิมพ์มาตรฐาน, 2526
วันที่รับ: 30 พฤศจิกายน 2521
วันที่เริ่มต้น: 01 กรกฎาคม 2522
วันหมดอายุ: 01 มกราคม 1987
วันที่แก้ไข: 01 มกราคม 1983

วันนี้เราจะพูดถึงมาตรฐานภายในประเทศสำหรับเอกสารการออกแบบ มาตรฐานเหล่านี้ทำงานอย่างไรในทางปฏิบัติ เหตุใดจึงไม่ดี และเหตุใดจึงดี เมื่อพัฒนาเอกสารสำหรับลูกค้าภาครัฐและเอกชนที่จริงจัง เรามักจะไม่มีทางเลือก - การปฏิบัติตามมาตรฐานจะรวมอยู่ในข้อกำหนดสำหรับการจัดทำเอกสารข้อกำหนดทางเทคนิค ในทางปฏิบัติ ฉันได้พบตัวอย่างต่างๆ มากมายของความเข้าใจผิดเกี่ยวกับโครงสร้างของมาตรฐาน สิ่งที่ควรอยู่ในเอกสาร และเหตุใดจึงจำเป็นต้องใช้เอกสารเหล่านี้ เป็นผลให้ปากกาของนักเขียนด้านเทคนิคนักวิเคราะห์และผู้เชี่ยวชาญบางครั้งผลิตอัญมณีดังกล่าวซึ่งไม่ชัดเจนว่าพวกเขาเขียนในสภาวะจิตสำนึกใด แต่ในความเป็นจริงทุกอย่างค่อนข้างง่าย การค้นหา Habr ไม่ได้ส่งคืนลิงก์ใด ๆ ไปยังเนื้อหาที่สมบูรณ์ไม่มากก็น้อยในหัวข้อนี้ดังนั้นฉันจึงเสนอให้เติมช่องว่างที่น่ารำคาญนี้

มาตรฐานเอกสารคืออะไร?

ในซีรี่ส์ 34 ที่เป็นปัญหา มีเพียง 3 มาตรฐานเอกสารหลักเท่านั้น:

มาตรฐานที่เป็นที่ชื่นชอบและได้รับความนิยมมากที่สุดสำหรับการพัฒนาข้อกำหนดทางเทคนิค สิ่งเดียวที่คุณไม่ควรลืมคือมีความเชื่อมโยงอย่างแน่นหนากับมาตรฐานอื่น ๆ ของซีรีส์ และหากคุณได้รับข้อกำหนดทางเทคนิคที่ทำตามมาตรฐานนี้ ขอแนะนำอย่างยิ่งให้ปฏิบัติตามมาตรฐานอื่น ๆ แม้ว่าจะไม่มีข้อกำหนดโดยตรงสำหรับ นี้. อย่างน้อยก็ในแง่อุดมการณ์ทั่วไป (ประมาณไหนด้านล่าง)

นี่เป็นเอกสารพื้นฐานที่แสดงรายการเอกสาร GOST 34 ทั้งหมด คำแนะนำสำหรับเอกสารการเข้ารหัส ขั้นตอนของโครงการที่เป็นของเอกสาร (ขั้นตอนต่างๆ อธิบายไว้ใน GOST 34.601-90) รวมถึงวิธีการรวมเข้าด้วยกัน กันและกัน.

ที่จริงแล้วมาตรฐานนี้เป็นตารางขนาดใหญ่พร้อมความคิดเห็น สามารถใส่ลงใน Excel ได้เพื่อความสะดวกในการใช้งาน

มาตรฐานมากมายที่อธิบายเนื้อหาของเอกสารโครงการด้วยรายละเอียดที่แตกต่างกัน GOST 34.201-89 ที่กล่าวถึงข้างต้นใช้เป็นดัชนี

มีคำถามและการตีความมากมายเกี่ยวกับมาตรฐาน RD 50-34.698-90 ซึ่งเนื่องจากความคลุมเครือ ลูกค้าและผู้รับเหมา หรือแม้แต่สมาชิกของทีมงานโครงการมักเข้าใจต่างกันออกไป แต่น่าเสียดายที่เราไม่มีอะไรที่เป็นรูปธรรมมากขึ้น

ให้เราพิจารณาข้อดีและข้อเสียของมาตรฐาน โดยเริ่มแรกด้วยข้อเสีย

ข้อเสียของมาตรฐาน

ข้อเสียเปรียบหลักนั้นชัดเจนสำหรับทุกคน - มาตรฐานนั้นเก่า พวกเขามีแนวคิดที่ล้าสมัยเกี่ยวกับสถาปัตยกรรมของระบบอัตโนมัติ ตัวอย่างเช่น:
  • แอปพลิเคชันแบบสองระดับ ประกอบด้วยโปรแกรมไคลเอ็นต์และเซิร์ฟเวอร์ DBMS (ไม่มีแอปพลิเคชัน "ระดับ" สามรายการขึ้นไป ไม่มี Weblogic หรือ JBoss)
  • โครงสร้างของตารางฐานข้อมูลที่อธิบายไว้จะให้แนวคิดเกี่ยวกับโมเดลข้อมูลเชิงตรรกะ (ความจริงที่ว่าอาจมีไฮเบอร์เนตบางประเภทระหว่างแอปพลิเคชันและฐานข้อมูลดูเหมือนจะมีส่วนเกินที่ไม่ดี)
  • ส่วนต่อประสานกับผู้ใช้เป็นแบบหน้าต่างเดียว (มีอะไรอีกไหม “เบราว์เซอร์” คืออะไร?)
  • มีรายงานไม่กี่ฉบับในระบบ ซึ่งทั้งหมดเป็นกระดาษและพิมพ์บนเครื่องพิมพ์ดอทเมทริกซ์
  • โปรแกรมที่กำลังพัฒนามุ่งเน้นไปที่การแก้ปัญหา "ปัญหาการประมวลผลข้อมูล" ซึ่งมีอินพุตและเอาท์พุตที่ชัดเจนและมีความเชี่ยวชาญสูง การประมวลผลข้อมูลจะขึ้นอยู่กับ "อัลกอริทึม" บางครั้งก็มี "อัลกอริทึม" หลายประการ (การเขียนโปรแกรมเชิงวัตถุเป็นเพียงการเริ่มต้นขั้นตอนแรกและไม่ได้รับการพิจารณาอย่างจริงจัง)
  • ผู้ดูแลระบบฐานข้อมูลเข้าใจว่าข้อมูลใดอยู่ในตารางและมีส่วนร่วมในการแก้ไขไดเร็กทอรีระบบ (มีเซิร์ฟเวอร์ DBMS หนึ่งเซิร์ฟเวอร์สำหรับ 50 แอปพลิเคชันที่แตกต่างกันจริง ๆ หรือไม่)
ดังนั้น มาตรฐานจึงมีอาร์ติแฟกต์ดังต่อไปนี้:

5.8. การเขียนแบบแบบฟอร์มเอกสาร (กรอบวีดีโอ)
เอกสารจะต้องมีรูปภาพของรูปแบบของเอกสารหรือกรอบวิดีโอตามข้อกำหนดของมาตรฐานของรัฐของระบบเอกสารรวม R 50-77 และคำอธิบายที่จำเป็น

ประเด็นของเอกสารคือองค์กรโซเวียตใช้สิ่งที่เรียกว่า "พื้นที่การพิมพ์" ซึ่งมีเครื่องพิมพ์เมทริกซ์ความเร็วสูง ซึ่งไดรเวอร์ที่วิศวกรมักเขียนเอง ดังนั้นพวกเขาจึงต้องรักษาทะเบียนเอกสารทั้งหมดที่จำเป็นในการพิมพ์เพื่อให้แน่ใจว่าเอกสารจะดูอย่างที่ควรจะเป็นเมื่อพิมพ์

“เฟรมวิดีโอ” ยังเป็นเอกสารที่แสดงบนการแสดงข้อความ จอแสดงผลไม่รองรับอักขระที่จำเป็นและจำนวนอักขระแนวนอนและเส้นแนวตั้งที่ต้องการเสมอไป (และไม่รองรับกราฟิกเลย) ดังนั้นที่นี่จึงจำเป็นต้องประสานแบบฟอร์มของเอกสารหน้าจอทั้งหมดเพิ่มเติมด้วย

ตอนนี้คำว่า "แมชชีนแกรม", "เฟรมวิดีโอ", "ADC" ไม่ได้บอกอะไรเราอีกต่อไป ฉันไม่พบมันใช้งานเลยแม้ว่าฉันจะสำเร็จการศึกษาจากสถาบันเฉพาะทางในช่วงทศวรรษ 90 ก็ตาม นี่เป็นช่วงเวลาของการปรากฏตัวของ Windows 3.1, จอแสดงผล VGA, ฟล็อปปี้ดิสก์ขนาด 3 นิ้วและเว็บไซต์อินเทอร์เน็ตในประเทศแห่งแรก แต่คำเหล่านี้อยู่ในมาตรฐานและบางครั้งลูกค้าก็เรียกร้องให้เราจัดเตรียมเอกสารชุดสมบูรณ์ให้เขาตาม GOST 34.201-89 ยิ่งกว่านั้น ถ้อยคำดังกล่าวใน ToR ย้ายจากกระทรวงหนึ่งไปยังอีกกระทรวงหนึ่ง และกลายเป็นเทมเพลตที่ไม่ได้พูดซึ่งเนื้อหาถูกแทรกเข้าไป

ดังนั้นเอกสารที่มีชื่อโง่ ๆ ว่า "การวาดแบบฟอร์มเอกสาร (เฟรมวิดีโอ)" ในโครงการจึงควรและไม่ควรว่างเปล่า

มีอะไรดีอยู่ในมาตรฐาน

มาตรฐานใดๆ ก็ตามที่ดีคือช่วยให้ลูกค้าและผู้รับเหมาสามารถพูดภาษาเดียวกันได้ และรับประกันว่า อย่างน้อย ลูกค้าจะไม่มีการร้องเรียนใดๆ "ในรูปแบบ" ต่อผลลัพธ์ที่ส่ง

และมาตรฐาน GOST 34 ก็ดีเช่นกันเพราะรวบรวมโดยคนฉลาดผ่านการทดสอบมาหลายปีและมีเป้าหมายที่ชัดเจน - เพื่ออธิบายบนกระดาษให้ครบถ้วนที่สุดเกี่ยวกับสาระสำคัญเชิงนามธรรมที่ซับซ้อนซึ่งระบบควบคุมอัตโนมัติเป็นตัวแทน

เมื่อคุณต้องการกำหนดงานอย่างมีประสิทธิภาพให้กับผู้รับเหมาชาวตะวันตกที่ไม่เคยได้ยินเกี่ยวกับมาตรฐาน GOST ของเรา คุณสามารถพึ่งพามาตรฐานเหล่านี้หรือพึ่งพาเนื้อหาและองค์ประกอบทางความหมายได้ เพราะขอย้ำอีกครั้งว่าการรับประกันความครบถ้วนของข้อมูลนั้นคุ้มค่ามาก ไม่ว่าเราจะยกย่องตนเองด้วยความเป็นมืออาชีพในระดับสูงเพียงใด เราอาจลืมที่จะรวมสิ่งพื้นฐานไว้ในข้อกำหนดของเรา ในขณะที่ GOST 34.602-89 เดียวกันนั้น "จดจำ" ทุกอย่าง หากคุณไม่ชัดเจนว่าผลงานของผู้รับเหมาชาวตะวันตกควรเป็นอย่างไร ให้ดูข้อกำหนดด้านเอกสารและส่วนที่แนะนำ ฉันรับรองกับคุณว่าอย่าคิดเลยจะดีกว่า! เป็นไปได้มากว่าจะมีมาตรฐานแบบอะนาล็อกแบบตะวันตกซึ่งทุกสิ่งจะสมบูรณ์ยิ่งขึ้นทันสมัยยิ่งขึ้นและดีขึ้น น่าเสียดายที่ฉันไม่คุ้นเคยกับพวกเขาเนื่องจากยังไม่มีกรณีใดที่มาตรฐาน GOST ของเราไม่เพียงพอ

คุณสามารถหัวเราะกับความจริงที่ว่าผู้สร้างมาตรฐานไม่รู้อะไรเลยเกี่ยวกับ java หรือ .NET เกี่ยวกับจอภาพ HD และอินเทอร์เน็ต แต่ฉันจะไม่แนะนำให้ดูถูกดูแคลนขนาดของงานที่พวกเขาทำและคุณค่าของงานที่มีต่อชุมชนมืออาชีพของเรา

วิธีอ่านและทำความเข้าใจมาตรฐานเอกสารตามมาตรฐาน GOST series 34

มาตรฐานแบ่งเอกสารทั้งหมดออกเป็นสองแกน - เวลาและสาขาวิชา หากคุณดูตารางที่ 2 ใน GOST 34.201-89 คุณจะเห็นส่วนนี้อย่างชัดเจน (คอลัมน์ "ขั้นตอนการสร้าง" และ "ส่วนหนึ่งของโครงการ"
ขั้นตอนของการสร้างระบบควบคุมอัตโนมัติ
ขั้นตอนของการสร้างสรรค์กำหนดไว้ใน GOST 34.601-90 สามข้อเกี่ยวข้องกับเอกสาร:
  • การออกแบบร่าง (ED)
  • การออกแบบทางเทคนิค (TP)
  • การพัฒนาเอกสารการทำงาน (DD)
การออกแบบร่างติดตามหลังจากขั้นตอนข้อกำหนดทางเทคนิคและทำหน้าที่พัฒนาโซลูชันการออกแบบเบื้องต้น

โครงการด้านเทคนิคอธิบายระบบแห่งอนาคตจากทุกมุม หลังจากอ่านแล้ว เอกสารในขั้นตอน TP ควรทิ้งความชัดเจนอย่างสมบูรณ์ในแนวทาง วิธีการ โซลูชันทางสถาปัตยกรรมและทางเทคนิคที่เสนอไว้ ในระยะต่อไป มันจะสายเกินไปที่จะอธิบายแนวทางและหาเหตุผลในการแก้ปัญหาทางเทคนิค ดังนั้นระยะ P จึงเป็นกุญแจสำคัญในการบรรลุผลสำเร็จของงาน เนื่องจากข้อกำหนดที่หลากหลายทั้งหมดของข้อกำหนดทางเทคนิคจะต้องสะท้อนให้เห็นในเอกสารของระยะ P . ที่เฟส P ระบบอาจไม่มีอยู่เลย

เอกสารการทำงานออกแบบมาเพื่อการใช้งาน การทดสอบการใช้งาน และการดำเนินการต่อไปของระบบใหม่ให้ประสบความสำเร็จ เอกสารเหล่านี้เป็นเอกสารที่มีข้อมูลเฉพาะเจาะจงมากซึ่งอธิบายถึงสิ่งที่มีอยู่ทางกายภาพ ตรงกันข้ามกับระยะ P ซึ่งอธิบายถึงความงดงามในอนาคต

ส่วน (ส่วน) ของเอกสารโครงการสำหรับการสร้างระบบควบคุมอัตโนมัติ
สาขาวิชาแบ่งออกเป็น “บทบัญญัติ” ในตอนแรกดูเหมือนว่าการแบ่งแยกดังกล่าวจะซ้ำซ้อนและไม่จำเป็น แต่เมื่อคุณเริ่มทำงานกับชุดเครื่องมือนี้ในทางปฏิบัติ อุดมการณ์ที่ฝังอยู่ในชุดเครื่องมือนี้จะค่อยๆ ชัดเจนขึ้น

ระบบอัตโนมัติตามที่กำหนดโดยคอมไพเลอร์ของ GOST คือการผสมผสานระหว่างฮาร์ดแวร์ ซอฟต์แวร์ และช่องทางการสื่อสารที่ประมวลผลข้อมูลที่มาจากแหล่งต่างๆ ตามอัลกอริธึมบางอย่าง และสร้างผลลัพธ์การประมวลผลในรูปแบบของเอกสาร โครงสร้างข้อมูล หรือการดำเนินการควบคุม โมเดลดั้งเดิมของปืนกลที่ง่ายที่สุด

เพื่ออธิบาย "เครื่องจักร" นี้โดยสมบูรณ์ จึงได้มีการจัดทำส่วนต่อไปนี้ (ตามรูปวาด):

ซอฟต์แวร์ (MS)ตอบคำถาม: ตรรกะอะไรเดินสายอยู่ภายใน “กล่องดำ”? เหตุใดอัลกอริธึมเฉพาะเหล่านี้ สูตรเฉพาะเหล่านี้ และค่าสัมประสิทธิ์เฉพาะเหล่านี้จึงถูกเลือก

ซอฟต์แวร์ทางคณิตศาสตร์ไม่รู้อะไรเลยเกี่ยวกับโปรเซสเซอร์หรือฐานข้อมูล นี่เป็นพื้นที่นามธรรมที่แยกจากกัน ซึ่งเป็นที่พำนักของ "ม้าทรงกลมในสุญญากาศ" แต่ซอฟต์แวร์ทางคณิตศาสตร์มีความเกี่ยวข้องอย่างใกล้ชิดกับสาขาวิชาหรือที่เรียกว่าชีวิตจริง ตัวอย่างเช่น อัลกอริธึมการควบคุมสำหรับระบบควบคุมการจราจรจะต้องได้รับการอนุมัติจากสำนักงานตรวจความปลอดภัยการจราจรของรัฐ ก่อนที่จะได้รับการอนุมัติจากลูกค้า แล้วคุณจะเข้าใจว่าทำไมจึงรวมไว้ในหนังสือเล่มอื่น เพราะไม่มีใครในตำรวจจราจรสนใจว่าแอปพลิเคชันเซิร์ฟเวอร์จะทำงานบน OS ใด แต่ป้ายและการจำกัดความเร็วจะปรากฏขึ้นบนกระดานท่ามกลางสายฝนหรือหิมะนั้นน่าสนใจมาก พวกเขาต้องรับผิดชอบในส่วนของตนและจะไม่ลงนามในสิ่งอื่นใดอีก ในทางกลับกัน เมื่อพวกเขาเซ็นสัญญา จะไม่มีคำถามเกี่ยวกับด้านเทคนิคของปัญหา - เหตุใดพวกเขาจึงเลือกบอร์ดเหล่านั้น ไม่ใช่บอร์ดหรือสัญญาณไฟจราจรอื่นๆ ภูมิปัญญาของ "บรรพบุรุษ" ปรากฏให้เห็นอย่างชัดเจนในกรณีที่ใช้งานได้จริงเช่นนี้

การสนับสนุนข้อมูล (IS)- อีกส่วนหนึ่งของระบบ คราวนี้กล่องดำของระบบของเราถูกทำให้โปร่งใส และเราดูข้อมูลที่หมุนเวียนอยู่ในนั้น ลองจินตนาการถึงแบบจำลองของระบบไหลเวียนโลหิตของมนุษย์เมื่ออวัยวะอื่นๆ ทั้งหมดมองไม่เห็น บางอย่างเช่นนี้คือการสนับสนุนข้อมูล โดยจะอธิบายองค์ประกอบและเส้นทางของการไหลของข้อมูลภายในและภายนอก การจัดระเบียบข้อมูลในระบบแบบลอจิคัล คำอธิบายของหนังสืออ้างอิงและระบบการเข้ารหัส (ผู้ที่สร้างโปรแกรมสำหรับการผลิตจะรู้ว่าสิ่งเหล่านี้มีความสำคัญเพียงใด) ส่วนที่อธิบายหลักอยู่ในระยะ TP แต่ "พื้นฐาน" บางส่วนไหลเข้าสู่ระยะ RD เช่นเอกสาร "แค็ตตาล็อกฐานข้อมูล" เป็นที่ชัดเจนว่าก่อนหน้านี้มีสิ่งที่เขียนไว้ในชื่อเรื่องทุกประการ แต่วันนี้พยายามสร้างเอกสารดังกล่าวสำหรับระบบที่ซับซ้อนซึ่งบ่อยครั้งที่ระบบใช้ระบบย่อยที่ซื้อมาพร้อมกับที่จัดเก็บข้อมูลลึกลับของตัวเอง ฉันไม่ได้บอกว่าเอกสารนี้ไม่จำเป็นอย่างยิ่งในตอนนี้

หรือนี่คือ “คำชี้แจงเกี่ยวกับสื่อบันทึกข้อมูลคอมพิวเตอร์” เห็นได้ชัดว่าก่อนหน้านี้มีดรัมแม่เหล็กหรือม้วนฟิล์มจำนวนหนึ่ง ตอนนี้ฉันควรใส่อะไรลงไป?

กล่าวโดยสรุป ในระยะ RD เอกสารสนับสนุนข้อมูลแสดงถึงพื้นฐานที่ค่อนข้างเป็นอันตราย เนื่องจากควรมีอยู่อย่างเป็นทางการ แต่ไม่มีอะไรพิเศษที่จะกรอก

ซอฟต์แวร์- ส่วนเอกสารโครงการที่ทุกคนชื่นชอบ ใช่ ถ้าเพียงเพราะมันเป็นเพียงเอกสารเดียว! จากนั้นทุกคนก็เข้าใจถึงสิ่งที่ต้องเขียนลงไป แต่ฉันจะทำซ้ำมันต่อไป

ในเอกสารนี้ เราต้องแจ้งให้คุณทราบด้วยความช่วยเหลือว่าซอฟต์แวร์ใดที่อัลกอริทึมที่อธิบายไว้ใน ML ถูกดำเนินการ โดยประมวลผลข้อมูลที่อธิบายไว้ใน IR นั่นคือไม่จำเป็นต้องคัดลอกข้อมูลจากส่วนอื่นที่นี่ ในที่นี้จะมีการให้สถาปัตยกรรมของระบบ เหตุผลสำหรับเทคโนโลยีซอฟต์แวร์ที่เลือก คำอธิบาย (สิ่งต่าง ๆ ของระบบ: ภาษาการเขียนโปรแกรม กรอบงาน ระบบปฏิบัติการ ฯลฯ ) นอกจากนี้ในเอกสารนี้ เรายังอธิบายวิธีการจัดระเบียบเครื่องมือประมวลผลข้อมูล (คิวข้อความ พื้นที่เก็บข้อมูล เครื่องมือสำรองข้อมูล โซลูชันความพร้อมใช้งาน กลุ่มแอปพลิเคชันทุกประเภท ฯลฯ) มาตรฐานประกอบด้วยคำอธิบายโดยละเอียดเกี่ยวกับเนื้อหาของเอกสารนี้ ซึ่งผู้เชี่ยวชาญทุกคนจะเข้าใจ

การสนับสนุนด้านเทคนิค (ถึง)- ไม่มีส่วนที่เป็นที่รักของเอกสารประกอบโครงการ ภาพสีดอกกุหลาบถูกบดบังด้วยเอกสารจำนวนมากที่ต้องพัฒนาเท่านั้น โดยรวมแล้ว มาตรฐานกำหนดให้ต้องมีการพัฒนาเอกสาร 22 ฉบับ โดย 9 ฉบับอยู่ในขั้นตอน TC

ความจริงก็คือมาตรฐานนี้ให้คำอธิบายเกี่ยวกับการสนับสนุนทางเทคนิคทั้งหมด รวมถึงฮาร์ดแวร์และเครือข่ายคอมพิวเตอร์ ระบบวิศวกรรม และแม้แต่ชิ้นส่วนการก่อสร้าง (หากจำเป็น) และเศรษฐกิจนี้ถูกควบคุมโดยมาตรฐานและกฎระเบียบจำนวนมากที่ประสานงานในองค์กรต่าง ๆ ดังนั้นจึงสะดวกกว่าที่จะแยกทุกอย่างออกเป็นส่วน ๆ และประสานงาน (แก้ไข) เป็นส่วน ๆ ในเวลาเดียวกัน มาตรฐานช่วยให้คุณสามารถรวมเอกสารบางฉบับเข้าด้วยกันได้ ซึ่งเหมาะสมหากเอกสารทั้งหมดได้รับการอนุมัติโดยบุคคลเดียว

อย่าลืมด้วยว่าชุดมาตรฐานคุณภาพหมายถึงการบันทึกและการจัดเก็บเอกสารทางเทคนิค และ "หนังสือ" ของเราจากลูกค้าอาจถูกแจกจ่ายไปยังคลังข้อมูลต่างๆ ขึ้นอยู่กับหัวข้อของคำอธิบาย นี่เป็นอีกข้อโต้แย้งที่สนับสนุนการแยกส่วนเอกสาร

การสนับสนุนองค์กร (OO)- หลังจากระงับความปรารถนาซึ่งเป็นเรื่องปกติสำหรับช่างเทคนิคแล้ว ที่จะข้ามส่วนนี้โดยเร็วที่สุด ในทางกลับกัน ฉันจะพิจารณารายละเอียดเพิ่มเติม เนื่องจากเพื่อนร่วมงานเมื่อเร็ว ๆ นี้มีแนวโน้มที่ไม่ดีในโครงการที่ต้องการความชัดเจนในส่วนนี้

ในขั้นตอน TP ส่วนนี้มีเพียงเอกสารเดียวเท่านั้น “ คำอธิบายโครงสร้างองค์กร"โดยเราต้องบอกลูกค้าว่าเขาควรเตรียมอะไรบ้างในแง่ของการเปลี่ยนแปลงโครงสร้างองค์กร ทันใดนั้นคุณต้องจัดระเบียบแผนกใหม่เพื่อดำเนินการระบบของคุณ แนะนำตำแหน่งใหม่ ฯลฯ

ในขั้นตอน RD มีเอกสารอื่นที่น่าสนใจกว่าปรากฏขึ้น ซึ่งฉันต้องการพิจารณาแยกกัน

คู่มือการใช้งาน- ฉันคิดว่าความคิดเห็นไม่จำเป็น

ระเบียบวิธี (เทคโนโลยี) ของการออกแบบโดยใช้คอมพิวเตอร์ช่วย- หากจำเป็น เอกสารนี้สามารถประกอบด้วยคำอธิบายกระบวนการสร้างซอฟต์แวร์ การควบคุมเวอร์ชัน การทดสอบ ฯลฯ แต่ในกรณีนี้หากลูกค้าในข้อกำหนดทางเทคนิคต้องการประกอบซอฟต์แวร์เป็นการส่วนตัว หากเขาไม่ต้องการสิ่งนี้ (และไม่จ่ายเงิน) ห้องครัวภายในทั้งหมดของคุณก็ไม่ใช่ธุระของเขา และเอกสารนี้ก็ไม่จำเป็นต้องทำ

คำแนะนำทางเทคโนโลยี- เนื่องจากแฟชั่นสำหรับกระบวนการทางธุรกิจที่เป็นทางการ บางครั้งลูกค้าเจ้าเล่ห์จึงพยายามใส่กฎระเบียบในการปฏิบัติงานลงในเอกสารนี้ ดังนั้นคุณไม่ควรทำเช่นนี้ไม่ว่าในกรณีใด

คำอธิบายกระบวนการทางธุรกิจ บทบาทและลักษณะงาน ระเบียบการทำงาน - ทั้งหมดนี้คือ ORD นั่นคือเอกสารขององค์กรและการบริหาร ซึ่งเป็นผลงานของโครงการให้คำปรึกษาซึ่งเท่าที่ฉันเข้าใจไม่ได้ซื้อจากคุณ และเราซื้อโครงการด้านเทคนิคจากคุณและเอกสารทางเทคนิคด้วย

คำแนะนำทางเทคโนโลยีเป็นชั้นระหว่างคู่มือการใช้งานและคู่มือผู้ใช้ RP อธิบายอย่างละเอียด ยังไงคุณต้องดำเนินการบางอย่างในระบบ การเรียนการสอนทางเทคโนโลยีบอกว่า ที่จะต้องดำเนินการในบางกรณีที่เกี่ยวข้องกับการทำงานของระบบ โดยคร่าวแล้ว การสอนทางเทคโนโลยีเป็นเพียงการสรุปสั้นๆ ของ RP สำหรับตำแหน่งหรือบทบาทที่เฉพาะเจาะจง หากลูกค้าไม่มีการกำหนดบทบาทหรือต้องการให้คุณสร้างบทบาทและข้อกำหนดของงานด้วยตนเอง ให้รวมบทบาทพื้นฐานที่สุดในเอกสาร เช่น ผู้ปฏิบัติงาน ผู้ปฏิบัติงานอาวุโส ผู้ดูแลระบบ ความคิดเห็นของลูกค้าในหัวข้อ “แต่เราไม่ชอบ” หรือ “เราไม่ชอบ” ควรมีรายการบทบาทและคำอธิบายความรับผิดชอบในงานด้วย เพราะกระบวนการทางธุรกิจของเรา เราไม่ใส่มัน- เราคือกระบวนการทางธุรกิจเหล่านี้ อัตโนมัติ.

ฉันจะเขียนเกี่ยวกับคราดที่อธิบายแยกกันพร้อมตัวอย่างที่มีสีสัน เนื่องจากนี่ไม่ใช่ครั้งแรกที่มีการทำซ้ำในภาคส่วนต่างๆ ของ "เศรษฐกิจของประเทศ"

คำอธิบายของกระบวนการทางเทคโนโลยีของการประมวลผลข้อมูล (รวมถึงการประมวลผลทางไกล)- มรดกตกทอดที่น่าสมเพชแห่งยุคถ้ำ เมื่อมี "เจ้าหน้าที่คอมพิวเตอร์" ที่ได้รับการแต่งตั้งเป็นพิเศษ โดยป้อนบัตรเจาะเข้าเครื่องและบรรจุผลการพิมพ์ลงในซองจดหมาย คำแนะนำนี้มีไว้สำหรับพวกเขา ฉันไม่สามารถบอกคุณได้อย่างแน่ชัดว่าจะเขียนอะไรในศตวรรษที่ 21 ออกไปเอง สิ่งที่ดีที่สุดคือลืมเอกสารนี้ไปซะ

โซลูชันทั้งระบบ (WSO)- มาตรฐานนี้จัดทำเอกสาร 17 ฉบับในส่วน OP ประการแรก นี่เป็นเอกสารเกือบทั้งหมดของขั้นตอนเบื้องต้นของการออกแบบแผนผัง ประการที่สอง สิ่งเหล่านี้คือการประมาณ การคำนวณ และคำอธิบายโดยย่อของฟังก์ชันอัตโนมัติทุกประเภท นั่นคือข้อมูลสำหรับผู้ที่ไม่ได้มาจากการผลิตไอทีหลัก แต่สำหรับเจ้าหน้าที่สนับสนุน - ผู้จัดการ, นักประมาณการ, ผู้เชี่ยวชาญด้านการจัดซื้อ, นักเศรษฐศาสตร์ ฯลฯ

และประการที่สาม OP มีเอกสารขนาดใหญ่ที่เรียกว่า "คำอธิบายสำหรับโครงการทางเทคนิค" ซึ่งมีวัตถุประสงค์เพื่อเป็นบทสรุปผู้บริหาร แต่ในความเป็นจริงแล้ว นักออกแบบหลายคนใส่เนื้อหาที่เป็นประโยชน์ทั้งหมดของขั้นตอน TP ลงไป วิธีการที่รุนแรงดังกล่าวสามารถให้เหตุผลและเป็นประโยชน์ร่วมกันสำหรับทั้งลูกค้าและผู้รับเหมา แต่ในบางกรณี

ตัวเลือกสำหรับการใช้ GOST 34

  1. ยึดมั่นในมาตรฐานอย่างสมบูรณ์และแม่นยำ- โดยธรรมชาติแล้วจะไม่มีใครเขียนเอกสารจำนวนมากเช่นนี้โดยสมัครใจ ดังนั้นเอกสารทั้งชุดจึงถูกจัดเตรียมตามคำขอเร่งด่วนของลูกค้าเท่านั้น ซึ่งเขาระบุไว้ในข้อกำหนดทางเทคนิคและยังปักหมุดข้อตกลงไว้ด้านบนอีกด้วย ในกรณีนี้ คุณต้องทำทุกอย่างตามตัวอักษรและมอบ "หนังสือ" ทางกายภาพให้กับลูกค้าซึ่งจะเป็นชื่อของเอกสารจากตารางที่ 2 ของ GOST 34.201-89 ยกเว้นรายการที่คุณไม่จำเป็นโดยสิ้นเชิง จะต้องหารือและมีความปลอดภัยเป็นลายลักษณ์อักษร เนื้อหาของเอกสารจะต้องเป็นไปตาม RD 50-34.698-90 ไปจนถึงชื่อของส่วนต่างๆ โดยไม่ต้องจินตนาการใดๆ เพื่อให้สมองของลูกค้าระเบิด บางครั้งระบบขนาดใหญ่จะถูกแบ่งออกเป็นระบบย่อย และมีการออกเอกสารการออกแบบแยกต่างหากสำหรับแต่ละระบบย่อย มันดูน่ากลัวและไม่อยู่ภายใต้การควบคุมตามปกติด้วยความช่วยเหลือจากจิตใจของโลก โดยเฉพาะเรื่องการบูรณาการระบบย่อย ซึ่งช่วยลดความยุ่งยากในการยอมรับอย่างมาก สิ่งสำคัญคือคุณเองอย่าสับสนและระบบของคุณยังคงทำงานอย่างที่ควรจะเป็น
  2. เราแค่รักมาตรฐาน GOST- บริษัทใหญ่ที่จริงจังรักมาตรฐาน เพราะพวกเขาช่วยให้ผู้คนเข้าใจกันดีขึ้น หากลูกค้าของคุณมีชื่อเสียงในเรื่องความรักในความเป็นระเบียบเรียบร้อยและการสร้างมาตรฐาน พยายามยึดมั่นในอุดมการณ์ GOST มาตรฐานเมื่อพัฒนาเอกสาร แม้ว่าข้อกำหนดทางเทคนิคจะไม่จำเป็นก็ตาม คุณจะเข้าใจและอนุมัติได้ดีขึ้นโดยผู้เชี่ยวชาญที่ได้รับอนุมัติ และคุณเองจะไม่ลืมที่จะรวมข้อมูลสำคัญไว้ในเอกสาร คุณจะเห็นโครงสร้างเป้าหมายของเอกสารได้ดีขึ้น วางแผนงานเขียนได้แม่นยำยิ่งขึ้น และช่วยตัวเองและ เพื่อนร่วมงานของคุณมีความกังวลและเงินมากมาย
  3. เราไม่สนใจเรื่องเอกสารตราบใดที่ทุกอย่างยังใช้งานได้- รูปลักษณ์ที่หายไปของลูกค้าที่ไม่รับผิดชอบ มุมมองที่คล้ายกันของเอกสารยังคงสามารถพบได้ในหมู่ลูกค้ารายย่อยและยากจนเช่นเดียวกับใน "คนโง่เง่า" เผด็จการที่หลงเหลือมาจากสมัยเปเรสทรอยกาซึ่งเจ้านายถูกรายล้อมไปด้วยเพื่อนที่ภักดี - ผู้อำนวยการและปัญหาทั้งหมดได้รับการแก้ไขในการสนทนาส่วนตัว . ในเงื่อนไขดังกล่าวคุณมีอิสระที่จะละเลยเอกสารทั้งหมด แต่จะดีกว่าที่จะไม่ล้มสายตาและอย่างน้อยก็กรอกเอกสารพร้อมเนื้อหาตามแผนผัง ถ้าไม่ใช่ลูกค้ารายนี้ก็ส่งต่อ(ขาย)ให้รายต่อไป

บทสรุป

บทความนี้เกี่ยวกับมาตรฐาน GOST ของเราสำหรับการจัดทำเอกสารระบบควบคุมอัตโนมัติ GOST นั้นเก่า แต่ปรากฎว่าพวกมันยังคงมีประโยชน์มากในครัวเรือน นอกเหนือจากพื้นฐานที่ชัดเจนบางประการแล้ว โครงสร้างของเอกสารยังมีคุณสมบัติครบถ้วนและสม่ำเสมอ และการยึดมั่นในมาตรฐานช่วยลดความเสี่ยงของโครงการมากมาย ซึ่งเราอาจไม่ทราบถึงการมีอยู่ในตอนแรก

ฉันหวังว่าเนื้อหาที่นำเสนอจะเป็นประโยชน์กับคุณหรืออย่างน้อยก็น่าสนใจ แม้จะมีความน่าเบื่ออย่างเห็นได้ชัด แต่งานเอกสารก็เป็นงานที่สำคัญและมีความรับผิดชอบ ซึ่งความถูกต้องแม่นยำมีความสำคัญพอๆ กับการเขียนโค้ดที่ดี เขียนเอกสารดีๆนะเพื่อนร่วมงาน! และสัปดาห์หน้าฉันจะเดินทางไปทำธุรกิจสองครั้งติดต่อกัน ดังนั้นฉันจึงไม่สามารถรับประกันได้ว่าจะมีการตีพิมพ์เนื้อหาใหม่ (ฉันไม่มีแคช ฉันเขียนจากในหัว)

ข้อความอธิบายสำหรับโครงการด้านเทคนิค

วัตถุประสงค์หลักของการสร้างระบบสารสนเทศคือการเร่ง "กระบวนการขาย" ตลอดจนเพิ่มประสิทธิภาพของพนักงาน เพื่อให้มั่นใจถึงการทำงานของระบบ จะต้องติดตั้งซอฟต์แวร์ต่อไปนี้บนคอมพิวเตอร์ที่ใช้งาน:

  • - ระบบปฏิบัติการตระกูล Windows;
  • - 1C: องค์กร 8;

ข้อมูลใหม่จะถูกป้อนเข้าสู่ระบบก่อนเริ่มงาน ซึ่งจำเป็นสำหรับการป้อนยอดคงเหลือเริ่มต้น เพื่อจำกัดการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต ระบบจะใช้การอนุญาตเมื่อเข้าสู่โปรแกรม หากป้อนรหัสผ่านไม่ถูกต้องระบบจะแสดงข้อความและไม่อนุญาตให้คุณเชื่อมต่อกับฐานข้อมูล

ระบบดำเนินงานหลักสามประการ:

  • - การบำรุงรักษาไดเร็กทอรี;
  • - การบำรุงรักษาคลังสินค้า
  • - การลงทะเบียนการขาย
  • - การส่งออกรายงาน

แอปพลิเคชัน DB สำหรับ IS ได้รับการพัฒนาโดยใช้สภาพแวดล้อมซอฟต์แวร์ 1C: Enterprise 8 คอมพิวเตอร์ส่วนบุคคลที่มีให้สำหรับผู้ประกอบการแต่ละรายที่ระบบกำลังได้รับการพัฒนานั้นใช้เพื่อโฮสต์ระบบ

โครงการ ใช้งานได้ โครงสร้าง

ข้อกำหนดทั่วไปสำหรับการทำงานของระบบที่ออกแบบนั้นแสดงไว้โดยใช้แผนภาพ VI ในรูปที่ 1

ตาราง -2 ส่วนหลักของสคริปต์การดำเนินการ VI “เพิ่มข้อมูลไดเรกทอรี”

แก้ไขข้อมูลไดเร็กทอรี

เจ้าของร้าน ผู้ประกอบการรายบุคคล

ดูแลรักษาข้อมูลที่ทันสมัยเกี่ยวกับวัตถุในสาขาวิชา

คำอธิบายสั้น ๆ

ผู้ใช้เพิ่มรายการไดเร็กทอรีใหม่และจดบันทึกไว้ ระบบจะบันทึกข้อมูลที่เปลี่ยนแปลงลงในฐานข้อมูล

เงื่อนไขเบื้องต้น

  • 1. ผู้ใช้ที่ได้รับอนุญาตในระบบ
  • 2. ผู้ใช้มีสิทธิ์ในการเพิ่มข้อมูลลงในไดเร็กทอรี

ภาวะภายหลัง

  • 1. องค์ประกอบไดเร็กทอรีถูกเขียนลงในฐานข้อมูล
  • 2. รายการไดเร็กทอรีจะแสดงในรูปแบบของรายการไดเร็กทอรี

ตาราง -3 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการ VI “เพิ่มข้อมูลไดเรกทอรี”

ตารางที่ -4 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการ VI “เพิ่มข้อมูลไดเรกทอรี”

ตารางที่ -5 ส่วนหลักของสถานการณ์การดำเนินการ VI “กำหนดราคาสินค้า”

ตาราง - 6 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์จำลองการดำเนินการ VI “กำหนดราคาสินค้า”

ตารางที่ -7 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการ VI “กำหนดราคาสินค้า”

ตารางที่ -8 ส่วนหลักของสถานการณ์การดำเนินการ VI “ลงทะเบียนการรับสินค้า”

ตาราง -9 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการของ VI "ลงทะเบียนการรับสินค้า"

การกระทำของนักแสดง

การตอบสนองของระบบ

1. เจ้าของร้านดำเนินการคำสั่งเพื่อสร้างเอกสารใหม่ “การรับสินค้า”

2. ระบบแสดงแบบฟอร์มเอกสาร

3. เจ้าของร้านกรอกรายละเอียดส่วนหัว

ข้อยกเว้นหมายเลข 1: เจ้าของร้านกรอกข้อมูลในช่องตัวเลขด้วยตนเอง

4. เจ้าของร้านเพิ่มแถวใหม่ในส่วนตารางในหน้าสินค้า

5. ระบบจะแสดงบรรทัดใหม่

6. เจ้าของร้านกรอกคอลัมน์ระบบการตั้งชื่อ

7. ระบบจะทดแทนค่าคอลัมน์

8. เจ้าของร้านกรอกข้อมูลลงในคอลัมน์ปริมาณ

9. ระบบจะคำนวณค่าของคอลัมน์จำนวน

10. ระบบจะแสดงค่ารวมของคอลัมน์ Total ในส่วนท้ายของส่วนตาราง

11. เจ้าของร้านเข้าสู่ผลิตภัณฑ์ใหม่ (กลับไปที่ขั้นตอนที่ 4) หรือดำเนินการคำสั่ง Write

ข้อยกเว้น #2: ค่าของฟิลด์ Number ไม่ซ้ำกัน

12. ระบบบันทึกเอกสาร “การรับสินค้า” ใหม่ในฐานข้อมูล

13. เจ้าของร้านดำเนินการคำสั่งพิมพ์ -

14. ระบบแสดงแบบฟอร์มใบสั่งใบเสร็จที่พิมพ์เสร็จแล้ว

15. เจ้าของร้านดำเนินการคำสั่งพิมพ์

16. ระบบพิมพ์ใบรับสินค้า

17. เจ้าของร้านดำเนินการคำสั่งปิดแบบฟอร์มการพิมพ์

18. ระบบปิดแบบฟอร์มการพิมพ์

19. เจ้าของร้านดำเนินการตามคำสั่ง ปิดเอกสาร “การรับสินค้า”

20. ระบบปิดแบบฟอร์มเอกสาร “การรับสินค้า”

ตารางที่ -10 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการ VI “ลงทะเบียนการรับสินค้า”

ค่าของผลรวมและคอลัมน์ทั้งหมดคำนวณโดยใช้สูตร:

จำนวน = จำนวน * ราคา

ตารางที่ -11 ส่วนของสถานการณ์การดำเนินการ VI "การสร้างยอดขาย"

ตารางที่ -12 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการของ VI "การสร้างยอดขาย"

การกระทำของนักแสดง

การตอบสนองของระบบ

การชำระเงินสำหรับเอกสาร "การขาย" หนึ่งฉบับ

1. ผู้จัดการดำเนินการคำสั่งเพื่อสร้างเอกสารการขายใหม่

2. ระบบแสดงแบบฟอร์มเอกสาร “การขาย”

4. ผู้จัดการดำเนินการจัดทำเอกสาร

5. ระบบประมวลผลเอกสาร

9. ระบบจะพิมพ์

ตาราง - 13 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการของ VI "เอกสารการลงทะเบียน"

ตาราง -14 ส่วนของสถานการณ์การดำเนินการ VI "การจอง"

ตารางที่ -15 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการของ VI "การสร้างยอดขาย"

การกระทำของนักแสดง

การตอบสนองของระบบ

สำรองสินค้า

1. ผู้จัดการดำเนินการคำสั่งเพื่อสร้างเอกสารการจองใหม่

2. ระบบแสดงแบบฟอร์มเอกสาร “การจอง”

3. ผู้จัดการป้อนข้อมูลเกี่ยวกับลูกค้า ผลิตภัณฑ์ที่ซื้อ และบริการที่ซื้อ

4. ผู้จัดการดำเนินการจัดทำเอกสาร

ข้อยกเว้นหมายเลข 1: ไม่ได้กรอกข้อมูลทุกช่อง

5. ระบบประมวลผลเอกสาร

6. ผู้จัดการดำเนินการคำสั่งพิมพ์

7. ระบบแสดงแบบฟอร์มที่พิมพ์เสร็จแล้ว

8. ผู้จัดการดำเนินการคำสั่งพิมพ์

9. ระบบจะพิมพ์

10. ผู้จัดการดำเนินการคำสั่งปิดแบบฟอร์มที่พิมพ์ออกมา

11. ระบบปิดแบบฟอร์มการพิมพ์

11. ผู้จัดการดำเนินการคำสั่ง ปิดเอกสาร “การให้บริการ”

12. ระบบปิดแบบฟอร์มเอกสาร

ตาราง - 16 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการของ VI "เอกสารการลงทะเบียน"

ตาราง -17 VI “สร้างรายงาน”

การพัฒนาโครงสร้างไดเร็กทอรี

ไดเรกทอรี "คู่สัญญา"ออกแบบมาเพื่อจัดเก็บข้อมูลเกี่ยวกับลูกค้าและซัพพลายเออร์

ตาราง -15 รายละเอียดไดเร็กทอรีไคลเอ็นต์

สถานะทางกฎหมายเป็นประเภทการแจงนับ ซึ่งหมายความว่าเมื่อคุณเลือกฟิลด์นี้ รายการสถานะสามสถานะจะปรากฏขึ้น: ผู้ประกอบการรายบุคคล รายบุคคล บุคคล, องค์กร.

การสร้าง ไดเรกทอรี "พนักงาน"- ออกแบบมาเพื่อจัดเก็บข้อมูลเกี่ยวกับพนักงานขององค์กร ช่วยให้คุณสามารถเชื่อมโยงการขายกับพนักงานคนใดคนหนึ่งได้

ตารางที่ -16 รายละเอียดไดเรกทอรี พนักงาน

การสร้าง ไดเรกทอรี "โกดัง"- ออกแบบมาเพื่อกำหนดสถานที่จัดเก็บสินค้า ผู้ประกอบการแต่ละรายจะมีคลังสินค้าสองแห่ง: จุดซื้อขาย 1 และจุดซื้อขาย 2

การสร้าง หนังสืออ้างอิง "ตัวเลือก ศัพท์เฉพาะ" และ "เพิ่มเติม คุณสมบัติ"- หนังสืออ้างอิงเหล่านี้มีวัตถุประสงค์เพื่อกำหนดคุณลักษณะเพิ่มเติมสำหรับผลิตภัณฑ์เฉพาะ กล่าวคือ จอภาพอาจเหมือนกัน แต่สีจะแตกต่างกัน ไดเร็กทอรีเหล่านี้จะถูกเรียกในรูปแบบของไดเร็กทอรีระบบการตั้งชื่อ ค่าของฟิลด์เหล่านี้จะแสดงอยู่ในเอกสารการขาย

การสร้าง ไดเรกทอรี "ระบบการตั้งชื่อ"- เพื่อพิจารณาสินค้าที่ซื้อจากซัพพลายเออร์ เราจะสร้างไดเร็กทอรี "ระบบการตั้งชื่อ"

ผลิตภัณฑ์ในไดเร็กทอรี Nomenclature จะถูกรวมเป็นกลุ่มต่างๆ ตามวัตถุประสงค์การใช้งาน ดังนั้นไดเร็กทอรีจะมีรูปแบบของลำดับชั้น "ลำดับชั้นของกลุ่มและองค์ประกอบ"

ตารางที่ -17 รายละเอียดของไดเร็กทอรีระบบการตั้งชื่อ

การพัฒนาโครงสร้างทะเบียนข้อมูล “ราคาสินค้า”

เพื่อจัดเก็บต้นทุนของรายการสินค้า เราจะสร้างการลงทะเบียนข้อมูลชื่อ "ราคา" ความถี่ของการลงทะเบียนอยู่ภายในไม่กี่วินาที (เช่น สามารถติดตามราคาได้ตลอดเวลา) โหมดการบันทึกเป็นอิสระ

ตารางที่ -18 โครงสร้างของข้อมูลการลงทะเบียนราคา

คุณสมบัตินำหน้าบ่งชี้ว่ารายการลงทะเบียนข้อมูลเป็นที่สนใจตราบใดที่ออบเจ็กต์ที่มีการอ้างอิงถูกเลือกเป็นค่าของมิตินี้ในรายการนี้อยู่ เมื่อคุณลบออบเจ็กต์ บันทึกทั้งหมดในการลงทะเบียนข้อมูลสำหรับออบเจ็กต์นี้จะถูกลบโดยอัตโนมัติ

การพัฒนาโครงสร้างเอกสาร “การรับสินค้า”

เอกสาร "การรับสินค้า" มีวัตถุประสงค์เพื่อสะท้อนถึงความจริงที่ว่าองค์กรได้รับสินค้าที่ซื้อแล้ว

ตารางที่ 19 รายละเอียดเอกสาร “การรับสินค้า (ใบรับสินค้า)”

ตาราง -19 รายละเอียดของส่วนตารางของเอกสาร "การรับสินค้า"

มีการเขียนโค้ดเพื่อคำนวณค่าของคอลัมน์จำนวนโดยอัตโนมัติเมื่อค่าของคอลัมน์ปริมาณและราคาเปลี่ยนแปลง

รูปแบบของเอกสารจะมีลักษณะดังแสดงในรูปที่ 2


รูปที่ 2- แบบฟอร์มเอกสารการรับสินค้า

การพัฒนาโครงสร้างเอกสาร “การขาย”

เอกสารการให้บริการมีวัตถุประสงค์เพื่อบันทึกกิจกรรมของผู้ประกอบการแต่ละราย ควบคุมการตัดจำหน่ายสินค้าและบริการที่ได้ดำเนินการไปแล้ว และยังช่วยให้คุณดูรายงานการทำงานของพนักงานได้อีกด้วย

ตาราง -20 รายละเอียดของเอกสาร "การขาย"

ตาราง -21 รายละเอียดของส่วนตารางของเอกสารการขาย

การพัฒนาโครงสร้างเอกสาร “การจอง”

เอกสาร "การจอง" มีไว้สำหรับการจองสินค้าที่มีอยู่ในคลังสินค้า และในกรณีที่สินค้าขาดแคลน ให้รับช่วงต่อส่วนที่ขาดหายไปของสินค้าจากลูกค้า นอกจากนี้ยังจำเป็นต้องจองสินค้าจนกว่าลูกค้าจะชำระต้นทุนการสั่งซื้อ เอกสารนี้ออกแบบมาเพื่อควบคุมยอดคงเหลือในคลังสินค้าเพื่อหลีกเลี่ยงความเข้าใจผิดกับลูกค้า

ตารางที่ -20 รายละเอียดเอกสาร “การจอง”

ตาราง -21 รายละเอียดของส่วนตารางของเอกสารการจอง

การพัฒนา โครงสร้าง เอกสาร "ป้อนข้อมูล อักษรย่อ ของเหลือ"

เอกสารนี้จำเป็นในการป้อนยอดคงเหลือยกมาลงในฐานข้อมูล

โดยมีรายละเอียดคล้ายกับเอกสาร “ใบเสร็จรับเงิน”

การสร้าง รายงาน "สินค้า"

รายงาน "สินค้า" ได้รับการออกแบบมาเพื่อดูการตัดจำหน่ายและรับสินค้าได้อย่างรวดเร็ว นั่นคือช่วยให้ผู้ใช้สามารถดูจำนวนสินค้าที่มีอยู่ในสต็อกในปัจจุบันและจำนวนที่ขายไปแล้ว

ในสภาพแวดล้อม 1C Enterprise 8 มีตัวสร้างรายงานที่ช่วยให้คุณพัฒนารายงานได้อย่างรวดเร็วสร้างแบบสอบถามและการออกแบบตามตาราง

การสร้าง รายงาน “ทะเบียนเอกสารการขาย”

รายงานนี้มีจุดมุ่งหมายเพื่อสร้างทะเบียนเอกสาร "การขาย" ระบบจะใช้รายงานต่างๆ ซึ่งจะคล้ายกันในโครงสร้างการสร้าง

การสร้าง บทบาท และ การนัดหมาย ของพวกเขา ผู้ใช้

การดูแลรายชื่อผู้ใช้ 1C:Enterprise และการมอบหมายบทบาทตามความรับผิดชอบในงานเป็นจุดสำคัญมากในการจัดระเบียบอินเทอร์เฟซของโซลูชันแอปพลิเคชันโดยรวมและการกำหนดสิทธิ์และการดำเนินการของผู้ใช้แต่ละราย

คุณควรจำกัดไม่ให้ผู้ใช้ดำเนินการกับวัตถุฐานข้อมูล ดังนั้นเจ้าของร้านจึงสามารถสร้างเอกสาร “การรับสินค้า” และบันทึกเอกสารได้ เนื่องจากเขามีหน้าที่บันทึกการรับสินค้า ในทางกลับกันผู้จัดการควรมีสิทธิ์เข้าถึงการเพิ่มไดเร็กทอรีลูกค้า, จัดทำเอกสาร "การขาย", "การจอง" แต่ในขณะเดียวกันเขาก็ไม่ควรเข้าถึงการรับสินค้า

ออบเจ็กต์การกำหนดค่าบทบาทใช้เพื่ออธิบายสิทธิ์ดังกล่าว ผู้ใช้ระบบแต่ละคนจะได้รับมอบหมายบทบาทตั้งแต่หนึ่งบทบาทขึ้นไป

เมื่อสร้างบทบาท บทบาทจะขึ้นอยู่กับสิทธิ์ที่จำเป็นสำหรับกลุ่มผู้ใช้ที่แตกต่างกันในการเข้าถึงข้อมูล บทบาทต่อไปนี้จะถูกนำไปใช้ในระบบของเรา:

  • - ผู้ดูแลระบบ - ระบบ 1C:Enterprise ต้องมีบทบาทที่มีสิทธิ์เต็มที่ในการทำงานกับข้อมูลความปลอดภัยของข้อมูล
  • - เจ้าของร้าน;
  • - ผู้จัดการ;
  • - ไอพี.

การกำหนดบทบาทให้กับผู้ใช้จะดำเนินการผ่านรายการเมนูหลัก การดูแลระบบ -> ผู้ใช้

รูปที่ 3 - การสร้างผู้ใช้ “ผู้ดูแลระบบ” ที่มีบทบาท “ผู้ดูแลระบบ”

รูปที่ 4 - รายชื่อผู้ใช้ระบบ

สิทธิ์ในการลบแบบโต้ตอบได้ถูกเอาออกสำหรับวัตถุฐานข้อมูลทั้งหมดสำหรับทุกบทบาท

การแก้ไข สั่งการ อินเตอร์เฟซ ส่วนต่างๆ และ คนงาน โต๊ะ

การปรับปรุงอินเทอร์เฟซคำสั่งของแอปพลิเคชัน การปรับการมองเห็นคำสั่งตามบทบาทและเดสก์ท็อป ทำให้แอปพลิเคชันใช้งานง่ายขึ้น และทำให้มีรูปลักษณ์ที่สมบูรณ์

ลองเรียงลำดับคำสั่งตามลำดับความสำคัญและความถี่ในการใช้งานเป็นกลุ่มต่างๆ ดังต่อไปนี้:

  • - แผงนำทาง สำคัญ;
  • - แถบนำทาง ปกติ;
  • - แถบนำทาง ดู อีกด้วย;
  • - แผงการดำเนินการสร้างและ
  • - แผงการดำเนินการ

รูปที่ 5 - อินเทอร์เฟซคำสั่งของส่วน "การบัญชีวัสดุ" สำหรับผู้ใช้ที่มีบทบาท "ผู้จัดเก็บ"

รูปที่ 6 - อินเทอร์เฟซคำสั่งของส่วน "การให้บริการ" สำหรับผู้ใช้ที่มีบทบาท "ผู้จัดการ"


รูปที่ 7 - อินเทอร์เฟซคำสั่งของส่วน "องค์กร" สำหรับผู้ใช้ที่มีบทบาท "ผู้อำนวยการ"

รูปที่ 8 - อินเทอร์เฟซคำสั่งของส่วน "Retail.Electronics" สำหรับผู้ใช้ที่มีบทบาท "ผู้ดูแลระบบ"

เดสก์ท็อปได้รับการออกแบบเพื่อรองรับเอกสาร รายงาน หนังสืออ้างอิง ฯลฯ ที่ผู้ใช้ใช้บ่อยที่สุด เมื่อคุณเริ่ม 1C:Enterprise ส่วนเดสก์ท็อปจะเปิดใช้งานตามค่าเริ่มต้นและแบบฟอร์มที่จำเป็นจะเปิดขึ้นทันทีในพื้นที่ทำงานของแอปพลิเคชัน


รูปที่ 9 - เดสก์ท็อปสำหรับผู้ใช้ที่มีบทบาท "ผู้ดูแลร้าน"


รูปที่ 10 - เดสก์ท็อปสำหรับผู้ใช้ที่มีบทบาท "ผู้จัดการ"

เอกสารซอฟต์แวร์การค้าขายส่งอัตโนมัติ

ด้านล่างนี้เป็นตัวอย่าง (ตัวอย่าง) ของเอกสารโครงการ " คำอธิบายเกี่ยวกับโครงการทางเทคนิคสำหรับการสร้างระบบอัตโนมัติ"ตามแนวทาง ถ.50-34.698-90- เอกสารนี้จัดทำโดยผู้เชี่ยวชาญด้านไอทีในขั้นตอนนี้ การออกแบบทางเทคนิคของระบบสารสนเทศ.

ตัวอย่างของการพัฒนาระบบสารสนเทศใช้โครงการแนะนำข้อมูลและระบบวิเคราะห์ “คลังข้อมูลองค์กร”.

หน้าด้านล่างแสดง เนื้อหาของบันทึกอธิบายของโครงการด้านเทคนิคตาม GOST ภายในแต่ละส่วนโดยสังเขป ข้อกำหนดด้านเนื้อหาและข้อความของตัวอย่างการกรอกจะได้รับ(โดดเด่นด้วยเส้นแนวตั้ง)

ส่วนของหมายเหตุอธิบาย:

    บทบัญญัติทั่วไป

    โซลูชั่นทางเทคนิคหลัก

    การตัดสินใจเกี่ยวกับโครงสร้างของระบบ ระบบย่อย วิธีการ และวิธีการสื่อสารเพื่อการแลกเปลี่ยนข้อมูลระหว่างส่วนประกอบของระบบ

    โซลูชั่นสำหรับการเชื่อมต่อระบบลำโพงกับระบบที่เกี่ยวข้องและรับรองความเข้ากันได้

    การตัดสินใจเกี่ยวกับโหมดการทำงาน การวินิจฉัยการทำงานของระบบ

    การตัดสินใจเกี่ยวกับบุคลากรและรูปแบบการทำงาน

    ข้อมูลเกี่ยวกับการรับรองคุณลักษณะผู้บริโภคของระบบที่ระบุในข้อกำหนดทางเทคนิคซึ่งกำหนดคุณภาพของระบบ

    องค์ประกอบของฟังก์ชัน ชุดงานที่ระบบดำเนินการ

    องค์ประกอบและการจัดวางคอมเพล็กซ์อุปกรณ์ทางเทคนิค