GOST กับเอกสารประเภทซอฟต์แวร์ จัดทำเอกสารประกอบโปรแกรมตาม GOST อัลกอริธึมการออกแบบโปรแกรมโดยย่อ

วันที่แนะนำ ตั้งแต่ 01.01.80 น

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

มาตรฐานนี้สอดคล้องกับ ST SEV 1626-79 อย่างสมบูรณ์

1. ประเภทของโปรแกรม

1.1. โปรแกรม (ตาม GOST 19781-90) สามารถระบุและใช้งานได้อย่างอิสระและ (หรือ) เป็นส่วนหนึ่งของโปรแกรมอื่น

1.2. โปรแกรมแบ่งออกเป็นประเภทตามตาราง 1

ตารางที่ 1

1.3. เอกสารที่พัฒนาขึ้นสำหรับโปรแกรมสามารถใช้สำหรับการนำไปใช้และถ่ายโอนโปรแกรมบนสื่อบันทึกข้อมูล เช่นเดียวกับการผลิตผลิตภัณฑ์ซอฟต์แวร์

1.2,1.3.

2. ประเภทของเอกสารโปรแกรม

2.1. เอกสารซอฟต์แวร์ประกอบด้วยเอกสารที่มีข้อมูลที่จำเป็นสำหรับการพัฒนา การผลิต การบำรุงรักษา และการทำงานของโปรแกรม

2.2. ประเภทของเอกสารโปรแกรมและเนื้อหามีอยู่ในตาราง 2.

ตารางที่ 2

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

(แก้ไขฉบับแก้ไขครั้งที่ 1)

2.3. ประเภทของเอกสารการปฏิบัติงานและเนื้อหาแสดงไว้ในตารางที่ 3

ตารางที่ 3

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

(แก้ไขฉบับแก้ไขครั้งที่ 1)

2.4. เอกสารโปรแกรมแบ่งออกเป็นต้นฉบับ ทำซ้ำและคัดลอก (GOST 2.102-68) ขึ้นอยู่กับวิธีการนำไปใช้และลักษณะของแอปพลิเคชัน ซึ่งมีไว้สำหรับการพัฒนา การบำรุงรักษา และการทำงานของโปรแกรม

2.5. ประเภทของเอกสารโปรแกรมที่พัฒนาในขั้นตอนต่างๆ และรหัสจะมีระบุไว้ในตารางคลิก 4.

ตารางที่ 4

รหัสประเภทเอกสาร	ประเภทเอกสาร	ขั้นตอนการพัฒนา
		การออกแบบเบื้องต้น	โครงการด้านเทคนิค	ร่างการทำงาน
		การออกแบบเบื้องต้น	โครงการด้านเทคนิค	ส่วนประกอบ	ซับซ้อน
-	ข้อมูลจำเพาะ	-	-
05	รายชื่อผู้ถือเดิม	-	-	-
12	ข้อความโปรแกรม	-	-
13	คำอธิบายโปรแกรม	-	-
20	รายการเอกสารการดำเนินงาน	-	-
30	รูปร่าง	-	-
31	คำอธิบายของแอปพลิเคชัน	-	-
32	คู่มือโปรแกรมเมอร์ระบบ	-	-
33	คู่มือโปรแกรมเมอร์	-	-
34	คู่มือการใช้งาน	-	-
35	คำอธิบายภาษา	-	-
46	คู่มือการบำรุงรักษา	-	-
51	โปรแกรมทดสอบและวิธีการ	-	-
81	หมายเหตุอธิบาย			-	-
90-99	เอกสารอื่นๆ

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

2.2-2.5. (แก้ไขฉบับแก้ไขครั้งที่ 1)

2.6. อนุญาตให้รวมเอกสารการปฏิบัติงานบางประเภทได้ (ยกเว้นรายการเอกสารการปฏิบัติงานและแบบฟอร์ม) ความจำเป็นในการรวมเอกสารเหล่านี้ระบุไว้ในข้อกำหนดทางเทคนิค เอกสารที่ผสานได้รับการกำหนดชื่อและการกำหนดเอกสารที่ผสานอย่างใดอย่างหนึ่ง

เอกสารที่ผสานจะต้องระบุข้อมูลที่จะต้องรวมไว้ในเอกสารแต่ละฉบับที่จะผสาน

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

ข้อมูลจำเพาะทางเทคนิคได้รับการพัฒนาในขั้นตอน "การออกแบบโดยละเอียด"

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

(แนะนำเพิ่มเติม แก้ไขครั้งที่ 1)

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

เมื่อโปรแกรมเมอร์ได้รับงานในการพัฒนาโปรแกรม เขา ผู้จัดการโครงการ และทีมงานโครงการทั้งหมด ต้องเผชิญกับคำถามต่อไปนี้:

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

นอกจากประเด็นที่กล่าวมาก็ยังมีเรื่องอื่นๆ อีกมากมาย

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

จนถึงทุกวันนี้คำถามเกี่ยวกับการมีอยู่ของระบบมาตรฐานที่ควบคุมเอกสารของโปรแกรมที่พัฒนาแล้วยังคงมีความเกี่ยวข้อง

2. ลักษณะทั่วไปของภาวะ

พื้นฐานของกรอบการกำกับดูแลภายในประเทศในด้านเอกสารโปรแกรมคือชุดมาตรฐานของ Unified System of Program Documentation (USPD) ส่วนหลักและส่วนใหญ่ของอาคารแห่งนี้ได้รับการพัฒนาในช่วงทศวรรษที่ 70 และ 80 ในขณะนี้ คอมเพล็กซ์นี้แสดงถึงระบบมาตรฐานระหว่างรัฐของประเทศ CIS ที่ดำเนินงานในอาณาเขตของสหพันธรัฐรัสเซีย บนพื้นฐานของข้อตกลงระหว่างรัฐในเรื่องมาตรฐาน

มาตรฐาน ESPD ครอบคลุมส่วนหนึ่งของเอกสารที่สร้างขึ้นในระหว่างกระบวนการพัฒนาโปรแกรม และเกี่ยวข้องกับการจัดทำเอกสารคุณลักษณะการทำงาน อย่าลืมว่ามาตรฐาน ESPD (GOST 19) มีลักษณะเป็นคำแนะนำ อย่างไรก็ตาม สิ่งนี้ยังใช้กับมาตรฐานอื่น ๆ ในด้านการพัฒนาซอฟต์แวร์ด้วย เช่น GOST 34, มาตรฐานสากล ISO/IEC เป็นต้น ตามกฎหมายของสหพันธรัฐรัสเซีย "ว่าด้วยการมาตรฐาน" มาตรฐานเหล่านี้จะมีผลบังคับใช้เฉพาะใน พื้นฐานตามสัญญา - นั่นคือตามการอ้างอิงในข้อตกลงการพัฒนาโปรแกรม

เมื่อพูดถึงสถานะของ ESPD โดยรวมอาจกล่าวได้ว่ามาตรฐานส่วนใหญ่ล้าสมัยด้านศีลธรรม

ถึงข้อเสียเปรียบหลัก อีเอสพีดีสามารถนำมาประกอบได้:

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

เป็นไปตามนั้น ESPD จำเป็นต้องมีการแก้ไขทั้งหมดตามมาตรฐาน ISO/IEC 12207-95 (มาตรฐานนี้จะกล่าวถึงในรายละเอียดเพิ่มเติมด้านล่าง)

เป็นที่น่าสังเกตว่านอกเหนือจาก ESPD แล้ว ยังมีมาตรฐานที่มีแนวโน้มหลายประการในกรอบการกำกับดูแลอย่างเป็นทางการของสหพันธรัฐรัสเซียในด้านโปรแกรมการจัดทำเอกสารและด้านที่เกี่ยวข้อง เช่น:

มาตรฐานสากล ISO/IEC 12207: 1995-08-01เพื่อจัดระเบียบวงจรชีวิตของผลิตภัณฑ์ซอฟต์แวร์

มาตรฐานที่ซับซ้อน GOST 34สำหรับการสร้างและพัฒนาระบบอัตโนมัติ

2.1. คำอธิบายโดยย่อเกี่ยวกับมาตรฐาน ESPD ที่มีอยู่

แม้ว่าจะมีข้อบกพร่อง มาตรฐาน ESPD จำนวนมากก็สามารถนำมาใช้อย่างมีประโยชน์ในการจัดทำเอกสารโปรแกรมได้ เนื่องจาก:

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

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

มาตรฐาน ESPD แบ่งออกเป็นกลุ่มที่แสดงในตาราง:

การกำหนดมาตรฐาน ESPD ขึ้นอยู่กับเกณฑ์การจำแนกประเภท:

การกำหนดมาตรฐาน ESPD จะต้องประกอบด้วย:

หมายเลข 19 (กำหนดให้กับคลาสมาตรฐาน ESPD)
หนึ่งหลัก (หลังจุด) ระบุรหัสของกลุ่มการจำแนกมาตรฐานที่ระบุในตาราง
ตัวเลขสองหลัก (หลังขีดกลาง) ระบุปีที่จดทะเบียนมาตรฐาน

รายการเอกสาร ESPD:

GOST 19.001-77 อีเอสพีดี บทบัญญัติทั่วไป
GOST 19.101-77 ESPD ประเภทของโปรแกรมและเอกสารโปรแกรม
GOST 19.102-77 ESPD ขั้นตอนการพัฒนา
GOST 19.103-77 ESPD การกำหนดโปรแกรมและเอกสารโปรแกรม
GOST 19.104-78 อีเอสพีดี จารึกพื้นฐาน
GOST 19.105-78 อีเอสพีดี ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม
GOST 19.106-78 อีเอสพีดี ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์
GOST 19.201-78 อีเอสพีดี งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.202-78 อีเอสพีดี ข้อมูลจำเพาะ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.301-79 อีเอสพีดี ขั้นตอนและวิธีการทดสอบ
GOST 19.401-78 อีเอสพีดี ข้อความโปรแกรม ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.402-78 อีเอสพีดี คำอธิบายโปรแกรม
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.508-79 อีเอสพีดี คู่มือการบำรุงรักษา ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.604-78 อีเอสพีดี กฎสำหรับการเปลี่ยนแปลงเอกสารโปรแกรมที่ดำเนินการในรูปแบบการพิมพ์
GOST 19.701-90 ESPD แผนผังของอัลกอริธึม โปรแกรม ข้อมูล และระบบ อนุสัญญาและกฎการดำเนินการ
GOST 19.781-90 ซอฟต์แวร์สำหรับระบบประมวลผลข้อมูล

ข้อกำหนดและคำจำกัดความ

จากมาตรฐาน ESPD ทั้งหมด เราจะมุ่งเน้นไปที่มาตรฐานที่สามารถนำมาใช้บ่อยกว่าในการฝึกปฏิบัติการพัฒนาโปรแกรม

มาตรฐานแรกที่สามารถใช้เมื่อสร้างข้อกำหนดทางเทคนิคสำหรับการเขียนโปรแกรมคือ GOST (ST SEV) 19.201-78 (1626-79) อีเอสพีดี.
(ข้อกำหนดทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ)

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

เงื่อนไขการอ้างอิงสำหรับการพัฒนาโปรแกรมจะต้องมีส่วนต่อไปนี้:

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

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

มาตรฐานที่สองคือ GOST (ST SEV) 19.101-77 (1626-79) อีเอสพีดี.
ประเภทของโปรแกรมและเอกสารโปรแกรม)
มาตรฐานนี้กำหนดประเภทของโปรแกรมและเอกสารโปรแกรมสำหรับคอมพิวเตอร์ อาคารและระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขต

ประเภทของโปรแกรม:

ประเภทของเอกสารโปรแกรม:

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

ประเภทของเอกสารการปฏิบัติงาน:

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

เอกสารโปรแกรมแบ่งออกเป็นต้นฉบับ สำเนา และสำเนา (GOST 2.102-68) ขึ้นอยู่กับวิธีการนำไปใช้และลักษณะของแอปพลิเคชัน ซึ่งมีไว้สำหรับการพัฒนา การบำรุงรักษา และการทำงานของโปรแกรม

ประเภทของเอกสารโปรแกรมที่พัฒนาในแต่ละขั้นตอนและรหัส:

รหัสประเภทเอกสาร	ประเภทเอกสาร	ขั้นตอนการพัฒนา
		การออกแบบเบื้องต้น	โครงการด้านเทคนิค	ร่างการทำงาน
		การออกแบบเบื้องต้น	โครงการด้านเทคนิค	ส่วนประกอบ	ซับซ้อน
-	ข้อมูลจำเพาะ	-	-	!	+
05	รายชื่อผู้ถือเดิม	-	-	-	?
12	ข้อความโปรแกรม	-	-	+	?
13	คำอธิบายโปรแกรม	-	-	?	?
20	รายการเอกสารการดำเนินงาน	-	-	?	?
30	รูปร่าง	-	-	?	?
31	คำอธิบายของแอปพลิเคชัน	-	-	?	?
32	คู่มือโปรแกรมเมอร์ระบบ	-	-	?	?
33	คู่มือโปรแกรมเมอร์	-	-	?	?
34	คู่มือการใช้งาน	-	-	?	?
35	คำอธิบายภาษา	-	-	?	?
46	คู่มือการบำรุงรักษา	-	-	?	?
51	โปรแกรมทดสอบและวิธีการ	-	-	?	?
81	หมายเหตุอธิบาย	?	?	-	-
90-99	เอกสารอื่นๆ	?	?	?	?

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

…………………………………………………………

GOST 19.102-77 อีเอสพีดี. ขั้นตอนการพัฒนา

กำหนดขั้นตอนการพัฒนาโปรแกรมและเอกสารประกอบโปรแกรมสำหรับคอมพิวเตอร์ อาคารและระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขตการใช้งาน

ขั้นตอนการพัฒนาโปรแกรม ขั้นตอน และเนื้อหางาน

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

หมายเหตุ:

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

GOST 19.103-77 ESPD การกำหนดโปรแกรมและเอกสารโปรแกรม

รหัสประเทศของนักพัฒนาและรหัสองค์กรของนักพัฒนาได้รับการกำหนดในลักษณะที่กำหนด

หมายเลขทะเบียนถูกกำหนดโดยเรียงลำดับจากน้อยไปมาก เริ่มตั้งแต่ 00001 ถึง 99999 สำหรับแต่ละองค์กรเพื่อการพัฒนา
หมายเลขสิ่งพิมพ์ของโปรแกรมหรือหมายเลขแก้ไข จำนวนเอกสารประเภทนี้จำนวนส่วนของเอกสารถูกกำหนดตามลำดับจากน้อยไปมากจาก 01 ถึง 99 (หากเอกสารประกอบด้วยส่วนหนึ่งส่วนจะไม่มีการระบุยัติภังค์และหมายเลขซีเรียลของชิ้นส่วน)
หมายเลขการแก้ไขข้อกำหนดและรายการเอกสารการปฏิบัติงานสำหรับโปรแกรมจะต้องตรงกับหมายเลขการเผยแพร่ของโปรแกรมเดียวกัน

GOST 19.105-78 อีเอสพีดี ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม

มาตรฐานนี้กำหนดข้อกำหนดทั่วไปสำหรับการดำเนินการเอกสารโปรแกรมสำหรับคอมพิวเตอร์ คอมเพล็กซ์ และระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขตของการใช้งาน และจัดทำโดยมาตรฐานของ Unified System of Program Documentation (USPD) สำหรับวิธีการใด ๆ ในการดำเนินการเอกสารในหัวข้อต่างๆ ผู้ให้บริการข้อมูล

เอกสารโปรแกรมสามารถนำเสนอบนสื่อบันทึกข้อมูลประเภทต่างๆ และประกอบด้วยชิ้นส่วนทั่วไปดังต่อไปนี้:
ชื่อ;
ข้อมูล;
ขั้นพื้นฐาน.

กฎสำหรับการดำเนินการของเอกสารและส่วนต่าง ๆ ของผู้ให้บริการข้อมูลแต่ละรายนั้นถูกกำหนดโดยมาตรฐาน ESPD สำหรับกฎสำหรับการดำเนินการของเอกสารในผู้ให้บริการข้อมูลที่เกี่ยวข้อง

GOST 19.106-78 อีเอสพีดี ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์

เอกสารโปรแกรมจัดทำโดย:

บนแผ่นงานรูปแบบ A4 (GOST 2.301-68) เมื่อเตรียมเอกสารด้วยการพิมพ์หรือเขียนด้วยลายมือ
สามารถพิมพ์บนแผ่นขนาด A3;
ด้วยวิธีการใช้เครื่องในการดำเนินการเอกสารอนุญาตให้มีการเบี่ยงเบนขนาดของแผ่นงานที่สอดคล้องกับรูปแบบ A4 และ A3 โดยพิจารณาจากความสามารถของวิธีการทางเทคนิคที่ใช้ บนแผ่นงานรูปแบบ A4 และ A3 ซึ่งจัดทำโดยลักษณะเอาต์พุตของอุปกรณ์เอาต์พุตข้อมูลเมื่อสร้างเอกสารด้วยเครื่องจักร
บนแผ่นงานรูปแบบการพิมพ์เมื่อผลิตเอกสารโดยใช้วิธีพิมพ์

เนื้อหาของเอกสารโปรแกรมจะจัดเรียงตามลำดับต่อไปนี้:

ส่วนของชื่อเรื่อง:

เอกสารอนุมัติ (ไม่รวมอยู่ในจำนวนแผ่นงานทั้งหมดของเอกสาร)
หน้าชื่อเรื่อง (หน้าแรกของเอกสาร);

ส่วนข้อมูล:

คำอธิบายประกอบ;
สารบัญ;

ส่วนสำคัญ:

ข้อความในเอกสาร (พร้อมรูปภาพ ตาราง ฯลฯ)
รายการคำศัพท์และคำจำกัดความ
รายการคำย่อ
การใช้งาน;
ดัชนีหัวเรื่อง;
รายการเอกสารอ้างอิง

เปลี่ยนส่วนการบันทึก:

เปลี่ยนใบทะเบียน

รายการคำศัพท์และคำจำกัดความ รายการคำย่อ ภาคผนวก ดัชนีหัวเรื่อง รายการเอกสารอ้างอิงจะมีให้หากจำเป็น

มาตรฐานต่อไปนี้มุ่งเน้นไปที่การบันทึกผลลัพธ์ของผลิตภัณฑ์การพัฒนา:

GOST 19.402-78 อีเอสพีดี คำอธิบายโปรแกรม

องค์ประกอบของเอกสาร "คำอธิบายโปรแกรม" ในเนื้อหาสามารถเสริมด้วยส่วนและย่อหน้าที่นำมาจากมาตรฐานสำหรับเอกสารอธิบายและคู่มืออื่น ๆ : GOST 19.404-79 ESPD คำอธิบาย GOST 19.502-78 ESPD คำอธิบายแอปพลิเคชัน GOST 19.503-79 ESPD คู่มือโปรแกรมเมอร์ระบบ GOST 19.504-79 ESPD คู่มือโปรแกรมเมอร์ GOST 19.505-79 ESPD คู่มือการใช้งาน

นอกจากนี้ยังมีกลุ่มมาตรฐานที่กำหนดข้อกำหนดสำหรับการบันทึกชุดโปรแกรมทั้งหมดและ PD ที่จัดทำขึ้นเพื่อการถ่ายโอนซอฟต์แวร์ พวกเขาสร้างเอกสารทางบัญชีที่กระชับและมีประโยชน์ในการปรับปรุงการจัดการโปรแกรมและ PD ทั้งหมดให้มีประสิทธิภาพ (บ่อยครั้งมากที่คุณเพียงแค่ต้องเรียกคืนลำดับพื้นฐาน!) นอกจากนี้ยังมีมาตรฐานที่กำหนดหลักเกณฑ์ในการเก็บรักษาเอกสารใน “ครัวเรือน” ของ ป.ล.

เราต้องเน้นด้วย

GOST 19.301-79 อีเอสพีดี โปรแกรมทดสอบและวิธีการซึ่ง (ในรูปแบบดัดแปลง) สามารถใช้ในการพัฒนาเอกสารการวางแผนและดำเนินการทดสอบเพื่อประเมินความพร้อมและคุณภาพของสถานีไฟฟ้าย่อย

ในที่สุดมาตรฐานล่าสุดตามปีที่นำมาใช้

GOST 19.701-90 ESPD แผนผังของอัลกอริธึม โปรแกรม ข้อมูล และระบบ การกำหนดกราฟิกแบบทั่วไปและกฎการดำเนินการ

โดยกำหนดกฎสำหรับการดำเนินการไดอะแกรมที่ใช้แสดงถึงปัญหาการประมวลผลข้อมูลประเภทต่างๆ และวิธีการแก้ไข และเป็นไปตามมาตรฐาน ISO 5807:1985 โดยสมบูรณ์

นอกจาก ESPD แล้ว ยังมีมาตรฐานอีกสองมาตรฐานที่บังคับใช้ในระดับระหว่างรัฐ ซึ่งเกี่ยวข้องกับการจัดทำเอกสาร PS และนำมาใช้เมื่อไม่นานมานี้เหมือนกับ GOST ESPD ส่วนใหญ่

GOST 19781-90 ซอฟต์แวร์สำหรับระบบประมวลผลข้อมูล ข้อกำหนดและคำจำกัดความ พัฒนาขึ้นเพื่อแทนที่ GOST 19.781-83 และ GOST 19.004-80 และกำหนดข้อกำหนดและคำจำกัดความในด้านซอฟต์แวร์ (ซอฟต์แวร์) ของระบบประมวลผลข้อมูล (SOD) ที่ใช้ในเอกสารและวรรณกรรมทุกประเภทที่รวมอยู่ในขอบเขตของงานมาตรฐานหรือการใช้งาน ผลลัพธ์ของงานนี้

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

2.2. มาตรฐานของคอมเพล็กซ์ GOST 34

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

คอมเพล็กซ์ได้รับการออกแบบเพื่อการโต้ตอบระหว่างลูกค้าและผู้พัฒนา เช่นเดียวกับ ISO12207 โดยมีเงื่อนไขว่าลูกค้าสามารถพัฒนาวิทยากรสำหรับตัวเองได้ (หากเขาสร้างหน่วยพิเศษสำหรับสิ่งนี้) อย่างไรก็ตาม ถ้อยคำของ GOST 34 ไม่ได้เน้นไปที่การสะท้อนการกระทำของทั้งสองฝ่ายอย่างชัดเจนและในแง่หนึ่งในฐานะ ISO12207 เนื่องจาก GOST 34 ให้ความสำคัญกับเนื้อหาของเอกสารโครงการเป็นหลัก การกระจายการดำเนินการระหว่างทั้งสองฝ่ายจึงมักทำตามเนื้อหานี้

ในบรรดากลุ่มเอกสารที่มีอยู่และไม่ได้นำไปใช้ทั้งหมด เราจะยึดตามกลุ่ม 0 “บทบัญญัติทั่วไป” และกลุ่ม 6 “การสร้าง การดำเนินการ และการพัฒนา AS” เท่านั้น มาตรฐานที่ได้รับความนิยมสูงสุดถือได้ว่าเป็น GOST 34.601-90 (ขั้นตอนของการสร้าง AS), GOST 34.602-89 (TK สำหรับการสร้าง AS) และหลักเกณฑ์ RD 50-34.698-90 (ข้อกำหนดสำหรับเนื้อหาของเอกสาร) มาตรฐานกำหนดขั้นตอนและขั้นตอนของการทำงานเพื่อสร้าง AS แต่ไม่ได้ระบุไว้อย่างชัดเจนสำหรับกระบวนการตั้งแต่ต้นทางถึงปลายทาง

สำหรับกรณีทั่วไปของการพัฒนา AS ขั้นตอนและขั้นตอนของ GOST 34 แสดงไว้ในตาราง:

1. FT – การกำหนดข้อกำหนดสำหรับ AS	1.1. การตรวจสอบสิ่งอำนวยความสะดวกและเหตุผลของความจำเป็นในการสร้างโรงไฟฟ้านิวเคลียร์ 1.2. การสร้างข้อกำหนดของผู้ใช้สำหรับผู้พูด 1.3. การจัดทำรายงานเกี่ยวกับงานที่ทำและแอปพลิเคชันสำหรับการพัฒนา AS (ข้อกำหนดทางยุทธวิธีและทางเทคนิค)
2. RK – การพัฒนาแนวคิด AS	2.1. ศึกษาวัตถุ 2.2. ดำเนินงานวิจัยที่จำเป็น 2.3. การพัฒนาทางเลือกสำหรับแนวคิดวิทยากรที่ตรงตามความต้องการของผู้ใช้ 2.4. จัดทำรายงานเกี่ยวกับงานที่ทำ
3. TK – การสร้างทางเทคนิคของ NPP	3.1. การพัฒนาและการอนุมัติข้อกำหนดทางเทคนิคสำหรับงาน
4. EP - การออกแบบร่าง	4.1. การพัฒนาโซลูชั่นการออกแบบเบื้องต้นสำหรับระบบและชิ้นส่วน 4.2. การพัฒนาเอกสารสำหรับ AU และส่วนต่างๆ
5. TP – การออกแบบทางเทคนิค	5.1. การพัฒนาโซลูชั่นการออกแบบสำหรับระบบและชิ้นส่วน 5.2. การพัฒนาเอกสารสำหรับ NPP และส่วนต่างๆ 5.3. การพัฒนาและการดำเนินการเอกสารสำหรับการจัดหาผลิตภัณฑ์เพื่อให้เป็นไปตามข้อกำหนด NPP และ/หรือข้อกำหนดทางเทคนิค (ข้อกำหนดทางเทคนิค) เพื่อการพัฒนา 5.4. การพัฒนางานออกแบบในส่วนที่อยู่ติดกันของโครงการสิ่งอำนวยความสะดวกระบบอัตโนมัติ
6. RD – เอกสารการทำงาน	6.1. การพัฒนาเอกสารการทำงานสำหรับระบบและส่วนต่างๆ 6.2. การพัฒนาหรือดัดแปลงโปรแกรม
7. VD – นำไปปฏิบัติ	7.1. การเตรียมสิ่งอำนวยความสะดวกอัตโนมัติเพื่อนำโรงงานไปดำเนินการ 7.2. การฝึกอบรมบุคลากร 7.3. ชุดวิทยากรครบชุดพร้อมผลิตภัณฑ์ที่ให้มา (ซอฟต์แวร์และฮาร์ดแวร์ ระบบซอฟต์แวร์และฮาร์ดแวร์ ผลิตภัณฑ์ข้อมูล) 7.4. งานก่อสร้างและติดตั้ง 7.5. การว่าจ้างงาน; 7.6. ดำเนินการทดสอบเบื้องต้น 7.7. การดำเนินการทดลอง 7.8. ดำเนินการทดสอบการยอมรับ
8. รองรับ Sp – AC	8.1. ดำเนินงานตามภาระผูกพันในการรับประกัน 8.2. บริการหลังการรับประกัน

มีการอธิบายเนื้อหาของเอกสารที่พัฒนาในแต่ละขั้นตอน สิ่งนี้กำหนดศักยภาพในการระบุงาน end-to-end ระดับสาระสำคัญที่ดำเนินการแบบขนานหรือตามลำดับ (นั่นคือในสาระสำคัญกระบวนการ) และงานที่เป็นส่วนประกอบ เทคนิคนี้สามารถใช้เมื่อสร้างโปรไฟล์ของมาตรฐานวงจรชีวิตของโครงการ รวมถึงชุดย่อยที่ตกลงกันไว้ของมาตรฐาน GOST 34 และ ISO12207

จุดประสงค์หลัก: เพื่อแก้ปัญหา "หอคอยบาเบล"

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

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

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

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

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

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

ระดับของความสามารถในการปรับตัวถูกกำหนดอย่างเป็นทางการโดยความสามารถ:

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

ขั้นตอนและเหตุการณ์สำคัญที่ดำเนินการโดยองค์กรที่เข้าร่วมในการสร้างโรงไฟฟ้านิวเคลียร์นั้นได้รับการกำหนดไว้ในสัญญาและข้อกำหนดทางเทคนิคซึ่งใกล้เคียงกับแนวทางของ ISO

การแนะนำคำศัพท์ที่เป็นหนึ่งเดียวและกำหนดคุณภาพอย่างเป็นธรรม การจำแนกประเภทงาน เอกสาร ประเภทของการสนับสนุน ฯลฯ อย่างสมเหตุสมผลนั้นมีประโยชน์อย่างแน่นอน GOST 34 มีส่วนช่วยให้การรวมระบบที่แตกต่างกันอย่างแท้จริงมีความสมบูรณ์และมีคุณภาพสูงมากขึ้น ซึ่งมีความสำคัญอย่างยิ่งในสภาวะที่มีการพัฒนาระบบบูรณาการที่ซับซ้อนมากขึ้นเรื่อย ๆ เช่น CAD-CAM ซึ่งรวมถึงระบบควบคุมกระบวนการ ระบบควบคุม, ผู้ออกแบบ CAD, นักเทคโนโลยี CAD, ASNI และระบบอื่นๆ

มีการกำหนดข้อกำหนดสำคัญหลายประการที่สะท้อนถึงคุณลักษณะของ AS ในฐานะเป้าหมายของการกำหนดมาตรฐาน ตัวอย่างเช่น "โดยทั่วไป AS ประกอบด้วยซอฟต์แวร์และฮาร์ดแวร์ (PTK) ซอฟต์แวร์ที่ซับซ้อนและวิธีการ (PMK) และองค์ประกอบแต่ละส่วนขององค์กร การสนับสนุนทางเทคนิค ซอฟต์แวร์ และข้อมูล”

การแยกแนวคิดของ PTC และ AS ประดิษฐานหลักการตามที่ AS ไม่ใช่ "IS พร้อมฐานข้อมูล" แต่:

“ระบบองค์กรและเทคนิคที่รับรองการพัฒนาโซลูชันโดยอาศัยกระบวนการอัตโนมัติของกระบวนการข้อมูลในกิจกรรมต่างๆ (การจัดการ การออกแบบ การผลิต ฯลฯ) หรือการผสมผสานกัน” (ตาม RD 50-680-88) ซึ่ง มีความเกี่ยวข้องโดยเฉพาะอย่างยิ่งในด้านธุรกิจ - การรื้อปรับระบบ;
“ ระบบที่ประกอบด้วยบุคลากรและชุดเครื่องมืออัตโนมัติสำหรับกิจกรรมของพวกเขาการนำเทคโนโลยีสารสนเทศไปใช้สำหรับการปฏิบัติหน้าที่ที่กำหนดไว้” (ตาม GOST 34.003-90)

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

ระดับภาระผูกพัน:

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

เอกสารสำคัญสำหรับการปฏิสัมพันธ์ระหว่างทั้งสองฝ่ายคือข้อกำหนดทางเทคนิคสำหรับการสร้าง NPP ข้อกำหนดทางเทคนิคเป็นเอกสารแหล่งที่มาหลักสำหรับการสร้าง AS และการยอมรับ ข้อกำหนดทางเทคนิคจะกำหนดจุดที่สำคัญที่สุดของการโต้ตอบระหว่างลูกค้าและนักพัฒนา ในกรณีนี้ข้อกำหนดทางเทคนิคได้รับการพัฒนาโดยองค์กรนักพัฒนา (ตาม GOST 34.602-89) แต่ลูกค้าจะออกข้อกำหนดทางเทคนิคให้กับนักพัฒนาอย่างเป็นทางการ (ตาม RD 50-680-88)

2.3. มาตรฐานรัฐของสหพันธรัฐรัสเซีย (GOST R)

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

GOST R ISO/IEC 9294-93เทคโนโลยีสารสนเทศ คู่มือการจัดการเอกสารซอฟต์แวร์ มาตรฐานนี้สอดคล้องกับมาตรฐานสากล ISO/IEC TO 9294:1990 โดยสมบูรณ์ และกำหนดคำแนะนำสำหรับการจัดการเอกสารประกอบซอฟต์แวร์ที่มีประสิทธิภาพสำหรับผู้จัดการที่รับผิดชอบในการสร้างสรรค์เอกสารเหล่านั้น วัตถุประสงค์ของมาตรฐานคือการช่วยในการกำหนดกลยุทธ์สำหรับการจัดทำเอกสารซอฟต์แวร์ การเลือกมาตรฐานเอกสาร การเลือกขั้นตอนเอกสาร การกำหนดทรัพยากรที่จำเป็น จัดทำแผนเอกสาร

GOST R ISO/IEC 9126-93เทคโนโลยีสารสนเทศ การประเมินผลิตภัณฑ์ซอฟต์แวร์ ลักษณะคุณภาพและแนวทางการใช้งาน มาตรฐานนี้สอดคล้องกับมาตรฐานสากล ISO/IEC 9126:1991 อย่างสมบูรณ์ ในบริบท ลักษณะคุณภาพถูกเข้าใจว่าเป็น "ชุดของคุณสมบัติ (คุณลักษณะ) ของผลิตภัณฑ์ซอฟต์แวร์ที่ใช้อธิบายและประเมินคุณภาพ" มาตรฐานกำหนดคุณลักษณะที่ครอบคลุม 6 ประการที่อธิบายถึงคุณภาพของซอฟต์แวร์ (ซอฟต์แวร์ ผลิตภัณฑ์ซอฟต์แวร์) โดยมีความซ้ำซ้อนน้อยที่สุด ได้แก่ ฟังก์ชันการทำงาน ความน่าเชื่อถือ; การปฏิบัติจริง; ประสิทธิภาพ; คลอ; ความคล่องตัว คุณลักษณะเหล่านี้เป็นพื้นฐานสำหรับการชี้แจงและคำอธิบายเพิ่มเติมเกี่ยวกับคุณภาพของซอฟต์แวร์

GOST R ISO 9127-94ระบบประมวลผลข้อมูล เอกสารประกอบผู้ใช้และข้อมูลบรรจุภัณฑ์สำหรับแพ็คเกจซอฟต์แวร์สำหรับผู้บริโภค มาตรฐานนี้สอดคล้องกับมาตรฐานสากล ISO 9127:1989 อย่างสมบูรณ์ สำหรับวัตถุประสงค์ของมาตรฐานนี้ ชุดซอฟต์แวร์สำหรับผู้บริโภค (CSP) หมายถึง "ผลิตภัณฑ์ซอฟต์แวร์ที่ออกแบบและทำการตลาดเพื่อทำหน้าที่เฉพาะ โปรแกรมและเอกสารประกอบที่เกี่ยวข้องถูกบรรจุเพื่อขายเป็นหน่วยเดียว” เอกสารสำหรับผู้ใช้หมายถึงเอกสารที่ให้ข้อมูลเกี่ยวกับการติดตั้งและการทำงานของซอฟต์แวร์แก่ผู้ใช้ ข้อมูลบนบรรจุภัณฑ์หมายถึงข้อมูลที่ทำซ้ำบนบรรจุภัณฑ์ด้านนอกของ PP วัตถุประสงค์คือเพื่อให้ข้อมูลเบื้องต้นเกี่ยวกับซอฟต์แวร์แก่ผู้ซื้อที่มีศักยภาพ

GOST R ISO/IEC 8631-94เทคโนโลยีสารสนเทศ โครงสร้างซอฟต์แวร์และสัญลักษณ์สำหรับการเป็นตัวแทน อธิบายการนำเสนอขั้นตอนวิธีขั้นตอนวิธี

2.4. มาตรฐานสากล ISO/IEC 12207:1995-08-01

ISO12207 ฉบับพิมพ์ครั้งแรกจัดทำขึ้นในปี 1995 โดยคณะกรรมการด้านเทคนิคร่วม ISO/IEC JTC1 “เทคโนโลยีสารสนเทศ คณะอนุกรรมการ SC7 วิศวกรรมซอฟต์แวร์”

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

หมายเหตุที่สำคัญมากของมาตรฐาน:

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

คำจำกัดความมาตรฐาน:

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

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

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

กระบวนการวงจรชีวิตแต่ละกระบวนการแบ่งออกเป็นชุดของการดำเนินการ แต่ละการดำเนินการออกเป็นชุดของงาน ความแตกต่างที่สำคัญมากระหว่าง ISO: แต่ละกระบวนการ การดำเนินการ หรืองานจะถูกเริ่มต้นและดำเนินการโดยกระบวนการอื่นตามความจำเป็น และไม่มีลำดับที่กำหนดไว้ล่วงหน้า (แน่นอนว่า ในขณะที่ยังคงรักษาตรรกะของการเชื่อมต่อตามข้อมูลเริ่มต้นของงาน ฯลฯ ).

มาตรฐาน ISO12207 อธิบาย:

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

มาพร้อมกับกระบวนการปรับตัวพิเศษซึ่งกำหนดการดำเนินการหลักที่จำเป็นในการปรับมาตรฐานให้เข้ากับเงื่อนไขของโครงการเฉพาะ

กระบวนการปรับปรุงที่นี่ไม่ได้หมายถึงการปรับปรุง AS หรือซอฟต์แวร์ แต่เป็นการปรับปรุงกระบวนการได้มา การพัฒนา การประกันคุณภาพ ฯลฯ ที่ดำเนินการจริงในองค์กร

ไม่มีขั้นตอน ระยะ หรือขั้นตอนที่ให้ไว้ ซึ่งจะให้ระดับของความสามารถในการปรับตัวตามที่อธิบายไว้ด้านล่าง

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

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

ลักษณะนี้ทำให้สามารถใช้แบบจำลองวงจรชีวิตใดๆ ก็ได้

เมื่อทำการวิเคราะห์ข้อกำหนดซอฟต์แวร์ จะมีลักษณะคุณภาพ 11 คลาสที่ใช้ในภายหลังในการประกันคุณภาพ

ในกรณีนี้ นักพัฒนาจะต้องจัดทำและจัดทำเอกสารตามข้อกำหนดของซอฟต์แวร์:

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

(เป็นที่น่าสนใจและสำคัญที่คุณลักษณะเหล่านี้และลักษณะที่คล้ายกันนั้นสอดคล้องกับลักษณะของ NPP ที่กำหนดไว้ใน GOST 34 เป็นอย่างดีสำหรับประเภทของการสนับสนุนระบบ)

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

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

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

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

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

ปัจจุบันสถาบันวิจัยมาตรฐาน All-Russian ได้เตรียมข้อเสนอสำหรับการปรับปรุงและพัฒนาชุดมาตรฐานสำหรับซอฟต์แวร์จัดทำเอกสาร

ขึ้นไปด้านบน

GOST 19.105-78* (ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม)

จาก GOST นี้เราได้รับข้อกำหนดทั่วไปสำหรับการจัดทำเอกสารโปรแกรมด้านล่างนี้เป็นส่วนที่สำคัญที่สุด

มาตรฐานนี้กำหนดข้อกำหนดทั่วไปสำหรับการดำเนินการเอกสารโปรแกรมสำหรับคอมพิวเตอร์ คอมเพล็กซ์ และระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขตของการใช้งาน และจัดทำโดยมาตรฐานของ Unified System of Program Documentation (USPD) สำหรับวิธีการใด ๆ ในการดำเนินการเอกสารในหัวข้อต่างๆ ผู้ให้บริการข้อมูล
เอกสารโปรแกรมประกอบด้วยส่วนทั่วไปดังต่อไปนี้:

ชื่อ;
ข้อมูล;
ขั้นพื้นฐาน;
การลงทะเบียนการเปลี่ยนแปลง

ส่วนปกประกอบด้วยเอกสารอนุมัติและหน้าชื่อเรื่อง กฎสำหรับการจัดทำเอกสารอนุมัติและหน้าชื่อเรื่องนั้นจัดทำขึ้นตาม GOST 19.104-78
ส่วนข้อมูลควรประกอบด้วยบทคัดย่อและเนื้อหา

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

การกำหนดองค์ประกอบโครงสร้าง (จำนวนส่วนส่วนย่อย ฯลฯ )
ชื่อขององค์ประกอบโครงสร้าง
ที่อยู่ขององค์ประกอบโครงสร้างบนสื่อจัดเก็บข้อมูล (เช่น หมายเลขหน้า หมายเลขไฟล์ ฯลฯ)

องค์ประกอบและโครงสร้างของส่วนหลักของเอกสารโปรแกรมได้รับการกำหนดโดยมาตรฐาน ESPD สำหรับเอกสารที่เกี่ยวข้อง
เปลี่ยนส่วนการบันทึก(ต้องมีอยู่ในเอกสารหลักสูตรทุกฉบับ)

การเปลี่ยนแปลงในเอกสารโปรแกรมแต่ละครั้งจะถูกบันทึกในส่วนนี้ตามข้อกำหนดของ GOST 19.603-78

ขึ้นไปด้านบน
==================================
GOST 19.106-78* (ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรมที่ผลิตในรูปแบบสิ่งพิมพ์
ทาง)
จาก GOST นี้เราได้รับกฎทั่วไป สำหรับวิธีการพิมพ์เอกสารโปรแกรม. ด้านล่างนี้เป็นส่วนที่สำคัญที่สุด

มาตรฐานนี้กำหนดกฎสำหรับการดำเนินการเอกสารโปรแกรมสำหรับคอมพิวเตอร์ คอมเพล็กซ์ และระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขตของการใช้งาน และจัดทำตามมาตรฐานของ Unified System of Program Documentation (USPD) สำหรับวิธีการพิมพ์
มาตรฐานนี้ใช้ไม่ได้กับเอกสารโปรแกรม “ข้อความของโปรแกรม”
องค์ประกอบและโครงสร้างของเอกสารโปรแกรมได้รับการจัดทำขึ้นตาม GOST 19.105-78
เอกสารโปรแกรมถูกดำเนินการด้านหนึ่งของแผ่นงานสองช่วง อนุญาตในช่วงเวลาหนึ่งหรือหนึ่งและครึ่ง
เอกสารโปรแกรมจัดทำโดย:

บนแผ่นงานรูปแบบ A4 (GOST 2.301-68) - เมื่อเตรียมเอกสารด้วยการพิมพ์หรือเขียนด้วยลายมือ (แบบฟอร์ม 1) อนุญาตให้วาดภาพบนแผ่น A3

เนื้อหาของเอกสารโปรแกรมจะจัดเรียงตามลำดับต่อไปนี้:

ส่วนของชื่อเรื่อง:

เอกสารอนุมัติ (ไม่รวมอยู่ในจำนวนแผ่นงานทั้งหมดของเอกสาร)
หน้าชื่อเรื่อง (หน้าแรกของเอกสาร);

ส่วนข้อมูล:

คำอธิบายประกอบ;
สารบัญ;

ส่วนสำคัญ:

ข้อความของเอกสาร (พร้อมรูปภาพ ตาราง ฯลฯ );
การใช้งาน;
รายการคำศัพท์ รายการคำย่อ รายการตัวเลข รายการตาราง ดัชนีหัวเรื่อง รายการเอกสารอ้างอิง

เปลี่ยนส่วนการบันทึก:

เปลี่ยนใบทะเบียน

บทคัดย่อจะถูกวางไว้บนหน้าแยกต่างหาก (มีหมายเลข) โดยมีหัวข้อว่า “บทคัดย่อ” และไม่มีหมายเลขเป็นส่วน

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

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

ระยะห่างระหว่างส่วนหัวและข้อความต่อไปนี้ รวมถึงระหว่างส่วนหัวของส่วนและส่วนหัวของส่วนย่อย ควรเท่ากับ:

เมื่อดำเนินการเอกสารด้วยการพิมพ์ดีด - สองช่วงเวลา

สำหรับส่วนและส่วนย่อย ข้อความที่เขียนในหน้าเดียวกันกับข้อความของส่วนก่อนหน้า ระยะห่างระหว่างบรรทัดสุดท้ายของข้อความและหัวข้อถัดไปควรเท่ากับ:

เมื่อดำเนินการเอกสารโดยใช้วิธีการพิมพ์ดีด - ช่วงเวลาที่พิมพ์ดีดสามช่วง

ส่วน ส่วนย่อย ย่อหน้า และย่อหน้าย่อยควรใช้ตัวเลขเป็นเลขอารบิคและมีจุด
ภายในหัวข้อหนึ่งๆ จะต้องมีการเรียงลำดับหมายเลขอย่างต่อเนื่องสำหรับส่วนย่อย ย่อหน้า และย่อหน้าย่อยทั้งหมดที่รวมอยู่ในส่วนนี้
การกำหนดหมายเลขส่วนย่อยจะรวมถึงหมายเลขส่วนและหมายเลขลำดับของส่วนย่อยที่รวมอยู่ในส่วนนี้ โดยคั่นด้วยจุด (2.1; 3.1 ฯลฯ)
หากมีส่วนและส่วนย่อย หมายเลขลำดับของส่วนคำสั่งและส่วนย่อย (3.1.1, 3.1.1.1 ฯลฯ) จะถูกเพิ่มเข้าไปในหมายเลขส่วนย่อยหลังจุด

ตัวอย่างโครงสร้างของข้อความในเอกสารโปรแกรมและการกำหนดหมายเลขส่วน ส่วนย่อย ย่อหน้า และย่อหน้าย่อย

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

เชิงอรรถจะถูกระบุด้วยตัวเลขโดยมีวงเล็บอยู่ที่ระดับขอบด้านบนของแบบอักษร เช่น "อุปกรณ์การพิมพ์ 2) ... " หรือ "กระดาษ 5)"

หากเชิงอรรถอ้างถึงคำเดียว เครื่องหมายเชิงอรรถจะถูกวางไว้ถัดจากคำนี้โดยตรง แต่หากอ้างอิงถึงประโยคโดยรวม ก็จะอยู่ที่ท้ายประโยค ข้อความเชิงอรรถจะอยู่ท้ายหน้าและแยกออกจากข้อความหลักด้วยเส้นยาว 3 ซม. ที่ด้านซ้ายของหน้า

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

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

ไม่อนุญาตให้ใช้คำย่อของคำในข้อความและจารึกใต้ภาพประกอบ
วัสดุภาพประกอบ ตาราง หรือข้อความสนับสนุนอาจนำเสนอในรูปแบบของภาคผนวก
แต่ละแอปพลิเคชันจะต้องเริ่มต้นในหน้าใหม่โดยมีคำว่า "ภาคผนวก" ระบุไว้ที่มุมขวาบนและมีหัวข้อเฉพาะเรื่องซึ่งเขียนอย่างสมมาตรกับข้อความด้วยตัวพิมพ์ใหญ่(ท้ายที่สุดแล้ว ในการสร้างโปรเจ็กต์ เราจำเป็นต้องมีเพียงใบบันทึกการเปลี่ยนแปลง)
- มาตรฐานนี้กำหนดกฎสำหรับการเปลี่ยนแปลงเอกสารโปรแกรมที่จัดทำโดยมาตรฐานของ Unified System of Program Documentation (USPD) และจัดพิมพ์
เนื่องจากข้อมูลจำนวนมากใน GOST นี้และเพื่อประหยัดพื้นที่ในหน้านี้ ฉันขอแนะนำให้ดูด้วยตนเอง GOST 19.604-78* . ตัวอย่างการออกแบบพร้อม"เปลี่ยนใบทะเบียน"คุณสามารถดูได้ในเอกสารโปรแกรมใดๆ ที่ให้ไว้ในส่วนดาวน์โหลด

ขึ้นไปด้านบน
==================================

โปรแกรมคอมพิวเตอร์ถูกจัดทำขึ้นตามข้อกำหนดของ Unified System of Program Documentation (USPD) ESPD คือชุดของ GOST ที่กำหนดกฎสำหรับการออกแบบ เนื้อหา และโครงสร้างของเอกสารโปรแกรม
วิธีการนี้มีข้อความที่ตัดตอนมาจาก ESPD ข้อมูลที่สมบูรณ์สามารถรับได้โดยตรงจาก GOST

อัลกอริธึมการออกแบบโปรแกรมโดยย่อ

โดยสรุป อัลกอริธึมการออกแบบโปรแกรมและประเภทของเอกสารโปรแกรมแสดงไว้ในภาพ ขั้นตอนการลงทะเบียนมีรายละเอียดเพิ่มเติมด้านล่าง

จัดทำเอกสารโปรแกรม

เอกสารโปรแกรม - เอกสารที่มีข้อมูลที่จำเป็นสำหรับการพัฒนา การผลิต การบำรุงรักษา และการทำงานของโปรแกรม

เอกสารโปรแกรมแต่ละฉบับถูกจัดทำขึ้นตาม (ทั่วไปในเอกสาร ESPD ทั้งหมด) ข้อกำหนดของ GOST 19.101-77, GOST 19.103-77, GOST 19.104-78, GOST 19.105-78, GOST 19.106-78, GOST 19.604-78 ( คำอธิบายโดยละเอียดเพิ่มเติมของ GOST เหล่านี้มีดังต่อไปนี้) และ GOST สำหรับเอกสารโปรแกรมเฉพาะ

ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม GOST 19.105 - 78

ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์ GOST 19.106 - 78

GOST 19.106-78 กำหนดกฎสำหรับการดำเนินการเอกสารโปรแกรมสำหรับวิธีการดำเนินการที่พิมพ์ออกมา

สิ่งสำคัญคือต้องทราบว่า GOST นี้ใช้ไม่ได้กับเอกสารโปรแกรม "ข้อความโปรแกรม"

วัสดุของเอกสารโปรแกรม จะต้องอยู่ในลำดับต่อไปนี้:

ส่วนของชื่อเรื่อง:
- เอกสารอนุมัติ (ไม่รวมอยู่ในจำนวนแผ่นงานทั้งหมดของเอกสาร)
- หน้าชื่อเรื่อง (หน้าแรกของเอกสาร);
ส่วนข้อมูล:
- คำอธิบายประกอบ;
- สารบัญ;
ส่วนสำคัญ:
- ข้อความของเอกสาร (พร้อมรูปภาพ ตาราง ฯลฯ );
- การใช้งาน;
- รายการคำศัพท์ รายการคำย่อ รายการตัวเลข รายการตาราง ดัชนีหัวเรื่อง รายการเอกสารอ้างอิง
- เปลี่ยนส่วนการบันทึก:
- เปลี่ยนใบทะเบียน

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

การจัดรูปแบบข้อความ:

เอกสารโปรแกรมจะดำเนินการที่ด้านหนึ่งของแผ่นงาน ในช่วงเวลาสองช่วง อนุญาตในช่วงเวลาหนึ่งหรือหนึ่งและครึ่ง
บทคัดย่อจะถูกวางไว้บนหน้าแยกต่างหาก (มีหมายเลข) โดยมีหัวข้อว่า “บทคัดย่อ” และไม่มีหมายเลขเป็นส่วน
ส่วนหัวของส่วนเขียนด้วยตัวพิมพ์ใหญ่และจัดวางอย่างสมมาตรสัมพันธ์กับเส้นขอบด้านขวาและด้านซ้ายของข้อความ
หัวข้อย่อยเขียนจากย่อหน้าด้วยอักษรตัวพิมพ์เล็ก (ยกเว้นตัวพิมพ์ใหญ่ตัวแรก)
ไม่อนุญาตให้ใส่ยติภังค์คำในส่วนหัว ไม่มีจุดต่อท้ายชื่อเรื่อง
ระยะห่างระหว่างส่วนหัวและข้อความต่อไปนี้ รวมถึงระหว่างส่วนหัวของส่วนและส่วนหัวของส่วนย่อย ควรเท่ากับ:
- เมื่อดำเนินการเอกสารด้วยการพิมพ์ดีด - สองช่วงเวลา
สำหรับส่วนและส่วนย่อย ข้อความที่เขียนในหน้าเดียวกันกับข้อความของส่วนก่อนหน้า ระยะห่างระหว่างบรรทัดสุดท้ายของข้อความและหัวข้อถัดไปควรเท่ากับ:
- เมื่อดำเนินการเอกสารโดยใช้วิธีการพิมพ์ดีด - ช่วงเวลาที่พิมพ์ดีดสามช่วง
ส่วน ส่วนย่อย ย่อหน้า และย่อหน้าย่อยควรใช้ตัวเลขเป็นเลขอารบิคและมีจุด
ภายในหัวข้อหนึ่งๆ จะต้องมีการเรียงลำดับหมายเลขอย่างต่อเนื่องสำหรับส่วนย่อย ย่อหน้า และย่อหน้าย่อยทั้งหมดที่รวมอยู่ในส่วนนี้
การกำหนดหมายเลขส่วนย่อยจะรวมถึงหมายเลขส่วนและหมายเลขลำดับของส่วนย่อยที่รวมอยู่ในส่วนนี้ โดยคั่นด้วยจุด (2.1; 3.1 ฯลฯ)
หากมีส่วนและส่วนย่อย หมายเลขลำดับของส่วนคำสั่งและส่วนย่อย (3.1.1, 3.1.1.1 ฯลฯ) จะถูกเพิ่มเข้าไปในหมายเลขส่วนย่อยหลังจุด
ข้อความในเอกสารควรสั้น ชัดเจน ยกเว้นความเป็นไปได้ที่จะตีความผิด
ข้อกำหนดและคำจำกัดความจะต้องเหมือนกันและสอดคล้องกับมาตรฐานที่กำหนดไว้ และในกรณีที่ไม่มีอยู่นั้น เป็นที่ยอมรับโดยทั่วไปในวรรณกรรมทางวิทยาศาสตร์และทางเทคนิค และระบุไว้ในรายการข้อกำหนด
คำอธิบายที่จำเป็นสำหรับข้อความของเอกสารสามารถระบุได้ในเชิงอรรถ
เชิงอรรถจะระบุด้วยตัวเลขโดยมีวงเล็บอยู่ที่ระดับขอบด้านบนของแบบอักษร เช่น "อุปกรณ์การพิมพ์2)..." หรือ "กระดาษ5)"
หากเชิงอรรถอ้างถึงคำเดียว เครื่องหมายเชิงอรรถจะถูกวางไว้ถัดจากคำนี้โดยตรง แต่หากอ้างอิงถึงประโยคโดยรวม ก็จะอยู่ที่ท้ายประโยค ข้อความเชิงอรรถจะอยู่ท้ายหน้าและแยกออกจากข้อความหลักด้วยเส้นยาว 3 ซม. ที่ด้านซ้ายของหน้า
ภาพประกอบ หากมีมากกว่าหนึ่งรายการในเอกสารที่กำหนด จะมีการกำหนดหมายเลขเป็นเลขอารบิคตลอดทั้งเอกสาร
สูตรในเอกสาร (หากมีมากกว่าหนึ่งรายการ) จะมีการกำหนดหมายเลขเป็นเลขอารบิค โดยตัวเลขจะอยู่ทางด้านขวาของหน้าในวงเล็บที่ระดับสูตร
ความหมายของสัญลักษณ์และค่าสัมประสิทธิ์ตัวเลขที่รวมอยู่ในสูตรจะต้องระบุไว้ด้านล่างสูตรโดยตรง ความหมายของอักขระแต่ละตัวจะถูกพิมพ์บนบรรทัดใหม่ตามลำดับที่กำหนดไว้ในสูตร บรรทัดแรกของบทถอดเสียงควรขึ้นต้นด้วยคำว่า "where" โดยไม่มีเครื่องหมายทวิภาคตามหลัง
ในเอกสารโปรแกรมอนุญาตให้อ้างอิงถึงมาตรฐาน (ยกเว้นมาตรฐานองค์กร) ข้อกำหนดทางเทคนิคและเอกสารอื่น ๆ (เช่นเอกสารของหน่วยงานกำกับดูแลของรัฐกฎและข้อบังคับของคณะกรรมการการก่อสร้างแห่งรัฐของสหภาพโซเวียต) เมื่อพูดถึงมาตรฐานและข้อกำหนดทางเทคนิคจะมีการระบุการกำหนดไว้
ควรอ้างอิงถึงเอกสารทั้งหมดหรือส่วนต่างๆ ของเอกสาร (ระบุชื่อและชื่อของเอกสาร หมายเลขและชื่อของส่วนหรือภาคผนวก) เมื่ออ้างอิงถึงส่วนหรือแอปพลิเคชันซ้ำ จะมีการระบุเฉพาะตัวเลขเท่านั้น
หมายเหตุสำหรับข้อความและตารางระบุเฉพาะข้อมูลอ้างอิงและคำอธิบายเท่านั้น
โน้ตตัวหนึ่งไม่มีหมายเลข หลังจากคำว่า “หมายเหตุ” ให้ใส่จุด
ควรมีการกำหนดหมายเลขบันทึกย่อหลายรายการเพื่อใช้เลขอารบิคที่มีจุด หลังจากคำว่า “หมายเหตุ” ให้ใส่เครื่องหมายโคลอน
ไม่อนุญาตให้ใช้คำย่อของคำในข้อความและจารึกใต้ภาพประกอบ
วัสดุภาพประกอบ ตาราง หรือข้อความสนับสนุนอาจนำเสนอในรูปแบบของภาคผนวก
แต่ละแอปพลิเคชันจะต้องเริ่มต้นในหน้าใหม่โดยมีคำว่า "ภาคผนวก" ระบุไว้ที่มุมขวาบนและมีหัวข้อเฉพาะเรื่องซึ่งเขียนอย่างสมมาตรกับข้อความด้วยตัวพิมพ์ใหญ่

GOST มีแผ่นตัวอย่างที่ระบุฟิลด์ สถานที่สำหรับใส่หมายเลขหน้า และรหัส

ในรายงานของฉัน ฉันพึ่งพา:

บทความ "มาตรฐานในด้านซอฟต์แวร์" โดย V.V. Vasyutkovich - หัวหน้าภาควิชาและ S.S. Sammotokhin - นักวิจัยอาวุโส สถาบันวิจัยมาตรฐานแห่งรัฐรัสเซียทั้งหมดแห่งมาตรฐานแห่งสหพันธรัฐรัสเซีย;
บทความ “ความสัมพันธ์และการใช้มาตรฐานในการจัดวงจรชีวิตของระบบ” โดย E.Z. Zinder;
ข้อความของ GOST และมาตรฐานอื่น ๆ

1.ประเด็นพื้นฐานในการพัฒนาซอฟต์แวร์

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

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

นอกจากประเด็นที่กล่าวมาก็ยังมีประเด็นอื่นๆ อีก

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

ปัจจุบันประเด็นเรื่องการมีระบบควบคุมเอกสารของซอฟต์แวร์ยังคงมีความเกี่ยวข้องอยู่

2. ลักษณะทั่วไปของภาวะ

พื้นฐานของกรอบการกำกับดูแลภายในประเทศในด้านเอกสารประกอบซอฟต์แวร์คือชุดมาตรฐานของ Unified System of Program Documentation (USPD) ส่วนหลักและใหญ่ที่สุดของคอมเพล็กซ์ ESPD ได้รับการพัฒนาในช่วงทศวรรษที่ 70 และ 80 ขณะนี้คอมเพล็กซ์นี้เป็นระบบมาตรฐานระหว่างรัฐของกลุ่มประเทศ CIS (GOST) ซึ่งดำเนินงานในอาณาเขตของสหพันธรัฐรัสเซียบนพื้นฐานของข้อตกลงระหว่างรัฐในเรื่องมาตรฐาน

มาตรฐาน ESPD ส่วนใหญ่ครอบคลุมส่วนหนึ่งของเอกสารที่สร้างขึ้นในกระบวนการพัฒนาซอฟต์แวร์ และส่วนใหญ่เกี่ยวข้องกับการบันทึกลักษณะการทำงานของซอฟต์แวร์ ควรสังเกตว่ามาตรฐาน ESPD (GOST 19) มีลักษณะเป็นคำแนะนำ อย่างไรก็ตาม สิ่งนี้ยังนำไปใช้กับมาตรฐานอื่นๆ ทั้งหมดในสาขา PS (GOST 34, มาตรฐานสากล ISO/IEC ฯลฯ) ความจริงก็คือตามกฎหมายของสหพันธรัฐรัสเซีย "ในการมาตรฐาน" มาตรฐานเหล่านี้มีผลบังคับใช้ตามสัญญา - นั่นคือเมื่อมีการอ้างถึงในสัญญาสำหรับการพัฒนา (การจัดหา) ของซอฟต์แวร์

เมื่อพูดถึงสถานะของ ESPD โดยรวม อาจกล่าวได้ว่ามาตรฐาน ESPD ส่วนใหญ่ล้าสมัยทางศีลธรรม

ท่ามกลางข้อเสียเปรียบหลัก อีเอสพีดีสามารถนำมาประกอบได้:

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

ดังนั้น ESPD จำเป็นต้องมีการแก้ไขทั้งหมดตามมาตรฐาน ISO/IEC 12207-95 สำหรับกระบวนการวงจรชีวิตของซอฟต์แวร์ (มาตรฐานนี้จะกล่าวถึงในรายละเอียดเพิ่มเติมในภายหลัง)

ต้องบอกว่านอกเหนือจาก ESPD complex แล้ว กรอบการกำกับดูแลอย่างเป็นทางการของสหพันธรัฐรัสเซียในด้านเอกสาร PS และด้านที่เกี่ยวข้องยังรวมถึงมาตรฐานที่มีแนวโน้มหลายประการ (ระดับในประเทศ ระหว่างรัฐ และระดับนานาชาติ)

มาตรฐานสากล ISO/IEC 12207: 1995-08-01สำหรับการจัดวงจรชีวิตของผลิตภัณฑ์ซอฟต์แวร์ - ดูเหมือนคลุมเครือมาก แต่ค่อนข้างใหม่และเป็นมาตรฐาน "ทันสมัย" บ้าง

มาตรฐานที่ซับซ้อน GOST 34สำหรับการสร้างและพัฒนาระบบอัตโนมัติ (AS) - โดยทั่วไป แต่ถูกมองว่าเข้มงวดมากในโครงสร้างของวงจรชีวิตและเอกสารการออกแบบ แต่มาตรฐานเหล่านี้หลายคนมองว่าเป็นระบบราชการจนถึงขั้นเป็นอันตรายและอนุรักษ์นิยมจนถึงขั้นล้าสมัย สิ่งนี้เป็นจริงในระดับใดและ GOST 34 ยังคงมีประโยชน์มากเพียงใดนั้นมีประโยชน์ในการทำความเข้าใจ

ในบทความของเขา E.Z. Zinder กล่าวถึงรายละเอียดเกี่ยวกับวิธีการดังกล่าว ออราเคิล ซีดีเอ็ม(วิธีการพัฒนาแบบกำหนดเอง) สำหรับการพัฒนาระบบข้อมูลแอปพลิเคชันแบบกำหนดเอง - วัสดุเฉพาะ มีรายละเอียดจนถึงระดับช่องว่างเอกสารการออกแบบ ออกแบบมาเพื่อใช้โดยตรงในโครงการ AS โดยใช้เครื่องมือของ Oracle

2.1. บทนำโดยย่อเกี่ยวกับมาตรฐาน ESPD

อย่างไรก็ตาม ก่อนที่จะแก้ไขความซับซ้อนทั้งหมด มาตรฐาน ESPD จำนวนมากสามารถนำไปใช้อย่างมีประโยชน์ในการปฏิบัติงานด้านซอฟต์แวร์จัดทำเอกสารได้ ตำแหน่งนี้ขึ้นอยู่กับสิ่งต่อไปนี้:

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

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

มาตรฐาน ESPD (เช่นเดียวกับ GOST อื่น ๆ ) แบ่งออกเป็นกลุ่มตามตาราง:

การกำหนดมาตรฐาน ESPD ขึ้นอยู่กับเกณฑ์การจำแนกประเภท:

การกำหนดมาตรฐาน ESPD จะต้องประกอบด้วย:

หมายเลข 19 (กำหนดให้กับคลาสมาตรฐาน ESPD)
หนึ่งหลัก (หลังจุด) ระบุรหัสของกลุ่มการจำแนกมาตรฐานที่ระบุในตาราง
ตัวเลขสองหลัก (หลังขีดกลาง) ระบุปีที่จดทะเบียนมาตรฐาน

รายการเอกสาร ESPD

GOST 19.001-77 อีเอสพีดี บทบัญญัติทั่วไป
GOST 19.101-77 ESPD ประเภทของโปรแกรมและเอกสารโปรแกรม
GOST 19.102-77 ESPD ขั้นตอนการพัฒนา
GOST 19.103-77 ESPD การกำหนดโปรแกรมและเอกสารโปรแกรม
GOST 19.104-78 อีเอสพีดี จารึกพื้นฐาน
GOST 19.105-78 อีเอสพีดี ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม
GOST 19.106-78 อีเอสพีดี ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์
GOST 19.201-78 อีเอสพีดี งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.202-78 อีเอสพีดี ข้อมูลจำเพาะ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.301-79 อีเอสพีดี ขั้นตอนและวิธีการทดสอบ
GOST 19.401-78 อีเอสพีดี ข้อความโปรแกรม ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.402-78 อีเอสพีดี คำอธิบายโปรแกรม
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.508-79 อีเอสพีดี คู่มือการบำรุงรักษา ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.604-78 อีเอสพีดี กฎสำหรับการเปลี่ยนแปลงเอกสารโปรแกรมที่ดำเนินการในรูปแบบการพิมพ์
GOST 19.701-90 ESPD แผนผังของอัลกอริธึม โปรแกรม ข้อมูล และระบบ อนุสัญญาและกฎการดำเนินการ
GOST 19.781-90 ซอฟต์แวร์สำหรับระบบประมวลผลข้อมูล

ข้อกำหนดและคำจำกัดความ

จากมาตรฐาน ESPD ทั้งหมด เราจะเน้นเฉพาะมาตรฐานที่สามารถใช้ได้บ่อยกว่าในทางปฏิบัติเท่านั้น

ขั้นแรก เราจะระบุมาตรฐานที่สามารถใช้ในการสร้างงานการเขียนโปรแกรมได้

GOST (ST SEV) 19.201-78 (1626-79) อีเอสพีดี. งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ (พิมพ์ใหม่ในเดือนพฤศจิกายน พ.ศ. 2530 พร้อมฉบับแก้ไข 1)

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

เงื่อนไขการอ้างอิงจะต้องมีส่วนต่อไปนี้:

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

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

มาตรฐานต่อไป
GOST (ST SEV) 19.101-77 (1626-79) อีเอสพีดี. ประเภทโปรแกรมและเอกสารโปรแกรม (ออกใหม่ในเดือนพฤศจิกายน 2530 พร้อมแก้ไขครั้งที่ 1)
กำหนดประเภทของโปรแกรมและเอกสารโปรแกรมสำหรับคอมพิวเตอร์ อาคารและระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขต

ประเภทของโปรแกรม

ประเภทของเอกสารโปรแกรม

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

ประเภทของเอกสารการปฏิบัติงาน

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

เอกสารโปรแกรมแบ่งออกเป็นต้นฉบับ ทำซ้ำและคัดลอก (GOST 2.102-68) ขึ้นอยู่กับวิธีการนำไปใช้และลักษณะของแอปพลิเคชัน ซึ่งมีไว้สำหรับการพัฒนา การบำรุงรักษา และการทำงานของโปรแกรม

ประเภทของเอกสารโปรแกรมที่พัฒนาในแต่ละขั้นตอนและรหัส

รหัสประเภทเอกสาร	ประเภทเอกสาร	ขั้นตอนการพัฒนา
		การออกแบบเบื้องต้น	โครงการด้านเทคนิค	ร่างการทำงาน
		การออกแบบเบื้องต้น	โครงการด้านเทคนิค	ส่วนประกอบ	ซับซ้อน
-	ข้อมูลจำเพาะ	-	-	!	+
05	รายชื่อผู้ถือเดิม	-	-	-	?
12	ข้อความโปรแกรม	-	-	+	?
13	คำอธิบายโปรแกรม	-	-	?	?
20	รายการเอกสารการดำเนินงาน	-	-	?	?
30	รูปร่าง	-	-	?	?
31	คำอธิบายของแอปพลิเคชัน	-	-	?	?
32	คู่มือโปรแกรมเมอร์ระบบ	-	-	?	?
33	คู่มือโปรแกรมเมอร์	-	-	?	?
34	คู่มือการใช้งาน	-	-	?	?
35	คำอธิบายภาษา	-	-	?	?
46	คู่มือการบำรุงรักษา	-	-	?	?
51	โปรแกรมทดสอบและวิธีการ	-	-	?	?
81	หมายเหตุอธิบาย	?	?	-	-
90-99	เอกสารอื่นๆ	?	?	?	?

อนุญาตให้รวมเอกสารการปฏิบัติงานบางประเภทได้ (ยกเว้นรายการเอกสารการปฏิบัติงานและแบบฟอร์ม) ความจำเป็นในการรวมเอกสารเหล่านี้ระบุไว้ในข้อกำหนดทางเทคนิค เอกสารที่ผสานได้รับการกำหนดชื่อและการกำหนดเอกสารที่ผสานอย่างใดอย่างหนึ่ง เอกสารที่ผสานจะต้องระบุข้อมูลที่จะต้องรวมไว้ในเอกสารแต่ละฉบับที่จะผสาน

GOST 19.102-77 อีเอสพีดี. ขั้นตอนการพัฒนา

ขั้นตอนการพัฒนา ขั้นตอน และเนื้อหาของงาน

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

หมายเหตุ:

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

GOST 19.103-77 ESPD การกำหนดโปรแกรมและเอกสารโปรแกรม

หมายเลขทะเบียนถูกกำหนดโดยเรียงลำดับจากน้อยไปมาก เริ่มตั้งแต่ 00001 ถึง 99999 สำหรับแต่ละองค์กรเพื่อการพัฒนา
หมายเลขสิ่งพิมพ์ของโปรแกรมหรือหมายเลขแก้ไข จำนวนเอกสารประเภทนี้จำนวนส่วนของเอกสารถูกกำหนดตามลำดับจากน้อยไปมากจาก 01 ถึง 99 (หากเอกสารประกอบด้วยส่วนหนึ่งส่วนจะไม่มีการระบุยัติภังค์และหมายเลขซีเรียลของชิ้นส่วน)
หมายเลขการแก้ไขข้อกำหนดและรายการเอกสารการปฏิบัติงานสำหรับโปรแกรมจะต้องตรงกับหมายเลขการเผยแพร่ของโปรแกรมเดียวกัน

GOST 19.105-78 อีเอสพีดี ข้อกำหนดทั่วไปสำหรับเอกสารโปรแกรม

GOST 19.106-78 อีเอสพีดี ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์

เอกสารโปรแกรมจัดทำโดย:

บนแผ่นงานรูปแบบ A4 (GOST 2.301-68) เมื่อเตรียมเอกสารด้วยการพิมพ์หรือเขียนด้วยลายมือ
สามารถพิมพ์บนแผ่นขนาด A3;
ด้วยวิธีการใช้เครื่องในการดำเนินการเอกสารอนุญาตให้มีการเบี่ยงเบนขนาดของแผ่นงานที่สอดคล้องกับรูปแบบ A4 และ A3 โดยพิจารณาจากความสามารถของวิธีการทางเทคนิคที่ใช้ บนแผ่นงานรูปแบบ A4 และ A3 ซึ่งจัดทำโดยลักษณะเอาต์พุตของอุปกรณ์เอาต์พุตข้อมูลเมื่อสร้างเอกสารด้วยเครื่องจักร
บนแผ่นงานรูปแบบการพิมพ์เมื่อผลิตเอกสารโดยใช้วิธีพิมพ์

เนื้อหาของเอกสารโปรแกรมจะจัดเรียงตามลำดับต่อไปนี้:

ส่วนของชื่อเรื่อง:

เอกสารอนุมัติ (ไม่รวมอยู่ในจำนวนแผ่นงานทั้งหมดของเอกสาร)
หน้าชื่อเรื่อง (หน้าแรกของเอกสาร);

ส่วนข้อมูล:

คำอธิบายประกอบ;
สารบัญ;

ส่วนสำคัญ:

ข้อความในเอกสาร (พร้อมรูปภาพ ตาราง ฯลฯ)
รายการคำศัพท์และคำจำกัดความ
รายการคำย่อ
การใช้งาน;
ดัชนีหัวเรื่อง;
รายการเอกสารอ้างอิง

เปลี่ยนส่วนการบันทึก:

เปลี่ยนใบทะเบียน

มาตรฐานต่อไปนี้มุ่งเน้นไปที่การบันทึกผลลัพธ์ของผลิตภัณฑ์การพัฒนา:

GOST 19.402-78 อีเอสพีดี คำอธิบายโปรแกรม

เราต้องเน้นด้วย

ในที่สุดมาตรฐานล่าสุดตามปีที่นำมาใช้

2.2. มาตรฐานของคอมเพล็กซ์ GOST 34

สำหรับกรณีทั่วไปของการพัฒนา AS ขั้นตอนและขั้นตอนของ GOST 34 แสดงไว้ในตาราง:

1. FT - การกำหนดข้อกำหนดสำหรับผู้พูด	1.1. การตรวจสอบสิ่งอำนวยความสะดวกและเหตุผลของความจำเป็นในการสร้างโรงไฟฟ้านิวเคลียร์ 1.2. การสร้างข้อกำหนดของผู้ใช้สำหรับผู้พูด 1.3. การจัดทำรายงานเกี่ยวกับงานที่ทำและแอปพลิเคชันสำหรับการพัฒนา AS (ข้อกำหนดทางยุทธวิธีและทางเทคนิค)
2. RK - การพัฒนาแนวคิด AS	2.1. ศึกษาวัตถุ 2.2. ดำเนินงานวิจัยที่จำเป็น 2.3. การพัฒนาทางเลือกสำหรับแนวคิดวิทยากรที่ตรงตามความต้องการของผู้ใช้ 2.4. จัดทำรายงานเกี่ยวกับงานที่ทำ
3. TK - การสร้างทางเทคนิคของ AS	3.1. การพัฒนาและการอนุมัติข้อกำหนดทางเทคนิคสำหรับงาน
4. EP - การออกแบบร่าง	4.1. การพัฒนาโซลูชั่นการออกแบบเบื้องต้นสำหรับระบบและชิ้นส่วน 4.2. การพัฒนาเอกสารสำหรับ AU และส่วนต่างๆ
5. TP - การออกแบบทางเทคนิค	5.1. การพัฒนาโซลูชั่นการออกแบบสำหรับระบบและชิ้นส่วน 5.2. การพัฒนาเอกสารสำหรับ NPP และส่วนต่างๆ 5.3. การพัฒนาและการดำเนินการเอกสารสำหรับการจัดหาผลิตภัณฑ์เพื่อให้เป็นไปตามข้อกำหนด NPP และ/หรือข้อกำหนดทางเทคนิค (ข้อกำหนดทางเทคนิค) เพื่อการพัฒนา 5.4. การพัฒนางานออกแบบในส่วนที่อยู่ติดกันของโครงการสิ่งอำนวยความสะดวกระบบอัตโนมัติ
6. RD - เอกสารการทำงาน	6.1. การพัฒนาเอกสารการทำงานสำหรับระบบและส่วนต่างๆ 6.2. การพัฒนาหรือดัดแปลงโปรแกรม
7. VD - นำไปปฏิบัติ	7.1. การเตรียมสิ่งอำนวยความสะดวกอัตโนมัติเพื่อนำโรงงานไปดำเนินการ 7.2. การฝึกอบรมบุคลากร 7.3. ชุดวิทยากรครบชุดพร้อมผลิตภัณฑ์ที่ให้มา (ซอฟต์แวร์และฮาร์ดแวร์ ระบบซอฟต์แวร์และฮาร์ดแวร์ ผลิตภัณฑ์ข้อมูล) 7.4. งานก่อสร้างและติดตั้ง 7.5. การว่าจ้างงาน; 7.6. ดำเนินการทดสอบเบื้องต้น 7.7. การดำเนินการทดลอง 7.8. ดำเนินการทดสอบการยอมรับ
8. รองรับ Sp - AC	8.1. ดำเนินงานตามภาระผูกพันในการรับประกัน 8.2. บริการหลังการรับประกัน

มีการอธิบายเนื้อหาของเอกสารที่พัฒนาในแต่ละขั้นตอน สิ่งนี้จะกำหนดความเป็นไปได้ที่เป็นไปได้ในการระบุงานแบบ end-to-end ระดับสาระสำคัญที่ดำเนินการแบบคู่ขนานหรือตามลำดับ (นั่นคือในสาระสำคัญกระบวนการ) และงานที่เป็นส่วนประกอบ เทคนิคนี้สามารถใช้เมื่อสร้างโปรไฟล์ของมาตรฐานวงจรชีวิตของโครงการ รวมถึงชุดย่อยที่ตกลงกันไว้ของมาตรฐาน GOST 34 และ ISO12207

จุดประสงค์หลัก: เพื่อแก้ปัญหา "หอคอยบาเบล"

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

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

ระดับของความสามารถในการปรับตัวถูกกำหนดอย่างเป็นทางการโดยความสามารถ:

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

“ระบบองค์กรและเทคนิคที่รับรองการพัฒนาโซลูชันโดยอาศัยกระบวนการอัตโนมัติของกระบวนการข้อมูลในกิจกรรมต่างๆ (การจัดการ การออกแบบ การผลิต ฯลฯ) หรือการผสมผสานกัน” (ตาม RD 50-680-88) ซึ่ง มีความเกี่ยวข้องโดยเฉพาะอย่างยิ่งในด้านธุรกิจ - การรื้อปรับระบบ;
“ ระบบที่ประกอบด้วยบุคลากรและชุดเครื่องมืออัตโนมัติสำหรับกิจกรรมของพวกเขาการนำเทคโนโลยีสารสนเทศไปใช้สำหรับการปฏิบัติหน้าที่ที่กำหนดไว้” (ตาม GOST 34.003-90)

ระดับภาระผูกพัน:

2.3. มาตรฐานรัฐของสหพันธรัฐรัสเซีย (GOST R)

GOST R ISO 9127-94ระบบประมวลผลข้อมูล เอกสารประกอบผู้ใช้และข้อมูลบรรจุภัณฑ์สำหรับแพ็คเกจซอฟต์แวร์สำหรับผู้บริโภค มาตรฐานนี้สอดคล้องกับมาตรฐานสากล ISO 9127:1989 อย่างสมบูรณ์ สำหรับวัตถุประสงค์ของมาตรฐานนี้ ชุดซอฟต์แวร์สำหรับผู้บริโภค (CPP) หมายถึง "ผลิตภัณฑ์ซอฟต์แวร์ที่ออกแบบและจำหน่ายเพื่อทำหน้าที่เฉพาะ โปรแกรมและเอกสารที่เกี่ยวข้องซึ่งจัดทำเป็นแพ็คเกจเพื่อขายเป็นหน่วยเดียว" เอกสารสำหรับผู้ใช้หมายถึงเอกสารที่ให้ข้อมูลเกี่ยวกับการติดตั้งและการทำงานของซอฟต์แวร์แก่ผู้ใช้ ข้อมูลบนบรรจุภัณฑ์หมายถึงข้อมูลที่ทำซ้ำบนบรรจุภัณฑ์ด้านนอกของ PP วัตถุประสงค์คือเพื่อให้ข้อมูลเบื้องต้นเกี่ยวกับซอฟต์แวร์แก่ผู้ซื้อที่มีศักยภาพ

2.4. มาตรฐานสากล ISO/IEC 12207:1995-08-01

ISO12207 ฉบับพิมพ์ครั้งแรกจัดทำขึ้นในปี 1995 โดยคณะกรรมการด้านเทคนิคร่วม ISO/IEC JTC1 "เทคโนโลยีสารสนเทศ คณะอนุกรรมการ SC7 วิศวกรรมซอฟต์แวร์"

หมายเหตุที่สำคัญมากของมาตรฐาน:

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

คำจำกัดความมาตรฐาน:

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

มาตรฐาน ISO12207 อธิบาย:

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

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

ลักษณะนี้ทำให้สามารถใช้แบบจำลองวงจรชีวิตใดๆ ก็ได้

ในกรณีนี้ นักพัฒนาจะต้องจัดทำและจัดทำเอกสารตามข้อกำหนดของซอฟต์แวร์:

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

(เป็นที่น่าสนใจและสำคัญที่คุณลักษณะเหล่านี้และลักษณะที่คล้ายกันนั้นสอดคล้องกับลักษณะของ NPP ที่กำหนดไว้ใน GOST 34 เป็นอย่างดีสำหรับประเภทของการสนับสนุนระบบ)

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

ข้อมูลอ้างอิง

หากต้องการซื้อมาตรฐานเอกสาร เราขอแนะนำให้ติดต่อองค์กรต่อไปนี้:

IPK "มาตรฐานการเผยแพร่", แผนกจำหน่ายเอกสารทางวิทยาศาสตร์และทางเทคนิคของอาณาเขต (ร้านค้า "มาตรฐาน"), 17961, มอสโก, เซนต์. ดอนสกายา อายุ 8 ขวบ โทร. 236-50-34, 237-00-02 แฟกซ์/โทรศัพท์ 236-34-48 (เกี่ยวกับ GOST และ GOST R)