คำอธิบายประกอบ
บทนำ.
1. วงจรชีวิตบน
บทนำ.
ขั้นตอนกระบวนการเขียนโปรแกรมของไรลีย์
บทนำ.
1.1.1. การกำหนดปัญหา
1.1.2. การออกแบบโซลูชัน
1.1.3. การเข้ารหัสอัลกอริธึม
1.1.4. การสนับสนุนโปรแกรม
1.1.5. เอกสารประกอบซอฟต์แวร์
บทสรุปของวรรค 1.1
1.2. คำจำกัดความของ ZhTsPO ตาม Lehman
บทนำ.
1.2.1 คำจำกัดความของระบบ
1.2.2. การดำเนินการ
1.2.3. บริการ.
สรุปข้อ 1.2
1.3. ขั้นตอนและผลงานของโปรแกรมวงจรชีวิตตามBoehm
1.3.1. โมเดลน้ำตก
1.3.2. เหตุผลทางเศรษฐกิจโมเดลน้ำตก
1.3.3. การปรับปรุงแบบจำลองน้ำตก
1.3.4. คำจำกัดความของเฟสของวงจรชีวิต
1.3.5. งานพื้นฐานในโครงการ
วรรณกรรม.
บทนำ
การประยุกต์ใช้คอมพิวเตอร์ในอุตสาหกรรมและความต้องการโปรแกรมที่เพิ่มขึ้นได้กำหนดงานเร่งด่วนสำหรับการเพิ่มขึ้นอย่างมากใน ความสามารถในการพัฒนาซอฟต์แวร์การพัฒนาวิธีการทางอุตสาหกรรมสำหรับการวางแผนและการออกแบบโปรแกรม การถ่ายโอนเทคนิคขององค์กร เทคนิค เทคนิค เศรษฐกิจ และจิตวิทยาสังคม รูปแบบและวิธีการจากขอบเขตของการผลิตวัสดุไปยังขอบเขตของคอมพิวเตอร์ แนวทางที่ซับซ้อนในกระบวนการของการพัฒนา การดำเนินงาน และการบำรุงรักษาซอฟต์แวร์ได้หยิบยกปัญหาเร่งด่วนจำนวนหนึ่งขึ้นมา ซึ่งการแก้ปัญหาดังกล่าวจะช่วยขจัด "ปัญหาคอขวด" ในการออกแบบโปรแกรม ลดเวลาที่เสร็จสมบูรณ์ ปรับปรุงทางเลือกและการปรับตัว โปรแกรมที่มีอยู่และอาจกำหนดชะตากรรมของระบบด้วยคอมพิวเตอร์ฝังตัว
ในการพัฒนาโครงการซอฟต์แวร์ขนาดใหญ่ มักจะไม่มี วิธีการแบบครบวงจรไปจนถึงการประเมินค่าแรง เงื่อนไขการทำงาน และต้นทุนวัสดุ ซึ่งเป็นอุปสรรคต่อการเพิ่มประสิทธิผลของการพัฒนาซอฟต์แวร์ และท้ายที่สุด - การจัดการที่มีประสิทธิภาพวงจรชีวิตของซอฟต์แวร์ เนื่องจากโปรแกรมประเภทใดก็ตามกลายเป็นผลิตภัณฑ์ (ยกเว้น โปรแกรมเพื่อการศึกษา โปรแกรมจำลอง) แนวทางการผลิตจึงควรมีความคล้ายคลึงกันหลายประการกับแนวทางการผลิตผลิตภัณฑ์อุตสาหกรรม และปัญหาการออกแบบซอฟต์แวร์จึงมีความสำคัญอย่างยิ่ง . แนวคิดนี้สนับสนุน B.U. Boehm "การออกแบบทางวิศวกรรม ซอฟต์แวร์” ซึ่งเราใช้เมื่อเขียนสิ่งนี้ ภาคนิพนธ์. ในหนังสือเล่มนี้ การออกแบบซอฟต์แวร์หมายถึงกระบวนการสร้างการออกแบบสำหรับผลิตภัณฑ์ซอฟต์แวร์
1 วงจรชีวิตของซอฟต์แวร์
การแนะนำ
LCPE เป็นกระบวนการต่อเนื่องที่เริ่มต้นจากช่วงเวลาที่ตัดสินใจเกี่ยวกับความจำเป็นในการสร้างซอฟต์แวร์และสิ้นสุดในขณะที่ถูกถอนออกจากการดำเนินการโดยสมบูรณ์
มีหลายวิธีในการกำหนดเฟสและกิจกรรมของวงจรชีวิตซอฟต์แวร์ (SLLC) ขั้นตอนกระบวนการเขียนโปรแกรม แบบจำลองน้ำตกและแบบเกลียว แต่ทั้งหมดมีองค์ประกอบพื้นฐานทั่วไป: คำแถลงปัญหา การออกแบบโซลูชัน การนำไปใช้งาน การบำรุงรักษา
ที่มีชื่อเสียงและสมบูรณ์ที่สุดอาจเป็นโครงสร้างของวงจรชีวิตตาม Boehm ซึ่งรวมถึงแปดขั้นตอน จะนำเสนอในรายละเอียดเพิ่มเติมในภายหลัง
หนึ่งในตัวเลือกที่เป็นไปได้อาจเป็นคำอธิบายของระดับบนตาม Lehman ซึ่งรวมถึงสามขั้นตอนหลักและแสดงถึงคำอธิบายของโปรแกรมวงจรชีวิตในกรณีทั่วไปส่วนใหญ่
และสำหรับการเปลี่ยนแปลง นี่คือขั้นตอนของกระบวนการเขียนโปรแกรมที่นำเสนอโดย D. Riley ในหนังสือ “Using the Modula-2 Language” ในความคิดของฉัน ความคิดนี้เรียบง่ายและคุ้นเคย และเราจะเริ่มด้วยมัน
1.1 ขั้นตอนกระบวนการเขียนโปรแกรมของไรลีย์
ขั้นตอนการเขียนโปรแกรมประกอบด้วยสี่ขั้นตอน (รูปที่ 1):
คำชี้แจงปัญหาคือ รับแนวคิดที่เพียงพอว่าโปรแกรมควรทำงานอะไร
การออกแบบวิธีแก้ปัญหาที่เกิดขึ้นแล้ว (โดยทั่วไป การแก้ปัญหาดังกล่าวเป็นทางการน้อยกว่าโปรแกรมสุดท้าย)
การเข้ารหัสโปรแกรม เช่น การแปลโซลูชันที่ออกแบบเป็นโปรแกรมที่สามารถดำเนินการบนเครื่อง
การสนับสนุนโปรแกรม กล่าวคือ กระบวนการต่อเนื่องในการแก้ไขจุดบกพร่องในโปรแกรมและเพิ่มคุณสมบัติใหม่
ข้าว. 1.สี่ขั้นตอนการเขียนโปรแกรม
การเขียนโปรแกรมเริ่มจากช่วงเวลาที่ ผู้ใช้, เช่น. คนที่ต้องการโปรแกรมเพื่อแก้ปัญหาก่อให้เกิดปัญหา วิเคราะห์ระบบ.ผู้ใช้และนักวิเคราะห์ระบบร่วมกันกำหนดข้อความแจ้งปัญหา หลังโอนแล้ว อัลกอริทึมซึ่งมีหน้าที่รับผิดชอบในการออกแบบโซลูชัน โซลูชัน (หรืออัลกอริธึม) คือลำดับของการดำเนินการ ซึ่งการดำเนินการดังกล่าวจะนำไปสู่การแก้ปัญหา เนื่องจากอัลกอริธึมมักไม่ได้รับการดัดแปลงให้ทำงานบนเครื่อง จึงควรแปลเป็นโปรแกรมเครื่อง การดำเนินการนี้ดำเนินการโดยตัวเข้ารหัส โปรแกรมเมอร์ที่ร่วมรับผิดชอบในการเปลี่ยนแปลงโปรแกรมในภายหลัง และนักวิเคราะห์ระบบ อัลกอริธึม นักเขียนโค้ด และโปรแกรมเมอร์ที่มาร่วมงานกัน ล้วนเป็นโปรแกรมเมอร์
ในกรณีของโครงการซอฟต์แวร์ขนาดใหญ่ จำนวนผู้ใช้ นักวิเคราะห์ระบบ และอัลกอริทึมอาจมีนัยสำคัญ นอกจากนี้ อาจจำเป็นต้องย้อนกลับไปยังขั้นตอนก่อนหน้าเนื่องจากสถานการณ์ที่ไม่คาดฝัน ทั้งหมดนี้ทำหน้าที่เป็นข้อโต้แย้งเพิ่มเติมในการออกแบบซอฟต์แวร์อย่างระมัดระวัง: ผลลัพธ์ของแต่ละขั้นตอนควรสมบูรณ์ ถูกต้อง และเข้าใจได้
1.1.1 คำชี้แจงปัญหา
ขั้นตอนที่สำคัญที่สุดอย่างหนึ่งในการเขียนโปรแกรมคือการตั้งปัญหา มันทำหน้าที่เป็นสัญญาระหว่างผู้ใช้และโปรแกรมเมอร์ เช่นเดียวกับสัญญาที่ร่างกฎหมายไม่ดี พันธกิจที่ไม่ดีก็ไร้ประโยชน์ ด้วยคำชี้แจงปัญหาที่ดี ทั้งผู้ใช้และโปรแกรมเมอร์แสดงถึงงานที่ต้องทำอย่างชัดเจนและชัดเจน กล่าวคือ ในกรณีนี้คำนึงถึงผลประโยชน์ของทั้งผู้ใช้และโปรแกรมเมอร์ ผู้ใช้สามารถวางแผนการใช้ซอฟต์แวร์ที่ยังไม่ได้สร้างได้ตามความรู้ที่สามารถทำได้ ถ้อยแถลงที่ดีของปัญหาทำหน้าที่เป็นพื้นฐานสำหรับการก่อตัวของการแก้ปัญหา
การกำหนดปัญหา (สเปคโปรแกรม); โดยพื้นฐานแล้วหมายถึงคำอธิบายที่ถูกต้อง สมบูรณ์ และเข้าใจได้ว่าอะไรจะเกิดขึ้นเมื่อมีการเรียกใช้โปรแกรมเฉพาะ ผู้ใช้มักจะมองว่าคอมพิวเตอร์เป็นกล่องดำ: ไม่สำคัญสำหรับเขาว่าคอมพิวเตอร์ทำงานอย่างไร แต่สิ่งสำคัญคือคอมพิวเตอร์สามารถทำสิ่งที่ผู้ใช้สนใจได้ โฟกัสอยู่ที่ปฏิสัมพันธ์ระหว่างมนุษย์กับเครื่องจักร
ลักษณะของคำชี้แจงปัญหาที่ดี:
ความแม่นยำ, เช่น. การยกเว้นความคลุมเครือใดๆ ไม่ควรมีคำถามว่าผลลัพธ์ของโปรแกรมจะเป็นอย่างไรสำหรับอินพุตที่กำหนด
ความสมบูรณ์, เช่น. พิจารณาตัวเลือกทั้งหมดสำหรับข้อมูลที่ป้อน รวมถึงการป้อนข้อมูลที่ผิดพลาดหรือไม่คาดคิด และการพิจารณาผลลัพธ์ที่เหมาะสม
ความชัดเจน, เช่น. ทั้งผู้ใช้และนักวิเคราะห์ระบบควรเข้าใจได้ เนื่องจากข้อความแจ้งปัญหาเป็นสัญญาเดียวระหว่างพวกเขา
บ่อยครั้งข้อกำหนดสำหรับความถูกต้อง ความสมบูรณ์ และความชัดเจนขัดแย้งกัน ดังนั้น เอกสารทางกฎหมายจำนวนมากจึงเข้าใจได้ยาก เนื่องจากเอกสารเหล่านี้เขียนด้วยภาษาที่เป็นทางการ ซึ่งช่วยให้คุณกำหนดข้อกำหนดเหล่านี้หรือข้อกำหนดเหล่านั้นได้อย่างแม่นยำที่สุด ยกเว้นข้อแตกต่างที่เล็กน้อยที่สุด ตัวอย่างเช่น คำถามบางข้อในข้อสอบบางครั้งใช้คำได้อย่างแม่นยำจนนักเรียนใช้เวลาทำความเข้าใจคำถามมากกว่าตอบคำถาม นอกจากนี้ นักเรียนอาจไม่เข้าใจความหมายหลักของคำถามเลย เนื่องจากมีรายละเอียดจำนวนมาก คำแถลงปัญหาที่ดีที่สุดคือคำที่บรรลุความสมดุลของข้อกำหนดทั้งสาม
รูปแบบมาตรฐานของคำชี้แจงปัญหา
พิจารณาข้อความแจ้งปัญหาต่อไปนี้: "ป้อนตัวเลขสามตัวและส่งออกตัวเลขตามลำดับ"
ข้อความดังกล่าวไม่เป็นไปตามข้อกำหนดข้างต้น: ไม่แม่นยำ ไม่ครบถ้วน และไม่สามารถเข้าใจได้ อันที่จริงควรป้อนตัวเลขหนึ่งหมายเลขต่อบรรทัดหรือป้อนตัวเลขทั้งหมดในบรรทัดเดียว? นิพจน์ "ตามลำดับ" หมายถึงการเรียงลำดับจากมากไปน้อย จากน้อยไปมาก หรือลำดับเดียวกับที่ป้อน
เห็นได้ชัดว่าข้อความดังกล่าวไม่ได้ตอบคำถามมากมาย หากเราคำนึงถึงคำตอบของคำถามทุกข้อแล้ว คำชี้แจงปัญหาจะกลายเป็นคำพูดที่เข้าใจยาก ดังนั้น ดี. ไรลีย์จึงเสนอให้ใช้รูปแบบมาตรฐานในการกำหนดปัญหา ซึ่งรับรองความถูกต้อง ความสมบูรณ์ ความชัดเจนสูงสุด และรวมถึง:
ชื่องาน (คำจำกัดความแผนผัง);
คำอธิบายทั่วไป (สรุปงาน);
ข้อผิดพลาด (ตัวเลือกอินพุตที่ผิดปกติแสดงไว้อย่างชัดเจนเพื่อแสดงให้ผู้ใช้และโปรแกรมเมอร์ทราบถึงการดำเนินการที่เครื่องจะดำเนินการในสถานการณ์ดังกล่าว)
ตัวอย่าง ( ตัวอย่างที่ดีสามารถถ่ายทอดแก่นแท้ของปัญหาพร้อมทั้งแสดงตัวอย่างกรณีต่างๆ ได้)
ตัวอย่าง. คำชี้แจงปัญหาในรูปแบบมาตรฐาน
ชื่อ
เรียงจำนวนเต็มสามจำนวน
คำอธิบาย
อินพุตและเอาต์พุตของจำนวนเต็มสามจำนวน เรียงจากน้อยไปมาก
มีการป้อนจำนวนเต็มสามจำนวน หนึ่งหมายเลขต่อบรรทัด ในกรณีนี้ จำนวนเต็มคือหนึ่งหรือมากกว่าต่อเนื่องกัน ทศนิยมซึ่งสามารถนำหน้าด้วยเครื่องหมายบวก "+" หรือเครื่องหมายลบ "-"
จำนวนเต็มทั้งสามที่ป้อนเป็นเอาต์พุต โดยทั้งสามแสดงอยู่ในบรรทัดเดียวกัน ตัวเลขที่อยู่ติดกันคั่นด้วยช่องว่าง ตัวเลขจะแสดงจากน้อยไปมาก จากซ้ายไปขวา
1) หากป้อนตัวเลขน้อยกว่าสามตัว โปรแกรมจะรอการป้อนข้อมูลเพิ่มเติม
การพัฒนาซอฟต์แวร์เป็นไปไม่ได้หากปราศจากความเข้าใจถึงวงจรชีวิตซอฟต์แวร์ที่เรียกว่า ผู้ใช้ทั่วไปอาจไม่จำเป็นต้องรู้สิ่งนี้ แต่ควรเรียนรู้มาตรฐานพื้นฐาน (จะกล่าวในภายหลังว่าทำไมจึงจำเป็น)
วงจรชีวิตในความหมายที่เป็นทางการคืออะไร?
ภายใต้วัฏจักรชีวิตใด ๆ เป็นเรื่องปกติที่จะเข้าใจเวลาของการดำรงอยู่ตั้งแต่ขั้นตอนการพัฒนาจนถึงปัจจุบัน ล้มเหลวโดยสิ้นเชิงตั้งแต่การใช้งานในสาขาที่เลือกไปจนถึงการนำแอปพลิเคชันออกจากการใช้งานโดยสมบูรณ์
กล่าวอย่างง่าย ๆ ระบบสารสนเทศในรูปแบบของโปรแกรม ฐานข้อมูล หรือแม้แต่ระบบปฏิบัติการเป็นที่ต้องการก็ต่อเมื่อข้อมูลและโอกาสที่ให้ข้อมูลนั้นมีความเกี่ยวข้อง
เป็นที่เชื่อกันว่าคำจำกัดความของวงจรชีวิตใช้ไม่ได้ในการทดสอบแอปพลิเคชันใดๆ เช่น เวอร์ชันเบต้า ซึ่งเป็นเวอร์ชันที่ไม่เสถียรที่สุดในการดำเนินการ วัฏจักรชีวิตของซอฟต์แวร์นั้นขึ้นอยู่กับหลายปัจจัย ซึ่งหนึ่งในบทบาทหลักที่เล่นโดยสภาพแวดล้อมที่จะใช้โปรแกรม อย่างไรก็ตามเราสามารถแยกแยะได้ ข้อกำหนดและเงื่อนไขทั่วไปใช้ในการกำหนดแนวคิดวงจรชีวิต
ข้อกำหนดเบื้องต้น
- การกำหนดปัญหา
- การวิเคราะห์ความต้องการร่วมกันของซอฟต์แวร์ในอนาคตต่อระบบ
- ออกแบบ;
- การเขียนโปรแกรม;
- การเข้ารหัสและการรวบรวม
- การทดสอบ;
- การดีบัก;
- การใช้งานและบำรุงรักษาผลิตภัณฑ์ซอฟต์แวร์
การพัฒนาซอฟต์แวร์ประกอบด้วยขั้นตอนทั้งหมดที่กล่าวมาข้างต้น และไม่สามารถทำได้โดยปราศจากขั้นตอนใดขั้นตอนหนึ่ง แต่เพื่อควบคุมกระบวนการดังกล่าว จึงมีการกำหนดมาตรฐานพิเศษขึ้น
มาตรฐานกระบวนการวงจรชีวิตซอฟต์แวร์
ในบรรดาระบบที่กำหนดเงื่อนไขและข้อกำหนดไว้ล่วงหน้าสำหรับกระบวนการดังกล่าว วันนี้มีเพียงสามระบบหลักเท่านั้นที่สามารถตั้งชื่อได้:
- 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 แอปพลิเคชันเพิ่มเติม
ในขั้นตอนการพัฒนา มีการใช้เครื่องมือของภาษาซี แต่แพลตฟอร์มดูค่อนข้างดั้งเดิมและไม่อนุญาตให้ผู้ใช้ปลายทาง คุณภาพที่ต้องการเสียง.
ในเรื่องนี้ ในขั้นตอนของการทดสอบและการดีบัก นักพัฒนาต้องปฏิบัติตามแนวทางของบริษัทเยอรมัน Steinberg และใช้การรองรับโหมดฟูลดูเพล็กซ์ในข้อกำหนดสำหรับไดรเวอร์เสียงหลัก คุณภาพของเสียงสูงขึ้น และให้คุณเปลี่ยนจังหวะ ระดับเสียง และใช้เอฟเฟกต์ FX เพิ่มเติมได้แบบเรียลไทม์
การสิ้นสุดวงจรชีวิตของซอฟต์แวร์นี้ถือเป็นการเปิดตัวครั้งแรก รุ่นทางการ FL Studio ซึ่งแตกต่างจากบรรพบุรุษ มีอินเทอร์เฟซซีเควนเซอร์เต็มรูปแบบพร้อมความสามารถในการแก้ไขพารามิเตอร์บนคอนโซลมิกซ์ 64 แชนเนลเสมือนพร้อมการเพิ่มแทร็กเสียงและแทร็ก MIDI ได้ไม่จำกัด
นี้ไม่ได้จำกัด ในขั้นตอนการจัดการโครงการ มีการแนะนำการสนับสนุนสำหรับการเชื่อมต่อปลั๊กอินในรูปแบบ VST (รุ่นแรกเป็นรุ่นที่สอง และรุ่นที่สาม) ซึ่งครั้งหนึ่งได้รับการพัฒนาโดย Steinberg กล่าวโดยสรุป ซินธิไซเซอร์เสมือนใดๆ ที่รองรับโฮสต์ VST สามารถเชื่อมต่อกับโปรแกรมได้
ไม่น่าแปลกใจที่ในไม่ช้านักประพันธ์เพลงคนใดก็สามารถใช้แอนะล็อกของโมเดล "เหล็ก" ได้ ตัวอย่างเช่น ชุดเสียงที่สมบูรณ์ของ Korg M1 ซึ่งครั้งหนึ่งเคยเป็นที่นิยม นอกจากนี้. การใช้โมดูลอย่าง Addictive Drums หรือปลั๊กอิน Kontakt สากล ทำให้สามารถสร้างเสียงสดของเครื่องดนตรีจริงที่บันทึกด้วยเฉดสีที่เปล่งออกมาในสตูดิโอมืออาชีพได้
ในเวลาเดียวกัน นักพัฒนาพยายามที่จะบรรลุคุณภาพสูงสุดโดยการสร้างการรองรับไดรเวอร์ ASIO4ALL ซึ่งกลายเป็นหัวหน้าและไหล่เหนือโหมดฟูลดูเพล็กซ์ ดังนั้นบิตเรตก็เพิ่มขึ้นเช่นกัน จนถึงปัจจุบัน คุณภาพของไฟล์เสียงที่ส่งออกสามารถเป็น 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 เมื่อข้อมูลเข้าสู่จิตใจของผู้ใช้โดยไม่คำนึงถึงตัวเขาเอง)
แน่นอนว่าเทคโนโลยีดังกล่าวเป็นสิ่งต้องห้ามในโลก แต่พวกเราหลายคนไม่รู้ด้วยซ้ำว่าเทคโนโลยีเหล่านี้ยังสามารถใช้และส่งผลต่อจิตใต้สำนึกได้ในบางวิธี สิ่งที่ควรค่าแก่ “ซอมบี้” ตามช่องข่าวหรือเว็บไซต์อินเทอร์เน็ต ไม่ต้องพูดถึงการใช้วิธีการที่ทรงพลังกว่า เช่น การสัมผัสกับอินฟราซาวน์ (อันนี้ใช้ในการผลิตละครโอเปร่าเรื่องหนึ่ง) อันเป็นผลให้บุคคลอาจประสบกับความกลัวหรือไม่เพียงพอ อารมณ์
เมื่อกลับมาที่ซอฟต์แวร์ การเพิ่มบางโปรแกรมใช้สัญญาณเสียงเมื่อเริ่มต้นเพื่อดึงดูดความสนใจของผู้ใช้ และจากการศึกษาพบว่าแอปพลิเคชันดังกล่าวมีศักยภาพมากกว่าโปรแกรมอื่นๆ โดยธรรมชาติแล้ว วงจรชีวิตของซอฟต์แวร์ก็เพิ่มขึ้นเช่นกัน ไม่ว่าจะถูกกำหนดให้ใช้งานฟังก์ชันใดก็ตาม และน่าเสียดายที่นักพัฒนาหลายคนใช้สิ่งนี้ซึ่งทำให้สงสัยเกี่ยวกับความถูกต้องตามกฎหมายของวิธีการดังกล่าว
แต่ไม่ใช่สำหรับเราที่จะตัดสินสิ่งนี้ เป็นไปได้ว่าในอนาคตอันใกล้จะมีการพัฒนาเครื่องมือเพื่อระบุภัยคุกคามดังกล่าว จนถึงตอนนี้ นี่เป็นเพียงทฤษฎี แต่ตามที่นักวิเคราะห์และผู้เชี่ยวชาญบางคนเคยกล่าวไว้ก่อนหน้านี้ การใช้งานจริงเหลือน้อยมาก หากพวกเขากำลังสร้างสำเนาของโครงข่ายประสาทในสมองมนุษย์อยู่แล้ว ฉันจะพูดอะไรได้
ข้าว. 5.2.
ด้านเหล่านี้คือ:
- ด้านสัญญาที่ลูกค้าและซัพพลายเออร์เข้าร่วม ความสัมพันธ์ตามสัญญาและใช้กระบวนการจัดหาและจัดหา
- ด้านการจัดการ ซึ่งรวมถึงการดำเนินการจัดการของบุคคลที่เข้าร่วมในวงจรชีวิตของซอฟต์แวร์ (ซัพพลายเออร์ ลูกค้า ผู้พัฒนา ผู้ปฏิบัติงาน ฯลฯ)
- ด้านการดำเนินงานซึ่งรวมถึงการดำเนินการของผู้ให้บริการเพื่อให้บริการแก่ผู้ใช้ระบบ
- ด้านวิศวกรรมซึ่งประกอบด้วยการกระทำของผู้พัฒนาหรือบริการสนับสนุนเพื่อแก้ไขปัญหาทางเทคนิคที่เกี่ยวข้องกับการพัฒนาหรือดัดแปลงผลิตภัณฑ์ซอฟต์แวร์
- แง่มุมของการสนับสนุนที่เกี่ยวข้องกับการดำเนินการตามกระบวนการสนับสนุน โดยบริการสนับสนุนจะให้บริการที่จำเป็นแก่ผู้เข้าร่วมคนอื่นๆ ในงานทั้งหมด ในด้านนี้ เราสามารถแยกแยะแง่มุมของการจัดการคุณภาพซอฟต์แวร์ รวมถึงกระบวนการประกันคุณภาพ การตรวจสอบ การรับรอง การประเมินร่วมกันและการตรวจสอบ
กระบวนการในองค์กรดำเนินการในระดับองค์กรหรือระดับขององค์กรทั้งหมด โดยสร้างพื้นฐานสำหรับการนำไปใช้งานและปรับปรุงกระบวนการวงจรชีวิตของซอฟต์แวร์อย่างต่อเนื่อง
5.6. รุ่นและขั้นตอนของวงจรชีวิตซอฟต์แวร์
แบบจำลองวงจรชีวิตของซอฟต์แวร์เป็นที่เข้าใจกันว่าเป็นโครงสร้างที่กำหนดลำดับของการดำเนินการและความสัมพันธ์ของกระบวนการ การดำเนินการ และงานตลอดวงจรชีวิตของซอฟต์แวร์ แบบจำลองวงจรชีวิตขึ้นอยู่กับลักษณะเฉพาะ ขนาดและความซับซ้อนของโครงการ และเงื่อนไขเฉพาะที่ระบบถูกสร้างขึ้นและดำเนินการ
มาตรฐาน ISO/IEC 12207 ไม่ได้เสนอแบบจำลองวงจรชีวิตเฉพาะและวิธีการพัฒนาซอฟต์แวร์ ข้อกำหนดนี้เป็นเรื่องปกติสำหรับแบบจำลองวงจรชีวิต วิธีการ และเทคโนโลยีของการพัฒนาซอฟต์แวร์ มาตรฐานนี้อธิบายโครงสร้างของกระบวนการวงจรชีวิตของซอฟต์แวร์ แต่ไม่ได้ระบุวิธีการนำไปใช้หรือดำเนินการกิจกรรมและงานที่รวมอยู่ในกระบวนการเหล่านี้
แบบจำลองวงจรชีวิตของซอฟต์แวร์เฉพาะใด ๆ กำหนดลักษณะของกระบวนการสร้างซึ่งเป็นชุดของงานที่ได้รับคำสั่งในเวลา เชื่อมต่อถึงกันและรวมกันเป็นขั้นตอน (ขั้นตอน) การใช้งานซึ่งจำเป็นและเพียงพอที่จะสร้างซอฟต์แวร์ที่ตรงตามข้อกำหนด ข้อกำหนดที่ระบุ
ขั้นตอน (เฟส) ของการสร้างซอฟต์แวร์เป็นที่เข้าใจกันว่าเป็นส่วนหนึ่งของกระบวนการพัฒนาซอฟต์แวร์ ซึ่งถูกจำกัดด้วยกรอบเวลาหนึ่งและสิ้นสุดด้วยการเปิดตัวผลิตภัณฑ์เฉพาะ (รุ่นซอฟต์แวร์ ส่วนประกอบซอฟต์แวร์ เอกสารประกอบ ฯลฯ) ซึ่งกำหนดโดยข้อกำหนดที่ระบุ สำหรับขั้นตอนนี้ ขั้นตอนของการสร้างซอฟต์แวร์มีความแตกต่างกันด้วยเหตุผลของการวางแผนอย่างมีเหตุผลและการจัดระบบงาน โดยลงท้ายด้วยผลลัพธ์ที่ระบุ วงจรชีวิตซอฟต์แวร์มักจะประกอบด้วยขั้นตอนต่อไปนี้:
- การก่อตัวของข้อกำหนดซอฟต์แวร์
- การออกแบบ (การพัฒนาโครงการระบบ);
- การใช้งาน (สามารถแบ่งออกเป็นขั้นตอนย่อย: การออกแบบโดยละเอียด, การเข้ารหัส);
- การทดสอบ (สามารถแบ่งออกเป็นแบบสแตนด์อะโลนและ การทดสอบที่ครอบคลุมและบูรณาการ)
- การว่าจ้าง (การดำเนินการ);
- การดำเนินงานและการบำรุงรักษา;
- การรื้อถอน
ผู้เชี่ยวชาญบางคนแนะนำขั้นตอนเริ่มต้นเพิ่มเติม - การศึกษาความเป็นไปได้ระบบ หมายถึงระบบซอฟต์แวร์และฮาร์ดแวร์ที่ใช้สร้าง ซื้อ หรือแก้ไขซอฟต์แวร์
ขั้นตอนของการก่อตัวของข้อกำหนดซอฟต์แวร์เป็นหนึ่งในขั้นตอนที่สำคัญที่สุดและกำหนดในระดับสูง (ถึงกับชี้ขาด!) ความสำเร็จของโครงการทั้งหมด จุดเริ่มต้นของขั้นตอนนี้คือการได้รับสถาปัตยกรรมระบบที่ได้รับอนุมัติและได้รับการอนุมัติโดยรวมถึงข้อตกลงพื้นฐานเกี่ยวกับการแจกจ่ายฟังก์ชันระหว่างฮาร์ดแวร์และซอฟต์แวร์ เอกสารนี้ควรมีการยืนยันแนวคิดทั่วไปเกี่ยวกับการทำงานของซอฟต์แวร์ รวมถึงข้อตกลงหลักเกี่ยวกับการแจกจ่ายฟังก์ชันระหว่างบุคคลและระบบ
ขั้นตอนของการก่อตัวของข้อกำหนดซอฟต์แวร์ประกอบด้วยขั้นตอนต่อไปนี้
- วางแผนการทำงานล่วงหน้าของโครงการ งานหลักของเวทีคือการกำหนดเป้าหมายการพัฒนาเบื้องต้น การประเมินทางเศรษฐกิจโครงการสร้างตารางการทำงานสร้างและฝึกอบรมคณะทำงานร่วม
- ดำเนินการสำรวจกิจกรรมขององค์กรอัตโนมัติ (วัตถุ) ภายในกรอบที่มีการระบุข้อกำหนดเบื้องต้นสำหรับระบบในอนาคตการกำหนดโครงสร้างขององค์กรการกำหนดรายการหน้าที่เป้าหมายขององค์กรการวิเคราะห์ การกระจายหน้าที่โดยหน่วยงานและพนักงานระบุ ปฏิสัมพันธ์เชิงหน้าที่ระหว่างแผนก การไหลของข้อมูลภายในแผนกและระหว่างแผนก วัตถุภายนอกองค์กรและอิทธิพลของข้อมูลภายนอก การวิเคราะห์วิธีการที่มีอยู่ของการทำให้กิจกรรมขององค์กรเป็นแบบอัตโนมัติ
- แบบจำลอง "AS-IS" ("ตามที่เป็น") ที่สะท้อนถึงสถานะปัจจุบันของกิจการในองค์กร ณ เวลาที่ทำการสำรวจ และช่วยให้คุณเข้าใจวิธีการทำงานขององค์กร ตลอดจนระบุปัญหาคอขวดและกำหนดข้อเสนอเพื่อปรับปรุง สถานการณ์;
- โมเดล "TO-BE" ("ตามที่ควรจะเป็น") สะท้อนแนวคิดเทคโนโลยีใหม่ๆ ในการทำงานขององค์กร
การสร้างแบบจำลองกิจกรรมขององค์กร (วัตถุ) ซึ่งจัดให้มีการประมวลผลวัสดุการสำรวจและการสร้างแบบจำลองสองประเภท:
โมเดลแต่ละแบบควรมีรูปแบบการทำงานและข้อมูลที่สมบูรณ์ของกิจกรรมขององค์กร เช่นเดียวกับแบบจำลอง (ถ้าจำเป็น) ที่อธิบายพลวัตของพฤติกรรมขององค์กร โปรดทราบว่าแบบจำลองที่สร้างขึ้นนั้นมีความสำคัญในทางปฏิบัติโดยอิสระ ไม่ว่าองค์กรจะพัฒนาและนำระบบข้อมูลไปใช้หรือไม่ก็ตาม เนื่องจากสามารถใช้ในการฝึกอบรมพนักงานและปรับปรุงกระบวนการทางธุรกิจขององค์กรได้
ผลลัพธ์ของความสมบูรณ์ของขั้นตอนของการก่อตัวของข้อกำหนดของซอฟต์แวร์คือข้อมูลจำเพาะของซอฟต์แวร์ ฟังก์ชัน ทางเทคนิค และข้อกำหนดของอินเทอร์เฟซ ซึ่งยืนยันความสมบูรณ์ การตรวจสอบได้ และความเป็นไปได้
ขั้นตอนการออกแบบประกอบด้วยขั้นตอนต่อไปนี้
การพัฒนาโครงการระบบซอฟต์แวร์ ในขั้นตอนนี้ให้คำตอบสำหรับคำถาม "ระบบในอนาคตควรทำอย่างไร" กล่าวคือ: สถาปัตยกรรมของระบบ, หน้าที่, สภาพภายนอกการทำงาน การเชื่อมต่อและการกระจายฟังก์ชันระหว่างผู้ใช้และระบบ ข้อกำหนดสำหรับส่วนประกอบซอฟต์แวร์และข้อมูล พนักงานและเวลาในการพัฒนา แผนการแก้จุดบกพร่องของซอฟต์แวร์ และการควบคุมคุณภาพ
พื้นฐานของโครงการระบบคือแบบจำลองของระบบที่ออกแบบซึ่งสร้างขึ้นจากรุ่น "TO-BE" ผลลัพธ์ของการพัฒนาโครงการระบบควรเป็นข้อกำหนดเฉพาะของซอฟต์แวร์ที่ได้รับการอนุมัติและยืนยันแล้ว: ข้อมูลจำเพาะด้านการทำงาน ทางเทคนิค และอินเทอร์เฟซ ซึ่งยืนยันความสมบูรณ์ การตรวจสอบได้ และความเป็นไปได้
- การพัฒนาโครงการโดยละเอียด (ทางเทคนิค) ในขั้นตอนนี้ จะมีการออกแบบซอฟต์แวร์จริง รวมถึงการออกแบบสถาปัตยกรรมระบบและการออกแบบโดยละเอียด ดังนั้นคำตอบสำหรับคำถามคือ: "จะสร้างระบบอย่างไรเพื่อให้เป็นไปตามข้อกำหนด"
ผลลัพธ์ของการออกแบบโดยละเอียดคือการพัฒนาข้อกำหนดซอฟต์แวร์ที่ผ่านการตรวจสอบแล้ว ซึ่งรวมถึง:
- การก่อตัวของลำดับชั้นของส่วนประกอบซอฟต์แวร์ ส่วนต่อประสานระหว่างโมดูลสำหรับข้อมูลและการควบคุม
- ข้อมูลจำเพาะของส่วนประกอบซอฟต์แวร์แต่ละอย่าง ชื่อ วัตถุประสงค์ สมมติฐาน ขนาด ลำดับการโทร ข้อมูลอินพุตและเอาต์พุต ผิดพลาด ผลลัพธ์ อัลกอริธึมและวงจรลอจิก
- การก่อตัวของโครงสร้างข้อมูลทางกายภาพและเชิงตรรกะจนถึงระดับของแต่ละสาขา
- การพัฒนาแผนสำหรับการกระจายทรัพยากรการคำนวณ (เวลาของโปรเซสเซอร์กลาง หน่วยความจำ ฯลฯ );
- การทวนสอบความสมบูรณ์ ความสม่ำเสมอ ความเป็นไปได้และความถูกต้องของข้อกำหนด
- แผนบูรณาการเบื้องต้นและการแก้ไขจุดบกพร่อง คู่มือผู้ใช้ และแผนการทดสอบการยอมรับ
ความสมบูรณ์ของขั้นตอนการออกแบบโดยละเอียดคือแบบ end-to-end
เมื่อวันที่ 1 มีนาคม 2555 หน่วยงานกลางสำหรับกฎระเบียบทางเทคนิคและมาตรวิทยาของสหพันธรัฐรัสเซียได้นำมาตรฐาน GOST R ISO / IEC 12207-2010 มาใช้แทน GOST R ISO / IEC 12207-99 " เทคโนโลยีสารสนเทศ. วิศวกรรมระบบและซอฟต์แวร์ กระบวนการวงจรชีวิตของซอฟต์แวร์” เหมือนกับมาตรฐานสากล ISO/IEC 12207: 2008 “วิศวกรรมระบบและซอฟต์แวร์ - กระบวนการวงจรชีวิตซอฟต์แวร์”
มาตรฐานนี้ โดยใช้ศัพท์เฉพาะที่กำหนดขึ้น โครงสร้างโดยรวมกระบวนการวงจรชีวิตซอฟต์แวร์ที่สามารถใช้เป็นข้อมูลอ้างอิงในอุตสาหกรรมซอฟต์แวร์ได้ มาตรฐานกำหนดกระบวนการ กิจกรรม และงานที่ใช้ในการได้มาซึ่งผลิตภัณฑ์หรือบริการซอฟต์แวร์ และในการส่งมอบ การพัฒนา การใช้งานตามวัตถุประสงค์ การบำรุงรักษา และการยุติผลิตภัณฑ์ซอฟต์แวร์
กระบวนการวงจรชีวิตของซอฟต์แวร์
กลุ่มมาตรฐาน ประเภทต่างๆกิจกรรมที่สามารถทำได้ในช่วงวงจรชีวิต ระบบซอฟต์แวร์ออกเป็นเจ็ดกลุ่มกระบวนการ แต่ละกระบวนการของวงจรชีวิตภายในกลุ่มเหล่านี้มีการอธิบายในแง่ของวัตถุประสงค์และผลลัพธ์ที่ต้องการ รายการของการดำเนินการและงานที่ต้องทำเพื่อให้บรรลุผลลัพธ์เหล่านั้น
- กระบวนการข้อตกลง - สองกระบวนการ
- กระบวนการสนับสนุนองค์กรโครงการ - ห้ากระบวนการ
- กระบวนการโครงการ - เจ็ดกระบวนการ
- กระบวนการทางเทคนิค - สิบเอ็ดกระบวนการ;
- กระบวนการปรับใช้ซอฟต์แวร์ - เจ็ดกระบวนการ
- กระบวนการสนับสนุนซอฟต์แวร์ - แปดกระบวนการ
- กระบวนการนำซอฟต์แวร์กลับมาใช้ใหม่ - สามกระบวนการ
- หลัก:
- การได้มา (การดำเนินการและงานของลูกค้าที่ซื้อซอฟต์แวร์)
- การส่งมอบ (กิจกรรมและงานของซัพพลายเออร์ที่จัดหาผลิตภัณฑ์หรือบริการซอฟต์แวร์ให้กับลูกค้า)
- การพัฒนา (การดำเนินการและงานที่ดำเนินการโดยนักพัฒนา: การสร้างซอฟต์แวร์ การเขียนแบบเอกสารการออกแบบและการปฏิบัติงาน การเตรียมเอกสารการทดสอบและการฝึกอบรม ฯลฯ)
- การดำเนินงาน (การดำเนินการและงานของผู้ปฏิบัติงาน - องค์กรที่ดำเนินการระบบ)
- การบำรุงรักษา (การดำเนินการและงานที่ดำเนินการโดยองค์กรที่เกี่ยวข้องนั่นคือบริการบำรุงรักษา) การบำรุงรักษา - การเปลี่ยนแปลงซอฟต์แวร์เพื่อแก้ไขจุดบกพร่อง ปรับปรุงประสิทธิภาพ หรือปรับให้เข้ากับสภาพการทำงานหรือข้อกำหนดที่เปลี่ยนแปลงไป
- ตัวช่วย
- เอกสารประกอบ (คำอธิบายอย่างเป็นทางการของข้อมูลที่สร้างขึ้นระหว่างวงจรชีวิตของซอฟต์แวร์)
- การจัดการการกำหนดค่า (การประยุกต์ใช้ขั้นตอนการบริหารและทางเทคนิคตลอดวงจรชีวิตของซอฟต์แวร์เพื่อกำหนดสถานะของส่วนประกอบซอฟต์แวร์ จัดการการแก้ไข)
- การประกันคุณภาพ (ตรวจสอบให้แน่ใจว่า IS และกระบวนการของวงจรชีวิตเป็นไปตามข้อกำหนดที่ระบุและแผนที่ได้รับอนุมัติ)
- การตรวจสอบ (การพิจารณาว่าผลิตภัณฑ์ซอฟต์แวร์ซึ่งเป็นผลมาจากการดำเนินการบางอย่าง เป็นไปตามข้อกำหนดหรือเงื่อนไขอันเนื่องมาจากการกระทำก่อนหน้านี้)
- การรับรอง (การกำหนดความสมบูรณ์ของการปฏิบัติตามข้อกำหนดที่ระบุและระบบที่สร้างขึ้นโดยมีวัตถุประสงค์การทำงานเฉพาะ)
- การประเมินร่วม (การประเมินสถานะงานในโครงการ: การควบคุมการวางแผนและการจัดการทรัพยากรบุคลากรอุปกรณ์เครื่องมือ)
- การตรวจสอบ (การกำหนดการปฏิบัติตามข้อกำหนด แผน และเงื่อนไขของสัญญา)
- การแก้ปัญหา (การวิเคราะห์และการแก้ปัญหาโดยไม่คำนึงถึงที่มาหรือแหล่งที่มาซึ่งค้นพบในระหว่างการพัฒนา การดำเนินงาน การบำรุงรักษาหรือกระบวนการอื่น ๆ )
- องค์กร
- การจัดการ (กิจกรรมและงานที่ดำเนินการโดยฝ่ายใดฝ่ายหนึ่งที่จัดการกระบวนการของตน)
- การสร้างโครงสร้างพื้นฐาน (การเลือกและการบำรุงรักษาเทคโนโลยี มาตรฐาน และ เครื่องมือการเลือกและติดตั้งฮาร์ดแวร์และซอฟต์แวร์ที่ใช้ในการพัฒนา ใช้งาน หรือบำรุงรักษาซอฟต์แวร์)
- การปรับปรุง (การประเมิน การวัด การควบคุม และปรับปรุงกระบวนการวงจรชีวิต)
- การฝึกอบรม (การฝึกอบรมเบื้องต้นและการพัฒนาพนักงานอย่างต่อเนื่องในภายหลัง)
แต่ละขั้นตอนประกอบด้วยกิจกรรมจำนวนหนึ่ง ตัวอย่างเช่น กระบวนการได้มาซึ่งครอบคลุมขั้นตอนต่อไปนี้:
- การเข้าซื้อกิจการ
- การเตรียมการประมูล
- การจัดเตรียมและการปรับสัญญา
- การกำกับดูแลซัพพลายเออร์
- การยอมรับและเสร็จสิ้นการทำงาน
การดำเนินการแต่ละครั้งประกอบด้วยงานจำนวนหนึ่ง ตัวอย่างเช่น การเตรียมการประมูลควรรวมถึง:
- การก่อตัวของข้อกำหนดสำหรับระบบ
- การก่อตัวของรายการผลิตภัณฑ์ซอฟต์แวร์
- การกำหนดเงื่อนไขและข้อตกลง
- คำอธิบายของข้อจำกัดทางเทคนิค (สภาพแวดล้อมการทำงานของระบบ ฯลฯ)
ระยะวงจรชีวิตของซอฟต์แวร์ ความสัมพันธ์ระหว่างกระบวนการและขั้นตอน
แบบจำลองวงจรชีวิตของซอฟต์แวร์- โครงสร้างที่กำหนดลำดับของการดำเนินการและความสัมพันธ์ของกระบวนการ การกระทำ และงานตลอดวงจรชีวิต แบบจำลองวงจรชีวิตขึ้นอยู่กับลักษณะเฉพาะ ขนาดและความซับซ้อนของโครงการ และเงื่อนไขเฉพาะที่ระบบถูกสร้างขึ้นและดำเนินการ
มาตรฐาน GOST R ISO/IEC 12207-2010 ไม่มีรูปแบบวงจรชีวิตเฉพาะ ข้อกำหนดนี้เป็นเรื่องปกติสำหรับแบบจำลองวงจรชีวิต วิธีการ และเทคโนโลยีสำหรับการสร้าง IP อธิบายโครงสร้างของกระบวนการวงจรชีวิตโดยไม่ระบุวิธีการดำเนินการหรือดำเนินกิจกรรมและงานที่รวมอยู่ในกระบวนการเหล่านี้
โมเดลวงจรชีวิตของซอฟต์แวร์ประกอบด้วย:
- ขั้นตอน;
- ผลงานในแต่ละขั้นตอน
- เหตุการณ์สำคัญ - จุดสำเร็จของงานและการตัดสินใจ
ในมาตรฐาน PS นี้ (หรือ ซอฟต์แวร์) ถูกกำหนดเป็น set โปรแกรมคอมพิวเตอร์, ขั้นตอนและเอกสารและข้อมูลที่เกี่ยวข้อง กระบวนการถูกกำหนดให้เป็นชุดของการกระทำที่สัมพันธ์กันซึ่งแปลงข้อมูลอินพุตบางส่วนให้เป็นข้อมูลเอาต์พุต (G. Myers เรียกการแปลข้อมูลนี้) แต่ละกระบวนการมีลักษณะงานและวิธีการบางอย่างในการแก้ปัญหา ในทางกลับกัน แต่ละกระบวนการจะถูกแบ่งออกเป็นชุดของการกระทำ และแต่ละการกระทำจะถูกแบ่งออกเป็นชุดของงาน แต่ละกระบวนการ การดำเนินการ หรืองานจะเริ่มต้นและดำเนินการโดยกระบวนการอื่นตามความจำเป็น และไม่มีลำดับการดำเนินการที่กำหนดไว้ล่วงหน้า (แน่นอน ในขณะที่ยังคงเชื่อมต่อข้อมูลอินพุตไว้)
ควรสังเกตว่าในสหภาพโซเวียตและในรัสเซียการสร้างซอฟต์แวร์ (SW) ในขั้นต้นในยุค 70 ของศตวรรษที่ผ่านมาถูกควบคุมโดยมาตรฐาน GOST ESPD ( ระบบครบวงจรเอกสารประกอบซอฟต์แวร์ - ชุดของ GOST 19.XXX) ซึ่งเน้นที่คลาสของโปรแกรมขนาดเล็กที่ค่อนข้างง่ายซึ่งสร้างโดยโปรแกรมเมอร์แต่ละคน ในปัจจุบัน มาตรฐานเหล่านี้ล้าสมัยตามแนวคิดและอยู่ในรูปแบบ ความถูกต้องหมดอายุและไม่แนะนำให้ใช้
กระบวนการสร้างระบบอัตโนมัติ (AS) ซึ่งรวมถึงซอฟต์แวร์ถูกควบคุมโดยมาตรฐาน GOST 34.601-90 "เทคโนโลยีสารสนเทศ ชุดมาตรฐานสำหรับระบบอัตโนมัติ ขั้นตอนการสร้าง", GOST 34.602-89 "เทคโนโลยีสารสนเทศ ชุด ของมาตรฐานระบบอัตโนมัติ งานด้านเทคนิคสำหรับการสร้างระบบอัตโนมัติ" และ GOST 34.603-92 "เทคโนโลยีสารสนเทศ ประเภทของการทดสอบระบบอัตโนมัติ" อย่างไรก็ตาม บทบัญญัติหลายประการของมาตรฐานเหล่านี้ล้าสมัย ในขณะที่ข้อกำหนดอื่นๆ ไม่ได้สะท้อนให้เห็นเพียงพอที่จะใช้สำหรับโครงการที่จริงจังสำหรับการสร้าง PS ดังนั้นจึงแนะนำให้ใช้มาตรฐานสากลที่ทันสมัยในการพัฒนาภายในประเทศ
ตาม มาตรฐาน ISO/ IEC 12207 กระบวนการวงจรชีวิตซอฟต์แวร์ทั้งหมดแบ่งออกเป็นสามกลุ่ม (รูปที่ 5.1)
ข้าว. 5.1.
มีการกำหนดกระบวนการหลักห้ากระบวนการในกลุ่ม: การได้มา การจัดหา การพัฒนา การดำเนินงาน และการบำรุงรักษา แปดกระบวนการย่อยช่วยให้มั่นใจถึงการดำเนินการของกระบวนการหลัก ได้แก่ เอกสาร, การจัดการการตั้งค่า, การประกันคุณภาพ, การทวนสอบ, การตรวจสอบ, การประเมินร่วมกัน, การตรวจสอบ, การแก้ไขปัญหา โฟร์ กระบวนการขององค์กรจัดให้มีการจัดการ โครงสร้างพื้นฐาน การปรับปรุง และการฝึกอบรม
5.2. กระบวนการหลักของวงจรชีวิตของ PS
กระบวนการได้มาประกอบด้วยกิจกรรมและงานของลูกค้าที่ซื้อซอฟต์แวร์ กระบวนการนี้ครอบคลุมกิจกรรมดังต่อไปนี้:
- การเริ่มต้นการเข้าซื้อกิจการ;
- การจัดทำข้อเสนอการสมัคร
- การเตรียมและการปรับสัญญา
- การกำกับดูแลกิจกรรมของซัพพลายเออร์
- การยอมรับและเสร็จสิ้นการทำงาน
การเริ่มต้นการจัดหารวมถึงงานต่อไปนี้:
- การกำหนดโดยลูกค้าเกี่ยวกับความต้องการของเขาในการได้มา การพัฒนาหรือปรับปรุงระบบ ผลิตภัณฑ์ซอฟต์แวร์หรือบริการ
- การตัดสินใจเกี่ยวกับการได้มา การพัฒนา หรือการปรับปรุงซอฟต์แวร์ที่มีอยู่
- เช็คห้องว่าง เอกสารที่จำเป็นการรับประกัน ใบรับรอง ใบอนุญาต และการสนับสนุนในกรณีซื้อผลิตภัณฑ์ซอฟต์แวร์
- การจัดเตรียมและการอนุมัติแผนการเข้าซื้อกิจการ รวมถึงข้อกำหนดของระบบ ประเภทของสัญญา ความรับผิดชอบของคู่สัญญา เป็นต้น
การเสนอราคาต้องมี:
- ความต้องการของระบบ;
- รายการผลิตภัณฑ์ซอฟต์แวร์
- เงื่อนไขการได้มาและข้อตกลง
- ข้อจำกัดทางเทคนิค (เช่น ในสภาพแวดล้อมการทำงานของระบบ)
การเสนอราคาจะถูกส่งไปยังซัพพลายเออร์ที่เลือกหรือซัพพลายเออร์หลายรายในกรณีที่มีการประกวดราคา ซัพพลายเออร์คือองค์กรที่ทำสัญญากับลูกค้าเพื่อจัดหาระบบ ซอฟต์แวร์ หรือบริการซอฟต์แวร์ตามเงื่อนไขที่ระบุไว้ในสัญญา
การเตรียมและการปรับสัญญารวมถึงงานต่อไปนี้:
- การกำหนดโดยลูกค้าเกี่ยวกับขั้นตอนการคัดเลือกซัพพลายเออร์ รวมถึงเกณฑ์การประเมินข้อเสนอของซัพพลายเออร์ที่เป็นไปได้
- การเลือกซัพพลายเออร์เฉพาะตามการวิเคราะห์ข้อเสนอ
- การเตรียมการและข้อสรุป สัญญาซัพพลายเออร์;
- ทำการเปลี่ยนแปลง (ถ้าจำเป็น) กับสัญญาในกระบวนการดำเนินการ
กิจกรรมของซัพพลายเออร์ได้รับการดูแลตามการดำเนินการที่กำหนดไว้ในกระบวนการประเมินและตรวจสอบร่วมกัน ในระหว่างขั้นตอนการยอมรับ การทดสอบที่จำเป็นจะถูกจัดเตรียมและดำเนินการ การทำงานให้เสร็จตามสัญญาจะดำเนินการในกรณีที่เป็นไปตามเงื่อนไขการยอมรับทั้งหมด
กระบวนการจัดส่งครอบคลุมกิจกรรมและงานที่ดำเนินการโดยผู้ขายที่จัดหาผลิตภัณฑ์หรือบริการซอฟต์แวร์ให้กับลูกค้า กระบวนการนี้รวมถึงขั้นตอนต่อไปนี้:
- การเริ่มต้นการส่งมอบ;
- การเตรียมการตอบสนองต่อการเสนอราคา
- การเตรียมสัญญา
- การวางแผนงานตามสัญญา
- ประสิทธิภาพและการควบคุมงานตามสัญญาและการประเมิน
- การส่งมอบและเสร็จสิ้นการทำงาน
การเริ่มต้นของการจัดหาประกอบด้วยการพิจารณาโดยซัพพลายเออร์ของข้อเสนอการประมูลและการตัดสินใจว่าจะเห็นด้วยกับข้อกำหนดและเงื่อนไขที่กำหนดไว้หรือเสนอของตนเอง (ตกลง) การวางแผนรวมถึงงานต่อไปนี้:
- การตัดสินใจโดยซัพพลายเออร์เกี่ยวกับการปฏิบัติงานด้วยตนเองหรือโดยการมีส่วนร่วมของผู้รับเหมาช่วง
- การพัฒนาโดยซัพพลายเออร์ของแผนการจัดการโครงการที่มี โครงสร้างองค์กรโครงการแบ่งความรับผิดชอบ ความต้องการทางด้านเทคนิคต่อสภาพแวดล้อมการพัฒนาและทรัพยากร การจัดการผู้รับเหมาช่วง ฯลฯ
กระบวนการพัฒนาจัดเตรียมกิจกรรมและงานที่ดำเนินการโดยนักพัฒนา และครอบคลุมงานในการสร้างซอฟต์แวร์และส่วนประกอบตามข้อกำหนดที่ระบุ ซึ่งรวมถึงการเตรียมเอกสารการออกแบบและการปฏิบัติงาน การเตรียมวัสดุที่จำเป็นสำหรับการทดสอบประสิทธิภาพ และ คุณภาพของผลิตภัณฑ์ซอฟต์แวร์, วัสดุที่จำเป็นสำหรับการจัดฝึกอบรมพนักงาน เป็นต้น
กระบวนการพัฒนาประกอบด้วยขั้นตอนต่อไปนี้:
- งานเตรียมการ
- การวิเคราะห์ข้อกำหนดของระบบ
- การออกแบบสถาปัตยกรรมระบบ
- การวิเคราะห์ข้อกำหนดสำหรับซอฟต์แวร์
- การออกแบบสถาปัตยกรรมซอฟต์แวร์
- การออกแบบซอฟต์แวร์โดยละเอียด
- การเข้ารหัสและการทดสอบซอฟต์แวร์
- การรวมซอฟต์แวร์
- การทดสอบคุณสมบัติซอฟต์แวร์
- ระบบบูรณาการ;
- การทดสอบคุณสมบัติของระบบ
- การติดตั้งซอฟต์แวร์
- การยอมรับซอฟต์แวร์
งานเตรียมการเริ่มต้นด้วยการเลือกแบบจำลองวงจรชีวิตของซอฟต์แวร์ที่เหมาะสมกับขนาด ความสำคัญ และความซับซ้อนของโครงการ กิจกรรมและงานของกระบวนการพัฒนาควรสอดคล้องกับรูปแบบที่เลือก ผู้พัฒนาต้องเลือก ปรับให้เข้ากับเงื่อนไขของโครงการ และใช้มาตรฐาน วิธีการ และวิธีการที่ตกลงกับลูกค้า เครื่องมือพัฒนาพร้อมทั้งจัดทำแผนการทำงาน
การวิเคราะห์ข้อกำหนดสำหรับระบบเกี่ยวข้องกับการกำหนดฟังก์ชันการทำงาน ข้อกำหนดที่กำหนดเอง, ข้อกำหนดสำหรับความน่าเชื่อถือ ความปลอดภัย ข้อกำหนดสำหรับอินเทอร์เฟซภายนอก ประสิทธิภาพ ฯลฯ ความต้องการของระบบจะได้รับการประเมินตามเกณฑ์ความเป็นไปได้และตรวจสอบได้ในระหว่างการทดสอบ
การออกแบบสถาปัตยกรรมระบบประกอบด้วยการกำหนดส่วนประกอบของอุปกรณ์ (ฮาร์ดแวร์) ซอฟต์แวร์และการดำเนินการที่ดำเนินการโดยบุคลากรที่ใช้ระบบ สถาปัตยกรรมของระบบต้องเป็นไปตามข้อกำหนดของระบบรวมทั้งได้รับการยอมรับ มาตรฐานการออกแบบและวิธีการ
การวิเคราะห์ข้อกำหนดของซอฟต์แวร์เกี่ยวข้องกับการกำหนดคุณลักษณะต่อไปนี้สำหรับส่วนประกอบซอฟต์แวร์แต่ละรายการ:
- ฟังก์ชันการทำงาน รวมถึงคุณลักษณะด้านประสิทธิภาพและสภาพแวดล้อมการทำงานของส่วนประกอบ
- อินเทอร์เฟซภายนอก
- ข้อกำหนดด้านความน่าเชื่อถือและความปลอดภัย
- ข้อกำหนดตามหลักสรีรศาสตร์
- ข้อกำหนดสำหรับข้อมูลที่ใช้
- ข้อกำหนดในการติดตั้งและการยอมรับ
- ข้อกำหนดสำหรับเอกสารผู้ใช้
- ข้อกำหนดสำหรับการดำเนินงานและการบำรุงรักษา
ข้อกำหนดของซอฟต์แวร์จะได้รับการประเมินตามเกณฑ์สำหรับการปฏิบัติตามข้อกำหนดสำหรับระบบโดยรวม ความเป็นไปได้ และการตรวจสอบระหว่างการทดสอบ
การออกแบบสถาปัตยกรรมซอฟต์แวร์ประกอบด้วยงานต่อไปนี้สำหรับส่วนประกอบซอฟต์แวร์แต่ละรายการ:
- การเปลี่ยนแปลงข้อกำหนดของซอฟต์แวร์เป็นสถาปัตยกรรมที่กำหนดโครงสร้างของซอฟต์แวร์และองค์ประกอบของส่วนประกอบในระดับสูง
- การพัฒนาและจัดทำเอกสารอินเทอร์เฟซของโปรแกรมสำหรับซอฟต์แวร์และฐานข้อมูล (DB)
- การพัฒนาเอกสารผู้ใช้เวอร์ชันเบื้องต้น
- การพัฒนาและจัดทำเอกสารข้อกำหนดเบื้องต้นสำหรับการทดสอบและแผนบูรณาการซอฟต์แวร์
การออกแบบซอฟต์แวร์โดยละเอียดประกอบด้วยงานต่อไปนี้:
- คำอธิบายของส่วนประกอบซอฟต์แวร์และส่วนต่อประสานระหว่างกันในระดับที่ต่ำกว่า ซึ่งเพียงพอสำหรับการเข้ารหัสและการทดสอบในภายหลัง
- การพัฒนาและเอกสาร ออกแบบรายละเอียดฐานข้อมูล;
- อัปเดตเอกสารผู้ใช้ (ถ้าจำเป็น)
- การพัฒนาและจัดทำเอกสารข้อกำหนดการทดสอบและแผนการทดสอบส่วนประกอบซอฟต์แวร์
การเข้ารหัสและการทดสอบซอฟต์แวร์ประกอบด้วยงานต่อไปนี้:
- การเข้ารหัสและการจัดทำเอกสารแต่ละองค์ประกอบของซอฟต์แวร์และฐานข้อมูล ตลอดจนการเตรียมชุดขั้นตอนการทดสอบและข้อมูลสำหรับการทดสอบ
- ทดสอบแต่ละองค์ประกอบของซอฟต์แวร์และฐานข้อมูลเพื่อให้เป็นไปตามข้อกำหนด ตามด้วยเอกสารประกอบของผลการทดสอบ
- อัปเดตเอกสาร (ถ้าจำเป็น)
- อัปเดตแผนการรวมซอฟต์แวร์
การรวมซอฟต์แวร์เกี่ยวข้องกับการประกอบส่วนประกอบซอฟต์แวร์ที่พัฒนาแล้วตามแผนการรวมและการทดสอบสำหรับส่วนประกอบที่รวมกัน สำหรับแต่ละองค์ประกอบที่รวมกัน ชุดทดสอบและขั้นตอนการทดสอบได้รับการพัฒนาเพื่อทดสอบสมรรถนะแต่ละรายการในการทดสอบความชำนาญในภายหลัง ข้อกำหนดคุณสมบัติเป็นชุดของเกณฑ์หรือเงื่อนไขที่ต้องปฏิบัติตามจึงจะมีคุณสมบัติ ซอฟต์แวร์ตรงตามข้อกำหนดและพร้อมใช้งานในภาคสนาม
การทดสอบคุณสมบัติของซอฟต์แวร์ดำเนินการโดยนักพัฒนาต่อหน้าลูกค้า (
กระบวนการดำเนินการครอบคลุมกิจกรรมและงานขององค์กรของผู้ปฏิบัติงานที่ใช้ระบบ กระบวนการดำเนินการประกอบด้วยขั้นตอนต่อไปนี้
งานเตรียมการซึ่งรวมถึงงานต่อไปนี้โดยผู้ปฏิบัติงาน:
- กิจกรรมการวางแผนและงานที่ดำเนินการระหว่างการปฏิบัติงาน และการกำหนดมาตรฐานการปฏิบัติงาน
- การกำหนดขั้นตอนสำหรับการแปลเป็นภาษาท้องถิ่นและการแก้ไขปัญหาที่เกิดขึ้นระหว่างการดำเนินการ
- ดำเนินการทดสอบการทำงานสำหรับผลิตภัณฑ์ซอฟต์แวร์รุ่นถัดไปแต่ละรุ่น หลังจากนั้นจึงโอนรุ่นนี้ไปยังการทำงาน
- การทำงานจริงของระบบ ซึ่งดำเนินการในสภาพแวดล้อมที่มีไว้สำหรับสิ่งนี้ตามเอกสารสำหรับผู้ใช้
- การวิเคราะห์ปัญหาและคำขอแก้ไขซอฟต์แวร์ (การวิเคราะห์ข้อความเกี่ยวกับปัญหาที่เกิดขึ้นหรือคำขอแก้ไข การประเมินขนาด ต้นทุนในการแก้ไข ผลกระทบที่ตามมา การประเมินความเป็นไปได้ในการแก้ไข)
- การดัดแปลงซอฟต์แวร์ (การเปลี่ยนแปลงส่วนประกอบและเอกสารของผลิตภัณฑ์ซอฟต์แวร์ตามกฎของกระบวนการพัฒนา)
- การตรวจสอบและการยอมรับ (ในแง่ของความสมบูรณ์ของระบบที่กำลังแก้ไข)
- การถ่ายโอนซอฟต์แวร์ไปยังสภาพแวดล้อมอื่น (การแปลงโปรแกรมและข้อมูล การทำงานคู่ขนานของซอฟต์แวร์ในสภาพแวดล้อมเก่าและใหม่ในช่วงเวลาหนึ่ง)
- การเลิกใช้งานซอฟต์แวร์โดยการตัดสินใจของลูกค้าโดยมีส่วนร่วมขององค์กรปฏิบัติการ บริการบำรุงรักษา และผู้ใช้ ในเวลาเดียวกัน ผลิตภัณฑ์ซอฟต์แวร์และเอกสารประกอบอาจมีการเก็บถาวรตามสัญญา
