วงจรชีวิตและขั้นตอนของการพัฒนาซอฟต์แวร์ วงจรชีวิตของซอฟต์แวร์: แนวคิดมาตรฐานกระบวนการวงจรชีวิตของซอฟต์แวร์

รูปที่. 5.2

ลักษณะเหล่านี้ ได้แก่ :

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

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

5.6 แบบจำลองและขั้นตอนของวงจรชีวิตซอฟต์แวร์

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

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

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

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

1. การสร้างข้อกำหนดซอฟต์แวร์
2. การออกแบบ (การพัฒนาโครงการระบบ);
3. การนำไปใช้งาน (สามารถแบ่งออกเป็นขั้นตอนย่อย: การออกแบบโดยละเอียดการเข้ารหัส);
4. การทดสอบ (สามารถแบ่งออกเป็นการทดสอบแบบสแตนด์อโลนและแบบซับซ้อนและการรวม)
5. การว่าจ้าง (การใช้งาน);
6. การดำเนินงานและการบำรุงรักษา;
7. การรื้อถอน

ผู้เชี่ยวชาญบางคนแนะนำขั้นตอนเริ่มต้นเพิ่มเติม - การศึกษาความเป็นไปได้ ระบบ หมายถึงซอฟต์แวร์และระบบฮาร์ดแวร์ที่ซอฟต์แวร์ถูกสร้างซื้อหรือแก้ไข

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

ขั้นตอนของการสร้างข้อกำหนดซอฟต์แวร์ประกอบด้วยขั้นตอนต่อไปนี้

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

การสร้างแบบจำลองของกิจกรรม (วัตถุ) ขององค์กรโดยจัดเตรียมสำหรับการประมวลผลวัสดุสำรวจและการสร้างแบบจำลองสองประเภท:

• แบบจำลอง "AS-IS" ("ตามสภาพ") ที่สะท้อนสถานการณ์ปัจจุบันขององค์กรในขณะที่ทำการสำรวจและช่วยให้เข้าใจวิธีการทำงานขององค์กรตลอดจนระบุปัญหาคอขวดและกำหนดข้อเสนอในการปรับปรุงสถานการณ์
• แบบจำลอง "TO-BE" ("ควรจะเป็นอย่างไร") ซึ่งสะท้อนถึงแนวคิดเกี่ยวกับเทคโนโลยีใหม่ ๆ ในองค์กร

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

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

ขั้นตอนการออกแบบประกอบด้วยขั้นตอนต่อไปนี้

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

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

2. การพัฒนาโครงการโดยละเอียด (ทางเทคนิค) ในขั้นตอนนี้จะดำเนินการออกแบบซอฟต์แวร์จริงรวมถึงการออกแบบสถาปัตยกรรมระบบและการออกแบบรายละเอียด ดังนั้นคำตอบจะได้รับสำหรับคำถาม: "จะสร้างระบบอย่างไรให้เป็นไปตามข้อกำหนด"

ผลของการออกแบบโดยละเอียดคือการพัฒนาข้อกำหนดซอฟต์แวร์ที่ได้รับการยืนยันซึ่ง ได้แก่ :

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

ขั้นตอนการออกแบบรายละเอียดเสร็จสิ้นแล้ว

มาตรฐานวงจรชีวิตของซอฟต์แวร์

• GOST 34.601-90
• ISO / IEC 12207: 1995 (อะนาล็อกของรัสเซีย - GOST R ISO / IEC 12207-99)

มาตรฐาน GOST 34 .601-90

แบบจำลองซ้ำ

อีกทางเลือกหนึ่งของแบบจำลองตามลำดับคือรูปแบบการพัฒนาแบบวนซ้ำและแบบเพิ่มหน่วย (อังกฤษ. การพัฒนาแบบวนซ้ำและแบบเพิ่มหน่วย IID ) ซึ่งได้รับจาก T. Gilb ในยุค 70 ชื่อ แบบจำลองวิวัฒนาการ... รุ่นนี้เรียกอีกอย่างว่า แบบจำลองซ้ำ และ แบบจำลองที่เพิ่มขึ้น .

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

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

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

แนวทางการทำซ้ำหลาย ๆ รูปแบบถูกนำไปใช้ในวิธีการพัฒนาที่ทันสมัยที่สุด (RUP, MSF,)

แบบจำลองเกลียว

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

ในการทำซ้ำแต่ละครั้งจะมีการประเมินสิ่งต่อไปนี้:

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

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

คุณลักษณะที่โดดเด่นของแบบจำลองเกลียวคือความสนใจเป็นพิเศษที่จ่ายให้กับความเสี่ยงที่มีผลต่อการจัดระเบียบวงจรชีวิตและเหตุการณ์สำคัญ Boehm แสดงรายการความเสี่ยง 10 อันดับที่พบบ่อยที่สุด (จัดลำดับความสำคัญ):

1. ความบกพร่องของผู้เชี่ยวชาญ
2. ไทม์ไลน์และงบประมาณที่ไม่สมจริง
3. การใช้งานฟังก์ชันที่ไม่เหมาะสม
4. การออกแบบส่วนต่อประสานผู้ใช้ที่ไม่ถูกต้อง
5. ความสมบูรณ์แบบการเพิ่มประสิทธิภาพที่ไม่จำเป็นและการสร้างเสริมรายละเอียด
6. กระแสแห่งการเปลี่ยนแปลงไม่หยุดหย่อน
7. ขาดข้อมูลเกี่ยวกับองค์ประกอบภายนอกที่กำหนดสภาพแวดล้อมของระบบหรือเกี่ยวข้องกับการรวม
8. ข้อบกพร่องในงานที่ดำเนินการโดยทรัพยากรภายนอก (ที่เกี่ยวข้องกับโครงการ)
9. ประสิทธิภาพของระบบผลลัพธ์ไม่เพียงพอ
10. ช่องว่างในคุณสมบัติของผู้เชี่ยวชาญในสาขาต่างๆ

แบบจำลองเกลียวปัจจุบันกำหนดชุดจุดควบคุมทั่วไปดังต่อไปนี้:

1. Concept of Operations (COO) - แนวคิด (การใช้งาน) ของระบบ
2. Life Cycle Objectives (LCO) - เป้าหมายและเนื้อหาของวงจรชีวิต
3. Life Cycle Architecture (LCA) - สถาปัตยกรรมวงจรชีวิต ที่นี่เป็นไปได้ที่จะพูดเกี่ยวกับความพร้อมของสถาปัตยกรรมแนวความคิดของระบบซอฟต์แวร์เป้าหมาย
4. Initial Operational Capability (IOC) - เวอร์ชันแรกของผลิตภัณฑ์ที่สร้างขึ้นเหมาะสำหรับการทดลองใช้งาน
5. Final Operational Capability (FOC) คือผลิตภัณฑ์สำเร็จรูปที่ปรับใช้ (ติดตั้งและกำหนดค่า) สำหรับการใช้งานจริง

วิธีการพัฒนาซอฟต์แวร์

• Microsoft Solutions Framework (MSF) ประกอบด้วย 4 ขั้นตอน ได้แก่ การวิเคราะห์การออกแบบการพัฒนาการทำให้เสถียรเกี่ยวข้องกับการใช้การสร้างแบบจำลองเชิงวัตถุ
• การเขียนโปรแกรมขั้นสูง (อังกฤษ. Extreme Programming, XP) วิธีการนี้ขึ้นอยู่กับการทำงานเป็นทีมการสื่อสารที่มีประสิทธิภาพระหว่างลูกค้าและผู้รับเหมาระหว่างโครงการทั้งหมดสำหรับการพัฒนา IS การพัฒนาดำเนินการโดยใช้ต้นแบบที่กลั่นอย่างสม่ำเสมอ
• ESPD เป็นชุดของมาตรฐานระดับรัฐของสหพันธรัฐรัสเซียที่กำหนดกฎเกณฑ์ที่เกี่ยวข้องกันสำหรับการพัฒนาการออกแบบและการเผยแพร่โปรแกรมและเอกสารประกอบโปรแกรม

วรรณกรรม

• Bratishchenko V.V. การออกแบบระบบสารสนเทศ - Irkutsk: สำนักพิมพ์ BSUEP, 2004. - 84 p.
• Vendrov A.M. การออกแบบซอฟต์แวร์สำหรับระบบสารสนเทศทางเศรษฐกิจ - ม.: การเงินและสถิติ, 2543
• Grekul V.I. , Denischenko G.N. , Korovkina N.L. การออกแบบระบบสารสนเทศ - M .: Internet University of Information Technologies - INTUIT.ru, 2005
• Mishenin A.I. ทฤษฎีระบบสารสนเทศทางเศรษฐกิจ - ม.: การเงินและสถิติ, 2543. - 240 น.

หมายเหตุ

มูลนิธิวิกิมีเดีย 2010

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

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

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

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

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

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

ผลิตภัณฑ์ซอฟต์แวร์อายุการใช้งานสั้น

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

โดยที่วงจรชีวิตของผลิตภัณฑ์ซอฟต์แวร์แทบจะไม่เกิน 3 ปี

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

ผลิตภัณฑ์ซอฟต์แวร์ที่มีอายุการใช้งานยาวนาน

ทีมผู้เชี่ยวชาญจำนวนมากมีส่วนร่วมในการออกแบบและการดำเนินการซึ่งต้องมีการทำให้เป็นทางการของระบบซอฟต์แวร์ตลอดจนการทดสอบอย่างเป็นทางการและการกำหนดตัวบ่งชี้คุณภาพของผลิตภัณฑ์ขั้นสุดท้าย วงจรชีวิตของพวกเขาคือ 10 ... 20 ปี ถึง 70 ... 90% ของเวลานี้ใช้ไปกับการดำเนินงานและการบำรุงรักษา เนื่องจากการจำลองแบบจำนวนมากและการบำรุงรักษาในระยะยาวค่าใช้จ่ายทั้งหมดในระหว่างการดำเนินการและการบำรุงรักษาผลิตภัณฑ์ซอฟต์แวร์ดังกล่าวสูงกว่าค่าใช้จ่ายในการวิเคราะห์และออกแบบระบบอย่างมีนัยสำคัญ

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

โมเดลทั่วไป วงจรชีวิต ผลิตภัณฑ์ซอฟต์แวร์อาจมีลักษณะดังนี้:

ผม. การวิเคราะห์ระบบ:

ก) การวิจัย;

b) การวิเคราะห์ความเป็นไปได้:

การปฏิบัติงาน

เศรษฐกิจ;

เชิงพาณิชย์

ครั้งที่สอง การออกแบบซอฟต์แวร์:

ก) การออกแบบ:

การสลายตัวตามหน้าที่ของระบบสถาปัตยกรรมของมัน

การออกแบบซอฟต์แวร์ภายนอก

การออกแบบฐานข้อมูล

สถาปัตยกรรมซอฟต์แวร์

b) การเขียนโปรแกรม:

การออกแบบซอฟต์แวร์ภายใน

การออกแบบภายนอกของโมดูลซอฟต์แวร์

การออกแบบภายในของโมดูลซอฟต์แวร์

การเข้ารหัส;

โปรแกรมดีบั๊ก

Programming;

c) การดีบักซอฟต์แวร์

สาม. การประเมิน (การทดสอบ) ของซอฟต์แวร์

IV การใช้ซอฟต์แวร์:

ก) การดำเนินการ;

b) ประกอบ

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

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

การวิจัยเริ่มขึ้น ตั้งแต่วินาทีที่ผู้จัดการฝ่ายพัฒนาตระหนักถึงความต้องการซอฟต์แวร์

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

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

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

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

- ความเป็นไปได้ในการดำเนินงาน , ผลิตภัณฑ์จะสะดวกสบายเพียงพอสำหรับการใช้งานจริงหรือไม่?

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

- ความเป็นไปได้ในเชิงพาณิชย์ สินค้าจะน่าสนใจเป็นที่ต้องการติดตั้งง่ายปรับตัวเข้ากับบริการเรียนรู้ได้ง่ายหรือไม่?

ปัญหาเหล่านี้และปัญหาอื่น ๆ จำเป็นต้องได้รับการแก้ไขเป็นหลักเมื่อพิจารณาข้อกำหนดข้างต้น

การศึกษาความเป็นไปได้จะสิ้นสุดลงเมื่อมีการรวบรวมและอนุมัติข้อกำหนดทั้งหมด

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

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

บ่อยครั้งในช่วงของการวิเคราะห์ระบบจะมีการตัดสินใจที่จะหยุดการพัฒนาซอฟต์แวร์เพิ่มเติม

ครั้งที่สอง... การออกแบบซอฟต์แวร์ การออกแบบเป็นขั้นตอนหลักและชี้ขาดของวงจรชีวิตซอฟต์แวร์ในระหว่างที่ผลิตภัณฑ์ซอฟต์แวร์ถูกสร้างขึ้นและ 90% ได้รับรูปแบบสุดท้าย

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

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

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

ในส่วนนี้ของอายุการใช้งานซอฟต์แวร์พวกเขาดำเนินการ:

การสลายตัวตามหน้าที่ของปัญหาที่กำลังแก้ไขบนพื้นฐานของการกำหนดสถาปัตยกรรมระบบของปัญหานี้

การออกแบบภายนอกของซอฟต์แวร์แสดงออกในรูปแบบของปฏิสัมพันธ์ภายนอกกับผู้ใช้

การออกแบบฐานข้อมูลหากจำเป็น

การออกแบบสถาปัตยกรรมซอฟต์แวร์ - การกำหนดวัตถุโมดูลและส่วนต่อประสาน

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

ในขั้นตอนนี้งานที่เกี่ยวข้องกับการประกอบผลิตภัณฑ์ซอฟต์แวร์จะดำเนินการ ประกอบด้วยการออกแบบภายในโดยละเอียดของผลิตภัณฑ์ซอฟต์แวร์ในการพัฒนาตรรกะภายในของแต่ละโมดูลของระบบซึ่งจะแสดงในข้อความของโปรแกรมเฉพาะ

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

ซอฟต์แวร์ดีบั๊ก จะดำเนินการหลังจากที่ส่วนประกอบทั้งหมดถูกดีบั๊กแยกจากกันและประกอบเป็นผลิตภัณฑ์ซอฟต์แวร์เดียว

สาม... การประเมิน (การทดสอบ) ของซอฟต์แวร์ในขั้นตอนนี้ผลิตภัณฑ์ซอฟต์แวร์จะต้องผ่านการทดสอบระบบอย่างเข้มงวดโดยกลุ่มผู้ไม่พัฒนา

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

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

ใช้เวลานานพอ ๆ กับการเขียนโปรแกรม

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

การเปรียบเทียบดังกล่าวมีความเหมาะสมในแง่ของข้อเท็จจริงที่ว่าในระหว่างการใช้ผลิตภัณฑ์ซอฟต์แวร์ข้อผิดพลาดที่เกิดขึ้นในกระบวนการออกแบบจะได้รับการแก้ไข

ขั้นตอนการใช้งานของรายการซอฟต์แวร์เริ่มต้นเมื่อรายการถูกโอนไปยังระบบการแจกจ่าย

นี่คือช่วงเวลาที่ผลิตภัณฑ์กำลังทำงานและใช้งานได้อย่างมีประสิทธิภาพ

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

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

การใช้ผลิตภัณฑ์ซอฟต์แวร์จะพิจารณาจากการใช้งานและการบำรุงรักษา

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

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

การบำรุงรักษามีบทบาทของข้อเสนอแนะที่จำเป็นจากขั้นตอนการปฏิบัติงาน

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

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

ทับซ้อนระหว่างขั้นตอนของวงจรชีวิตผลิตภัณฑ์ซอฟต์แวร์

การทับซ้อนระหว่างระยะต่างๆของวงจรชีวิตผลิตภัณฑ์ซอฟต์แวร์เป็นไปได้และโดยปกติแล้วจะเป็นที่ต้องการ อย่างไรก็ตามไม่ควรมีการทับซ้อนกันระหว่างกระบวนการที่ไม่ต่อเนื่องกัน

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

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

ตัวอย่างเช่นเมื่อมีการออกแบบโปรแกรมเดียวสถาปัตยกรรมระบบมักจะจ่ายด้วยและ

การออกแบบฐานข้อมูล กระบวนการของการออกแบบภายนอกเริ่มต้นและรายละเอียดมักจะรวมเข้าด้วยกัน ฯลฯ

มาตรฐานวงจรชีวิตของซอฟต์แวร์

• GOST 34.601-90
• ISO / IEC 12207: 1995 (อะนาล็อกของรัสเซีย - GOST R ISO / IEC 12207-99)

วิธีการพัฒนาซอฟต์แวร์

• Rational Unified Process (RUP)
• Microsoft Solutions Framework (MSF) ประกอบด้วย 4 ขั้นตอน ได้แก่ การวิเคราะห์การออกแบบการพัฒนาการทำให้เสถียรเกี่ยวข้องกับการใช้การสร้างแบบจำลองเชิงวัตถุ
• การเขียนโปรแกรมขั้นสูง ( การเขียนโปรแกรมขั้นสูง, XP) วิธีการนี้ขึ้นอยู่กับการทำงานเป็นทีมการสื่อสารที่มีประสิทธิภาพระหว่างลูกค้าและผู้รับเหมาระหว่างโครงการทั้งหมดสำหรับการพัฒนา IS การพัฒนาดำเนินการโดยใช้ต้นแบบที่กลั่นอย่างสม่ำเสมอ

มาตรฐาน GOST 34.601-90

มาตรฐาน GOST 34.601-90 จัดเตรียมขั้นตอนและขั้นตอนต่อไปนี้ในการสร้างระบบอัตโนมัติ:

1. การสร้างข้อกำหนดสำหรับ AU
   1. การสำรวจสถานที่และเหตุผลของความจำเป็นในการสร้างโรงไฟฟ้านิวเคลียร์
   2. การสร้างความต้องการของผู้ใช้สำหรับลำโพง
   3. การลงทะเบียนรายงานความคืบหน้าของงานและการสมัครเพื่อพัฒนาอสส
2. การพัฒนาแนวคิดของวิทยากร
   1. การศึกษาวัตถุ
   2. ดำเนินงานวิจัยที่จำเป็น
   3. การพัฒนาตัวเลือกสำหรับแนวคิดของลำโพงและการเลือกเวอร์ชันของแนวคิดของลำโพงที่ตรงตามความต้องการของผู้ใช้
   4. การรายงานเกี่ยวกับงานที่ทำ
3. งานด้านเทคนิค
   1. การพัฒนาและการอนุมัติข้อกำหนดทางเทคนิคสำหรับการสร้าง AU
4. การออกแบบเบื้องต้น
   1. การพัฒนาโซลูชันการออกแบบเบื้องต้นสำหรับระบบและชิ้นส่วน
5. โครงการทางเทคนิค
   1. การพัฒนาโซลูชันการออกแบบสำหรับระบบและชิ้นส่วนต่างๆ
   2. การพัฒนาเอกสารสำหรับ NPP และชิ้นส่วน
   3. การพัฒนาและการดำเนินการของเอกสารสำหรับการจัดหาส่วนประกอบ
   4. การพัฒนางานออกแบบในส่วนที่เกี่ยวข้องของโครงการ
6. เอกสารการทำงาน
   1. การพัฒนาเอกสารประกอบการทำงานสำหรับ NPP และส่วนต่างๆ
   2. การพัฒนาและปรับโปรแกรม
7. การว่าจ้าง
   1. การเตรียมวัตถุอัตโนมัติ
   2. การฝึกอบรมพนักงาน
   3. การเติมเต็มระบบลำโพงด้วยผลิตภัณฑ์ที่ให้มา (ซอฟต์แวร์และฮาร์ดแวร์ซอฟต์แวร์และฮาร์ดแวร์คอมเพล็กซ์ผลิตภัณฑ์ข้อมูล)
   4. งานก่อสร้างและติดตั้ง
   5. การว่าจ้างงาน
   6. การทดสอบเบื้องต้น
   7. ทดลองใช้งาน
   8. การทดสอบการยอมรับ
8. AC คุ้มกัน
   1. การปฏิบัติงานตามข้อผูกพันในการรับประกัน
   2. บริการหลังการรับประกัน

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

มาตรฐานนี้ไม่เหมาะสมอย่างยิ่งสำหรับการพัฒนาในปัจจุบัน: กระบวนการหลายอย่างไม่ได้รับการสะท้อนอย่างเพียงพอและบทบัญญัติบางประการล้าสมัย

ISO / IEC 12207 / มาตรฐานและการประยุกต์ใช้

ISO / IEC 12207: 1995 "Information Technology - Software Life Cycle Processes" เป็นเอกสารเชิงบรรทัดฐานหลักที่ควบคุมองค์ประกอบของกระบวนการวงจรชีวิตซอฟต์แวร์ เป็นการกำหนดโครงสร้างวงจรชีวิตที่ประกอบด้วยกระบวนการกิจกรรมและงานที่ต้องดำเนินการระหว่างการสร้างซอฟต์แวร์

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

กระบวนการวงจรชีวิตของซอฟต์แวร์

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

แต่ละกระบวนการเกี่ยวข้องกับชุดของการกระทำ ตัวอย่างเช่นกระบวนการได้มาซึ่งครอบคลุมขั้นตอนต่อไปนี้:

1. การเริ่มต้นการซื้อกิจการ
2. การจัดทำข้อเสนอการสมัคร
3. การจัดทำและแก้ไขสัญญา
4. การกำกับดูแลซัพพลายเออร์
5. การยอมรับและความสำเร็จของงาน

แต่ละการดำเนินการประกอบด้วยชุดของงาน ตัวอย่างเช่นการจัดทำข้อเสนอการเสนอราคาควรประกอบด้วย:

1. การสร้างข้อกำหนดของระบบ
2. การสร้างรายการผลิตภัณฑ์ซอฟต์แวร์
3. การกำหนดเงื่อนไขและข้อตกลง
4. คำอธิบายข้อ จำกัด ทางเทคนิค (สภาพแวดล้อมของการทำงานของระบบ ฯลฯ )

ขั้นตอนของวงจรชีวิตซอฟต์แวร์ความสัมพันธ์ระหว่างกระบวนการและขั้นตอน

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

GOST R ISO / IEC 12207-99 ไม่มีรูปแบบวงจรชีวิตเฉพาะ ข้อกำหนดของมันเป็นเรื่องธรรมดาสำหรับแบบจำลองวงจรชีวิตวิธีการและเทคโนโลยีสำหรับการสร้าง IP อธิบายถึงโครงสร้างของกระบวนการวงจรชีวิตโดยไม่ได้ระบุวิธีการนำไปใช้หรือดำเนินกิจกรรมและงานที่รวมอยู่ในกระบวนการเหล่านี้

รูปแบบซอฟต์แวร์วงจรชีวิตประกอบด้วย:

1. ขั้นตอน;
2. ผลงานในแต่ละขั้นตอน
3. เหตุการณ์สำคัญคือจุดแห่งความสำเร็จและการตัดสินใจ

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

ในแต่ละขั้นตอนสามารถดำเนินการหลายกระบวนการที่กำหนดไว้ในมาตรฐาน GOST R ISO / IEC 12207-99 และในทางกลับกันกระบวนการเดียวกันสามารถทำได้ในแต่ละขั้นตอน ความสัมพันธ์ระหว่างกระบวนการและขั้นตอนยังพิจารณาจากแบบจำลองวงจรชีวิตของซอฟต์แวร์ที่ใช้

แบบจำลองวงจรชีวิตของซอฟต์แวร์

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

จนถึงปัจจุบันแบบจำลองวงจรชีวิตหลักต่อไปนี้แพร่หลายมากที่สุด:

• แบบจำลองปัญหา;

• แบบจำลองน้ำตก (หรือระบบ) (70-85 ปี);

• แบบเกลียว (ปัจจุบัน)

แบบจำลองปัญหา

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

• ความเร่งด่วนมาก (คุณต้องแก้ไขปัญหาอย่างใดจากนั้นคุณต้องทำทุกอย่างอีกครั้ง)

• การทดลองและการปรับตัวของลูกค้า (อัลกอริทึมไม่ชัดเจนการแก้ปัญหาถูกคลำโดยการลองผิดลองถูก)

ข้อสรุปทั่วไป: เป็นไปไม่ได้ที่จะสร้างระบบข้อมูลที่มีประสิทธิภาพขนาดใหญ่เพียงพอด้วยวิธีนี้

แบบจำลอง Cascade

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

ประโยชน์ของการใช้วิธีน้ำตกมีดังนี้:

• ในแต่ละขั้นตอนจะมีการจัดทำเอกสารโครงการที่สมบูรณ์ซึ่งตรงตามเกณฑ์สำหรับความสมบูรณ์และความสอดคล้อง

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

ขั้นตอนโครงการตามแบบจำลองน้ำตก:

1. การก่อตัวของข้อกำหนด
2. ออกแบบ;
3. การดำเนินงาน;
4. การทดสอบ;
5. การดำเนินงาน;
6. การดำเนินงานและการบำรุงรักษา.

รูปที่. 1. โครงการพัฒนาน้ำตก

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

รูปที่. 2. ขั้นตอนที่แท้จริงของการพัฒนาซอฟต์แวร์ในรูปแบบน้ำตก

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

แบบจำลองเกลียว

เพื่อเอาชนะปัญหาที่ระบุไว้จึงเสนอ แบบเกลียว วงจรชีวิต (รูปที่ 3) ซึ่งได้รับการพัฒนาในช่วงกลางทศวรรษที่ 1980 โดย Barry Boehm ขึ้นอยู่กับขั้นตอนเริ่มต้นของวงจรชีวิต: การวิเคราะห์และการออกแบบ ในขั้นตอนเหล่านี้ความเป็นไปได้ของโซลูชันทางเทคนิคจะได้รับการตรวจสอบโดยการสร้างต้นแบบ

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

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

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

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

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

รูปที่ 3 แบบจำลองวงจรชีวิตแบบเกลียว IS

แนวทางหนึ่งที่เป็นไปได้ในการพัฒนาซอฟต์แวร์ภายใต้กรอบของแบบจำลองวัฏจักรชีวิตแบบเกลียวคือวิธีการที่แพร่หลายเมื่อเร็ว ๆ นี้ในการพัฒนาแอปพลิเคชันอย่างรวดเร็ว RAD (Rapid Application Development) คำนี้มักหมายถึงกระบวนการพัฒนาซอฟต์แวร์ที่ประกอบด้วย 3 องค์ประกอบ:

• ทีมโปรแกรมเมอร์ขนาดเล็ก (ตั้งแต่ 2 ถึง 10 คน)

• ตารางการผลิตสั้น แต่มีการพัฒนาอย่างดี (ตั้งแต่ 2 ถึง 6 เดือน)

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

วงจรชีวิตของซอฟต์แวร์ RAD ประกอบด้วยสี่ขั้นตอน:

• ข้อกำหนดและขั้นตอนการวิเคราะห์ข้อกำหนด

• ขั้นตอนการออกแบบ

• ขั้นตอนการดำเนินการ

• ขั้นตอนการดำเนินการ

ในการทำซ้ำแต่ละครั้งจะมีการประเมินสิ่งต่อไปนี้:

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

ข้อดีของวิธีการทำซ้ำ:

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

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

ตามมาตรฐาน ISO / IEC 12207 กระบวนการของวงจรชีวิตทั้งหมดแบ่งออกเป็นสามกลุ่ม (รูปที่ 2.1)

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

1. การสร้างข้อกำหนดซอฟต์แวร์

2. การออกแบบ

3. การนำไปใช้.

4. การทดสอบ

5. การว่าจ้าง

6. การดำเนินการและการบำรุงรักษา

7. การรื้อถอน

ปัจจุบันวงจรการใช้งานซอฟต์แวร์รุ่นพื้นฐานต่อไปนี้ถูกใช้กันอย่างแพร่หลายมากที่สุด:

ก) เรียงซ้อนและ

b) เกลียว (วิวัฒนาการ)

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

ข้อดีของการใช้แบบจำลองน้ำตกมีดังนี้:

ในแต่ละขั้นตอนจะมีการสร้างชุดเอกสารการออกแบบที่สมบูรณ์

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

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

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

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

แบบจำลองน้ำตก (วิวัฒนาการ) สามารถแสดงในรูปแบบของแผนภาพซึ่งแสดงในรูปที่ 2.5

หนึ่งในผลลัพธ์ของการใช้แบบจำลองวงจรชีวิตแบบเกลียวเป็นวิธีที่ใช้กันอย่างแพร่หลายในสิ่งที่เรียกว่า การพัฒนาแอปพลิเคชันอย่างรวดเร็ว , หรือ RAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว) ตามวิธีนี้วงจรชีวิตของซอฟต์แวร์ประกอบด้วยสี่ขั้นตอน:

1) การวิเคราะห์และการวางแผนข้อกำหนด

2) การออกแบบ;

3) การใช้งาน;

4) การใช้งาน

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

1) กลยุทธ์;

2) การวิเคราะห์;

3) การออกแบบ;

4) การดำเนินการ;

5) การทดสอบ;

6) การดำเนินการ;

7) การดำเนินการและการสนับสนุนทางเทคนิค

กลยุทธ์

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

ผลลัพธ์ของขั้นตอนการกำหนดกลยุทธ์คือเอกสารที่มีการกำหนดขั้นตอนต่อไปนี้อย่างชัดเจน:

ลูกค้าเกิดจากอะไรหากเขาตกลงที่จะจัดหาเงินทุนให้กับโครงการ

เขาจะสามารถรับผลิตภัณฑ์สำเร็จรูปได้เมื่อใด (ตารางการทำงาน)

เขาต้องเสียค่าใช้จ่ายเท่าไร (กำหนดการขั้นตอนการจัดหาเงินทุนสำหรับโครงการขนาดใหญ่)

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

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

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

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

นักวิเคราะห์รวบรวมและบันทึกข้อมูลในสองรูปแบบที่สัมพันธ์กัน:

ก) ฟังก์ชัน - ข้อมูลเกี่ยวกับเหตุการณ์และกระบวนการที่เกิดขึ้นในธุรกิจ

b) เอนทิตี - ข้อมูลเกี่ยวกับรายการที่เกี่ยวข้องกับองค์กรและสิ่งที่เป็นที่รู้จัก

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

ออกแบบ

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

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

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

งานออกแบบคือ:

การตรวจสอบผลการวิเคราะห์และการตรวจสอบความสมบูรณ์

สัมมนากับลูกค้า

การระบุประเด็นสำคัญของโครงการและการประเมินข้อ จำกัด

การกำหนดสถาปัตยกรรมระบบ

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

การออกแบบคลังข้อมูล: แบบจำลองฐานข้อมูล;

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

การกำหนดข้อกำหนดสำหรับกระบวนการทดสอบ

การกำหนดข้อกำหนดด้านความปลอดภัยของระบบ

การดำเนินงาน

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

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

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

ขั้นตอนการพัฒนาเกี่ยวข้องกับขั้นตอนการทดสอบและกระบวนการทั้งสองทำงานแบบขนานกัน ระบบติดตามข้อบกพร่องจะซิงโครไนซ์การดำเนินการของผู้ทดสอบและนักพัฒนา

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

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

การทดสอบ

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

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

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

ระบบแจ้งเตือนเกี่ยวกับข้อผิดพลาดใหม่เกี่ยวกับการเปลี่ยนแปลงสถานะข้อผิดพลาดที่ทราบในระบบ (การแจ้งเตือนทางอีเมล)

รายงานข้อผิดพลาดที่เกิดขึ้นจริงตามส่วนประกอบของระบบ

ข้อมูลเกี่ยวกับข้อผิดพลาดและประวัติ

กฎสำหรับการเข้าถึงข้อผิดพลาดของบางประเภท

ระบบติดตามข้อผิดพลาดอินเทอร์เฟซการเข้าถึงที่ จำกัด สำหรับผู้ใช้ปลายทาง

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

การทดสอบระบบจริงมักแบ่งออกเป็นหลายประเภท:

ก) การทดสอบออฟไลน์ โมดูล; มีการใช้งานอยู่แล้วในขั้นตอนของการพัฒนาส่วนประกอบของระบบและอนุญาตให้ติดตามข้อผิดพลาดของแต่ละองค์ประกอบ

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

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

ง) การทดสอบการยอมรับ; จุดประสงค์หลักคือการส่งมอบระบบให้กับลูกค้า

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

แต่ละกลุ่มจำเป็นต้องมีการทดสอบความล้มเหลวในการสร้างแบบจำลอง พวกเขาตรวจสอบการตอบสนองขององค์ประกอบกลุ่มของส่วนประกอบและระบบโดยรวมต่อความล้มเหลวต่อไปนี้:

องค์ประกอบแยกต่างหากของระบบสารสนเทศ

กลุ่มส่วนประกอบของระบบ

โมดูลหลักของระบบ

ระบบปฏิบัติการ;

ฮาร์ดล้มเหลว (ไฟฟ้าดับฮาร์ดไดรฟ์)

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

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

การดำเนินงาน

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

การว่าจ้างต้องผ่านอย่างน้อยสามขั้นตอน:

2) การสะสมข้อมูล;

3) ถึงขีดความสามารถในการออกแบบ (นั่นคือการเปลี่ยนไปสู่ขั้นตอนการปฏิบัติงานจริง)

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

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

ระบบถึงขีดความสามารถในการออกแบบ ในทางที่ดีเป็นการปรับความผิดพลาดเล็กน้อยและความผิดพลาดร้ายแรงที่หายาก

การดำเนินการและการสนับสนุนทางเทคนิค

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