วันนี้เราจะพูดถึงมาตรฐานภายในประเทศสำหรับเอกสารการออกแบบ มาตรฐานเหล่านี้ทำงานอย่างไรในทางปฏิบัติ เหตุใดจึงไม่ดี และเหตุใดจึงดี เมื่อพัฒนาเอกสารสำหรับลูกค้าภาครัฐและเอกชนที่จริงจัง เรามักจะไม่มีทางเลือก - การปฏิบัติตามมาตรฐานจะรวมอยู่ในข้อกำหนดสำหรับการจัดทำเอกสารข้อกำหนดทางเทคนิค ในทางปฏิบัติ ฉันได้พบตัวอย่างต่างๆ มากมายของความเข้าใจผิดเกี่ยวกับโครงสร้างของมาตรฐาน สิ่งที่ควรอยู่ในเอกสาร และเหตุใดจึงจำเป็นต้องใช้เอกสารเหล่านี้ เป็นผลให้ปากกาของนักเขียนด้านเทคนิคนักวิเคราะห์และผู้เชี่ยวชาญบางครั้งผลิตอัญมณีดังกล่าวซึ่งไม่ชัดเจนว่าพวกเขาเขียนในสภาวะจิตสำนึกใด แต่ในความเป็นจริงทุกอย่างค่อนข้างง่าย การค้นหา 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
- ยึดมั่นในมาตรฐานอย่างสมบูรณ์และแม่นยำ- โดยธรรมชาติแล้วจะไม่มีใครเขียนเอกสารจำนวนมากเช่นนี้โดยสมัครใจ ดังนั้นเอกสารทั้งชุดจึงถูกจัดเตรียมตามคำขอเร่งด่วนของลูกค้าเท่านั้น ซึ่งเขาระบุไว้ในข้อกำหนดทางเทคนิคและยังปักหมุดข้อตกลงไว้ด้านบนอีกด้วย ในกรณีนี้ คุณต้องทำทุกอย่างตามตัวอักษรและมอบ "หนังสือ" ทางกายภาพให้กับลูกค้าซึ่งจะเป็นชื่อของเอกสารจากตารางที่ 2 ของ GOST 34.201-89 ยกเว้นรายการที่คุณไม่จำเป็นโดยสิ้นเชิง จะต้องหารือและมีความปลอดภัยเป็นลายลักษณ์อักษร เนื้อหาของเอกสารจะต้องเป็นไปตาม RD 50-34.698-90 ไปจนถึงชื่อของส่วนต่างๆ โดยไม่ต้องจินตนาการใดๆ เพื่อให้สมองของลูกค้าระเบิด บางครั้งระบบขนาดใหญ่จะถูกแบ่งออกเป็นระบบย่อย และมีการออกเอกสารการออกแบบแยกต่างหากสำหรับแต่ละระบบย่อย มันดูน่ากลัวและไม่อยู่ภายใต้การควบคุมตามปกติด้วยความช่วยเหลือจากจิตใจของโลก โดยเฉพาะเรื่องการบูรณาการระบบย่อย ซึ่งช่วยลดความยุ่งยากในการยอมรับอย่างมาก สิ่งสำคัญคือคุณเองอย่าสับสนและระบบของคุณยังคงทำงานอย่างที่ควรจะเป็น
- เราแค่รักมาตรฐาน GOST- อย่างจริงจัง บริษัทใหญ่มาตรฐานความรัก เพราะพวกเขาช่วยให้ผู้คนเข้าใจกันดีขึ้น หากลูกค้าของคุณมีชื่อเสียงในเรื่องความรักในความเป็นระเบียบเรียบร้อยและการสร้างมาตรฐาน พยายามยึดมั่นในอุดมการณ์ GOST มาตรฐานเมื่อพัฒนาเอกสาร แม้ว่าข้อกำหนดทางเทคนิคจะไม่จำเป็นก็ตาม ผู้เชี่ยวชาญที่ได้รับการอนุมัติจะเข้าใจคุณดีขึ้นและอนุมัติคุณ และคุณเองก็จะไม่ลืมรวมพวกเขาไว้ในเอกสารด้วย ข้อมูลสำคัญคุณจะเห็นโครงสร้างเป้าหมายของเอกสารได้ดีขึ้น วางแผนงานเขียนได้แม่นยำยิ่งขึ้น และช่วยตัวเองและเพื่อนร่วมงานให้ไม่ต้องกังวลและเสียเงินมากมาย
- เราไม่สนใจเรื่องเอกสารตราบใดที่ทุกอย่างยังใช้งานได้- รูปลักษณ์ที่หายไปของลูกค้าที่ไม่รับผิดชอบ มุมมองที่คล้ายกันของเอกสารยังคงพบได้ในหมู่ลูกค้ารายย่อยและยากจน เช่นเดียวกับใน "พวกโง่เขลา" เผด็จการที่เหลืออยู่ตั้งแต่สมัยเปเรสทรอยกาซึ่งเจ้านายถูกล้อมรอบ เพื่อนแท้- กรรมการและปัญหาทั้งหมดได้รับการแก้ไขในการสนทนาส่วนตัว ในเงื่อนไขดังกล่าวคุณมีอิสระที่จะละเลยเอกสารทั้งหมด แต่จะดีกว่าที่จะไม่ล้มสายตาและอย่างน้อยก็กรอกเอกสารพร้อมเนื้อหาตามแผนผัง ถ้าไม่ใช่ลูกค้ารายนี้ก็ส่งต่อ(ขาย)ให้รายต่อไป
บทสรุป
บทความนี้เกี่ยวกับมาตรฐาน GOST ของเราสำหรับการจัดทำเอกสารระบบควบคุมอัตโนมัติ GOST นั้นเก่า แต่ปรากฎว่าพวกมันยังคงมีประโยชน์มากในครัวเรือน นอกเหนือจากพื้นฐานที่ชัดเจนบางประการแล้ว โครงสร้างของเอกสารยังมีคุณสมบัติครบถ้วนและสม่ำเสมอ และการยึดมั่นในมาตรฐานช่วยลดความเสี่ยงของโครงการมากมาย ซึ่งเราอาจไม่ทราบถึงการมีอยู่ในตอนแรก
ฉันหวังว่าเนื้อหาที่นำเสนอจะเป็นประโยชน์กับคุณหรืออย่างน้อยก็น่าสนใจ แม้จะมีความน่าเบื่ออย่างเห็นได้ชัด แต่งานเอกสารก็เป็นงานที่สำคัญและมีความรับผิดชอบ ซึ่งความถูกต้องแม่นยำมีความสำคัญพอๆ กับการเขียนโค้ดที่ดี เขียน เอกสารที่ดี, เพื่อนร่วมงาน! และฉันก็พร้อมแล้ว สัปดาห์หน้าฉันกำลังเดินทางไปทำธุรกิจสองครั้งติดต่อกัน ดังนั้นฉันจึงไม่สามารถรับประกันการตีพิมพ์เนื้อหาใหม่ได้ (ฉันไม่มีที่เก็บสะสม ฉันเขียนจากในหัว)
เอ็ม. ออสโตรกอร์สกี้, 2008
เพื่อที่จะใช้ GOST 34 ได้สำเร็จจำเป็นต้องเข้าใจว่าจากมุมมองของชุดมาตรฐานนี้ระบบอัตโนมัติมีโครงสร้างอย่างไร มิฉะนั้นเราจะไม่เห็นสิ่งใดในแขกยกเว้นรายการเอกสารยาว ๆ ที่มีชื่อลึกลับและข้อกำหนดสำหรับเนื้อหาของพวกเขาจะทำให้เราเชื่ออีกครั้งว่าในภูมิปัญญาหลายอย่างมีความเศร้ามากมาย ดังนั้นก่อนที่จะคุยเรื่องเอกสารกันเองเราจะต้องเข้าใจว่าเรื่องของเอกสารคืออะไร
ระบบอัตโนมัติ หน้าที่และงานต่างๆ
คำจำกัดความของระบบอัตโนมัติ
GOST 34.003-90 มีคำจำกัดความต่อไปนี้ของระบบอัตโนมัติ: ระบบที่ประกอบด้วยบุคลากรและชุดเครื่องมืออัตโนมัติสำหรับกิจกรรมของพวกเขาการนำเทคโนโลยีสารสนเทศไปใช้เพื่อทำหน้าที่ที่กำหนดไว้ คำจำกัดความนี้หมายถึงอะไรจริงๆ? คุณสามารถเข้าใจสิ่งนี้ได้โดยการอ่านคำจำกัดความอื่น ๆ ของมาตรฐานนี้แล้วเปรียบเทียบกัน เราจะทำอะไรตอนนี้?
เป้าหมายกิจกรรม
ระบบอัตโนมัติจะอยู่ได้ก็ต่อเมื่อมีบุคลากรมีส่วนร่วมในกิจกรรมเฉพาะเท่านั้น โดยทั่วไปแล้ว เรากำลังพูดถึงกิจกรรมที่เป็นประโยชน์ต่อใครบางคน โดยไม่คำนึงถึงเครื่องมือที่ใช้ ตัวอย่างเช่น ฉันไปที่บ็อกซ์ออฟฟิศของโรงละครเพื่อซื้อตั๋ว และฉันก็ดีใจมากถ้าแคชเชียร์เขียนแบบฟอร์มให้ฉันด้วยปากกา ตราบใดที่พวกเขาให้ฉันเข้าไปในโรงละครโดยใช้มัน โดยทั่วไปแล้วแคชเชียร์ก็ไม่สนใจว่าจะมีการทำตั๋วอย่างไร เธอจะไม่มีปัญหากับวิธีการใดๆ ก็ตาม ตราบใดที่มันไม่ใช้แรงงานมากเกินไป และเปิดโอกาสให้เธอขายตั๋วให้ฉันได้ เธอและฉันมีเป้าหมายร่วมกัน GOST 34.003-90 ใช้คำนี้เพื่อแสดงถึง วัตถุประสงค์ของกิจกรรม- ทุกครั้งที่ผู้ชมอีกคนออกจากหน้าต่างพร้อมกับตั๋วในมือ และโรงละครก็มีความสมบูรณ์ยิ่งขึ้นอีกเล็กน้อย กิจกรรมนี้ก็บรรลุเป้าหมาย
ฟังก์ชั่นของระบบอัตโนมัติ
กิจกรรมสามารถมีเป้าหมายได้หลายอย่าง (และตามกฎแล้ว) ผลลัพธ์ที่เป็นประโยชน์ใด ๆ นอกเหนือจากกิจกรรมนั้นถือได้ว่าเป็นเป้าหมายของมัน ดังนั้นหากแคชเชียร์ไม่เพียงแต่ขายตั๋ว แต่ยังเตรียมรายงานการขายสำหรับฝ่ายบริหารเมื่อสิ้นสุดวันทำการด้วย การจัดทำรายงานรายวันก็ถือเป็นเป้าหมายกิจกรรมอื่นได้
ถ้าเราวางคอมพิวเตอร์และเครื่องพิมพ์ไว้บนโต๊ะแคชเชียร์ และหัวหน้าแคชเชียร์ออกคำสั่งให้เธอพิมพ์ตั๋วและรายงานในโปรแกรมประมวลผลคำแล้วพิมพ์ลงบนเครื่องพิมพ์ เราก็จะได้ระบบอัตโนมัติ ตามแนวคิดสมัยใหม่ มันเป็นแบบดั้งเดิมมาก โดยจะเป็นไปตามคำจำกัดความของ Gost อย่างเป็นทางการ โปรดทราบว่าเป้าหมายของกิจกรรมไม่ได้เปลี่ยนแปลงอันเป็นผลมาจากการนำระบบอัตโนมัติไปใช้ มีเพียงวิธีการในการบรรลุเป้าหมายเท่านั้นที่เปลี่ยนไป สิ่งที่เคยทำ “แบบนั้น” บัดนี้กลับทำภายใต้กรอบของระบบอัตโนมัติแล้ว ชุดการดำเนินการของระบบอัตโนมัติที่มีเป้าหมายเพื่อให้บรรลุเป้าหมายเฉพาะตาม GOST 34.003-90 เรียกว่า การทำงาน- หมายเหตุ: ไม่ว่าจะมองอย่างไรพนักงานก็ถือว่าเป็นส่วนหนึ่งของระบบ
ฟังก์ชั่นของระบบอัตโนมัติเป็นแนวคิดพื้นฐานใน GOST 34 ประการแรกระบบอัตโนมัติถือเป็นผลรวมของฟังก์ชันและต่อจากนั้นเป็นเพียงกลุ่มของ "ซอฟต์แวร์" และ "ฮาร์ดแวร์" สิ่งที่สำคัญที่สุดคือสิ่งที่ระบบทำ และสิ่งที่ประกอบด้วยนั้นเป็นเรื่องรอง
ข้อความข้างต้นอาจทำให้ผู้อ่านสรุปได้ว่าแต่ละเป้าหมายของกิจกรรมในระบบอัตโนมัติสอดคล้องกับฟังก์ชันเดียวเท่านั้น ระบบดังกล่าวเป็นเรื่องง่ายที่จะจินตนาการ แต่การฝึกฝนมีความหลากหลายมากกว่า ประการหนึ่ง กิจกรรมต่างๆ ไม่ได้เกิดขึ้นโดยอัตโนมัติเสมอไป แม้หลังจากนำระบบอัตโนมัติไปใช้แล้ว เป้าหมายบางอย่างยังต้องบรรลุเป้าหมายด้วยตนเอง ในทางกลับกัน เนื่องจากสามารถบรรลุผลลัพธ์เดียวกันได้ภายใต้เงื่อนไขที่ต่างกัน ในรูปแบบที่แตกต่างกันฟังก์ชั่นหลายอย่างสามารถมุ่งเป้าไปที่เป้าหมายเดียวของกิจกรรมในระบบอัตโนมัติ เช่น การขายตั๋วที่บ็อกซ์ออฟฟิศ และการขายตั๋วทางอินเทอร์เน็ต นอกจากนี้ ระบบอัตโนมัติใดๆ จำเป็นต้องมีการบำรุงรักษา ดังนั้นจึงจำเป็นต้องแนะนำแนวคิดของฟังก์ชันเสริม ตัวอย่างทั่วไปคือการสร้างสำเนาสำรองของข้อมูล
หน้าที่ของระบบอัตโนมัติ
ในกรณีทั่วไป เมื่อปฏิบัติงาน ส่วนหนึ่งของงานจะดำเนินการโดยพนักงาน และอีกส่วนหนึ่งใช้เทคโนโลยี เช่น ตั๋วจะถูกพิมพ์โดยอัตโนมัติและแคชเชียร์จะมอบให้แก่ผู้ซื้อด้วยตนเอง ลำดับของการดำเนินการอัตโนมัติ (sic) ที่นำไปสู่ผลลัพธ์ของประเภทที่กำหนดเรียกว่าใน GOST 34.003-90 งาน.
คำจำกัดความของปัญหาในที่นี้ไม่ได้อ้างอิงอย่างถูกต้องทั้งหมด แต่สำหรับตอนนี้ก็เพียงพอแล้วสำหรับเรา ท้ายที่สุดแล้ว ไม่มีความละอายเลยที่ใครก็ตามที่อ่านมาตรฐานนี้ด้วยตนเอง สิ่งสำคัญคืองานคือส่วนที่เป็นทางการที่สุดของกิจกรรมอัตโนมัติ คุณสามารถจินตนาการถึงฟังก์ชันที่ทำงานโดยอัตโนมัติทั้งหมดได้ เช่น การสำรองข้อมูลที่กล่าวถึงข้างต้น ในกรณีนี้ ฟังก์ชันจะลดลงเหลือเพียงงานเดียว
งานเดียวกันสามารถแก้ไขได้ด้วยการทำหน้าที่ต่างกัน ตัวอย่างเช่น หากระบบอัตโนมัติมีฟังก์ชันหลายอย่างในการขายตั๋ว การดำเนินการแต่ละฟังก์ชันอาจจำเป็นต้องพิมพ์ตั๋วในบางครั้ง
องค์ประกอบของระบบอัตโนมัติ
ระบบย่อย
หากระบบอัตโนมัติค่อนข้างซับซ้อนก็จะแบ่งเป็น ระบบย่อย- หมายความว่าอย่างไร ค่อนข้างซับซ้อน พูดค่อนข้างยาก ทฤษฎีระบบอธิบายระดับต่างๆ และเกณฑ์ของความซับซ้อน ในทางปฏิบัติ ความจำเป็นในการจัดสรรระบบย่อยหลายระบบในระบบอัตโนมัติมักเกิดจากเหตุผลด้านองค์กรและทางการเงิน เช่น ระบบย่อยได้รับการพัฒนาและนำไปใช้งานตามลำดับ
แม้ว่าใน GOST 34 จะใช้คำว่าระบบย่อยหลายครั้ง แต่ดูเหมือนว่าจะไม่มีคำจำกัดความที่เป็นทางการของแนวคิดนี้ ประสบการณ์แสดงให้เห็นว่าระบบย่อยเป็นส่วนหนึ่งของระบบอัตโนมัติที่ตอบสนองคำจำกัดความของระบบอัตโนมัติด้วย โดยเฉพาะอย่างยิ่งระบบนี้มีฟังก์ชันที่ครบครัน
กลับมาที่ตัวอย่างการออกตั๋ว เราสามารถตัดสินใจได้ว่าระบบอัตโนมัติประกอบด้วยสองระบบย่อย: ระบบย่อยการออกตั๋ว และระบบย่อยการรายงานรายวัน เพื่อความชัดเจนยิ่งขึ้น เรามาตกลงกันว่าแคชเชียร์จะพิมพ์ตั๋วในโปรแกรมแก้ไขข้อความ และรายงานในสเปรดชีต
ส่วนประกอบ
การระบุเป้าหมายกิจกรรม ฟังก์ชั่นของระบบอัตโนมัติ และระบบย่อยหากจำเป็น ส่วนใหญ่เป็นอัตวิสัยและขึ้นอยู่กับมุมมองของบุคคลที่ตัดสินใจทำเช่นนี้ หากผลลัพธ์บางอย่างมีความสำคัญในบริบทของปัญหาที่กำลังแก้ไข เราก็อาจถือว่ามันเป็นเป้าหมาย ไม่เช่นนั้นก็เพิกเฉยไป นอกจากนี้เรายังจะแบ่งระบบอัตโนมัติออกเป็นระบบย่อยในลักษณะที่สะดวกสำหรับเรา ตราบใดที่การตัดสินใจของเราไม่ขัดแย้งกับเนื้อหาของแนวคิดนี้
ส่วนประกอบคือส่วนที่เรา ความเป็นจริงตามวัตถุประสงค์เรากำลังสร้างระบบอัตโนมัติ ระบบทางกายภาพประกอบด้วยส่วนประกอบต่างๆ ดังนั้นการแบ่งระบบอัตโนมัติออกเป็นส่วนประกอบต่างๆ จึงมีวัตถุประสงค์มากที่สุด
เราซื้อส่วนประกอบแต่ละชิ้น ติดตั้งและเชื่อมต่อ (หากเป็นอุปกรณ์) ติดตั้ง (หากเป็นโปรแกรม) และบำรุงรักษาแยกจากส่วนประกอบอื่นๆ เราซื้อและวางคอมพิวเตอร์ไว้บนโต๊ะ - เป็นส่วนประกอบ เราได้พัฒนาโปรแกรมแก้ไขข้อความพิเศษสำหรับการพิมพ์ตั๋ว - ส่วนประกอบอื่น ดาวน์โหลดสเปรดชีตฟรีจากอินเทอร์เน็ต - เป็นส่วนประกอบอีกครั้ง และแม้กระทั่งแคชเชียร์เองก็เป็นส่วนหนึ่งของระบบอัตโนมัติเช่นกัน
องค์ประกอบองค์ประกอบของระบบอัตโนมัติมีความสำคัญมากจากมุมมองของเอกสารประกอบ เนื่องจากเอกสารทางเทคนิคสำหรับระบบดังกล่าวและสำหรับส่วนประกอบได้รับการจัดการที่แตกต่างกัน โดยทั่วไปแล้วควรได้รับการพัฒนา คนละคนและได้รับการออกแบบตามมาตรฐานที่แตกต่างกันขึ้นอยู่กับประเภทของส่วนประกอบ
ประเภทของหลักประกัน
หนึ่งในแนวคิดที่ยากที่สุดสำหรับผู้ใช้มือใหม่ของ GOST 34 คือ ประเภทของการรักษาความปลอดภัย- นี่คือการรักษาความปลอดภัยแบบไหน? คุณมองเห็นหรือสัมผัสมันได้หรือไม่? ขายหรือซื้อ?
ซอฟต์แวร์แต่ละประเภทผสมผสานส่วนประกอบหรือโซลูชันทางเทคนิคในลักษณะเฉพาะเข้าด้วยกัน GOST 34 กล่าวถึงมาก ประเภทต่างๆซอฟต์แวร์ เราจะไม่อธิบายแต่ละซอฟต์แวร์ตามลำดับที่นี่ แต่จะแสดงเฉพาะสิ่งที่สังเกตได้ชัดเจนที่สุดเท่านั้น:
- การสนับสนุนข้อมูล - ข้อมูลและข้อมูลเมตาทั้งหมดที่ระบบทำงาน
- ซอฟต์แวร์ - โปรแกรมทั้งหมดที่เป็นส่วนหนึ่งของระบบ
- การสนับสนุนด้านเทคนิค - วิธีการทางเทคนิคทั้งหมด (กล่าวคือ อุปกรณ์ อุปกรณ์) ที่เป็นส่วนหนึ่งของระบบ
ขอย้ำอีกครั้ง สิ่งเหล่านี้ไม่ใช่การรักษาความปลอดภัยทุกประเภท เราไม่สามารถพูดได้อย่างมั่นใจว่าสิ่งเหล่านั้นสำคัญที่สุด ตัวอย่างเช่นสำหรับ ระบบอัตโนมัติการควบคุมกระบวนการ (APCS) ความสำคัญอย่างยิ่งมีการสนับสนุนทางมาตรวิทยา ระบบอัตโนมัติจำนวนมากต้องการการสนับสนุนทางคณิตศาสตร์และภาษาที่ซับซ้อน แต่เป็นการยากที่จะจินตนาการถึงระบบอัตโนมัติที่จะปราศจากการสนับสนุนหนึ่งในสามประเภทที่ระบุไว้ข้างต้นโดยสิ้นเชิง (แบบฝึกหัด: ลองใช้ดู)
การแนะนำ
ใน โลกสมัยใหม่ทุกๆ วันมีโปรแกรม แอพพลิเคชั่น และระบบข้อมูลมากมายปรากฏขึ้นมากมาย สามารถพัฒนาสำหรับภาครัฐหรือภาคการค้ารวมถึงผู้ใช้ทั่วไปได้ 90% ของผู้ใช้ทั้งหมดไม่อ่านเอกสาร คิดว่าน่าเบื่อ น่าเบื่อ และไม่น่าสนใจ และเปิดคู่มือผู้ใช้เฉพาะเมื่อมีบางอย่างไม่ได้ผล หรือเป็นไปไม่ได้เลยที่จะเข้าใจโดยไม่มีคำแนะนำ ปัจจุบันการออกแบบส่วนต่อประสานกับผู้ใช้ในลักษณะที่ใช้งานง่ายกลายเป็นเรื่องปกติ และผู้ใช้สามารถเข้าใจระบบได้โดยไม่ต้องอ่านคู่มือที่ยาว อย่างไรก็ตาม เมื่อทำงานกับลูกค้ารายใหญ่ เกือบทุกครั้งจำเป็นต้องส่งเอกสารบางชุด - คู่มือ คำแนะนำ โซลูชันการออกแบบ ซึ่งร่างขึ้นตาม GOST
เมื่อคุณพบการเขียนเอกสารตาม GOST เป็นครั้งแรกคุณจะมึนงงและตกใจอย่างยิ่งเนื่องจากมี "ทะเล" ของ GOST เหล่านี้และวิธีการเขียนตาม GOST เหล่านี้ยังไม่ชัดเจน
บทความนี้กล่าวถึงมาตรฐาน GOST สำหรับการเขียนเอกสารและประเด็นหลัก
มาตรฐาน GOST คืออะไร?
ก่อนอื่นคุณต้องเข้าใจว่ามาตรฐาน GOST คืออะไร ทุกคนรู้ดีว่า GOST เป็นสิ่งที่ได้รับการพัฒนาภายใต้สหภาพและมีจำนวนไม่สิ้นสุด ฉันรีบเร่งให้ความมั่นใจกับคุณว่ามี GOST ไม่มากนักสำหรับภาคไอทีและทั้งหมดแม้จะใช้เวลาสร้าง แต่ก็ไม่ได้สูญเสียความเกี่ยวข้องไป
ประการแรก มาตรฐานการเขียนเอกสารแบ่งออกเป็น 2 ประเภท คือ
- มาตรฐานสากล (ISO, IEEE Std);
- GOST ของรัสเซียหรือโซเวียต
มาตรฐานสากล
มาตรฐานสากลถูกนำมาใช้เพื่อพัฒนาเอกสารระดับสากล ตามกฎแล้ว พวกมันไม่ฟรี เนื่องจากพวกมันไม่ได้รับการพัฒนา องค์กรภาครัฐแต่ต่างจากของเราตรงที่พวกเขาได้รับการพัฒนาเมื่อไม่นานมานี้ เรื่อง มาตรฐานสากลกว้างมาก เลยจะกล่าวถึงในบทความอื่น มีการกล่าวถึงมาตรฐานหลายประการที่เกี่ยวข้องอย่างใกล้ชิดกับการเขียนเอกสารด้วย
รายการมาตรฐานสากลหลักสำหรับการเขียนเอกสาร:
- IEEE Std 1063-2001 “มาตรฐาน IEEE สำหรับเอกสารผู้ใช้ซอฟต์แวร์” - มาตรฐานสำหรับการเขียนคู่มือผู้ใช้
- IEEE Std 1016-1998 “แนวทางปฏิบัติที่แนะนำของ IEEE สำหรับคำอธิบายการออกแบบซอฟต์แวร์” - มาตรฐานสำหรับการเขียนคำอธิบายทางเทคนิคของโปรแกรม
- ISO/IEC FDIS 18019:2004 “แนวทางสำหรับการออกแบบและการจัดทำเอกสารประกอบผู้ใช้สำหรับแอพพลิเคชั่นซอฟต์แวร์” เป็นอีกหนึ่งมาตรฐานในการเขียนคู่มือผู้ใช้ เอกสารนี้ประกอบด้วย จำนวนมากตัวอย่าง พูดง่ายๆ ก็คือนี่เป็นเหมือนแนวทางในการเขียนคู่มือผู้ใช้มากกว่า มันจะมีประโยชน์อย่างยิ่งสำหรับผู้เชี่ยวชาญมือใหม่
- ISO/IEC 26514:2008 “ข้อกำหนดสำหรับนักออกแบบและนักพัฒนาเอกสารสำหรับผู้ใช้” เป็นอีกหนึ่งมาตรฐานสำหรับนักออกแบบและนักพัฒนาเอกสารสำหรับผู้ใช้
จริงๆ แล้วมีมาตรฐานสากลมากมายและแต่ละประเทศก็มีมาตรฐานของตัวเอง เนื่องจากมาตรฐานเดียวกันอาจไม่เหมาะกับทั้งบริษัทในยุโรปและเอเชียเสมอไป
มาตรฐานของรัสเซีย
มาตรฐานของรัสเซียได้รับการพัฒนาในระดับรัฐ ทั้งหมดนี้ฟรีและแต่ละอันก็หาได้ง่ายบนอินเทอร์เน็ต ในการเขียนเอกสารสำหรับโปรแกรมจะใช้ GOST 19 และ 34 สองชุด ซึ่งจะกล่าวถึงต่อไป
GOST ซีรีย์ 19 และ 34 แตกต่างกันอย่างไร?
คำถามแรกที่เกิดขึ้นคือโดยทั่วไปแล้ว GOST 19 และ 34 เหล่านี้แตกต่างกันอย่างไร
ใน GOST 19.781-90 " ระบบแบบครบวงจรเอกสารประกอบซอฟต์แวร์ ซอฟต์แวร์สำหรับระบบประมวลผลข้อมูล ข้อกำหนดและคำจำกัดความ" มีการระบุคำจำกัดความ:
- โปรแกรม - ข้อมูลที่มีวัตถุประสงค์เพื่อควบคุมส่วนประกอบเฉพาะของระบบประมวลผลข้อมูลเพื่อใช้อัลกอริทึมเฉพาะ
- ซอฟต์แวร์คือชุดของโปรแกรมระบบประมวลผลข้อมูลและเอกสารโปรแกรมที่จำเป็นสำหรับการทำงานของโปรแกรมเหล่านี้
ใน GOST 34.003-90 “เทคโนโลยีสารสนเทศ ชุดมาตรฐานสำหรับระบบอัตโนมัติ ระบบอัตโนมัติ ข้อกำหนดและคำจำกัดความ" คำจำกัดความระบุไว้:
- ระบบอัตโนมัติ (AS) - ระบบที่ประกอบด้วยบุคลากรและชุดเครื่องมืออัตโนมัติสำหรับกิจกรรมของพวกเขาการนำเทคโนโลยีสารสนเทศไปใช้เพื่อทำหน้าที่ที่กำหนดไว้
ตัวอย่างเช่นขึ้นอยู่กับประเภทของกิจกรรม AS ประเภทต่อไปนี้มีความโดดเด่น: ระบบควบคุมอัตโนมัติ (ACS), ระบบการออกแบบโดยใช้คอมพิวเตอร์ช่วย (CAD), ระบบอัตโนมัติ การวิจัยทางวิทยาศาสตร์(ASNI) และอื่นๆ
ขึ้นอยู่กับประเภทของวัตถุควบคุม (กระบวนการ) ระบบควบคุมอัตโนมัติจะถูกแบ่งออกเป็น: ระบบควบคุมอัตโนมัติสำหรับกระบวนการทางเทคโนโลยี (ACS) ระบบควบคุมอัตโนมัติสำหรับองค์กร (ACS) เป็นต้น
GOST 34 ยังแบ่งประเภทของการสนับสนุน AS:
- องค์กร;
- ระเบียบ;
- เทคนิค;
- คณิตศาสตร์;
- ซอฟต์แวร์;
- ข้อมูล;
- ภาษา;
- ถูกกฎหมาย;
- ตามหลักสรีรศาสตร์
ด้วยเหตุนี้ ระบบอัตโนมัติจึงไม่ใช่โปรแกรม แต่เป็นซอฟต์แวร์ประเภทที่ซับซ้อน รวมถึงซอฟต์แวร์ด้วย ตามกฎแล้ว AS จะมีโซลูชันระดับองค์กรสำหรับผู้ใช้และลูกค้าเฉพาะ และโปรแกรมสามารถสร้างและทำซ้ำสำหรับผู้ใช้จำนวนมากโดยไม่ต้องเชื่อมโยงกับองค์กรใดๆ
ดังนั้น หากคุณกำลังพัฒนาเอกสารสำหรับโปรแกรมที่คุณสร้างขึ้นสำหรับองค์กรเฉพาะ GOST ของคุณคือ 34 หากคุณกำลังเขียนเอกสารสำหรับโปรแกรมจำนวนมาก GOST ของคุณคือ 19
GOST 34
ซีรี่ส์ GOST 34 (มาตรฐานเทคโนโลยีสารสนเทศ GOST 34.xxx) ประกอบด้วย:
- GOST 34.201-89 ประเภทความสมบูรณ์และการกำหนดเอกสารเมื่อสร้างระบบอัตโนมัติ - มาตรฐานนี้กำหนดประเภทชื่อความสมบูรณ์และจำนวนเอกสาร นี่เป็นหนึ่งในเอกสารหลักของซีรี่ส์ GOST 34 อันที่จริงนี่เป็นเอกสารพื้นฐาน ดังนั้นผู้เริ่มต้นต้องทำความคุ้นเคยกับมันก่อน
- GOST 34.320-96 แนวคิดและคำศัพท์เฉพาะสำหรับแผนภาพแนวคิดและ ฐานข้อมูล- มาตรฐานนี้กำหนดแนวคิดพื้นฐานและเงื่อนไขของโครงร่างแนวคิดและฐานข้อมูล ครอบคลุมการพัฒนา คำอธิบาย และการประยุกต์ใช้โครงร่างแนวคิดและฐานข้อมูล การจัดการข้อมูล ตลอดจนคำอธิบายและการดำเนินการของกระบวนการข้อมูล มาตรฐานจะกำหนดบทบาทของแผนภาพแนวคิด ข้อกำหนดที่กำหนดไว้ในนั้นมีลักษณะเป็นคำแนะนำและสามารถใช้เพื่อประเมินระบบการจัดการฐานข้อมูล (DBMS) เอกสารนี้ไม่ได้อธิบายวิธีการเฉพาะสำหรับการใช้เครื่องมือสนับสนุนแผนภาพแนวคิด ภาษาสคีมาแนวคิดที่อธิบายไว้ในมาตรฐานไม่ควรถือเป็นภาษามาตรฐาน
- GOST 34.321-96 เทคโนโลยีสารสนเทศ ระบบมาตรฐานฐานข้อมูล แบบจำลองอ้างอิงการกำกับดูแล - เอกสารนี้สร้างแบบจำลองอ้างอิงการกำกับดูแลข้อมูล
โมเดลอ้างอิงกำหนดคำศัพท์ทั่วไปและแนวคิดที่เกี่ยวข้องกับข้อมูลระบบสารสนเทศ แนวคิดดังกล่าวใช้เพื่อกำหนดบริการที่จัดทำโดยระบบการจัดการฐานข้อมูลหรือระบบพจนานุกรมข้อมูล
โมเดลอ้างอิงไม่พิจารณาโปรโตคอลสำหรับการจัดการข้อมูล
ขอบเขตของแบบจำลองอ้างอิงรวมถึงกระบวนการที่เกี่ยวข้องกับการจัดการข้อมูลถาวรและการโต้ตอบกับกระบวนการที่แตกต่างจากข้อกำหนดของข้อมูลเฉพาะ ระบบสารสนเทศตลอดจนบริการการจัดการข้อมูลทั่วไปสำหรับการกำหนด จัดเก็บ เรียกค้น อัปเดต จับภาพ คัดลอก กู้คืน และส่งข้อมูล - GOST 34.601-90 ระบบอัตโนมัติ ขั้นตอนของการสร้าง - มาตรฐานกำหนดขั้นตอนและขั้นตอนของการสร้าง AS
- GOST 34.602-89 ข้อกำหนดทางเทคนิคสำหรับการสร้างระบบอัตโนมัติ (แทน GOST 24.201-85) - กำหนดองค์ประกอบ เนื้อหา กฎสำหรับการจัดทำเอกสาร "เงื่อนไขการอ้างอิงสำหรับการสร้าง (การพัฒนาหรือการปรับปรุงให้ทันสมัย) ของระบบ ”
เอกสารนี้เป็นหนึ่งในเอกสารที่ใช้บ่อยในชุด GOST 34 เมื่อพัฒนาข้อกำหนดทางเทคนิคสำหรับ GOST นี้ คุณควรจำเกี่ยวกับมาตรฐานอื่น ๆ แม้ว่าเอกสารนี้จะไม่มีการอ้างอิงถึงมาตรฐานเหล่านี้ก็ตาม - GOST 34.603-92 เทคโนโลยีสารสนเทศ ประเภทของการทดสอบระบบอัตโนมัติ - มาตรฐานกำหนดประเภทของการทดสอบ AS (การทดสอบอัตโนมัติ ซับซ้อน การยอมรับ และการดำเนินการทดลอง) และข้อกำหนดทั่วไปสำหรับการนำไปปฏิบัติ
- RD 50-34.698-90 ระบบอัตโนมัติ ข้อกำหนดสำหรับเนื้อหาของเอกสารเป็นหนึ่งในเอกสารที่สำคัญที่สุดของ GOST 34 เนื่องจากจะอธิบายเนื้อหาของเอกสารเกือบทั้งหมดตลอดจนคำอธิบายของแต่ละย่อหน้าของเอกสาร
- GOST R ISO/IEC 8824-3-2002 เทคโนโลยีสารสนเทศ Abstract Syntax Notation Version One - มาตรฐานนี้เป็นส่วนหนึ่งของ Abstract Syntax Notation Version 1 (ASN.1) และสร้างสัญลักษณ์สำหรับข้อกำหนดเฉพาะของข้อจำกัดที่ผู้ใช้กำหนดและข้อจำกัดของตาราง
- GOST R ISO/IEC 10746-3-2001 การจัดการข้อมูลและการประมวลผลแบบกระจายแบบเปิด
ในมาตรฐานนี้:- กำหนดวิธีการระบุระบบการประมวลผลแบบกระจายแบบเปิด (ODP) โดยใช้แนวคิดที่แนะนำใน GOST R ISO/IEC 10746-2
- มีการระบุคุณลักษณะตามระบบที่เป็นของระบบ OPO แล้ว
มาตรฐานดังกล่าวกำหนดกรอบการทำงานสำหรับการประสานงานการพัฒนามาตรฐานสำหรับระบบ ODP
- GOST R ISO/IEC 15271-02 กระบวนการวงจรชีวิตของซอฟต์แวร์ - GOST นี้จำเป็นมากขึ้นในความคิดของฉัน สำหรับนักวิเคราะห์เมื่อออกแบบและสร้างแบบจำลอง AS
ในมุมมองของฉัน เอกสารนี้มีประโยชน์เพื่อวัตถุประสงค์ทางการศึกษาเท่านั้น - GOST R ISO/IEC 15910-2002 กระบวนการสำหรับการสร้างเอกสารประกอบผู้ใช้สำหรับเครื่องมือซอฟต์แวร์ - กำหนดกระบวนการขั้นต่ำที่จำเป็นในการสร้างเอกสารประกอบผู้ใช้ทุกประเภทสำหรับเครื่องมือซอฟต์แวร์ที่มีอินเทอร์เฟซผู้ใช้ ประเภทเหล่านี้ประกอบด้วยเอกสารฉบับพิมพ์ (เช่น คู่มือผู้ใช้และการ์ดอ้างอิงฉบับย่อ) เอกสารออนไลน์ ข้อความช่วยเหลือ และระบบเอกสารออนไลน์
จากทุกสิ่งที่เขียนข้างต้นเป็นที่ชัดเจนว่าเอกสารหลักใน GOST 34 คือ 3: GOST 34.201-89, RD 50-34.698-90 และ GOST 34.602-89
เมื่อพัฒนาแพ็คเกจเอกสาร ขั้นแรกคุณต้องเปิด GOST 34.201-89 และเลือกขั้นตอนการสร้าง: การออกแบบร่าง การออกแบบทางเทคนิค และเอกสารการทำงาน ต่อไปคุณควรเลือกเอกสารสำหรับการพัฒนาให้สอดคล้องกับขั้นตอนการสร้าง
รายการเอกสาร 34 GOST
| เวที การสร้าง |
ชื่อเอกสาร | รหัส | ส่วนหนึ่ง โครงการ |
ปรีนาท เตียง ถึง โครงการ แต่-ประมาณการ โนอาห์ โดกุ ตำรวจ สิ่งต่างๆ |
ปรีนาท เตียง ถึง การแสวงหาผลประโยชน์ ที่ตั้ง โนอาห์ขึ้น คุเมน สเตชั่น |
คำแนะนำเพิ่มเติม |
| อีพี | แผ่นงานออกแบบเบื้องต้น | อีพี* | หรือ | — | — | — |
| หมายเหตุอธิบาย เพื่อการออกแบบเบื้องต้น |
ป1 | หรือ | — | — | — | |
| อีพี, ทีพี | แผนผังองค์กร | บจก | หรือ | — | — | อนุญาตให้รวม P3 หรือ PV ในเอกสารได้ |
| แผนภาพโครงสร้างของคอมเพล็กซ์ วิธีการทางเทคนิค |
ค1* | ที่ | เอ็กซ์ | — | ||
| แผนภาพโครงสร้างการทำงาน | ค2* | หรือ | — | — | เมื่อพัฒนาเอกสาร CO, C1, C2, C3 ในขั้นตอน ES อนุญาตให้รวมไว้ในเอกสาร P1 | |
เฉพาะทาง (ใหม่) วิธีการทางเทคนิค |
B9 | ที่ | เอ็กซ์ | — | เมื่อพัฒนาในขั้นทางเทคนิค อนุญาตให้รวม เพื่อจัดทำเอกสาร P2 |
|
| โครงการอัตโนมัติ | C3* | ที่ | เอ็กซ์ | — | — | |
| ข้อกำหนดทางเทคนิคสำหรับการพัฒนา เฉพาะทาง (ใหม่) วิธีการทางเทคนิค |
— | ที่ | — | — | ไม่รวมโครงการ | |
| ทีพี | งานพัฒนา สุขาภิบาลและ ส่วนอื่นๆ โครงการที่เกี่ยวข้อง ด้วยการสร้างระบบ |
— | ที่ | เอ็กซ์ | — | ไม่รวมโครงการ |
| แผ่นออกแบบทางเทคนิค | ทีพี* | หรือ | — | — | — | |
| รายการสินค้าที่ซื้อ | รองประธาน* | หรือ | — | — | — | |
| รายการสัญญาณอินพุต และข้อมูล |
B1 | ไอโอ | — | — | — | |
| รายการสัญญาณเอาท์พุต (เอกสาร) |
บี2 | ไอโอ | — | — | — | |
| รายการงานพัฒนา การก่อสร้าง, ไฟฟ้า, สุขาภิบาลและ ส่วนอื่นๆ โครงการที่เกี่ยวข้อง ด้วยการสร้างระบบ |
B3 | ที่ | เอ็กซ์ | — | อนุญาตให้รวม P2 ไว้ในเอกสารได้ | |
| หมายเหตุอธิบาย สู่โครงการด้านเทคนิค |
ป2 | หรือ | — | — | รวมถึงแผนการจัดงาน ในการเตรียมวัตถุสำหรับการป้อนข้อมูล ระบบต่างๆ เข้าสู่การดำเนินงาน |
|
| คำอธิบายของระบบอัตโนมัติ ฟังก์ชั่น |
ป3 | หรือ | — | — | — | |
| คำอธิบายของการตั้งค่างาน (ชุดของงาน) |
ป4 | หรือ | — | — | อนุญาตให้รวม ไปยังเอกสาร P2 หรือ P3 |
|
| คำอธิบายของข้อมูล สร้างความมั่นใจให้กับระบบ |
ป5 | ไอโอ | — | — | — | |
| คำอธิบายขององค์กร ฐานข้อมูล |
หน้า 6 | ไอโอ | — | — | — | |
| ทีพี | คำอธิบายของระบบการจำแนกประเภทและ การเข้ารหัส |
หน้า 7 | ไอโอ | — | — | — |
| คำอธิบายอาร์เรย์ ข้อมูล |
หน้า 8 | ไอโอ | — | — | — | |
| คำอธิบายของคอมเพล็กซ์ วิธีการทางเทคนิค |
หน้า 9 | ที่ | — | — | สำหรับงานนั้นอนุญาตให้รวมไว้ในเอกสาร 46 ตาม GOST 19.101 | |
| คำอธิบายของซอฟต์แวร์ บทบัญญัติ |
พีเอ | โดย | — | — | — | |
| คำอธิบายของอัลกอริทึม (ขั้นตอนโครงการ) |
พีบี | มอ | — | — | อนุญาตให้รวม P2, P3 หรือ P4 ในเอกสารได้ | |
| คำอธิบายขององค์กร โครงสร้าง |
พีวี | อู๋ | — | — | — | |
| แผนเค้าโครง | C8 | ที่ | เอ็กซ์ | — | อนุญาตให้รวม P9 ไว้ในเอกสารได้ | |
| รายการอุปกรณ์ และวัสดุ |
— | ที่ | เอ็กซ์ | — | — | |
| การคำนวณประมาณการท้องถิ่น | บี2 | หรือ | เอ็กซ์ | — | — | |
| ทีพี ถ | การประเมินโครงการ ความน่าเชื่อถือของระบบ |
B1 | หรือ | — | — | — |
| การเขียนแบบแบบฟอร์มเอกสาร (เฟรมวิดีโอ) |
C9 | ไอโอ | — | เอ็กซ์ | ในขั้นตอน TP จะได้รับอนุญาต รวมไว้ในเอกสาร P4 หรือ P5 |
|
| ถ | รายชื่อผู้ถือ ต้นฉบับ |
ดีพี* | หรือ | — | — | — |
| แผ่นปฏิบัติการ เอกสาร |
ED* | หรือ | — | เอ็กซ์ | — | |
| ข้อมูลจำเพาะของอุปกรณ์ | B4 | ที่ | เอ็กซ์ | — | — | |
| รายการข้อกำหนด ในวัสดุ |
B5 | ที่ | เอ็กซ์ | — | — | |
| สินค้าคงคลังสื่อเครื่องจักร ข้อมูล |
วีเอ็ม* | ไอโอ | — | เอ็กซ์ | — | |
| อาร์เรย์อินพุต | B6 | ไอโอ | — | เอ็กซ์ | — | |
| ถ | ไดเร็กทอรีฐานข้อมูล | B7 | ไอโอ | — | เอ็กซ์ | — |
| องค์ประกอบของข้อมูลที่ส่งออก (ข้อความ) |
B8 | ไอโอ | — | เอ็กซ์ | — | |
| ประมาณการท้องถิ่น | B3 | หรือ | เอ็กซ์ | — | — | |
| ระเบียบวิธี (เทคโนโลยี) อัตโนมัติ ออกแบบ |
I1 | อู๋ | — | เอ็กซ์ | — | |
| คำแนะนำทางเทคโนโลยี | I2 | อู๋ | — | เอ็กซ์ | — | |
| คู่มือการใช้งาน | I3 | อู๋ | — | เอ็กซ์ | — | |
| คำแนะนำในการขึ้นรูปและ การบำรุงรักษาฐานข้อมูล (ชุดข้อมูล) |
I4 | ไอโอ | — | เอ็กซ์ | — | |
| คำแนะนำการใช้งาน KTS | เช่น | ที่ | — | เอ็กซ์ | — | |
| แผนภาพการเดินสายไฟภายนอก | C4* | ที่ | เอ็กซ์ | — | อนุญาตให้ดำเนินการได้ใน ในรูปแบบของตาราง |
|
| แผนภาพการเชื่อมต่อ การโพสต์ภายนอก |
C5* | ที่ | เอ็กซ์ | — | เดียวกัน | |
| ตารางการเชื่อมต่อและการเชื่อมต่อ | ค6 | ที่ | เอ็กซ์ | — | — | |
| แผนภาพการแบ่งระบบ (โครงสร้าง) |
E1* | ที่ | — | — | — | |
| การวาดภาพทั่วไป | ใน* | ที่ | เอ็กซ์ | — | — | |
| ภาพวาดการติดตั้งอุปกรณ์ทางเทคนิค | SA | ที่ | เอ็กซ์ | — | — | |
| แผนผัง | เอสบี | ที่ | เอ็กซ์ | — | — | |
| แผนภาพโครงสร้างของคอมเพล็กซ์ วิธีการทางเทคนิค |
ค1* | ที่ | เอ็กซ์ | — | — | |
| แผนผังโครงร่างอุปกรณ์และสายไฟ | C7 | ที่ | เอ็กซ์ | — | — | |
| คำอธิบายของเทคโนโลยี กระบวนการประมวลผล ข้อมูล (รวมถึง การประมวลผลทางไกล) |
พีจี | อู๋ | — | เอ็กซ์ | — | |
| คำอธิบายทั่วไปของระบบ | พีดี | หรือ | — | เอ็กซ์ | — | |
| โปรแกรมทดสอบและวิธีการ (ส่วนประกอบ ระบบอัตโนมัติ ระบบย่อย ระบบ) |
PM* | หรือ | — | — | — | |
| รูปร่าง | สำหรับ* | หรือ | — | เอ็กซ์ | — | |
| หนังสือเดินทาง | ปล.* | หรือ | — | เอ็กซ์ | — | |
| *เอกสารที่มีการกำหนดรหัสตามข้อกำหนดของมาตรฐาน ESKD | ||||||
หมายเหตุถึงตาราง:
- สัญลักษณ์ต่อไปนี้ใช้ในตาราง:
- EP - การออกแบบเบื้องต้น
- TP - โครงการทางเทคนิค
- RD - เอกสารการทำงาน
- หรือ - โซลูชันทั้งระบบ
- OO - การตัดสินใจเกี่ยวกับการสนับสนุนองค์กร
- TO - โซลูชั่นสำหรับการสนับสนุนด้านเทคนิค
- IO - โซลูชั่นสำหรับการสนับสนุนข้อมูล
- ซอฟต์แวร์ - โซลูชันซอฟต์แวร์
- MO - โซลูชันซอฟต์แวร์
- เครื่องหมาย X ระบุว่าเป็นของประมาณการการออกแบบหรือเอกสารการปฏิบัติงาน
- ระบบการตั้งชื่อเอกสารที่มีชื่อเดียวกันนั้นขึ้นอยู่กับการตัดสินใจในการออกแบบระหว่างการสร้างระบบ
เมื่อกำหนดรายการเอกสารแล้วใน RD 50-34.698-90 คุณควรค้นหาเอกสารที่เลือกและพัฒนาอย่างเคร่งครัดตามจุดที่ระบุ จุดเนื้อหาทั้งหมดที่ระบุจะต้องอยู่ในเอกสาร
หากมีการพัฒนาข้อกำหนดทางเทคนิคคุณจะต้องเปิด GOST 34.602-89 ทันทีและพัฒนาข้อกำหนดทางเทคนิคอย่างเคร่งครัดตามประเด็นต่างๆ
GOST 19
ซีรี่ส์ GOST 19 (GOST 19.xxx Unified System of Program Documentation (USPD)) ประกอบด้วย:
- GOST 19.001-77 บทบัญญัติทั่วไป - เอกสารที่กว้างเกินไปไม่มีการใช้งานจริง ดังนั้นคุณสามารถข้ามไปได้
- GOST 19781-90 ข้อกำหนดและคำจำกัดความ - รายการที่ดีคำจำกัดความในด้านซอฟต์แวร์สำหรับระบบประมวลผลข้อมูล มันไม่มีอะไรมากไปกว่าคำจำกัดความ
- GOST 19.101-77 ประเภทของโปรแกรมและเอกสารโปรแกรม - หนึ่งในเอกสารหลักของ 19 GOST นี่คือที่ที่คุณควรเริ่มทำงานกับ GOST 19 เนื่องจากมีรายการและการกำหนดเอกสาร GOST ทั้งหมด
รายการเอกสาร 19 GOST
| รหัส | ประเภทเอกสาร | ขั้นตอนการพัฒนา | |||
| ร่าง โครงการ |
เทคนิค โครงการ |
ร่างการทำงาน | |||
| ส่วนประกอบ | ซับซ้อน | ||||
| — | ข้อมูลจำเพาะ | — | — | ||
| 05 | รายชื่อผู้ถือเดิม | — | — | — | |
| 12 | ข้อความโปรแกรม | — | — | ||
| 13 | คำอธิบายของโปรแกรม | — | — | ||
| 20 | รายการเอกสารการดำเนินงาน | — | — | ||
| 30 | รูปร่าง | — | — | ||
| 31 | คำอธิบายของแอปพลิเคชัน | — | — | ||
| 32 | คู่มือโปรแกรมเมอร์ระบบ | — | — | ||
| 33 | คู่มือโปรแกรมเมอร์ | — | — | ||
| 34 | คู่มือการใช้งาน | — | — | ||
| 35 | คำอธิบายภาษา | — | — | ||
| 46 | คู่มือทางเทคนิค บริการ |
— | — | ||
| 51 | โปรแกรมทดสอบและวิธีการ | — | — | ||
| 81 | หมายเหตุอธิบาย | — | — | ||
| 90-99 | เอกสารอื่นๆ | ||||
ตำนาน:
— เอกสารมีผลบังคับใช้
— เอกสารนี้จำเป็นสำหรับส่วนประกอบที่มีการใช้งานอย่างอิสระ
— ความจำเป็นในการจัดทำเอกสารจะพิจารณาในขั้นตอนของการพัฒนาและการอนุมัติข้อกำหนดทางเทคนิค
- - เอกสารไม่ได้จัดทำขึ้น
- GOST 19.102-77 ขั้นตอนของการพัฒนา - มีคำอธิบายขั้นตอนของการพัฒนา มีประโยชน์เพื่อการศึกษา ในความคิดของฉัน มันไม่มีประโยชน์ในทางปฏิบัติมากนัก
- GOST 19.103-77 การกำหนดโปรแกรมและเอกสารโปรแกรม - มีคำอธิบายการกำหนดหมายเลข (รหัส) ให้กับเอกสาร แม้หลังจากอ่าน GOST นี้แล้ว แต่ยังมีคำถามมากมายเกี่ยวกับวิธีกำหนดหมายเลขเดียวกันนี้ให้กับเอกสาร
- GOST 19.104-78 จารึกหลัก - กำหนดรูปร่างขนาดตำแหน่งและขั้นตอนการกรอกจารึกหลักของแผ่นอนุมัติและ หน้าชื่อเรื่องในเอกสารโปรแกรมที่จัดทำโดยมาตรฐาน ESPD โดยไม่คำนึงถึงวิธีการนำไปใช้งาน เนื่องจากเอกสาร 19 GOST ถูกวาดขึ้นในเฟรม เอกสารนี้จึงมีความสำคัญมาก
- GOST 19.105-78 ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม - กำหนดข้อกำหนดทั่วไปสำหรับการจัดทำเอกสารโปรแกรม ข้อกำหนดกว้างเกินไป ตามกฎแล้ว GOST นี้แทบจะไม่ได้ใช้ในการพัฒนาเอกสารเนื่องจาก GOST พิเศษสำหรับเอกสารก็เพียงพอแล้ว แต่สำหรับความรู้ทั่วไปก็ยังดีกว่าที่จะพิจารณา GOST นี้เพียงครั้งเดียว
- GOST 19.106-78 ข้อกำหนดสำหรับเอกสารโปรแกรมที่ดำเนินการในรูปแบบที่พิมพ์ - มีข้อกำหนดสำหรับการดำเนินการของเอกสารทั้งหมด 19 GOST
- GOST 19.201-78 ข้อกำหนดทางเทคนิคข้อกำหนดสำหรับเนื้อหาและการออกแบบ - กำหนดขั้นตอนในการสร้างและจัดเตรียมข้อกำหนดทางเทคนิคสำหรับการพัฒนาโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์
ข้อกำหนดทางเทคนิคของ 34 GOST และ 19 GOST นั้นแตกต่างกัน
- GOST 19.601-78 กฎทั่วไปสำหรับการทำซ้ำการบัญชีและการจัดเก็บ - กฎทั่วไปการทำซ้ำ การหมุนเวียน การบัญชี และการจัดเก็บเอกสารโปรแกรม GOST อธิบายไว้ในหลายประเด็นถึงวิธีการตรวจสอบให้แน่ใจว่าเอกสารไม่สูญหาย
- GOST 19.602-78 กฎสำหรับการทำซ้ำการบัญชีและการจัดเก็บเอกสารโปรแกรมการดำเนินการพิมพ์ วิธีการ - นอกเหนือจาก GOST 19.601-78
- GOST 19.603-78 กฎทั่วไปสำหรับการเปลี่ยนแปลง - กำหนดกฎทั่วไปสำหรับการเปลี่ยนแปลงเอกสารโปรแกรม โดยพื้นฐานแล้ว มันอธิบายอัลกอริธึมระบบราชการที่ยาวนานสำหรับการเปลี่ยนแปลงเอกสาร
- GOST 19.604-78 กฎสำหรับการเปลี่ยนแปลงเอกสารโปรแกรมที่พิมพ์ - อธิบายขั้นตอนการทำงานและการกรอกเอกสารการลงทะเบียนการเปลี่ยนแปลง
รายการ GOST เฉพาะทางซึ่งแต่ละรายการจะอธิบายเนื้อหาและข้อกำหนดสำหรับเอกสารเฉพาะ:
- ข้อกำหนด GOST 19.202-78 ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.301-79 โปรแกรมและวิธีการทดสอบ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.401-78 ข้อความของโปรแกรม ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.402-78 คำอธิบายของโปรแกรม
- GOST 19.403-79 รายชื่อผู้ถือดั้งเดิม
- GOST 19.404-79 คำอธิบายคำอธิบาย ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- แบบฟอร์ม GOST 19.501-78 ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.502-78 คำอธิบายแอปพลิเคชัน ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.503-79 คู่มือโปรแกรมเมอร์ระบบ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.504-79 คู่มือโปรแกรมเมอร์ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.505-79 คู่มือการใช้งาน ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.506-79 คำอธิบายภาษา ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
- GOST 19.507-79 คำชี้แจงเอกสารการปฏิบัติงาน
- GOST 19.508-79 แนวทางสำหรับ การซ่อมบำรุง- ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
ขั้นตอนการทำงานกับ 19 GOST:
- ใน GOST 19.101-77 ให้เลือกเอกสารและรหัสตามขั้นตอนของการพัฒนา
- ตาม GOST 19.103-77 ให้กำหนดหมายเลขให้กับเอกสาร
- จากนั้นตาม GOST 19.104-78 และ 19.106-78 ให้จัดทำเอกสาร
- จากรายการเฉพาะของ GOST คุณควรเลือกรายการที่สอดคล้องกับเอกสารที่กำลังพัฒนา
บทสรุป
GOST ไม่น่ากลัวและง่าย! สิ่งสำคัญคือการทำความเข้าใจว่าต้องเขียนอะไรและ GOST ใดที่ใช้สำหรับสิ่งนี้ GOST หลักของเรา 19 และ 34 สำหรับการเขียนเอกสารนั้นเก่ามาก แต่ยังคงมีความเกี่ยวข้องมาจนถึงทุกวันนี้ การเขียนเอกสารตามมาตรฐานช่วยขจัดปัญหามากมายระหว่างผู้รับเหมาและลูกค้า ดังนั้นจึงช่วยประหยัดเวลาและเงิน
วันที่แนะนำ 01/01/92
มาตรฐานนี้ใช้กับระบบอัตโนมัติ (AS) ที่ใช้ใน ประเภทต่างๆกิจกรรม (การวิจัย การออกแบบ การจัดการ ฯลฯ) รวมถึงการรวมกันที่ถูกสร้างขึ้นในองค์กร สมาคม และวิสาหกิจ (ต่อไปนี้จะเรียกว่าองค์กร)
มาตรฐานนี้กำหนดขั้นตอนและขั้นตอนของการสร้าง AS ภาคผนวก 1 แสดงเนื้อหางานในแต่ละขั้นตอน
1. ข้อกำหนดทั่วไป
2. ขั้นตอนและขั้นตอนของการสร้าง AS
ภาคผนวก 1 (สำหรับการอ้างอิง)
ภาคผนวก 2 (ข้อมูลอ้างอิง)
1. บทบัญญัติทั่วไป
1.1. คือชุดของงานที่สั่งการทันเวลา เชื่อมโยงถึงกัน รวมกันเป็นขั้นตอนและขั้นตอน ซึ่งการดำเนินการมีความจำเป็นและเพียงพอที่จะสร้างระบบอัตโนมัติที่ตรงตามข้อกำหนดที่กำหนด
1.2. ขั้นตอนและขั้นตอนของการสร้าง AS นั้นแตกต่างกันโดยเป็นส่วนหนึ่งของกระบวนการสร้างด้วยเหตุผลของการวางแผนอย่างมีเหตุผลและการจัดระเบียบงานที่ลงท้ายด้วยผลลัพธ์ที่กำหนด
1.3. งานเกี่ยวกับการพัฒนา AS นั้นดำเนินการตามขั้นตอนและขั้นตอนที่ใช้ในการสร้าง AS
1.4. องค์ประกอบและกฎเกณฑ์สำหรับการปฏิบัติงานในขั้นตอนและขั้นตอนที่กำหนดโดยมาตรฐานนี้ถูกกำหนดไว้ในเอกสารที่เกี่ยวข้องขององค์กรที่เข้าร่วมในการสร้างโรงไฟฟ้านิวเคลียร์ประเภทเฉพาะ
รายชื่อองค์กรที่เกี่ยวข้องกับการสร้างโรงไฟฟ้านิวเคลียร์แสดงไว้ในภาคผนวก 2
2. ขั้นตอนและขั้นตอนของการสร้าง AS
2.1. โดยทั่วไปขั้นตอนและขั้นตอนของการสร้าง AS จะแสดงอยู่ในตาราง
| ขั้นตอน | ขั้นตอนการทำงาน |
|---|---|
| 1. การกำหนดข้อกำหนดสำหรับวิทยากร | 1.1. การตรวจสอบโรงงานและเหตุผลความจำเป็นในการสร้างโรงไฟฟ้านิวเคลียร์ |
| 1.2. การสร้างข้อกำหนดของผู้ใช้สำหรับผู้พูด | |
| 1.3. การจัดทำรายงานเกี่ยวกับงานที่ทำและแอปพลิเคชันสำหรับการพัฒนา AS (ข้อกำหนดทางยุทธวิธีและทางเทคนิค) | |
| 2. การพัฒนาแนวคิด AC | 2.1. กำลังศึกษาวัตถุ |
| 2.2. ดำเนินงานวิจัยที่จำเป็น | |
| 2.3. การพัฒนาตัวเลือกแนวคิด AC และการเลือกตัวเลือกแนวคิด AC ที่ตรงตามความต้องการของผู้ใช้ | |
| 2.4. จัดทำรายงานเกี่ยวกับงานที่ทำ | |
| 3. เงื่อนไขการอ้างอิง | 3.1. การพัฒนาและการอนุมัติข้อกำหนดทางเทคนิคสำหรับการสร้างโรงไฟฟ้านิวเคลียร์ |
| 4. การออกแบบร่าง | 4.1. การพัฒนาโซลูชั่นการออกแบบเบื้องต้นสำหรับระบบและชิ้นส่วน |
| 4.2. การพัฒนาเอกสารสำหรับระบบลำโพงและส่วนประกอบต่างๆ | |
| 5. การออกแบบทางเทคนิค | 5.1. การพัฒนาโซลูชั่นการออกแบบสำหรับระบบและชิ้นส่วน |
| 5.2. การพัฒนาเอกสารสำหรับระบบลำโพงและส่วนประกอบต่างๆ | |
| 5.3. การพัฒนาและการดำเนินการเอกสารสำหรับการจัดหาผลิตภัณฑ์เพื่อให้เป็นไปตามข้อกำหนด NPP และ (หรือ) ข้อกำหนดทางเทคนิค (ข้อกำหนดทางเทคนิค) สำหรับการพัฒนา | |
| 5.4. การพัฒนางานออกแบบในส่วนที่อยู่ติดกันของโครงการสิ่งอำนวยความสะดวกระบบอัตโนมัติ | |
| 6. เอกสารการทำงาน | 6.1. การพัฒนาเอกสารการทำงานสำหรับระบบและส่วนประกอบต่างๆ |
| 6.2. การพัฒนาหรือดัดแปลงโปรแกรม | |
| 7. การป้อนข้อมูลและการดำเนินการ | 7.1. การเตรียมออบเจ็กต์อัตโนมัติสำหรับการนำ NPP ไปใช้งาน |
| 7.2. การฝึกอบรมบุคลากร | |
| 7.3. ชุดลำโพงครบชุดพร้อมผลิตภัณฑ์ที่ให้มา (ซอฟต์แวร์และฮาร์ดแวร์ ระบบซอฟต์แวร์และฮาร์ดแวร์ ผลิตภัณฑ์ข้อมูล) | |
| 7.4. งานก่อสร้างและติดตั้ง | |
| 7.5. การว่าจ้างงาน | |
| 7.6. ดำเนินการทดสอบเบื้องต้น | |
| 7.7. การดำเนินการทดลอง | |
| 7.8. ดำเนินการทดสอบการยอมรับ | |
| 8. รองรับไฟฟ้ากระแสสลับ | 8.1. ดำเนินงานตามภาระผูกพันในการรับประกัน |
| 8.2. บริการหลังการรับประกัน |
2.2. ขั้นตอนและเหตุการณ์สำคัญที่ดำเนินการโดยองค์กรที่เข้าร่วมในการสร้างโรงไฟฟ้านิวเคลียร์นั้นถูกกำหนดไว้ในสัญญาและข้อกำหนดทางเทคนิคตามมาตรฐานนี้
เป็นไปได้ที่จะยกเว้นขั้นตอน "การออกแบบร่าง" และขั้นตอนการทำงานแต่ละขั้นตอนในทุกขั้นตอน และรวมขั้นตอน "การออกแบบทางเทคนิค" และ "เอกสารการทำงาน" ไว้ในขั้นตอน "การออกแบบรายละเอียดทางเทคนิค" เดียว ขึ้นอยู่กับลักษณะเฉพาะของ AS ที่ถูกสร้างขึ้นและเงื่อนไขสำหรับการสร้างอนุญาตให้ดำเนินงานแต่ละขั้นตอนก่อนที่จะเสร็จสิ้นขั้นตอนก่อนหน้าการดำเนินการขั้นตอนการทำงานแบบขนานหรือรวมขั้นตอนใหม่ของงาน
ภาคผนวก 1. การอ้างอิง
1. ในขั้นตอนที่ 1.1 “การตรวจสอบสิ่งอำนวยความสะดวกและเหตุผลของความจำเป็นในการสร้าง NPP” ในกรณีทั่วไปจะดำเนินการดังต่อไปนี้:
- การรวบรวมข้อมูลเกี่ยวกับวัตถุอัตโนมัติและประเภทของกิจกรรมที่ดำเนินการ
- ประเมินคุณภาพการทำงานของสิ่งอำนวยความสะดวกและประเภทของกิจกรรมที่ดำเนินการ ระบุปัญหาที่สามารถแก้ไขได้โดยใช้เครื่องมืออัตโนมัติ
- การประเมิน (ทางเทคนิค เศรษฐกิจ สังคม ฯลฯ) ของความเป็นไปได้ในการสร้าง NPP
2. ในขั้นตอนที่ 1.2 “การสร้างข้อกำหนดของผู้ใช้สำหรับผู้พูด” มีการดำเนินการดังต่อไปนี้:
- การเตรียมข้อมูลเริ่มต้นสำหรับการสร้างข้อกำหนดสำหรับระบบอัตโนมัติ (ลักษณะของออบเจ็กต์ระบบอัตโนมัติ, คำอธิบายข้อกำหนดสำหรับระบบ, ข้อ จำกัด ของต้นทุนที่ยอมรับได้สำหรับการพัฒนา, การทดสอบการใช้งานและการดำเนินงาน, ผลที่คาดหวังจากระบบ, เงื่อนไขสำหรับการสร้าง และการทำงานของระบบ)
- การกำหนดและการดำเนินการตามความต้องการของผู้ใช้สำหรับวิทยากร
3. ในขั้นตอนที่ 1.3 “ การจัดทำรายงานเกี่ยวกับงานที่ทำและแอปพลิเคชันสำหรับการพัฒนา AS (ข้อกำหนดทางยุทธวิธีและทางเทคนิค)” รายงานเกี่ยวกับงานที่ดำเนินการในขั้นตอนนี้และแอปพลิเคชันสำหรับการพัฒนา AS (ทางยุทธวิธี) และข้อกำหนดทางเทคนิค) หรือเอกสารอื่นแทนที่ด้วยเนื้อหาที่คล้ายคลึงกัน
4. ในขั้นตอนที่ 2.1 “การศึกษาวัตถุ” และ 2.2 “การดำเนินการวิจัยที่จำเป็น” องค์กรพัฒนาดำเนินการศึกษารายละเอียดของวัตถุอัตโนมัติและงานวิจัยที่จำเป็น (R&D) ที่เกี่ยวข้องกับการค้นหาวิธีการและการประเมินความเป็นไปได้ของ ดำเนินการตามข้อกำหนดของผู้ใช้ จัดทำและอนุมัติรายงานการวิจัย
5. ในขั้นตอนที่ 2.3 “การพัฒนาตัวเลือกสำหรับแนวคิด AS และการเลือกตัวเลือกสำหรับแนวคิด AS ที่ตรงตามความต้องการของผู้ใช้” ในกรณีทั่วไปการพัฒนา ตัวเลือกอื่นแนวคิดของ AS ที่ถูกสร้างขึ้นและแผนการดำเนินงาน การประเมิน ทรัพยากรที่จำเป็นสำหรับการนำไปปฏิบัติและการดำเนินงาน การประเมินข้อดีและข้อเสียของแต่ละทางเลือก การเปรียบเทียบความต้องการของผู้ใช้และคุณลักษณะของระบบและการเลือกที่เสนอ ตัวเลือกที่ดีที่สุด- กำหนดขั้นตอนการประเมินคุณภาพและเงื่อนไขการรับระบบ การประเมินผลกระทบที่ได้รับจากระบบ
6. ในขั้นตอนที่ 2.4 “จัดทำรายงานเกี่ยวกับงานที่ทำ” จัดทำและจัดทำรายงานที่มีคำอธิบายของงานที่ดำเนินการในขั้นตอน คำอธิบายและเหตุผลของแนวคิดระบบเวอร์ชันที่เสนอ
7. ในขั้นตอนที่ 3.1 “การพัฒนาและการอนุมัติข้อกำหนดทางเทคนิคสำหรับการสร้างโรงไฟฟ้านิวเคลียร์” การพัฒนา การดำเนินการ การประสานงาน และการอนุมัติข้อกำหนดทางเทคนิคสำหรับโรงไฟฟ้านิวเคลียร์ และหากจำเป็น ข้อกำหนดทางเทคนิคสำหรับชิ้นส่วนของนิวเคลียร์ โรงไฟฟ้ากำลังดำเนินการ
8. ในขั้นตอนที่ 4.1 “การพัฒนาโซลูชันการออกแบบเบื้องต้นสำหรับระบบและชิ้นส่วน” กำหนด: หน้าที่ของ AS; หน้าที่ของระบบย่อย เป้าหมายและผลกระทบ องค์ประกอบของความซับซ้อนของงานและงานส่วนบุคคล แนวคิดเกี่ยวกับฐานข้อมูล โครงสร้างที่ขยายใหญ่ขึ้น ฟังก์ชั่นระบบการจัดการฐานข้อมูล องค์ประกอบของระบบคอมพิวเตอร์ ฟังก์ชั่นและพารามิเตอร์ของซอฟต์แวร์พื้นฐาน
9. ในขั้นตอนที่ 5.1 "การพัฒนาโซลูชันการออกแบบสำหรับระบบและชิ้นส่วน" พวกเขารับประกันการพัฒนาโซลูชันทั่วไปสำหรับระบบและชิ้นส่วนโครงสร้างฟังก์ชันอัลกอริธึมการทำงานของระบบหน้าที่ของบุคลากรและ โครงสร้างองค์กร, โครงสร้างของวิธีการทางเทคนิค, อัลกอริทึมสำหรับการแก้ปัญหาและภาษาที่ใช้, การจัดองค์กรและการบำรุงรักษาฐานข้อมูล, ระบบการจำแนกประเภทและการเข้ารหัสข้อมูล, บนซอฟต์แวร์
10. ที่ระยะ 4.2 และ 5.2" การพัฒนาเอกสาร"เกี่ยวกับ NPP และส่วนต่างๆ" ดำเนินการพัฒนา การดำเนินการ การประสานงาน และการอนุมัติเอกสารในขอบเขตที่จำเป็นเพื่ออธิบายชุดการตัดสินใจการออกแบบทั้งหมดที่ได้รับ และเพียงพอสำหรับการดำเนินงานต่อไปในการสร้าง NPP ประเภทของเอกสาร - ตาม GOST 34.201
11. ในขั้นตอนที่ 5.3 “ การพัฒนาและดำเนินการเอกสารสำหรับการจัดหาผลิตภัณฑ์เพื่อดำเนินการตาม NPP และ (หรือ) ข้อกำหนดทางเทคนิค (ข้อกำหนดทางเทคนิค) สำหรับการพัฒนา” การเตรียมและดำเนินการเอกสารสำหรับการจัดหาผลิตภัณฑ์เพื่อดำเนินการ NPP ให้เสร็จสิ้น ดำเนินการ; การกำหนดข้อกำหนดทางเทคนิคและจัดทำข้อกำหนดทางเทคนิคสำหรับการพัฒนาผลิตภัณฑ์ที่ไม่ได้ผลิตในปริมาณมาก
12. ในขั้นตอนที่ 5.4 “ การพัฒนาการมอบหมายการออกแบบในส่วนที่อยู่ติดกันของโครงการระบบอัตโนมัติ” พวกเขาดำเนินการพัฒนา ดำเนินการ ประสานงานและการอนุมัติการมอบหมายการออกแบบในส่วนที่อยู่ติดกันของโครงการออบเจ็กต์ระบบอัตโนมัติเพื่อดำเนินการก่อสร้าง ไฟฟ้า สุขาภิบาลและ งานเตรียมการอื่น ๆ ที่เกี่ยวข้องกับการสร้าง AC
13. ในขั้นตอน 6.1 “ การพัฒนาเอกสารการทำงานสำหรับระบบและชิ้นส่วน” เอกสารการทำงานได้รับการพัฒนาซึ่งมีข้อมูลที่จำเป็นและเพียงพอทั้งหมดเพื่อให้แน่ใจว่าการดำเนินงานในการนำ NPP ไปสู่การดำเนินงานและการดำเนินงานตลอดจนการรักษา ระดับของลักษณะการปฏิบัติงาน (คุณภาพ) ของระบบตามการตัดสินใจออกแบบที่นำมาใช้ การดำเนินการ การประสานงาน และการอนุมัติ ประเภทของเอกสาร - ตาม GOST 34.201
14. ในขั้นตอนที่ 6.2 “การพัฒนาหรือดัดแปลงโปรแกรม” โปรแกรมและซอฟต์แวร์ระบบได้รับการพัฒนา การเลือก ดัดแปลง และ (หรือ) การเชื่อมโยงซอฟต์แวร์ที่ซื้อมา และการพัฒนาเอกสารประกอบของโปรแกรมตาม GOST 19.101
15. ในขั้นตอนที่ 7.1 “ การเตรียมออบเจ็กต์ระบบอัตโนมัติสำหรับการนำโรงงานไปใช้งาน” งานจะดำเนินการในการเตรียมองค์กรของออบเจ็กต์ระบบอัตโนมัติสำหรับการนำโรงงานไปใช้งาน รวมถึง: การใช้โซลูชันการออกแบบสำหรับโครงสร้างองค์กรของ ปลูก; จัดเตรียมสื่อการสอนและระเบียบวิธีให้กับแผนกต่างๆ ของสถานที่จัดการ การใช้ตัวแยกประเภทข้อมูล
16. ในขั้นตอนที่ 7.2 "การฝึกอบรมบุคลากร" บุคลากรจะได้รับการฝึกอบรมและมีการตรวจสอบความสามารถในการตรวจสอบการทำงานของโรงงาน
17. ในขั้นตอน "การจัดเตรียมลำโพงให้สมบูรณ์ด้วยผลิตภัณฑ์ที่ให้มา" พวกเขารับประกันว่าจะได้รับส่วนประกอบ วัสดุ และผลิตภัณฑ์การติดตั้งแบบอนุกรมและแบบแยกส่วน มีการควบคุมคุณภาพที่เข้ามา
18. ในขั้นตอนที่ 7.4 “ งานก่อสร้างและติดตั้ง” มีการดำเนินการดังต่อไปนี้: งานเกี่ยวกับการก่อสร้างอาคารเฉพาะ (สถานที่) เพื่อรองรับอุปกรณ์ทางเทคนิคและบุคลากร NPP การก่อสร้างช่องเคเบิล ปฏิบัติงานติดตั้งอุปกรณ์ทางเทคนิคและสายสื่อสาร การทดสอบอุปกรณ์ทางเทคนิคที่ติดตั้ง การส่งมอบอุปกรณ์ทางเทคนิคสำหรับการว่าจ้าง
19. ในขั้นตอนที่ 7.5 "การว่าจ้าง" พวกเขาดำเนินการปรับแต่งฮาร์ดแวร์และซอฟต์แวร์โดยอัตโนมัติ โหลดข้อมูลลงในฐานข้อมูลและตรวจสอบระบบเพื่อบำรุงรักษา การตั้งค่าเครื่องมือระบบทั้งหมดอย่างครอบคลุม
20. ในขั้นตอนที่ 7.6 “การดำเนินการทดสอบเบื้องต้น” ให้ดำเนินการดังต่อไปนี้:
- การทดสอบลำโพงในการใช้งานและการปฏิบัติตามข้อกำหนดทางเทคนิคตามโปรแกรมและวิธีการทดสอบเบื้องต้น
- การแก้ไขปัญหาและการเปลี่ยนแปลงเอกสาร NPP รวมถึงเอกสารการปฏิบัติงานตามรายงานการทดสอบ
- การดำเนินการยอมรับ NPP เพื่อดำเนินการทดลอง
21. ในขั้นตอนที่ 7.7 "การดำเนินการทดลอง" จะมีการดำเนินการทดลองของ NPP การวิเคราะห์ผลการดำเนินการทดลองของ NPP การดัดแปลง (หากจำเป็น) ของซอฟต์แวร์ AS การปรับเพิ่มเติม (ถ้าจำเป็น) ของอุปกรณ์ทางเทคนิคของ NPP การดำเนินการรับรองการดำเนินการทดลองให้เสร็จสิ้น
22. ในขั้นตอนที่ 7.8 “การดำเนินการทดสอบการยอมรับ” จะดำเนินการดังต่อไปนี้:
- การทดสอบการปฏิบัติตามข้อกำหนดทางเทคนิคตามโปรแกรมและวิธีการทดสอบการยอมรับ
- การวิเคราะห์ผลการทดสอบ AS และการกำจัดข้อบกพร่องที่ระบุในระหว่างการทดสอบ
- การดำเนินการยอมรับ NPP เพื่อดำเนินการถาวร
23. ในขั้นตอนที่ 8.1 “ การปฏิบัติงานตามภาระผูกพันในการรับประกัน” งานจะดำเนินการเพื่อกำจัดข้อบกพร่องที่ระบุระหว่างการดำเนินงานของ NPP ในช่วงระยะเวลาการรับประกันที่กำหนดและเพื่อทำการเปลี่ยนแปลงที่จำเป็นในเอกสารประกอบสำหรับ NPP
24. ในขั้นตอนที่ 8.2 งาน "บริการหลังการรับประกัน" ดำเนินการใน:
- การวิเคราะห์การทำงานของระบบ
- การระบุความเบี่ยงเบนของลักษณะการปฏิบัติงานที่แท้จริงของ NPP จากค่าการออกแบบ
- การกำหนดสาเหตุของการเบี่ยงเบนเหล่านี้
- ขจัดข้อบกพร่องที่ระบุและสร้างความมั่นใจเสถียรภาพของลักษณะการปฏิบัติงานของ NPP
- ทำการเปลี่ยนแปลงที่จำเป็นในเอกสารสำหรับผู้บรรยาย
ภาคผนวก 2. การอ้างอิง
รายชื่อองค์กรที่เข้าร่วมในการสร้าง AU
1. องค์กรลูกค้า (ผู้ใช้) ที่จะสร้าง NPP และจัดหาเงินทุน การยอมรับงานและการดำเนินงานของ NPP รวมถึงการดำเนินงานของแต่ละบุคคลในการสร้าง NPP
2. องค์กรพัฒนาซึ่งดำเนินงานเกี่ยวกับการจัดตั้ง NPP ให้บริการลูกค้าด้วยชุดบริการทางวิทยาศาสตร์และทางเทคนิคสำหรับ ขั้นตอนที่แตกต่างกันและขั้นตอนการสร้างสรรค์ ตลอดจนการพัฒนาและจัดหาซอฟต์แวร์และเครื่องมือฮาร์ดแวร์ต่างๆ สำหรับ AS
3. องค์กรซัพพลายเออร์ที่ผลิตและจัดหาซอฟต์แวร์และฮาร์ดแวร์ตามคำสั่งของผู้พัฒนาหรือลูกค้า
4. ผู้ออกแบบทั่วไปขององค์กรสิ่งอำนวยความสะดวกอัตโนมัติ
5. องค์กรออกแบบ ส่วนต่างๆการออกแบบสิ่งอำนวยความสะดวกอัตโนมัติสำหรับงานก่อสร้าง งานไฟฟ้า สุขาภิบาล และงานเตรียมการอื่น ๆ ที่เกี่ยวข้องกับการสร้างโรงไฟฟ้านิวเคลียร์
6. การก่อสร้าง การติดตั้ง การว่าจ้าง และองค์กรอื่นๆ
หมายเหตุ:
1. ขึ้นอยู่กับเงื่อนไขในการสร้าง NPP การผสมผสานฟังก์ชันต่างๆ ของลูกค้า ผู้พัฒนา ซัพพลายเออร์ และองค์กรอื่น ๆ ที่เกี่ยวข้องในการสร้าง NPP เป็นไปได้
2. ขั้นตอนและขั้นตอนของงานที่พวกเขาทำเพื่อสร้าง AS จะถูกกำหนดบนพื้นฐานของมาตรฐานนี้
ข้อมูลสารสนเทศ
1. พัฒนาและแนะนำโดยคณะกรรมการแห่งรัฐสหภาพโซเวียตเพื่อการจัดการคุณภาพและมาตรฐานผลิตภัณฑ์
นักพัฒนา
ยู.เอช. Vermishev ปริญญาเอกสาขาวิศวกรรมศาสตร์ วิทยาศาสตร์; ย.จี. วิเลนชิค; วี.ไอ. โวโรปาเยฟ ปริญญาเอก สาขาวิศวกรรมศาสตร์ วิทยาศาสตร์; แอล.เอ็ม. ไซเดนเบิร์ก, Ph.D. เทคโนโลยี วิทยาศาสตร์; ยู.บี. ไอร์ซปริญญาเอก เทคโนโลยี วิทยาศาสตร์; วี.ดี. Kostyukov, Ph.D. เทคโนโลยี วิทยาศาสตร์; ศศ.ม. ลาบูติน คอนดิชันเนอร์ เทคโนโลยี วิทยาศาสตร์; เอ็น.พี. เลสคอฟสกายา; เป็น. มิทยาเยฟ; วี.เอฟ. โปปอฟ (ผู้นำหัวข้อ); เอส.วี. การชินา; AI. หูหนวก; ใต้. จูคอฟ, Ph.D. วิทยาศาสตร์; ซี.พี. ซาดูบอฟสกายา; วี.จี. อีวานอฟ; ยูไอ คาราวานอฟ, Ph.D. วิทยาศาสตร์; เอเอ โคลชคอฟ; วี.ยู. โคโรเลฟ; วี.ไอ. มัคนาช, Ph.D. เทคโนโลยี วิทยาศาสตร์; เอส.บี. มิคาเลฟ ปริญญาเอก สาขาวิศวกรรมศาสตร์ วิทยาศาสตร์; วี.เอ็น. เพทริเควิช; วีเอ รัคมานอฟ, Ph.D. เศรษฐกิจ วิทยาศาสตร์; เอเอ รัตโควิช; อาร์.เอส. Sedegov ปริญญาเอกเศรษฐศาสตร์ วิทยาศาสตร์; เอ็น.วี. สเตปันชิโควา; วิทยาศาสตรมหาบัณฑิต สุโรเวตส์; เอ.วี. เฟลเจนตอฟ; แอล.โอ. Khvilevsky, Ph.D. เทคโนโลยี วิทยาศาสตร์; วี.เค. คริสตอฟ, Ph.D. เศรษฐกิจ วิทยาศาสตร์
2. ได้รับการอนุมัติและมีผลบังคับใช้โดยมติของคณะกรรมการรัฐสหภาพโซเวียตเพื่อการจัดการคุณภาพและมาตรฐานผลิตภัณฑ์ลงวันที่ 29 ธันวาคม 2533 ฉบับที่ 3469
