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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ฉัน. การวิเคราะห์ระบบ:

ก) การวิจัย;

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

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

ทางเศรษฐกิจ;

ทางการค้า.

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

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

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

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

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

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

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

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

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

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

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

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

เค้าโครงโปรแกรม

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

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

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

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

b) คลอ

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

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

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

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

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

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

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

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

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

- ความเป็นไปได้ทางการค้า สินค้าจะน่าสนใจ เป็นที่ต้องการ ติดตั้งง่าย ดูแลรักษาง่าย เรียนรู้ง่ายหรือไม่?

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

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

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

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

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

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

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

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

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

ในช่วงอายุของซอฟต์แวร์นี้ จะมีการดำเนินการดังต่อไปนี้:

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

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

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

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

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

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

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

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

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

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

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

มันคงอยู่ตราบเท่าที่การเขียนโปรแกรม

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

มาตรฐาน GOST 34.601-90

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

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

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

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

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

มาตรฐาน ISO/IEC 12207:1995 “เทคโนโลยีสารสนเทศ - กระบวนการวงจรชีวิตของซอฟต์แวร์” เป็นมาตรฐานหลัก เอกสารเชิงบรรทัดฐานควบคุมองค์ประกอบของกระบวนการวงจรชีวิตของซอฟต์แวร์ โดยกำหนดโครงสร้างวงจรชีวิตซึ่งประกอบด้วยกระบวนการ กิจกรรม และงานที่ต้องทำให้เสร็จสิ้นระหว่างการสร้างซอฟต์แวร์

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

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

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

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

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);

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

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

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

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

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

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

โมเดลน้ำตก

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

ด้านบวกของการใช้วิธีการแบบเรียงซ้อนมีดังนี้:

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

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

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

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

ข้าว. 1. โครงการพัฒนาน้ำตก

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

ข้าว. 2. กระบวนการพัฒนาซอฟต์แวร์จริงโดยใช้รูปแบบน้ำตก

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

รุ่นเกลียว

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

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

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

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

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

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

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

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

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

• ตารางการผลิตสั้น แต่จัดทำอย่างรอบคอบ (ตั้งแต่ 2 ถึง 6 เดือน)

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

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

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

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

• ระยะการดำเนินการ;

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

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

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

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

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

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

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

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

โมเดลน้ำตก

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

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

วงจรชีวิตแบ่งตามประเพณีออกเป็นวงจรหลักดังต่อไปนี้ขั้นตอน:

1. การวิเคราะห์ความต้องการ,
2. ออกแบบ,
3. การเข้ารหัส (การเขียนโปรแกรม)
4. การทดสอบและการดีบัก
5. การดำเนินงานและการบำรุงรักษา

ข้อดีของรุ่นนี้:

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

ข้อเสียของรุ่นนี้:

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

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

ขอบเขตการใช้งานของโมเดล Cascade

ข้อจำกัดของขอบเขตการใช้งานแบบจำลองคาสเคดนั้นพิจารณาจากข้อบกพร่อง การใช้งานจะมีประสิทธิภาพสูงสุดในกรณีต่อไปนี้:

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

รูปแบบที่เพิ่มขึ้น

(รุ่นทีละขั้นตอนพร้อมการควบคุมระดับกลาง)

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

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

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

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

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

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

ข้อดี:

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

ข้อเสียของรุ่นนี้:

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

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

รุ่นเกลียว

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

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

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

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

ข้อดีของรุ่นนี้:

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

ข้อเสียของรุ่นนี้:

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

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

ขอบเขตการใช้งานของรุ่นเกลียว

แนะนำให้ใช้รุ่นเกลียวในกรณีต่อไปนี้:

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

คำอธิบายประกอบ

การแนะนำ.

1. วงจรชีวิตของซอฟต์แวร์

การแนะนำ.

ขั้นตอนกระบวนการเขียนโปรแกรมไรลีย์

การแนะนำ.

1.1.1. คำชี้แจงของปัญหา

1.1.2. การออกแบบโซลูชัน

1.1.3. การเข้ารหัสอัลกอริทึม

1.1.4. การสนับสนุนโปรแกรม

1.1.5. เอกสารประกอบซอฟต์แวร์

บทสรุปของข้อ 1.1

1.2. คำจำกัดความของ LCPO ตาม 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.W. "วิศวกรรมซอฟต์แวร์" ของ Boehm ที่เราเคยเขียนเรื่องนี้ งานหลักสูตร- ในหนังสือเล่มนี้ การออกแบบซอฟต์แวร์หมายถึงกระบวนการสร้างการออกแบบผลิตภัณฑ์ซอฟต์แวร์

1 วงจรชีวิตของซอฟต์แวร์

การแนะนำ

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

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

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

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

และเพื่อความหลากหลาย เรานำเสนอขั้นตอนของกระบวนการเขียนโปรแกรมที่นำเสนอโดย D. Riley ในหนังสือ “การใช้ภาษา Modula-2” ในความคิดของฉัน แนวคิดนี้เรียบง่ายและคุ้นเคยมาก เรามาเริ่มกันเลยดีกว่า

1.1 ขั้นตอนในกระบวนการเขียนโปรแกรม Riley

กระบวนการเขียนโปรแกรมประกอบด้วยสี่ขั้นตอน (รูปที่ 1):

คำแถลงปัญหาเช่น การได้รับความเข้าใจอย่างเพียงพอว่างานใดที่โปรแกรมควรปฏิบัติ

การออกแบบวิธีแก้ปัญหาสำหรับปัญหาที่ระบุไว้แล้ว (โดยทั่วไป วิธีแก้ปัญหาดังกล่าวเป็นทางการน้อยกว่าโปรแกรมขั้นสุดท้าย)

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

การสนับสนุนโปรแกรมเช่น กระบวนการแก้ไขปัญหาโปรแกรมและเพิ่มคุณสมบัติใหม่อย่างต่อเนื่อง

ข้าว. 1.สี่ขั้นตอนการเขียนโปรแกรม

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

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

1.1.1 คำชี้แจงปัญหา

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

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

ลักษณะของคำชี้แจงปัญหาที่ดี:

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

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

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

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

รูปแบบมาตรฐานของคำชี้แจงปัญหา

พิจารณาข้อความแจ้งปัญหาต่อไปนี้: “ป้อนตัวเลขสามตัวแล้วส่งออกตัวเลขตามลำดับ”

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

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

ชื่อของงาน (คำจำกัดความของแผนผัง);

คำอธิบายทั่วไป(คำชี้แจงสั้น ๆ ของปัญหา);

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

ตัวอย่าง ( ตัวอย่างที่ดีสามารถถ่ายทอดแก่นแท้ของปัญหาพร้อมทั้งยกตัวอย่างกรณีต่างๆ ได้)

ตัวอย่าง. คำชี้แจงปัญหาในรูปแบบมาตรฐาน

ชื่อ

การเรียงลำดับจำนวนเต็มสามตัว

คำอธิบาย

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

ป้อนจำนวนเต็มสามจำนวน หนึ่งตัวเลขต่อบรรทัด จำนวนเต็มคือเลขฐานสิบติดกันตั้งแต่หนึ่งหลักขึ้นไป ซึ่งอาจนำหน้าด้วยเครื่องหมายบวก “+” หรือเครื่องหมายลบ “–”

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

1) หากป้อนตัวเลขน้อยกว่าสามตัว โปรแกรมจะรออินพุตเพิ่มเติม

วงจรชีวิตของซอฟต์แวร์ ขั้นตอนและเหตุการณ์สำคัญ

วงจรชีวิตของ IS คือชุดของเหตุการณ์ที่เกิดขึ้นกับระบบในระหว่างกระบวนการสร้างและใช้งาน

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

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

ตามเนื้อผ้า ขั้นตอนหลักของวงจรชีวิตซอฟต์แวร์มีดังนี้:

การวิเคราะห์ความต้องการ

ออกแบบ,

การเข้ารหัส (การเขียนโปรแกรม)

การทดสอบและการดีบัก

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

วงจรชีวิตของซอฟต์แวร์ โมเดลน้ำตก

แบบจำลองน้ำตก (70-80 ปี) data เกี่ยวข้องกับการย้ายไปยังขั้นต่อไปหลังจากเสร็จสิ้นงานในระยะก่อนหน้า

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

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

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

แบบจำลองทีละขั้นตอนพร้อมการควบคุมระดับกลาง (80-85) µ แบบจำลองการพัฒนาซอฟต์แวร์ซ้ำพร้อมลูปป้อนกลับระหว่างขั้นตอน ข้อดีของแบบจำลองนี้คือการปรับระหว่างขั้นตอนทำให้มีความเข้มของแรงงานน้อยลงเมื่อเปรียบเทียบกับแบบจำลองแบบเรียงซ้อน อย่างไรก็ตามอายุการใช้งานของแต่ละขั้นตอนจะขยายออกไปตลอดระยะเวลาการพัฒนาทั้งหมด

ขั้นตอนหลักของการแก้ปัญหา

วัตถุประสงค์ของการเขียนโปรแกรมคือการอธิบายกระบวนการประมวลผลข้อมูล (ต่อไปนี้เรียกว่ากระบวนการ)

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

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

ชุดของตัวพาข้อมูลที่ใช้สำหรับการประมวลผลข้อมูลเรียกว่าสื่อข้อมูล

ชุดข้อมูลที่มีอยู่ในสภาพแวดล้อมข้อมูล - สถานะ สภาพแวดล้อมข้อมูล.

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

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

เกณฑ์คุณภาพซอฟต์แวร์

ผลิตภัณฑ์เชิงพาณิชย์ (ผลิตภัณฑ์ บริการ) จะต้องเป็นไปตามความต้องการของผู้บริโภค

คุณภาพเป็นลักษณะวัตถุประสงค์ของผลิตภัณฑ์ (ผลิตภัณฑ์ บริการ) ซึ่งแสดงถึงระดับความพึงพอใจของผู้บริโภค

ลักษณะคุณภาพ:

› ผลงาน– ระบบทำงานและใช้ฟังก์ชันที่จำเป็น

› ความน่าเชื่อถือ– ระบบทำงานโดยไม่มีความล้มเหลวหรือความล้มเหลว

› ความสามารถในการกู้คืน.

› ประสิทธิภาพ– ระบบใช้งานฟังก์ชั่นต่างๆ อย่างเหมาะสมที่สุด

› ประสิทธิภาพทางเศรษฐกิจ – ต้นทุนขั้นต่ำของผลิตภัณฑ์ขั้นสุดท้ายพร้อมกำไรสูงสุด

ลักษณะคุณภาพ:

› โดยคำนึงถึงปัจจัยความเป็นมนุษย์- ใช้งานง่าย ความเร็วในการเรียนรู้การทำงานกับซอฟต์แวร์ ความง่ายในการบำรุงรักษา การเปลี่ยนแปลง

› การพกพา(ความคล่องตัว) – การเคลื่อนย้ายโค้ดไปยังแพลตฟอร์มหรือระบบอื่น

› ความสมบูรณ์ของฟังก์ชั่น– บางทีการใช้งานฟังก์ชั่นภายนอกที่สมบูรณ์ที่สุด

› ความแม่นยำในการคำนวณ

คุณสมบัติของอัลกอริทึม

ประสิทธิภาพ หมายถึงความเป็นไปได้ที่จะได้รับผลลัพธ์หลังจากดำเนินการตามจำนวนที่จำกัด

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

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

ความรอบคอบ - ความเป็นไปได้ในการแบ่งกระบวนการคำนวณที่กำหนดโดยอัลกอริธึมออกเป็นขั้นตอนแยกกันความเป็นไปได้ในการเลือกส่วนของโปรแกรมด้วยโครงสร้างบางอย่าง

วิธีอธิบายอัลกอริทึม

มีวิธีอธิบายอัลกอริทึม (ปัจจุบัน) ดังต่อไปนี้:

1. คำอธิบายด้วยวาจา

2. คำอธิบายของอัลกอริทึมโดยใช้สูตรทางคณิตศาสตร์

3. คำอธิบายกราฟิกของอัลกอริทึมในรูปแบบของบล็อกไดอะแกรม

4. คำอธิบายของอัลกอริทึมโดยใช้รหัสเทียม

5. วิธีการรวมกันรูปภาพของอัลกอริทึมโดยใช้วาจา กราฟิก และวิธีการอื่น ๆ .

6.ใช้ตาข่ายเพาะเชื้อ

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

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

ผังงานอัลกอริทึมคือการแสดงภาพกราฟิกของวิธีการแก้ไขปัญหาที่ใช้สัญลักษณ์พิเศษเพื่อแสดงการดำเนินการ

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

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

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

รูปที่ 1 - ตัวอย่างคำอธิบายของอัลกอริทึมในรูปแบบของบล็อกไดอะแกรม

คำอธิบายของอัลกอริทึมเดียวกันในรหัสเทียม:

2. ใส่ตัวเลข: Z, X

3. ถ้า Z > X แล้วเอาต์พุต Z

4. มิฉะนั้นเอาต์พุต X

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

ประเภทของอัลกอริทึม

เชิงเส้น;

การแตกแขนง;

วัฏจักร

· อัลกอริธึมเชิงเส้น- ชุดคำสั่ง (คำสั่ง) ที่ดำเนินการตามลำดับ

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

· อัลกอริธึมแบบ Round-Robin- อัลกอริธึมที่เกี่ยวข้องกับการกระทำเดียวกันซ้ำ ๆ (การดำเนินการเดียวกัน) กับข้อมูลเริ่มต้นใหม่ วิธีการคำนวณและการแจกแจงตัวเลือกส่วนใหญ่จะลดลงเป็นอัลกอริธึมแบบวนรอบ วงจรโปรแกรม - ลำดับของคำสั่ง (ชุดข้อมูล, เนื้อความของลูป) ที่สามารถดำเนินการซ้ำๆ ได้ (สำหรับแหล่งข้อมูลใหม่) จนกว่าจะตรงตามเงื่อนไขที่กำหนด

ค. ประเภทข้อมูล

ประเภทข้อมูลคือคำอธิบายช่วงของค่าที่ตัวแปรประเภทที่ระบุสามารถรับได้ ข้อมูลแต่ละประเภทมีลักษณะดังนี้:
   1. จำนวนไบต์ที่ถูกครอบครอง (ขนาด)
   2. ช่วงของค่าที่ตัวแปรประเภทนี้สามารถรับได้

ประเภทข้อมูลทั้งหมดสามารถแบ่งออกเป็นประเภทต่อไปนี้:
   1. ประเภทง่าย (สเกลาร์) และซับซ้อน (เวกเตอร์)
   2. พื้นฐาน (ระบบ) และผู้ใช้ (กำหนดโดยผู้ใช้)
  ในภาษา SI ระบบประเภทพื้นฐานประกอบด้วยข้อมูลสี่ประเภท:
   1. สัญลักษณ์
   2. จำนวนเต็ม
   3. ความแม่นยำเดียวจริง
   4. ความแม่นยำสองเท่าของจริง

โครงสร้างของโปรแกรมภาษาซี

1. ตัวดำเนินการภาษา C++

ผู้ปฏิบัติงานควบคุมกระบวนการรันโปรแกรม ชุดตัวดำเนินการภาษา C++ ประกอบด้วยโครงสร้างการควบคุมทั้งหมดของการเขียนโปรแกรมแบบมีโครงสร้าง
คำสั่งผสมคั่นด้วยเครื่องหมายปีกกา ข้อความอื่นๆ ทั้งหมดจะลงท้ายด้วยเครื่องหมายอัฒภาค
ตัวดำเนินการว่างเปล่า – ;
คำสั่งว่างคือคำสั่งที่ประกอบด้วยเครื่องหมายอัฒภาคเท่านั้น มันสามารถปรากฏได้ทุกที่ในโปรแกรมที่ไวยากรณ์จำเป็นต้องมีคำสั่ง การดำเนินการคำสั่งว่างจะไม่เปลี่ยนสถานะของโปรแกรม
ตัวดำเนินการแบบผสม – (...)
ผลกระทบของคำสั่งผสมคือการรันคำสั่งที่ประกอบด้วยตามลำดับ เว้นแต่คำสั่งจะถ่ายโอนการควบคุมไปยังตำแหน่งอื่นในโปรแกรมอย่างชัดเจน
คำชี้แจงการจัดการข้อยกเว้น

พยายาม (<операторы> }
จับ (<объявление исключения>) { <операторы> }
จับ (<объявление исключения>) { <операторы> }
...
จับ (<объявление исключения>) { <операторы> }

ตัวดำเนินการแบบมีเงื่อนไข

ถ้า (<выражение>) <оператор 1>

ตัวดำเนินการสวิตช์

สวิตช์ (<выражение>)
( กรณี<константное выражение 1>: <операторы 1>
กรณี<константное выражение 2>: <операторы 2>
...
กรณี<константное выражение N>: <операторы N>
}
คำสั่ง switch ใช้เพื่อเลือกหนึ่งในหลายพาธสำหรับการทำงานของโปรแกรม การประเมินคำสั่ง switch เริ่มต้นด้วยการประเมินนิพจน์ หลังจากนั้นการควบคุมจะถูกโอนไปยังคำสั่งที่ทำเครื่องหมายด้วยนิพจน์คงที่เท่ากับค่าที่ประเมินของนิพจน์ การออกจากคำสั่ง switch จะดำเนินการโดยคำสั่ง break หากค่าของนิพจน์ไม่เท่ากับนิพจน์คงที่ใดๆ การควบคุมจะถูกโอนไปยังคำสั่งที่ทำเครื่องหมายด้วยคำสำคัญเริ่มต้น ถ้ามี
ตัวดำเนินการวนซ้ำพร้อมเงื่อนไขเบื้องต้น

ในขณะที่ (<выражение>) <оператор>

ตัวดำเนินการวนซ้ำพร้อมเงื่อนไขภายหลัง

ทำ<оператор>ในขณะที่<выражение>;
ในภาษา C++ โอเปอเรเตอร์นี้แตกต่างจากการใช้งานลูปแบบคลาสสิกโดยมีเงื่อนไขภายหลังตรงที่ว่าหากนิพจน์เป็นจริง การวนซ้ำจะดำเนินต่อไป แทนที่จะออกจากการวนซ้ำ
ตัวดำเนินการวนขั้นตอน

สำหรับ ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
เนื้อความของคำสั่ง for จะถูกดำเนินการจนกว่านิพจน์เงื่อนไขจะกลายเป็นเท็จ (เท่ากับ 0) โดยทั่วไปนิพจน์เริ่มต้นและนิพจน์ส่วนเพิ่มจะใช้ในการเริ่มต้นและแก้ไขพารามิเตอร์ลูปและค่าอื่นๆ นิพจน์เริ่มต้นจะได้รับการประเมินหนึ่งครั้งก่อนที่จะทดสอบนิพจน์แบบมีเงื่อนไขเป็นครั้งแรก และนิพจน์ส่วนเพิ่มจะได้รับการประเมินหลังจากการดำเนินการคำสั่งแต่ละครั้ง คุณสามารถละเว้นนิพจน์ส่วนหัวของลูปทั้งสามรายการ และแม้แต่ทั้งสามรายการได้ (อย่าลืมเว้นเครื่องหมายอัฒภาค) หากละเว้นนิพจน์เงื่อนไข จะถือว่าเป็นจริงและการวนซ้ำจะไม่มีที่สิ้นสุด
ตัวดำเนินการลูปทีละขั้นตอนในภาษา C++ เป็นโครงสร้างที่ยืดหยุ่นและสะดวกสบาย ดังนั้นตัวดำเนินการลูปที่มีเงื่อนไขเบื้องต้นในขณะที่ไม่ค่อยได้ใช้ในภาษา C++ เนื่องจาก ในกรณีส่วนใหญ่จะสะดวกกว่าในการใช้ตัวดำเนินการ for
ตัวดำเนินการหยุด

หยุดพัก;
ตัวดำเนินการแบ่งขัดจังหวะการดำเนินการคำสั่ง while, do, for และ switch สามารถอยู่ในเนื้อหาของข้อความเหล่านี้เท่านั้น การควบคุมจะถูกถ่ายโอนไปยังผู้ปฏิบัติงานโปรแกรมตามการขัดจังหวะ หากคำสั่งแบ่งถูกเขียนภายในคำสั่งที่ซ้อนกัน ในขณะที่, ทำ, เพื่อ, สลับ คำสั่งนั้นจะยุติเฉพาะคำสั่งที่ล้อมรอบคำสั่งนั้นทันที
ตัวดำเนินการต่อเนื่อง

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

กลับ [<выражение>];
คำสั่ง return จะสิ้นสุดการทำงานของฟังก์ชันที่มีอยู่และส่งกลับการควบคุมไปยังฟังก์ชันที่เรียก การควบคุมจะถูกถ่ายโอนไปยังจุดที่เรียกใช้ฟังก์ชัน

ถ้า (นิพจน์บูลีน)

ผู้ประกอบการ;

ถ้า (นิพจน์บูลีน)

ตัวดำเนินการ_1;

ตัวดำเนินการ_2;

<логическое выражение> ? <выражение_1> : <выражение_2>;

หากค่าของนิพจน์เชิงตรรกะเป็นจริง ดังนั้น expression_1 จะถูกประเมิน มิฉะนั้น expression_2 จะถูกประเมิน

สวิตช์ (นิพจน์จำนวนเต็ม)

กรณีค่า_1:

คำสั่ง_ลำดับ_1;

กรณีค่า_2:

คำสั่ง_ลำดับ_2;

กรณีมูลค่า_n:

คำสั่ง_ลำดับ_n;

ค่าเริ่มต้น:

ตัวดำเนินการ_ลำดับ_n+1;

สาขา ค่าเริ่มต้น ไม่สามารถอธิบายได้ จะถูกดำเนินการหากไม่มีนิพจน์ที่สูงกว่าใดที่ตรงตามความต้องการ

ตัวดำเนินการวนซ้ำ

Turbo C มีโครงสร้างต่อไปนี้ที่ช่วยให้คุณสามารถตั้งโปรแกรมรอบการทำงานได้: ในขณะที่ทำในขณะที่ และ สำหรับ - สามารถอธิบายโครงสร้างของพวกมันได้ ดังต่อไปนี้:

วนตรวจสอบสภาพที่ด้านบน:

โอเปอเรเตอร์การเลือก

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

สวิตช์ (ตัวแปร)
{
มูลค่ากรณีที่ 1:
การกระทำ1
หยุดพัก;

ค่ากรณีที่ 2:
การกระทำ2
หยุดพัก;
...

ค่าเริ่มต้น:
การกระทำเริ่มต้น
}

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

สวิตช์ (ตัวแปร)
{
มูลค่ากรณีที่ 1:
ค่ากรณีที่ 2:
การกระทำ1
หยุดพัก;

มูลค่ากรณีที่ 3:
การกระทำ2
หยุดพัก;
...
}

ตัวอย่างการใช้การเลือก:

int n, x;
...
สวิตช์(n)
{
กรณีที่ 0:
หยุดพัก; //ถ้า n เป็น 0 เราจะไม่ดำเนินการใดๆ

กรณีที่ 1:
กรณีที่ 2:
กรณีที่ 3:
x = 3 * น; //ถ้า n คือ 1, 2 หรือ 3 ให้ดำเนินการบางอย่าง
หยุดพัก;

กรณีที่ 4:
x = n; //ถ้า n เป็น 4 ให้ดำเนินการอื่นๆ
หยุดพัก;

ค่าเริ่มต้น:
x = 0; //สำหรับค่าอื่น ๆ ทั้งหมดของ n ให้ดำเนินการตามค่าเริ่มต้น
}

C.Cycle: วนซ้ำพร้อมพารามิเตอร์

แบบฟอร์มทั่วไปบันทึก

สำหรับ (การกำหนดค่าเริ่มต้นพารามิเตอร์ การตรวจสอบเงื่อนไขสิ้นสุด การแก้ไขพารามิเตอร์) (

บล็อกการดำเนินงาน

สำหรับ - ลูปพาราเมตริก (วนซ้ำด้วยจำนวนซ้ำคงที่) เพื่อจัดระเบียบวงจรดังกล่าว จะต้องดำเนินการสามประการ:

§ การเริ่มต้นพารามิเตอร์- การกำหนดค่าเริ่มต้นให้กับพารามิเตอร์รอบ

§ ตรวจสอบสภาพปลาย- การเปรียบเทียบค่าพารามิเตอร์กับค่าขอบเขตที่แน่นอน

§ การแก้ไขพารามิเตอร์- การเปลี่ยนค่าพารามิเตอร์ทุกครั้งที่ส่งผ่านเนื้อหาลูป

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

ตัวอย่าง

#รวม
int หลัก() (

สำหรับ(num = 1; num< 5; num++)

printf("num = %d\n",num);

ศรี. วนซ้ำโดยมีเงื่อนไขเบื้องต้น

แบบฟอร์มบันทึกทั่วไป

ในขณะที่(การแสดงออก) (

บล็อกการดำเนินงาน
}

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

ตัวอย่าง

อินท์ k=5;
อินท์ i=1;
ผลรวมเต็ม=0;
ในขณะที่(i<=k) {

เมื่อสร้าง while loop จำเป็นต้องรวมโครงสร้างที่เปลี่ยนค่าของนิพจน์ที่กำลังทดสอบ เพื่อให้กลายเป็นเท็จในที่สุด (เท่ากับศูนย์) มิฉะนั้น การวนซ้ำจะทำงานอย่างไม่มีที่สิ้นสุด (การวนซ้ำไม่สิ้นสุด) เป็นต้น

บล็อกการดำเนินงาน
}

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

ศรี. วนซ้ำกับเงื่อนไขภายหลัง

วนซ้ำด้วย do... while postcondition

แบบฟอร์มบันทึกทั่วไป

บล็อกการดำเนินงาน

) ในขณะที่(การแสดงออก);

วนซ้ำกับเงื่อนไขภายหลัง

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

ควรใช้การวนซ้ำ do... While ในกรณีที่ต้องวนซ้ำอย่างน้อยหนึ่งครั้ง หรือเมื่อการเริ่มต้นของอ็อบเจ็กต์ที่เกี่ยวข้องกับการตรวจสอบเงื่อนไขเกิดขึ้นภายในเนื้อความของลูป

ตัวอย่าง- ป้อนตัวเลขตั้งแต่ 0 ถึง 10

#รวม
#รวม
int หลัก() (

ระบบ("chcp 1251");

printf("กรอกตัวเลขตั้งแต่ 0 ถึง 10: ");

scanf("%d", &num);

) ในขณะที่((หมายเลข< 0) || (num > 10));

printf("คุณกรอกหมายเลข %d", num);

รับชาร์(); รับชาร์();

การกำหนดฟังก์ชัน

ลองดูคำจำกัดความของฟังก์ชันโดยใช้ฟังก์ชัน sum เป็นตัวอย่าง

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

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