วงจรชีวิตของระบบซอฟต์แวร์: ขั้นตอนหลัก แนวคิดวงจรชีวิตของซอฟต์แวร์
วงจรชีวิตของซอฟต์แวร์
วงจรชีวิต ซอฟต์แวร์- ระยะเวลาที่เริ่มต้นจากการตัดสินใจเกี่ยวกับความจำเป็นในการสร้างผลิตภัณฑ์ซอฟต์แวร์และสิ้นสุดในขณะที่ถูกถอนออกจากการให้บริการโดยสมบูรณ์ (IEEE มาตรฐาน 610.12)
ความจำเป็นในการกำหนดขั้นตอนของวงจรชีวิตซอฟต์แวร์ (LC) เกิดจากความต้องการของนักพัฒนาในการปรับปรุงคุณภาพซอฟต์แวร์ผ่านการจัดการการพัฒนาที่เหมาะสมที่สุดและการใช้กลไกการควบคุมคุณภาพต่างๆ ในแต่ละขั้นตอน ตั้งแต่คำจำกัดความของปัญหาไปจนถึงการสนับสนุนการเขียนซอฟต์แวร์ การแสดงวงจรชีวิตซอฟต์แวร์โดยทั่วไปมากที่สุดคือแบบจำลองในรูปแบบของขั้นตอนพื้นฐาน - กระบวนการซึ่งรวมถึง:
การวิเคราะห์ระบบและเหตุผลของข้อกำหนดซอฟต์แวร์
การออกแบบซอฟต์แวร์เบื้องต้น (ร่าง) และรายละเอียด (ทางเทคนิค)
การพัฒนาส่วนประกอบซอฟต์แวร์ การบูรณาการและการดีบักซอฟต์แวร์โดยรวม
การทดสอบ การทดลองใช้งาน และการจำลองซอฟต์แวร์
การทำงานปกติของซอฟต์แวร์ การสนับสนุนการดำเนินงานและการวิเคราะห์ผลลัพธ์
การบำรุงรักษาซอฟต์แวร์ การดัดแปลงและปรับปรุง การสร้างเวอร์ชันใหม่
โมเดลนี้เป็นที่ยอมรับโดยทั่วไปและสอดคล้องกับทั้งในประเทศ เอกสารกำกับดูแลในด้านการพัฒนาซอฟต์แวร์และต่างประเทศ จากมุมมองของการรับรองความปลอดภัยทางเทคโนโลยี ขอแนะนำให้พิจารณารายละเอียดเพิ่มเติมเกี่ยวกับคุณสมบัติของการแสดงขั้นตอนวงจรชีวิตในรุ่นต่างประเทศ เนื่องจากเป็นซอฟต์แวร์ต่างประเทศที่มีโอกาสเป็นพาหะของข้อบกพร่องของซอฟต์แวร์ประเภทก่อวินาศกรรมมากที่สุด
มาตรฐานวงจรชีวิตของซอฟต์แวร์
GOST 34.601-90
ISO/IEC 12207:1995 ( อะนาล็อกรัสเซีย- GOST R ISO/IEC 12207-99)
การแสดงกราฟิกของแบบจำลองวงจรชีวิตทำให้สามารถเน้นคุณลักษณะและคุณสมบัติบางอย่างของกระบวนการได้อย่างชัดเจน
ในขั้นแรก แบบจำลองวงจรชีวิตของน้ำตกได้ถูกสร้างขึ้น ซึ่งขั้นตอนหลักๆ จะเริ่มต้นทีละขั้นตอนโดยใช้ผลลัพธ์ ผลงานก่อนหน้า. จัดให้มีการดำเนินการตามลำดับของทุกขั้นตอนของโครงการในลำดับคงที่อย่างเคร่งครัด การเปลี่ยนไปสู่ขั้นต่อไปหมายถึงงานที่สมบูรณ์ในขั้นก่อนหน้า ข้อกำหนดที่กำหนดในขั้นตอนของการสร้างข้อกำหนดนั้นได้รับการบันทึกไว้อย่างเคร่งครัดในรูปแบบของข้อกำหนดทางเทคนิคและจะถูกบันทึกไว้สำหรับการพัฒนาทั้งหมดของโครงการ แต่ละขั้นตอนจะสิ้นสุดลงด้วยการปล่อยชุดเอกสารที่สมบูรณ์เพียงพอเพื่อให้ทีมพัฒนาอื่นสามารถดำเนินการพัฒนาต่อไปได้ ความไม่ถูกต้องของข้อกำหนดใดๆ หรือการตีความที่ไม่ถูกต้องส่งผลให้จำเป็นต้อง "ย้อนกลับ" ไปยังช่วงเริ่มต้นของโครงการ และการทำงานซ้ำที่จำเป็นไม่เพียงแต่ทำให้ทีมงานโครงการผิดกำหนดเวลาเท่านั้น แต่ยังมักจะนำไปสู่การเพิ่มคุณภาพใน ค่าใช้จ่ายและอาจถึงการยุติโครงการในรูปแบบที่ตั้งใจไว้แต่แรก ความเข้าใจผิดหลักของผู้เขียนโมเดล Waterfall คือสมมติฐานว่าโครงการต้องผ่านกระบวนการทั้งหมดเพียงครั้งเดียว สถาปัตยกรรมที่ออกแบบไว้นั้นดีและใช้งานง่าย การออกแบบการใช้งานมีความสมเหตุสมผล และข้อผิดพลาดในการนำไปใช้งานจะถูกกำจัดได้อย่างง่ายดายผ่านการทดสอบ แบบจำลองนี้สันนิษฐานว่าข้อผิดพลาดทั้งหมดจะกระจุกตัวอยู่ในการใช้งาน ดังนั้นการกำจัดข้อผิดพลาดจะเกิดขึ้นอย่างเท่าเทียมกันในระหว่างการทดสอบส่วนประกอบและระบบ ดังนั้นโมเดลน้ำตกจึงไม่สมจริงมากนักสำหรับโปรเจ็กต์ขนาดใหญ่ และสามารถใช้ได้อย่างมีประสิทธิภาพเพื่อสร้างระบบขนาดเล็กเท่านั้น
เฉพาะเจาะจงที่สุดคือแบบจำลองวงจรชีวิตแบบเกลียว โมเดลนี้เน้นที่กระบวนการวนซ้ำ ระยะเริ่มแรกออกแบบ. ในขั้นตอนเหล่านี้ แนวคิด ข้อกำหนดเฉพาะ การออกแบบเบื้องต้นและรายละเอียดจะถูกสร้างขึ้นตามลำดับ ในแต่ละรอบ เนื้อหาของงานจะได้รับการชี้แจงและลักษณะที่ปรากฏของซอฟต์แวร์ที่กำลังสร้างจะเข้มข้นขึ้น ประเมินคุณภาพของผลลัพธ์ที่ได้รับ และมีการวางแผนงานในการทำซ้ำครั้งถัดไป ในการวนซ้ำแต่ละครั้ง จะมีการประเมินสิ่งต่อไปนี้:
ความเสี่ยงในการเกินกำหนดเวลาและต้นทุนของโครงการ
ความจำเป็นในการทำซ้ำอีกครั้ง
ระดับความสมบูรณ์และความถูกต้องของการทำความเข้าใจข้อกำหนดของระบบ
ความเป็นไปได้ในการยุติโครงการ
การกำหนดมาตรฐานวงจรชีวิตซอฟต์แวร์ดำเนินการในสามทิศทาง ทิศทางแรกถูกจัดระเบียบและกระตุ้น องค์กรระหว่างประเทศสำหรับการมาตรฐาน (ISO - International Standard Organization) และ International Electro-technical Commission (IEC - International Electro-technical Commission) ในระดับนี้ การดำเนินการมาตรฐานของกระบวนการทางเทคโนโลยีทั่วไปส่วนใหญ่ที่มีความสำคัญสำหรับความร่วมมือระหว่างประเทศ ทิศทางที่สองกำลังได้รับการพัฒนาอย่างแข็งขันในสหรัฐอเมริกาโดยสถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์ (IEEE) ร่วมกับสถาบันมาตรฐานแห่งชาติอเมริกัน (ANSI) มาตรฐาน ISO/IEC และ ANSI/IEEE มีลักษณะเป็นคำแนะนำเป็นหลัก ทิศทางที่ 3 กระตุ้นโดยกระทรวงกลาโหมสหรัฐฯ (DOD) มาตรฐาน DOD มีผลบังคับใช้สำหรับบริษัทที่ทำงานให้กับกระทรวงกลาโหมสหรัฐอเมริกา
สำหรับการออกแบบซอฟต์แวร์ ระบบที่ซับซ้อนโดยเฉพาะระบบเรียลไทม์ ขอแนะนำให้ใช้แบบจำลองวงจรชีวิตทั้งระบบโดยพิจารณาจากการรวมทั้งหมด ผลงานที่มีชื่อเสียงภายในกรอบของกระบวนการพื้นฐานที่พิจารณาแล้ว โมเดลนี้มีไว้สำหรับใช้ในการวางแผน กำหนดเวลา และจัดการโครงการซอฟต์แวร์ต่างๆ
ขอแนะนำให้แบ่งชุดขั้นตอนของแบบจำลองวงจรชีวิตนี้ออกเป็นสองส่วน ซึ่งแตกต่างกันอย่างมีนัยสำคัญในลักษณะของกระบวนการ ลักษณะทางเทคนิคและเศรษฐกิจ และปัจจัยที่มีอิทธิพลต่อสิ่งเหล่านี้
ในส่วนแรกของวงจรชีวิต จะดำเนินการวิเคราะห์ระบบ ออกแบบ พัฒนา ทดสอบ และทดสอบซอฟต์แวร์ ช่วงของงาน ความซับซ้อน ระยะเวลา และคุณลักษณะอื่นๆ ในขั้นตอนเหล่านี้ขึ้นอยู่กับวัตถุและสภาพแวดล้อมการพัฒนาอย่างมาก การศึกษาการพึ่งพาดังกล่าวสำหรับซอฟต์แวร์ประเภทต่างๆ ช่วยให้สามารถคาดการณ์องค์ประกอบและลักษณะสำคัญของตารางงานสำหรับซอฟต์แวร์เวอร์ชันใหม่ได้
ส่วนที่สองของวงจรชีวิต ซึ่งสะท้อนถึงการสนับสนุนการดำเนินงานและการบำรุงรักษาซอฟต์แวร์ มีความสัมพันธ์ค่อนข้างน้อยกับลักษณะของออบเจ็กต์และสภาพแวดล้อมการพัฒนา ช่วงของงานในขั้นตอนเหล่านี้มีเสถียรภาพมากขึ้น แต่ความเข้มข้นของแรงงานและระยะเวลาอาจแตกต่างกันอย่างมากและขึ้นอยู่กับการใช้งานซอฟต์แวร์อย่างแพร่หลาย สำหรับโมเดลวงจรชีวิตใดๆ การรับรองว่าระบบซอฟต์แวร์คุณภาพสูงจะเป็นไปได้ก็ต่อเมื่อใช้กระบวนการทางเทคโนโลยีที่ได้รับการควบคุมในแต่ละขั้นตอนเหล่านี้ กระบวนการนี้ได้รับการสนับสนุนโดยเครื่องมือการพัฒนาอัตโนมัติซึ่งแนะนำให้เลือกจากเครื่องมือที่มีอยู่หรือสร้างขึ้นโดยคำนึงถึงวัตถุการพัฒนาและรายการงานที่เพียงพอ
การพัฒนาซอฟต์แวร์เป็นไปไม่ได้หากไม่เข้าใจวงจรชีวิตซอฟต์แวร์ที่เรียกว่า ผู้ใช้โดยเฉลี่ยอาจไม่จำเป็นต้องรู้สิ่งนี้ แต่แนะนำให้เชี่ยวชาญมาตรฐานพื้นฐาน (ภายหลังจะมีการบอกว่าเหตุใดจึงจำเป็น)
วงจรชีวิตในความหมายที่เป็นทางการคืออะไร?
วงจรชีวิตของสิ่งใดๆ มักจะเข้าใจว่าเป็นเวลาของการดำรงอยู่ของมัน ตั้งแต่ขั้นตอนการพัฒนาจนถึงขณะนี้ การปฏิเสธโดยสมบูรณ์จากการใช้งานในสาขาแอปพลิเคชันที่เลือกจนถึงการลบแอปพลิเคชันออกจากการใช้งานโดยสมบูรณ์
การพูด ในภาษาง่ายๆระบบข้อมูลในรูปแบบของโปรแกรม ฐานข้อมูล หรือแม้แต่ “ระบบปฏิบัติการ” นั้นเป็นที่ต้องการก็ต่อเมื่อข้อมูลและโอกาสที่พวกเขาให้นั้นเป็นข้อมูลที่ทันสมัยเท่านั้น
เชื่อกันว่าคำจำกัดความวงจรชีวิตใช้ไม่ได้กับการทดสอบแอปพลิเคชันใดๆ ทั้งสิ้น เช่น เวอร์ชันเบต้าซึ่งมีการทำงานที่ไม่เสถียรที่สุด วงจรชีวิตของซอฟต์แวร์นั้นขึ้นอยู่กับหลายปัจจัย โดยสภาพแวดล้อมที่จะใช้โปรแกรมจะมีบทบาทหลักประการหนึ่ง อย่างไรก็ตาม สามารถระบุเงื่อนไขทั่วไปที่ใช้ในการกำหนดแนวคิดเกี่ยวกับวงจรชีวิตได้
ข้อกำหนดเบื้องต้น
- การกำหนดปัญหา
- การวิเคราะห์ความต้องการร่วมกันของซอฟต์แวร์ในอนาคตสำหรับระบบ
- ออกแบบ;
- การเขียนโปรแกรม;
- การเขียนโค้ดและการคอมไพล์
- การทดสอบ;
- การดีบัก;
- การใช้งานและการบำรุงรักษาผลิตภัณฑ์ซอฟต์แวร์
การพัฒนาซอฟต์แวร์ประกอบด้วยขั้นตอนที่กล่าวมาข้างต้นทั้งหมด และไม่สามารถทำได้หากไม่มีขั้นตอนเหล่านี้อย่างน้อยหนึ่งขั้นตอน แต่มีการกำหนดมาตรฐานพิเศษเพื่อควบคุมกระบวนการดังกล่าว
มาตรฐานกระบวนการวงจรชีวิตของซอฟต์แวร์
ในบรรดาระบบที่กำหนดเงื่อนไขและข้อกำหนดล่วงหน้าสำหรับกระบวนการดังกล่าว ในปัจจุบันเราสามารถตั้งชื่อได้เพียงสามระบบหลักเท่านั้น:
- GOST 34.601-90;
- ISO/IEC 12207:2008;
- ออราเคิล ซีดีเอ็ม.
สำหรับมาตรฐานสากลที่สองนั้นมีอะนาล็อกของรัสเซีย นี่คือ GOST R ISO/IEC 12207-2010 ซึ่งรับผิดชอบด้านวิศวกรรมระบบและซอฟต์แวร์ แต่วงจรชีวิตของซอฟต์แวร์ที่อธิบายไว้ในกฎทั้งสองนั้นเหมือนกันโดยพื้นฐานแล้ว นี่เป็นคำอธิบายที่ค่อนข้างง่าย
ประเภทของซอฟต์แวร์และการอัพเดต
อย่างไรก็ตามสำหรับโปรแกรมมัลติมีเดียที่รู้จักในปัจจุบันส่วนใหญ่เป็นวิธีการบันทึกพารามิเตอร์การกำหนดค่าพื้นฐาน แน่นอนว่าการใช้ซอฟต์แวร์ประเภทนี้ค่อนข้างจำกัด แต่การทำความเข้าใจหลักการทั่วไปในการทำงานกับเครื่องเล่นสื่อเดียวกันจะไม่ส่งผลเสียหาย และนั่นคือเหตุผล
ในความเป็นจริงวงจรชีวิตซอฟต์แวร์จะรวมเฉพาะในระดับการอัปเดตเวอร์ชันของเครื่องเล่นหรือการติดตั้งตัวแปลงสัญญาณและตัวถอดรหัสเท่านั้น และตัวแปลงรหัสเสียงและวิดีโอเป็นคุณลักษณะที่สำคัญของระบบเสียงหรือวิดีโอ
ตัวอย่างจาก FL Studio
เริ่มแรก FL Studio เสมือนสตูดิโอซีเควนเซอร์ถูกเรียกว่า Fruity Loops วงจรชีวิตของซอฟต์แวร์ในการปรับเปลี่ยนครั้งแรกหมดอายุแล้ว แต่แอปพลิเคชันได้รับการเปลี่ยนแปลงบ้างและได้รับรูปแบบปัจจุบัน
หากเราพูดถึงขั้นตอนของวงจรชีวิต ประการแรก ในขั้นตอนของการตั้งค่าปัญหา มีการกำหนดเงื่อนไขบังคับหลายประการ:
- การสร้างโมดูลกลองที่คล้ายกับริทึมแมชชีนเช่น Yamaha RX แต่ใช้ตัวอย่างช็อตเดียวหรือซีเควนซ์ในรูปแบบ WAV ที่บันทึกสดในสตูดิโอ
- บูรณาการเข้ากับระบบปฏิบัติการ Windows
- ความสามารถในการส่งออกโครงการในรูปแบบ WAV, MP3 และ OGG
- ความเข้ากันได้ของโครงการกับแอพพลิเคชั่น Fruity Tracks เพิ่มเติม
ในขั้นตอนการพัฒนา ใช้เครื่องมือภาษาซี แต่แพลตฟอร์มนี้ดูค่อนข้างดั้งเดิมและไม่ได้มอบให้กับผู้ใช้ปลายทาง คุณภาพที่ต้องการเสียง.
ในเรื่องนี้ในขั้นตอนการทดสอบและการดีบัก นักพัฒนาจะต้องปฏิบัติตามแนวทางของบริษัท German Steinberg และใช้การสนับสนุนโหมด Full Duplex ในข้อกำหนดสำหรับไดรเวอร์เสียงหลัก คุณภาพเสียงสูงขึ้น และช่วยให้คุณเปลี่ยนจังหวะ ระดับเสียง และใช้เอฟเฟกต์ FX เพิ่มเติมได้แบบเรียลไทม์
การสิ้นสุดวงจรชีวิตของซอฟต์แวร์นี้ถือเป็นการเปิดตัว FL Studio เวอร์ชันแรกอย่างเป็นทางการซึ่งแตกต่างจากบรรพบุรุษที่มีอินเทอร์เฟซของซีเควนเซอร์เต็มรูปแบบอยู่แล้วพร้อมความสามารถในการแก้ไขพารามิเตอร์บน 64 เสมือน - คอนโซลมิกซ์ช่องสัญญาณพร้อมการเพิ่มแทร็กเสียงและแทร็ก MIDI อย่างไม่จำกัด
มันไม่ได้หยุดเพียงแค่นั้น ในขั้นตอนการจัดการโครงการ มีการแนะนำการสนับสนุนสำหรับการเชื่อมต่อปลั๊กอินของรูปแบบ VST (เวอร์ชันแรก เวอร์ชันที่สอง และเวอร์ชันที่สาม) ซึ่งครั้งหนึ่งเคยพัฒนาโดย Steinberg พูดโดยคร่าวๆ ซินธิไซเซอร์เสมือนที่รองรับ VST-host สามารถเชื่อมต่อกับโปรแกรมได้
ไม่น่าแปลกใจที่ในไม่ช้าผู้แต่งคนใดก็สามารถใช้อะนาล็อกของโมเดล "ฮาร์ดแวร์" ได้เช่นชุดเสียงที่สมบูรณ์ของ Korg M1 ที่ครั้งหนึ่งเคยโด่งดัง นอกจากนี้. การใช้โมดูล เช่น Addictive Drums หรือปลั๊กอิน Kontakt สากล ทำให้สามารถสร้างเสียงสดของเครื่องดนตรีจริงที่บันทึกด้วยเฉดสีทุกเฉดในสตูดิโอมืออาชีพ
ในเวลาเดียวกันนักพัฒนาพยายามที่จะบรรลุคุณภาพสูงสุดด้วยการสร้างการรองรับไดรเวอร์ ASIO4ALL ซึ่งกลายเป็นเรื่องเหนือศีรษะในโหมด Full Duplex ดังนั้นบิตเรตก็เพิ่มขึ้นเช่นกัน ปัจจุบัน คุณภาพของไฟล์เสียงที่ส่งออกสามารถอยู่ที่ 320 kbps ที่อัตราการสุ่มตัวอย่าง 192 kHz และนี่คือเสียงระดับมืออาชีพ
สำหรับเวอร์ชันเริ่มต้นนั้น วงจรชีวิตของมันสามารถเรียกได้ว่าสมบูรณ์อย่างสมบูรณ์ แต่คำสั่งดังกล่าวมีความเกี่ยวข้องเนื่องจากแอปพลิเคชันเปลี่ยนชื่อและได้รับความสามารถใหม่เท่านั้น
แนวโน้มการพัฒนา
ขั้นตอนของวงจรชีวิตซอฟต์แวร์มีความชัดเจนอยู่แล้ว แต่การพัฒนาเทคโนโลยีดังกล่าวก็คุ้มค่าที่จะกล่าวถึงแยกกัน
ไม่จำเป็นต้องพูดว่านักพัฒนาซอฟต์แวร์คนใดไม่สนใจที่จะสร้างผลิตภัณฑ์ที่เกิดขึ้นเพียงชั่วคราวซึ่งไม่น่าจะอยู่รอดในตลาดได้เป็นเวลาหลายปี ในระยะยาว ใครๆ ต่างก็มองถึงการใช้งานในระยะยาว สิ่งนี้สามารถบรรลุได้ วิธีทางที่แตกต่าง. แต่ตามกฎแล้วเกือบทั้งหมดมาถึงการเปิดตัวการอัปเดตหรือโปรแกรมเวอร์ชันใหม่
แม้แต่ในกรณีของระบบปฏิบัติการ Windows ก็ยังสามารถมองเห็นแนวโน้มดังกล่าวได้ด้วยตาเปล่า ไม่น่าเป็นไปได้ที่ในปัจจุบันจะมีผู้ใช้อย่างน้อยหนึ่งรายที่ใช้ระบบเช่นการแก้ไข 3.1, 95, 98 หรือ Millennium วงจรชีวิตของพวกเขาสิ้นสุดลงหลังจากการเปิดตัว XP แต่เวอร์ชันเซิร์ฟเวอร์ที่ใช้เทคโนโลยี NT ยังคงมีความเกี่ยวข้อง แม้แต่ Windows 2000 ในปัจจุบันก็ไม่เพียงแต่มีความเกี่ยวข้องเท่านั้น แต่ในการติดตั้งหรือพารามิเตอร์ความปลอดภัยบางตัวยังเหนือกว่าการพัฒนาล่าสุดด้วยซ้ำ เช่นเดียวกับระบบ NT 4.0 เช่นเดียวกับการดัดแปลงพิเศษของ Windows Server 2012
แต่ในส่วนที่เกี่ยวข้องกับระบบเหล่านี้ การสนับสนุนยังคงได้รับการประกาศในความเป็นจริง ระดับสูง. แต่ Vista ที่น่าตื่นเต้นครั้งหนึ่งกำลังประสบกับความเสื่อมถอยของวัฏจักรของมันอย่างชัดเจน ไม่เพียงแต่ปรากฏว่าสร้างไม่เสร็จเท่านั้น แต่ยังมีข้อผิดพลาดมากมายและช่องว่างในระบบรักษาความปลอดภัยที่ใครๆ ก็เดาได้เพียงอย่างเดียวว่าโซลูชันที่ป้องกันไม่ได้ดังกล่าวจะออกสู่ตลาดซอฟต์แวร์ได้อย่างไร
แต่ถ้าเราบอกว่าการพัฒนาซอฟต์แวร์ประเภทใดก็ตาม (การควบคุมหรือแอปพลิเคชัน) ไม่ได้หยุดนิ่ง เราสามารถพูดได้เพียงว่าในปัจจุบันนี้ไม่เพียงเกี่ยวข้องกับระบบคอมพิวเตอร์เท่านั้น แต่ยังรวมถึง อุปกรณ์เคลื่อนที่ซึ่งเทคโนโลยีที่ใช้มักจะนำหน้าภาคคอมพิวเตอร์ การเกิดขึ้นของชิปโปรเซสเซอร์ที่ใช้แปดคอร์นั้นไม่ใช่สิ่งที่ดีที่สุด ตัวอย่างที่ดีที่สุด? แต่ไม่ใช่ว่าแล็ปท็อปทุกเครื่องจะมีฮาร์ดแวร์ดังกล่าวได้
คำถามเพิ่มเติมบางประการ
สำหรับการทำความเข้าใจวงจรชีวิตของซอฟต์แวร์นั้น ค่อนข้างจะไร้เหตุผลที่จะบอกว่าซอฟต์แวร์สิ้นสุดลง ณ จุดหนึ่ง เนื่องจากผลิตภัณฑ์ซอฟต์แวร์ยังคงได้รับการสนับสนุนจากนักพัฒนาที่สร้างซอฟต์แวร์เหล่านั้น แต่การสิ้นสุดหมายถึงแอปพลิเคชันรุ่นเก่าที่ไม่ตรงตามข้อกำหนด ระบบที่ทันสมัยและไม่สามารถทำงานในสภาพแวดล้อมของตนได้
แต่แม้จะคำนึงถึงความก้าวหน้าทางเทคโนโลยีแล้ว หลายคนก็อาจจะไม่สามารถป้องกันได้ในไม่ช้า จากนั้นคุณจะต้องตัดสินใจว่าจะปล่อยการอัปเดตหรือแก้ไขแนวคิดทั้งหมดที่วางไว้ในตอนแรกทั้งหมด ซอฟต์แวร์. ดังนั้นวงจรใหม่ซึ่งเกี่ยวข้องกับการเปลี่ยนแปลงเงื่อนไขเริ่มต้น สภาพแวดล้อมการพัฒนา การทดสอบ และการใช้งานระยะยาวที่เป็นไปได้ในบางพื้นที่
แต่ในเทคโนโลยีคอมพิวเตอร์ในปัจจุบันการตั้งค่าให้กับการพัฒนาระบบควบคุมอัตโนมัติ (ACS) ซึ่งใช้ในการผลิต แม้แต่ระบบปฏิบัติการเมื่อเปรียบเทียบกับโปรแกรมพิเศษก็ยังแพ้
สภาพแวดล้อมที่ใช้ Visual Basic ยังคงได้รับความนิยมมากกว่าระบบ Windows และเราไม่ได้พูดถึงแอพพลิเคชั่นซอฟต์แวร์สำหรับระบบ UNIX เลย เราจะพูดอะไรได้บ้างหากเครือข่ายการสื่อสารเกือบทั้งหมดในสหรัฐอเมริกาเดียวกันทำงานเพื่อพวกเขาโดยเฉพาะ อย่างไรก็ตาม ระบบอย่าง Linux และ Android ก็ถูกสร้างขึ้นบนแพลตฟอร์มนี้เช่นกัน ดังนั้น UNIX จึงมีแนวโน้มมากกว่าผลิตภัณฑ์อื่นๆ รวมกันมาก
แทนที่จะเป็นยอดรวม
ยังคงต้องเสริมในกรณีนี้เท่านั้น หลักการทั่วไปและขั้นตอนของวงจรชีวิตซอฟต์แวร์ ในความเป็นจริง แม้แต่งานที่ตั้งค่าไว้ในตอนแรกก็อาจแตกต่างกันอย่างมาก ดังนั้นจึงสามารถสังเกตความแตกต่างได้ในระยะอื่น
แต่เทคโนโลยีพื้นฐานสำหรับการพัฒนาผลิตภัณฑ์ซอฟต์แวร์และการสนับสนุนที่ตามมาควรมีความชัดเจน ส่วนที่เหลือควรคำนึงถึงลักษณะเฉพาะของซอฟต์แวร์ที่ถูกสร้างขึ้น สภาพแวดล้อมที่ควรใช้งาน และความสามารถของโปรแกรมที่มอบให้กับผู้ใช้ปลายทางหรือการใช้งานจริง และอื่นๆ อีกมากมาย
นอกจากนี้ บางครั้งวงจรชีวิตอาจขึ้นอยู่กับความเกี่ยวข้องของเครื่องมือในการพัฒนา ตัวอย่างเช่น หากภาษาการเขียนโปรแกรมล้าสมัย จะไม่มีใครเขียนโปรแกรมตามภาษานั้น แม้แต่การนำภาษาเหล่านั้นไปใช้กับระบบควบคุมการผลิตแบบอัตโนมัติก็น้อยลงเช่นกัน นี่ไม่ใช่แม้แต่โปรแกรมเมอร์ที่มาก่อน แต่นักการตลาดที่ต้องตอบสนองต่อการเปลี่ยนแปลงในตลาดคอมพิวเตอร์อย่างทันท่วงที และมีผู้เชี่ยวชาญประเภทนี้ไม่มากนักในโลก บุคลากรที่มีคุณสมบัติสูงซึ่งสามารถติดตามชีพจรของตลาดได้กำลังกลายเป็นที่ต้องการมากที่สุด และมักถูกเรียกว่า “ พระคาร์ดินัลสีเทา” ซึ่งความสำเร็จหรือความล้มเหลวของผลิตภัณฑ์ซอฟต์แวร์บางอย่างในสาขาไอทีขึ้นอยู่กับ
พวกเขาอาจไม่เข้าใจสาระสำคัญของการเขียนโปรแกรมเสมอไป แต่พวกเขาสามารถกำหนดแบบจำลองของวงจรชีวิตซอฟต์แวร์และระยะเวลาในการใช้งานได้อย่างชัดเจน โดยพิจารณาจากแนวโน้มทั่วโลกในด้านนี้ การจัดการที่มีประสิทธิผลมักจะให้ผลลัพธ์ที่เป็นรูปธรรมมากกว่า ใช่ อย่างน้อยเทคโนโลยีประชาสัมพันธ์ การโฆษณา ฯลฯ ผู้ใช้อาจไม่ต้องการแอปพลิเคชันบางอย่าง แต่ถ้ามีการโฆษณาอย่างจริงจัง ผู้ใช้จะติดตั้งแอปพลิเคชันนั้น พูดได้เลยว่านี่เป็นระดับจิตใต้สำนึกแล้ว (เอฟเฟกต์แบบเดียวกันของเฟรมที่ 25 เมื่อข้อมูลถูกใส่เข้าไปในจิตสำนึกของผู้ใช้โดยเป็นอิสระจากเขา)
แน่นอนว่าเทคโนโลยีดังกล่าวเป็นสิ่งต้องห้ามในโลก แต่พวกเราหลายคนไม่รู้ด้วยซ้ำว่าเทคโนโลยีเหล่านี้ยังคงสามารถนำมาใช้และมีอิทธิพลต่อจิตใต้สำนึกได้ ในทางใดทางหนึ่ง. เพียงแค่ดูต้นทุนของ "การซอมบี้" โดยช่องข่าวหรือเว็บไซต์อินเทอร์เน็ต ไม่ต้องพูดถึงการใช้วิธีที่มีประสิทธิภาพมากกว่า เช่น การเปิดรับแสงอินฟราเรด (ใช้ในการผลิตโอเปร่ารายการเดียว) ซึ่งส่งผลให้บุคคลอาจประสบ ความกลัวหรืออารมณ์ที่ไม่เหมาะสม
เมื่อกลับมาที่ซอฟต์แวร์ ควรเพิ่มว่าบางโปรแกรมใช้สัญญาณเสียงเมื่อเริ่มต้นระบบเพื่อดึงดูดความสนใจของผู้ใช้ และจากการวิจัยพบว่าแอปพลิเคชันดังกล่าวมีศักยภาพมากกว่าโปรแกรมอื่นๆ โดยปกติแล้ว วงจรชีวิตของซอฟต์แวร์จะเพิ่มขึ้นเช่นกัน ไม่ว่าจะถูกกำหนดฟังก์ชันอะไรในตอนแรกก็ตาม และน่าเสียดายที่นักพัฒนาจำนวนมากใช้สิ่งนี้ ซึ่งทำให้เกิดข้อสงสัยเกี่ยวกับความถูกต้องตามกฎหมายของวิธีการดังกล่าว
แต่ไม่ใช่สำหรับเราที่จะตัดสินเรื่องนี้ เป็นไปได้ว่าเครื่องมือจะได้รับการพัฒนาในอนาคตอันใกล้นี้เพื่อระบุภัยคุกคามดังกล่าว จนถึงตอนนี้นี่เป็นเพียงทฤษฎี แต่ตามที่นักวิเคราะห์และผู้เชี่ยวชาญบางคนระบุว่า ยังเหลือน้อยมากก่อนที่จะนำไปใช้จริง หากพวกเขากำลังสร้างสำเนาของโครงข่ายประสาทเทียมของสมองมนุษย์อยู่แล้ว แล้วเราจะพูดอะไรได้บ้าง?
วงจรชีวิตของซอฟต์แวร์ประกอบด้วยหกขั้นตอน:
- การวิเคราะห์ความต้องการ
– การกำหนดข้อกำหนดเฉพาะ
- ออกแบบ;
– การเข้ารหัส;
– การทดสอบ;
– คลอ
การวิเคราะห์ความต้องการ. เป็นสิ่งสำคัญอย่างยิ่งในการพัฒนาซอฟต์แวร์ ข้อผิดพลาดที่เกิดขึ้นในขั้นตอนนี้แม้ว่าขั้นตอนต่อ ๆ ไปจะดำเนินการอย่างไม่มีที่ติ แต่ก็สามารถนำไปสู่ความจริงที่ว่าผลิตภัณฑ์ซอฟต์แวร์ที่พัฒนาแล้วจะไม่เป็นไปตามข้อกำหนดของการปฏิบัติและขอบเขตของแอปพลิเคชัน ในการสร้างผลิตภัณฑ์ที่สามารถแข่งขันได้ ขั้นตอนนี้จะต้องให้คำตอบที่ชัดเจน คำถามถัดไป:
– โปรแกรมควรทำอย่างไร?
– ปัญหาที่แท้จริงที่ควรช่วยแก้ไขคืออะไร?
– ข้อมูลอินพุตคืออะไร?
– ข้อมูลขาออกควรเป็นอย่างไร?
– ผู้ออกแบบมีทรัพยากรอะไรบ้าง?
การกำหนดข้อกำหนด. ข้อมูลจำเพาะ– คำอธิบายอย่างเป็นทางการที่ถูกต้องและครบถ้วนเกี่ยวกับคุณสมบัติ คุณลักษณะ และฟังก์ชันของโปรแกรม องค์ประกอบข้อมูล หรือวัตถุอื่น ๆ ในระดับหนึ่งขั้นตอนนี้ถือได้ว่าเป็นการกำหนดข้อสรุปต่อจากผลลัพธ์ของขั้นตอนที่แล้ว ข้อกำหนดของโปรแกรมจะต้องแสดงเป็นชุดข้อกำหนดที่กำหนดลักษณะการทำงานของโปรแกรมในอนาคตอย่างชัดเจน ลักษณะดังกล่าวอาจรวมถึงความเร็วในการดำเนินการ จำนวนหน่วยความจำที่ใช้ ความยืดหยุ่นในการใช้งาน เป็นต้น
ออกแบบ. ในขั้นตอนนี้ โครงสร้างโดยรวมของโปรแกรมจะถูกสร้างขึ้นซึ่งจะต้องเป็นไปตามข้อกำหนด มีการกำหนดหลักการทั่วไปของการจัดการและการโต้ตอบระหว่างองค์ประกอบต่างๆ ของโปรแกรม
การเข้ารหัส. ประกอบด้วยการแปลโครงสร้างที่เขียนด้วยภาษาการออกแบบให้เป็นภาษาโปรแกรม
การทดสอบ. ในขั้นตอนนี้ จะมีการตรวจสอบโปรแกรมอย่างครอบคลุม
คุ้มกันนี่คือขั้นตอนการทำงานของระบบ ไม่ว่าการทดสอบโปรแกรมจะซับซ้อนเพียงใด แต่น่าเสียดายที่ในระบบซอฟต์แวร์ขนาดใหญ่ การกำจัดข้อผิดพลาดทั้งหมดเป็นเรื่องยากอย่างยิ่ง การกำจัดข้อผิดพลาดที่พบระหว่างการดำเนินการเป็นงานหลักของขั้นตอนนี้ อย่างไรก็ตาม นี่ไม่ใช่ทั้งหมดที่จะทำสำเร็จในระหว่างการสนับสนุน การวิเคราะห์ประสบการณ์การทำงานของโปรแกรมที่ดำเนินการระหว่างการบำรุงรักษาช่วยให้เราตรวจพบปัญหาคอขวดหรือโซลูชันการออกแบบที่ไม่ประสบความสำเร็จในบางส่วน แพคเกจซอฟต์แวร์. จากการวิเคราะห์ดังกล่าว จึงสามารถตัดสินใจดำเนินการปรับปรุงระบบที่พัฒนาแล้วได้ การสนับสนุนยังอาจรวมถึงการให้คำปรึกษา การฝึกอบรมผู้ใช้ระบบ การจัดเตรียมข้อมูลเกี่ยวกับระบบเวอร์ชันใหม่แก่ผู้ใช้โดยทันที คุณภาพของขั้นตอนการบำรุงรักษาจะเป็นตัวกำหนดความสำเร็จทางการค้าของผลิตภัณฑ์ซอฟต์แวร์เป็นส่วนใหญ่
การทดสอบ. การตรวจสอบโปรแกรมมีสามด้าน:
– ความถูกต้อง;
– ประสิทธิภาพการดำเนินงาน
– ความซับซ้อนในการคำนวณ
การตรวจสอบความถูกต้องทำให้มั่นใจได้ว่าโปรแกรมจะทำสิ่งที่ได้รับการออกแบบมาให้ทำอย่างแน่นอน ความสมบูรณ์แบบทางคณิตศาสตร์ของอัลกอริทึมไม่ได้รับประกันความถูกต้องของการแปลเป็นโปรแกรม ในทำนองเดียวกัน การไม่มีข้อความวินิจฉัยของคอมไพลเลอร์หรือรูปลักษณ์ที่สมเหตุสมผลของผลลัพธ์ที่ได้รับนั้นไม่ได้ให้การรับประกันความถูกต้องของโปรแกรมอย่างเพียงพอ โดยทั่วไป การตรวจสอบเกี่ยวข้องกับการพัฒนาและดำเนินการชุดการทดสอบ นอกจากนี้ ในการคำนวณโปรแกรม บางครั้งอาจเป็นไปได้ที่จะเปรียบเทียบผลลัพธ์ที่ได้กับโซลูชันที่ทราบอยู่แล้ว โดยทั่วไปคุณไม่สามารถให้ได้ วิธีแก้ปัญหาทั่วไปเพื่อตรวจสอบความถูกต้องของโปรแกรม
ตามกฎแล้วการทดสอบความซับซ้อนในการคำนวณประกอบด้วยการวิเคราะห์เชิงทดลองเกี่ยวกับความซับซ้อนของอัลกอริทึมหรือการเปรียบเทียบเชิงทดลองของอัลกอริทึมตั้งแต่สองตัวขึ้นไปที่แก้ปัญหาเดียวกัน
การทดสอบประสิทธิผลของการใช้งานมีวัตถุประสงค์เพื่อค้นหาวิธีทำให้โปรแกรมที่เหมาะสมทำงานเร็วขึ้นหรือใช้หน่วยความจำน้อยลง เพื่อปรับปรุงโปรแกรม ผลการดำเนินงานจะได้รับการตรวจสอบในระหว่างกระบวนการสร้างอัลกอริทึม โดยไม่พิจารณาทุกอย่าง ตัวเลือกที่เป็นไปได้และขอบเขตของการเพิ่มประสิทธิภาพโปรแกรม เราขอนำเสนอวิธีการที่เป็นประโยชน์ซึ่งมุ่งเป้าไปที่การเพิ่มความเร็วของการทำงานของโปรแกรม
วิธีแรกจะขึ้นอยู่กับกฎต่อไปนี้ การบวกและการลบเร็วกว่าการคูณและการหาร เลขคณิตจำนวนเต็มเร็วกว่าเลขคณิตจริง ดังนั้น X+X ดีกว่า 2*X โดยที่ * คือเครื่องหมายคูณ เมื่อดำเนินการกับจำนวนเต็ม โปรดจำไว้ว่าด้วยการใช้ระบบเลขฐานสอง การคูณด้วยทวีคูณของสองสามารถถูกแทนที่ด้วยจำนวนกะทางด้านซ้ายที่สอดคล้องกัน
วิธีที่สองคือการลบการคำนวณที่ซ้ำซ้อนออก
วิธีที่สามในการทดสอบประสิทธิภาพของการใช้งานนั้นขึ้นอยู่กับความสามารถของคอมไพเลอร์บางตัวในการสร้างโค้ดสำหรับประเมินนิพจน์บูลีน เพื่อให้การประเมินหยุดลงเมื่อผลลัพธ์ปรากฏชัดเจน ตัวอย่างเช่น ในนิพจน์ A หรือ B หรือ C ถ้า A เป็นจริง ตัวแปร B และ C จะไม่ถูกตรวจสอบอีกต่อไป ดังนั้น คุณสามารถประหยัดเวลาได้ด้วยการวางตัวแปร A, B, C เพื่อให้ตัวแปรแรกเป็นตัวแปรที่มีแนวโน้มว่าจะเป็นจริงมากที่สุด และตัวแปรสุดท้ายคือตัวแปรที่มีโอกาสเป็นจริงน้อยที่สุด
เทคนิคที่สี่คือการกำจัดวงจร
เทคนิคที่ห้าคือการปรับใช้วงจร
นี่อยู่ไกลจาก รายการทั้งหมดวิธีการเพิ่มประสิทธิภาพ ที่นี่ให้เฉพาะสิ่งที่ชัดเจนที่สุดเท่านั้น ควรสังเกตด้วยว่าการแสวงหาความเร็วนั้นไม่คุ้มค่าเสมอไปเนื่องจากสิ่งนี้มักจะทำให้ความสามารถในการอ่านของโปรแกรมแย่ลง ในกรณีที่กำไรเป็น "เล็กน้อย" แทบจะไม่คุ้มที่จะเลือกใช้ความชัดเจนและความสามารถในการอ่านของโปรแกรม
วงจรชีวิตของโปรแกรม
วงจรชีวิตซอฟต์แวร์คือช่วงเวลาที่เริ่มต้นจากช่วงเวลาที่ตัดสินใจเกี่ยวกับความจำเป็นในการสร้างผลิตภัณฑ์ซอฟต์แวร์และสิ้นสุดเมื่อถูกลบออกจากบริการโดยสิ้นเชิง วงจรนี้เป็นกระบวนการสร้างและพัฒนาซอฟต์แวร์
ระยะของวงจรชีวิต:
2. การออกแบบ
3. การนำไปปฏิบัติ
4. การประกอบ การทดสอบ การทดสอบ
5. การนำไปปฏิบัติ (ปล่อย)
6. เพื่อนเที่ยว
การผลิตซอฟต์แวร์มี 2 กรณี คือ 1) ซอฟต์แวร์จัดทำขึ้นเพื่อลูกค้าเฉพาะราย ในกรณีนี้คุณต้องการ ปัญหาที่ใช้กลายเป็นโปรแกรมเมอร์ คุณต้องเข้าใจว่าสภาพแวดล้อมที่ต้องทำงานอัตโนมัติอย่างไร (การวิเคราะห์กระบวนการทางธุรกิจ) เป็นผลให้ข้อกำหนดเอกสารประกอบของข้อกำหนดปรากฏขึ้น ซึ่งระบุว่างานเฉพาะใดที่ควรดำเนินการ ได้รับการแก้ไขแล้วภายใต้เงื่อนไขใด งานนี้ดำเนินการโดยนักวิเคราะห์ระบบ (นักวิเคราะห์กระบวนการทางธุรกิจ)
2) มีการพัฒนาซอฟต์แวร์สำหรับตลาด คุณต้องทำการวิจัยการตลาดและค้นหาผลิตภัณฑ์ที่ไม่มีอยู่ในตลาด สิ่งนี้มาพร้อมกับความเสี่ยงมาก เป้าหมายคือการพัฒนาข้อกำหนดข้อกำหนด
ออกแบบ
วัตถุประสงค์ - คำจำกัดความ โครงสร้างทั่วไป(สถาปัตยกรรม) ซอฟต์แวร์ ผลลัพธ์ที่ได้คือข้อกำหนดซอฟต์แวร์ งานนี้ดำเนินการโดยโปรแกรมเมอร์ระบบ
การนำไปปฏิบัติ
การเขียนโค้ดโปรแกรม. การนำไปปฏิบัติรวมถึงการพัฒนา การทดสอบ และเอกสารประกอบ
การประกอบ การทดสอบ การทดสอบ
การรวบรวมทุกสิ่งที่ทำโดยโปรแกรมเมอร์ต่างๆ การทดสอบชุดซอฟต์แวร์ทั้งหมด การดีบัก – การค้นหาและกำจัดสาเหตุของข้อผิดพลาด ทดสอบ-ชี้แจง ลักษณะทางเทคนิค. เป็นผลให้โปรแกรมรับประกันการทำงาน
การนำไปปฏิบัติ (เผยแพร่)
การนำไปปฏิบัติ – เมื่อทำงานให้กับลูกค้ารายเดียว รวมถึงการจัดโปรแกรมที่ไซต์ของลูกค้า การฝึกอบรมลูกค้า การให้คำปรึกษา การขจัดข้อผิดพลาดและข้อบกพร่องที่ชัดเจน ซอฟต์แวร์จะต้องถูกแยกออก - ผู้ใช้สามารถทำงานกับซอฟต์แวร์ได้โดยไม่ต้องมีส่วนร่วมของผู้เขียน
Release – เมื่อมีการพัฒนาซอฟต์แวร์สำหรับตลาด เริ่มต้นด้วยขั้นตอนการทดสอบเบต้า ตอบกลับ รุ่น - รุ่นเบต้า การทดสอบอัลฟ่าคือการทดสอบโดยบุคคลจากองค์กรเดียวกันซึ่งไม่ได้เกี่ยวข้องกับการพัฒนาโปรแกรม การทดสอบเบต้าคือการผลิตสำเนาซอฟต์แวร์หลายชุดและส่งไปยังผู้มีโอกาสเป็นลูกค้า เป้าหมายคือการตรวจสอบการพัฒนาซอฟต์แวร์อีกครั้ง
หากซอฟต์แวร์ใหม่โดยพื้นฐานออกสู่ตลาด ก็จะมีการทดสอบเบต้าหลายครั้ง หลังจากการทดสอบเบต้า - การเปิดตัวเวอร์ชันเชิงพาณิชย์
คุ้มกัน
ขจัดข้อผิดพลาดที่สังเกตได้ระหว่างการทำงาน ทำการปรับปรุงที่ไม่จำเป็น รวบรวมข้อเสนอเพื่อพัฒนาเวอร์ชั่นต่อไป
แบบจำลองวงจรชีวิต
1. น้ำตก (“น้ำตก” แบบจำลองน้ำตก)
2. การสร้างต้นแบบ
ประการแรกไม่ใช่ผลิตภัณฑ์ซอฟต์แวร์ที่ได้รับการพัฒนา แต่เป็นผลิตภัณฑ์ต้นแบบซึ่งประกอบด้วยวิธีแก้ไขปัญหาหลักที่นักพัฒนาเผชิญอยู่ หลังจากเสร็จสิ้นการพัฒนาต้นแบบแล้ว ผลิตภัณฑ์ซอฟต์แวร์จริงก็ได้รับการพัฒนาโดยใช้หลักการเดียวกัน ต้นแบบช่วยให้คุณเข้าใจข้อกำหนดสำหรับโปรแกรมที่กำลังพัฒนาได้ดียิ่งขึ้น การใช้ต้นแบบช่วยให้ลูกค้ากำหนดความต้องการได้แม่นยำยิ่งขึ้น นักพัฒนามีโอกาสใช้ต้นแบบในการนำเสนอแก่ลูกค้า ผลการศึกษาเบื้องต้นงานของคุณ.
3. รูปแบบการวนซ้ำ
งานแบ่งออกเป็นงานย่อยและลำดับของการดำเนินการจะถูกกำหนดเพื่อให้งานย่อยที่ตามมาแต่ละงานขยายขีดความสามารถของซอฟต์แวร์ ความสำเร็จขึ้นอยู่กับว่างานแบ่งออกเป็นงานย่อยได้ดีเพียงใด และวิธีการเลือกลำดับ ข้อดี: 1) โอกาส การมีส่วนร่วมอย่างแข็งขันลูกค้าอยู่ระหว่างการพัฒนา เขามีโอกาสที่จะชี้แจงความต้องการของเขาในระหว่างการพัฒนา 2) ความสามารถในการทดสอบชิ้นส่วนที่พัฒนาขึ้นใหม่ร่วมกับชิ้นส่วนที่พัฒนาก่อนหน้านี้ ซึ่งจะช่วยลดต้นทุนของการดีบักที่ซับซ้อน 3) ในระหว่างการพัฒนา คุณสามารถเริ่มดำเนินการในส่วนต่างๆ ได้
แนวคิดวงจรชีวิตของซอฟต์แวร์
แนวคิดของวงจรชีวิตซอฟต์แวร์ (SOLC) เป็นหนึ่งในแนวคิดพื้นฐานในวิศวกรรมซอฟต์แวร์ วงจรชีวิต กำหนดเป็นช่วงเวลาที่เริ่มต้นจากช่วงเวลาที่ตัดสินใจเกี่ยวกับความจำเป็นในการสร้างซอฟต์แวร์และสิ้นสุดในขณะที่ถูกลบออกจากบริการโดยสิ้นเชิง
ตามมาตรฐาน ISO/IEC 12207 กระบวนการวงจรชีวิตทั้งหมดจะแบ่งออกเป็นสามกลุ่ม (รูปที่ 2.1)
ภายใต้ แบบจำลองวงจรชีวิต ซอฟต์แวร์เข้าใจว่าเป็นโครงสร้างที่กำหนดลำดับของการดำเนินการและความสัมพันธ์ของกระบวนการ การดำเนินการ และงานตลอดวงจรชีวิต ขึ้นอยู่กับลักษณะเฉพาะ ขนาด และความซับซ้อนของโครงการ และเงื่อนไขเฉพาะในการสร้างและดำเนินการระบบ วงจรชีวิตของซอฟต์แวร์มักประกอบด้วยขั้นตอนต่อไปนี้:
1. การก่อตัวของข้อกำหนดซอฟต์แวร์
2. การออกแบบ
3. การนำไปปฏิบัติ
4.การทดสอบ
5. การว่าจ้าง
6. การใช้งานและการบำรุงรักษา
7. การรื้อถอน.
ตอนนี้ การกระจายตัวที่ยิ่งใหญ่ที่สุดได้รับโมเดลวงจรชีวิตซอฟต์แวร์พื้นฐานดังต่อไปนี้:
ก) น้ำตกและ
b) เกลียว (วิวัฒนาการ)
อันแรกใช้สำหรับโปรแกรมขนาดเล็กที่ประกอบเป็นหนึ่งเดียว คุณสมบัติพื้นฐาน วิธีการน้ำตกคือการเปลี่ยนไปสู่ขั้นต่อไปจะดำเนินการเฉพาะหลังจากที่งานในปัจจุบันเสร็จสมบูรณ์แล้วเท่านั้น และไม่มีการส่งคืนไปยังขั้นตอนที่เสร็จสมบูรณ์ แผนภาพแสดงไว้ในรูปที่. 2.2.
ประโยชน์ของการสมัคร โมเดลน้ำตกมีรายละเอียดดังนี้:
ในแต่ละขั้นตอน จะมีการสร้างเอกสารการออกแบบชุดสมบูรณ์
ขั้นตอนของงานที่ดำเนินการทำให้สามารถวางแผนวันที่แล้วเสร็จและต้นทุนที่เกี่ยวข้องได้
แบบจำลองนี้ใช้สำหรับระบบที่สามารถกำหนดข้อกำหนดทั้งหมดได้อย่างแม่นยำตั้งแต่เริ่มต้นการพัฒนา ซึ่งรวมถึงระบบต่างๆ ที่แก้ไขปัญหาด้านการคำนวณเป็นหลัก กระบวนการจริงมักจะมีลักษณะวนซ้ำ: ผลลัพธ์ของขั้นตอนถัดไปมักจะทำให้เกิดการเปลี่ยนแปลงในโซลูชันการออกแบบที่พัฒนาขึ้นในขั้นตอนก่อนหน้า ดังนั้น โมเดลทั่วไปคือแบบที่มีการควบคุมระดับกลาง ซึ่งแสดงไว้ในรูปที่ 1 2.3.
ข้อเสียเปรียบหลักของวิธีการแบบเรียงซ้อนคือความล่าช้าอย่างมากในการได้รับผลลัพธ์และผลที่ตามมาก็ค่อนข้างมาก มีความเสี่ยงสูงสร้างระบบที่ไม่ตอบสนองความต้องการที่เปลี่ยนแปลงไปของผู้ใช้
ปัญหาเหล่านี้จะหมดไปใน แบบจำลองวงจรชีวิตแบบเกลียว (รูปที่ 2.4) คุณสมบัติพื้นฐานของมันคือแอพพลิเคชั่นซอฟต์แวร์ไม่ได้ถูกสร้างขึ้นทันทีเช่นในกรณีของวิธีการแบบเรียงซ้อน แต่ในบางส่วนที่ใช้วิธีการ การสร้างต้นแบบ . ต้นแบบเข้าใจว่าเป็นส่วนประกอบซอฟต์แวร์ที่ใช้งานได้ซึ่งใช้ฟังก์ชันแต่ละรายการและอินเทอร์เฟซภายนอกของซอฟต์แวร์ที่กำลังพัฒนา การสร้างต้นแบบนั้นดำเนินการวนซ้ำหลายครั้ง - การหมุนแบบเกลียว
แบบจำลองน้ำตก (วิวัฒนาการ) สามารถแสดงได้ในรูปแบบของแผนภาพ ซึ่งแสดงในรูปที่ 2.5
ผลลัพธ์อย่างหนึ่งของการใช้แบบจำลองวงจรชีวิตแบบเกลียวคือวิธีการที่เรียกว่าแพร่หลาย การพัฒนาแอปพลิเคชั่นอย่างรวดเร็ว , หรือ ราด (การพัฒนาแอพพลิเคชั่นอย่างรวดเร็ว). วงจรชีวิตซอฟต์แวร์ตามวิธีนี้ประกอบด้วยสี่ขั้นตอน:
1) การวิเคราะห์และการวางแผนข้อกำหนด
2) การออกแบบ;
3) การดำเนินการ;
4) การนำไปปฏิบัติ
การวิเคราะห์วงจรชีวิตของโปรแกรมช่วยให้เราสามารถชี้แจงเนื้อหาและเน้นกระบวนการต่อไปนี้สำหรับการออกแบบระบบที่ซับซ้อน
1) กลยุทธ์;
2) การวิเคราะห์;
3) การออกแบบ;
4) การนำไปปฏิบัติ;
5) การทดสอบ;
6) การนำไปปฏิบัติ;
7) การดำเนินงานและ การสนับสนุนทางเทคนิค.
กลยุทธ์
การกำหนดกลยุทธ์เกี่ยวข้องกับการตรวจสอบระบบ วัตถุประสงค์หลักของการสำรวจคือเพื่อประเมินขอบเขตที่แท้จริงของโครงการ เป้าหมาย และวัตถุประสงค์ ตลอดจนเพื่อให้ได้คำจำกัดความระดับสูงของเอนทิตีและหน้าที่ ในขั้นตอนนี้ นักวิเคราะห์ธุรกิจที่มีคุณสมบัติสูงจะถูกดึงดูดให้เข้าถึงฝ่ายบริหารของบริษัทอย่างต่อเนื่อง นอกจากนี้ คาดว่าจะมีปฏิสัมพันธ์อย่างใกล้ชิดกับผู้ใช้หลักของระบบและผู้เชี่ยวชาญทางธุรกิจ ภารกิจหลักของการโต้ตอบดังกล่าวคือการได้รับข้อมูลที่ครบถ้วนที่สุดเท่าที่จะเป็นไปได้เกี่ยวกับระบบ เข้าใจความต้องการของลูกค้าอย่างชัดเจน และถ่ายโอนข้อมูลที่ได้รับในรูปแบบที่เป็นทางการไปยังนักวิเคราะห์ระบบ โดยทั่วไป ข้อมูลเกี่ยวกับระบบสามารถรับได้จากการสนทนา (หรือการประชุมเชิงปฏิบัติการ) กับฝ่ายบริหาร ผู้เชี่ยวชาญ และผู้ใช้
ผลลัพธ์ของขั้นตอนการกำหนดกลยุทธ์คือเอกสารที่ระบุสิ่งต่อไปนี้อย่างชัดเจน:
ลูกค้าจะเป็นหนี้อะไรกันแน่หากเขาตกลงที่จะจัดหาเงินทุนให้กับโครงการ
เมื่อไหร่เขาจะได้ ผลิตภัณฑ์สำเร็จรูป(ตารางงาน);
เขาจะเสียค่าใช้จ่ายเท่าไหร่ (กำหนดขั้นตอนการจัดหาเงินทุนสำหรับโครงการขนาดใหญ่)
เอกสารต้องสะท้อนไม่เพียงแต่ต้นทุนเท่านั้น แต่ยังรวมถึงผลประโยชน์ด้วย เช่น ระยะเวลาคืนทุนของโครงการ ผลกระทบทางเศรษฐกิจที่คาดหวัง (หากสามารถประมาณได้)
ขั้นตอนที่พิจารณาของวงจรชีวิตซอฟต์แวร์สามารถแสดงได้เพียงครั้งเดียวในโมเดล โดยเฉพาะอย่างยิ่งหากโมเดลนั้นมีโครงสร้างแบบวนรอบ นี่ไม่ได้หมายความว่าการวางแผนเชิงกลยุทธ์ในรูปแบบวัฏจักรจะทำเพียงครั้งเดียวและตลอดไป ในแบบจำลองดังกล่าว ขั้นตอนของการกำหนดกลยุทธ์และการวิเคราะห์จะรวมกันและการแยกจะเกิดขึ้นในขั้นตอนแรกเท่านั้น เมื่อฝ่ายบริหารขององค์กรทำการตัดสินใจขั้นพื้นฐานที่จะเริ่มโครงการ โดยทั่วไปแล้ว ขั้นตอนเชิงกลยุทธ์นั้นเน้นไปที่การพัฒนาเอกสารในระดับการจัดการองค์กร
ขั้นตอนการวิเคราะห์เกี่ยวข้องกับการศึกษารายละเอียดของกระบวนการทางธุรกิจ (ฟังก์ชันที่กำหนดไว้ในขั้นตอนก่อนหน้า) และข้อมูลที่จำเป็นสำหรับการดำเนินการ (เอนทิตี คุณลักษณะ และการเชื่อมต่อ (ความสัมพันธ์)) ขั้นตอนนี้สร้างแบบจำลองข้อมูล และขั้นตอนการออกแบบถัดไปจะสร้างแบบจำลองข้อมูล
ข้อมูลทั้งหมดเกี่ยวกับระบบที่รวบรวมในขั้นตอนการกำหนดกลยุทธ์จะได้รับการจัดทำอย่างเป็นทางการและชี้แจงในขั้นตอนการวิเคราะห์ ความสนใจเป็นพิเศษจะจ่ายให้กับความสมบูรณ์ของข้อมูลที่ได้รับ การวิเคราะห์ความสอดคล้อง รวมถึงการค้นหาข้อมูลที่ไม่ได้ใช้หรือซ้ำกัน ตามกฎแล้ว ขั้นแรกลูกค้าจะต้องสร้างข้อกำหนดไม่ใช่สำหรับระบบโดยรวม แต่สำหรับส่วนประกอบแต่ละส่วน และในกรณีนี้ แบบจำลองวงจรชีวิตของซอฟต์แวร์แบบวนรอบมีข้อได้เปรียบ เนื่องจากมีแนวโน้มที่จะต้องมีการวิเคราะห์ซ้ำเมื่อเวลาผ่านไป เนื่องจากลูกค้ามักจะรู้สึกอยากอาหารเมื่อรับประทานอาหาร ในขั้นตอนนี้ จะมีการกำหนดองค์ประกอบที่จำเป็นของแผนการทดสอบ
นักวิเคราะห์รวบรวมและบันทึกข้อมูลในรูปแบบที่สัมพันธ์กันสองรูปแบบ:
ก) ฟังก์ชั่น - ข้อมูลเกี่ยวกับเหตุการณ์และกระบวนการที่เกิดขึ้นในธุรกิจ
b) เอนทิตี - ข้อมูลเกี่ยวกับวัตถุที่มีความสำคัญต่อองค์กรและสิ่งที่ทราบ
ซึ่งจะสร้างไดอะแกรมของส่วนประกอบ กระแสข้อมูล และวงจรชีวิตที่อธิบายไดนามิกของระบบ สิ่งเหล่านี้จะมีการหารือในภายหลัง
ออกแบบ
ในขั้นตอนการออกแบบ แบบจำลองข้อมูลจะถูกสร้างขึ้น ผู้ออกแบบประมวลผลข้อมูลการวิเคราะห์ ผลิตภัณฑ์ขั้นสุดท้ายของขั้นตอนการออกแบบคือสกีมาฐานข้อมูล (หากมีอยู่ในโครงการ) หรือสกีมาคลังข้อมูล (แบบจำลอง ER) และชุดข้อกำหนดเฉพาะของโมดูลระบบ (แบบจำลองฟังก์ชัน)
ในโปรเจ็กต์ขนาดเล็ก (เช่น งานในหลักสูตร) คนกลุ่มเดียวกันสามารถทำหน้าที่เป็นนักวิเคราะห์ นักออกแบบ และนักพัฒนาได้ ไดอะแกรมและโมเดลที่ระบุไว้ข้างต้นช่วยในการค้นหา เช่น ไม่ได้อธิบายเลย อธิบายไม่ชัดเจน อธิบายส่วนประกอบของระบบไม่สอดคล้องกัน และข้อบกพร่องอื่นๆ ซึ่งช่วยป้องกันข้อผิดพลาดที่อาจเกิดขึ้น
ข้อกำหนดทั้งหมดจะต้องมีความแม่นยำมาก แผนการทดสอบระบบยังได้รับการสรุปในระหว่างขั้นตอนการพัฒนานี้ ในหลายโครงการ ผลลัพธ์ของขั้นตอนการออกแบบจะถูกทำให้เป็นทางการในรูปแบบของเอกสารเดียว - ที่เรียกว่าข้อกำหนดทางเทคนิค ในเวลาเดียวกันภาษา UML มีการใช้กันอย่างแพร่หลายซึ่งช่วยให้สามารถรับทั้งเอกสารการวิเคราะห์ซึ่งมีรายละเอียดน้อยกว่า (ผู้บริโภคของพวกเขาคือผู้จัดการฝ่ายผลิต) และเอกสารการออกแบบ (ผู้บริโภคของพวกเขาเป็นผู้จัดการกลุ่มการพัฒนาและการทดสอบ) ภาษานี้จะกล่าวถึงในภายหลัง ซอฟต์แวร์ที่สร้างโดยใช้ UML ช่วยให้สร้างโค้ดได้ง่ายขึ้น อย่างน้อยก็ลำดับชั้นของคลาส รวมถึงโค้ดบางส่วนของวิธีการ (ขั้นตอนและฟังก์ชัน) ด้วยตัวมันเอง
วัตถุประสงค์การออกแบบคือ:
ทบทวนผลการวิเคราะห์และตรวจสอบความครบถ้วน
สัมมนากับลูกค้า
การระบุพื้นที่สำคัญของโครงการและการประเมินข้อจำกัด
คำจำกัดความของสถาปัตยกรรมระบบ
การตัดสินใจเกี่ยวกับการใช้ผลิตภัณฑ์ของบุคคลที่สาม ตลอดจนวิธีการบูรณาการและกลไกในการแลกเปลี่ยนข้อมูลกับผลิตภัณฑ์เหล่านี้
การออกแบบคลังข้อมูล: โมเดลฐานข้อมูล
การออกแบบกระบวนการและรหัส: การเลือกเครื่องมือการพัฒนาขั้นสุดท้าย คำจำกัดความของส่วนต่อประสานโปรแกรม การแมปฟังก์ชันของระบบกับโมดูล และการกำหนดข้อกำหนดเฉพาะของโมดูล
การกำหนดข้อกำหนดสำหรับกระบวนการทดสอบ
การกำหนดข้อกำหนดด้านความปลอดภัยของระบบ
การนำไปปฏิบัติ
เมื่อดำเนินโครงการ จำเป็นอย่างยิ่งที่จะต้องประสานงานกับทีมพัฒนา นักพัฒนาซอฟต์แวร์ทุกคนอยู่ภายใต้กฎการควบคุมแหล่งที่มาที่เข้มงวด เมื่อได้รับโครงการด้านเทคนิคแล้ว พวกเขาก็เริ่มเขียนโค้ดโมดูล ภารกิจหลักของนักพัฒนาคือการทำความเข้าใจข้อกำหนด: ผู้ออกแบบเขียนสิ่งที่ต้องทำ และนักพัฒนาจะกำหนดวิธีดำเนินการ
ในขั้นตอนการพัฒนา มีการปฏิสัมพันธ์อย่างใกล้ชิดระหว่างนักออกแบบ นักพัฒนา และกลุ่มทดสอบ ในกรณีของการพัฒนาอย่างเข้มข้น ผู้ทดสอบจะแยกออกจากนักพัฒนาไม่ได้อย่างแท้จริง และกลายเป็นสมาชิกของทีมพัฒนาได้อย่างมีประสิทธิภาพ
ส่วนใหญ่แล้วอินเทอร์เฟซผู้ใช้จะเปลี่ยนไปในระหว่างขั้นตอนการพัฒนา นี่เป็นเนื่องจากการสาธิตโมดูลให้กับลูกค้าเป็นระยะ นอกจากนี้ยังสามารถเปลี่ยนการสืบค้นข้อมูลได้อย่างมาก
ขั้นตอนการพัฒนาเกี่ยวข้องกับขั้นตอนการทดสอบ และกระบวนการทั้งสองทำงานพร้อมกัน ระบบติดตามจุดบกพร่องประสานการกระทำของผู้ทดสอบและนักพัฒนา
ควรจำแนกข้อบกพร่องตามลำดับความสำคัญ สำหรับข้อผิดพลาดแต่ละประเภท จะต้องกำหนดโครงสร้างการดำเนินการที่ชัดเจน: “ต้องทำอย่างไร” “เร่งด่วนแค่ไหน” “ใครเป็นผู้รับผิดชอบต่อผลลัพธ์” แต่ละปัญหาควรได้รับการติดตามโดยผู้ออกแบบ/ผู้พัฒนา/ผู้ทดสอบที่รับผิดชอบในการแก้ไข เช่นเดียวกับสถานการณ์ที่มีการละเมิดการพัฒนาตามแผนและการส่งมอบโมดูลสำหรับการทดสอบ
นอกจากนี้ควรจัดระเบียบที่เก็บของโมดูลโครงการสำเร็จรูปและไลบรารีที่ใช้ในการประกอบโมดูล พื้นที่เก็บข้อมูลนี้ได้รับการอัปเดตอย่างต่อเนื่อง บุคคลหนึ่งควรควบคุมกระบวนการอัปเดต พื้นที่เก็บข้อมูลหนึ่งถูกสร้างขึ้นสำหรับโมดูลที่ผ่านการทดสอบการทำงาน พื้นที่เก็บข้อมูลที่สองสำหรับโมดูลที่ผ่านการทดสอบการเชื่อมต่อ อย่างแรกคือแบบร่าง ส่วนอย่างที่สองคือสิ่งที่เป็นไปได้ที่จะประกอบชุดแจกจ่ายระบบและแสดงให้ลูกค้าเห็นเพื่อทำการทดสอบการควบคุมหรือผ่านขั้นตอนการทำงานใดๆ
การทดสอบ
ทีมทดสอบสามารถมีส่วนร่วมในการทำงานร่วมกันตั้งแต่ระยะเริ่มต้นของการพัฒนาโครงการ โดยปกติแล้ว การทดสอบที่ซับซ้อนจะแยกออกเป็นขั้นตอนการพัฒนาที่แยกจากกัน ขึ้นอยู่กับความซับซ้อนของโปรเจ็กต์ การทดสอบและแก้ไขข้อผิดพลาดอาจใช้เวลาหนึ่งในสามหรือครึ่งหนึ่งของเวลาทั้งหมดที่ใช้ในการทำงานในโปรเจ็กต์ หรือมากกว่านั้น
ยิ่งโปรเจ็กต์มีความซับซ้อนมากเท่าใด ความจำเป็นในการทำให้ระบบติดตามจุดบกพร่องอัตโนมัติมากขึ้นเท่านั้น ซึ่งมีฟังก์ชันดังต่อไปนี้:
การจัดเก็บข้อความแสดงข้อผิดพลาด (ส่วนประกอบของระบบที่เกี่ยวข้องกับข้อผิดพลาด ใครพบ วิธีทำซ้ำ ใครรับผิดชอบในการแก้ไข เมื่อควรแก้ไข)
ระบบแจ้งเตือนเกี่ยวกับการปรากฏตัวของข้อผิดพลาดใหม่เกี่ยวกับการเปลี่ยนแปลงสถานะของข้อผิดพลาดที่ทราบในระบบ (แจ้งเตือนโดย อีเมล);
รายงานข้อผิดพลาดปัจจุบันสำหรับส่วนประกอบของระบบ
ข้อมูลเกี่ยวกับข้อผิดพลาดและประวัติ
กฎการเข้าถึงข้อผิดพลาดบางหมวดหมู่
อินเทอร์เฟซของการเข้าถึงระบบติดตามจุดบกพร่องสำหรับผู้ใช้อย่างจำกัด
ระบบดังกล่าวช่วยดูแลปัญหาต่างๆ ขององค์กร โดยเฉพาะปัญหาการแจ้งเตือนข้อผิดพลาดอัตโนมัติ
การทดสอบระบบนั้นมักจะแบ่งออกเป็นหลายประเภท:
ก) การทดสอบออฟไลน์โมดูล; มีการใช้แล้วในขั้นตอนการพัฒนาส่วนประกอบของระบบและช่วยให้คุณสามารถติดตามข้อผิดพลาดของแต่ละส่วนประกอบได้
ข) การทดสอบการเชื่อมต่อส่วนประกอบของระบบ การทดสอบเหล่านี้ยังใช้ในขั้นตอนการพัฒนาซึ่งช่วยให้คุณสามารถตรวจสอบการโต้ตอบและการแลกเปลี่ยนข้อมูลระหว่างส่วนประกอบของระบบได้อย่างถูกต้อง
ค) การทดสอบระบบ; เป็นเกณฑ์หลักในการยอมรับระบบ ตามกฎแล้ว นี่คือกลุ่มของการทดสอบที่รวมถึงการทดสอบอัตโนมัติ การทดสอบการเชื่อมต่อ และแบบจำลอง การทดสอบดังกล่าวจะต้องจำลองการทำงานของส่วนประกอบและฟังก์ชันทั้งหมดของระบบ เป้าหมายหลักคือการยอมรับระบบภายในและการประเมินคุณภาพ
ง) การทดสอบการยอมรับ; วัตถุประสงค์หลักคือเพื่อส่งมอบระบบให้กับลูกค้า
จ) การทดสอบประสิทธิภาพและโหลด; การทดสอบกลุ่มนี้รวมอยู่ในระบบ 1 ซึ่งเป็นการทดสอบหลักในการประเมินความน่าเชื่อถือของระบบ
แต่ละกลุ่มจำเป็นต้องมีการทดสอบการสร้างแบบจำลองความล้มเหลวด้วย โดยจะทดสอบการตอบสนองของส่วนประกอบ กลุ่มของส่วนประกอบ และระบบโดยรวมต่อความล้มเหลวต่อไปนี้:
องค์ประกอบแยกต่างหากของระบบสารสนเทศ
กลุ่มส่วนประกอบของระบบ
โมดูลหลักของระบบ
ฮาร์ดล้มเหลว (ไฟฟ้าขัดข้อง, ฮาร์ดไดรฟ์ขัดข้อง)
การทดสอบเหล่านี้ช่วยให้คุณสามารถประเมินคุณภาพของระบบย่อยเพื่อกู้คืนสถานะที่ถูกต้องของระบบข้อมูลและทำหน้าที่เป็นแหล่งข้อมูลหลักสำหรับการพัฒนากลยุทธ์การป้องกัน ผลกระทบด้านลบความล้มเหลวระหว่างการดำเนินงานทางอุตสาหกรรม
สิ่งสำคัญอีกประการหนึ่งของโปรแกรมทดสอบระบบสารสนเทศคือความพร้อมของเครื่องกำเนิดข้อมูลทดสอบ ใช้สำหรับทดสอบการทำงาน ความน่าเชื่อถือ และประสิทธิภาพของระบบ ปัญหาในการประเมินลักษณะของการพึ่งพาประสิทธิภาพของระบบสารสนเทศกับการเติบโตของปริมาณข้อมูลที่ประมวลผลไม่สามารถแก้ไขได้หากไม่มีเครื่องกำเนิดข้อมูล
การนำไปปฏิบัติ
การดำเนินการทดลองทับซ้อนกับกระบวนการทดสอบ ระบบไม่ค่อยมีการใช้งานเต็มรูปแบบ โดยทั่วไป นี่เป็นกระบวนการที่ค่อยเป็นค่อยไปหรือทำซ้ำ (ในกรณีของวงจรชีวิตแบบวัฏจักร)
การว่าจ้างต้องผ่านอย่างน้อยสามขั้นตอน:
2) การสะสมข้อมูล
3) เข้าถึงความสามารถในการออกแบบ (นั่นคือ การเปลี่ยนไปสู่ขั้นตอนการดำเนินงานจริง)
ข้อมูลอาจทำให้เกิดข้อผิดพลาดได้ค่อนข้างแคบ โดยส่วนใหญ่แล้วข้อมูลไม่ตรงกันระหว่างการโหลดและข้อผิดพลาดของตัวโหลดบูตเอง วิธีการควบคุมคุณภาพข้อมูลใช้เพื่อระบุและกำจัดข้อมูลเหล่านั้น ข้อผิดพลาดดังกล่าวจะต้องได้รับการแก้ไขโดยเร็วที่สุดในระหว่าง การสะสมข้อมูลวี ระบบข้อมูลมีการระบุข้อผิดพลาดจำนวนมากที่สุดที่เกี่ยวข้องกับการเข้าถึงของผู้ใช้หลายราย การแก้ไขประเภทที่สองเกี่ยวข้องกับข้อเท็จจริงที่ว่าผู้ใช้ไม่พอใจกับอินเทอร์เฟซ ขณะเดียวกันก็มีรุ่นไซเคิลและรุ่นต่างๆด้วย ข้อเสนอแนะขั้นตอนช่วยลดต้นทุน ขั้นตอนนี้เป็นการทดสอบที่ร้ายแรงที่สุด - การทดสอบการยอมรับของลูกค้า
ระบบถึงขีดความสามารถในการออกแบบวี ตัวเลือกที่ดี- นี่คือการปรับแต่งข้อผิดพลาดเล็กน้อยและข้อผิดพลาดร้ายแรงที่หายาก
การดำเนินงานและการสนับสนุนทางเทคนิค
ในขั้นตอนนี้ เอกสารสุดท้ายสำหรับนักพัฒนาคือใบรับรองการยอมรับทางเทคนิค เอกสารนี้กำหนดบุคลากรที่จำเป็นและอุปกรณ์ที่จำเป็นเพื่อรักษาการทำงานของระบบตลอดจนเงื่อนไขสำหรับความล้มเหลวของผลิตภัณฑ์และความรับผิดชอบของฝ่ายต่างๆ นอกจากนี้ ข้อกำหนดและเงื่อนไขการสนับสนุนทางเทคนิคมักจะจัดทำเป็นเอกสารแยกต่างหาก