วงจรชีวิตของแอปพลิเคชัน วงจรชีวิตของโปรแกรม

วงจรชีวิตของโปรแกรม

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

ระยะของวงจรชีวิต:

2. การออกแบบ

3. การนำไปปฏิบัติ

4. การประกอบ การทดสอบ การทดสอบ

5. การนำไปปฏิบัติ (ปล่อย)

6. เพื่อนเที่ยว

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

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

ออกแบบ

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

การนำไปปฏิบัติ

การเขียนโค้ดโปรแกรม. การนำไปปฏิบัติรวมถึงการพัฒนา การทดสอบ และเอกสารประกอบ

การประกอบ การทดสอบ การทดสอบ

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

การนำไปปฏิบัติ (เผยแพร่)

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

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

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

คุ้มกัน

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

แบบจำลองวงจรชีวิต

1. น้ำตก (“น้ำตก” แบบจำลองน้ำตก)

2. การสร้างต้นแบบ

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

3. รูปแบบการวนซ้ำ

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

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

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

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

1. แนวทางวิศวกรรม
2. โดยคำนึงถึงลักษณะเฉพาะของงาน
3. เทคโนโลยีสมัยใหม่ที่มีการพัฒนาอย่างรวดเร็ว

ตอนนี้เรามาดูโมเดลที่มีอยู่ (คลาสย่อย) และประเมินข้อดีและข้อเสีย

การเข้ารหัสข้อผิดพลาดและแบบจำลองการกำจัด

โมเดลที่เรียบง่ายสมบูรณ์แบบสำหรับนักศึกษามหาวิทยาลัย เป็นไปตามโมเดลนี้ที่นักเรียนส่วนใหญ่พัฒนาขึ้น เช่น งานในห้องปฏิบัติการ
โมเดลนี้มีอัลกอริธึมดังต่อไปนี้:

1. การกำหนดปัญหา
2. ผลงาน
3. การตรวจสอบผลลัพธ์
4. หากจำเป็นให้ไปที่จุดแรก

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

แบบจำลองวงจรชีวิตซอฟต์แวร์ Waterfall (วอเตอร์ฟอล)

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

ข้อดี:

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

ข้อบกพร่อง:

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

เป็นของกลุ่มรุ่นแรก

โมเดลคาสเคดพร้อมระบบควบคุมระดับกลาง (วังวน)

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

รุ่น V (การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ)

รุ่นนี้มีอัลกอริธึมที่ใกล้เคียงกับวิธีการสมัยใหม่มากขึ้น แต่ก็ยังมีข้อเสียอยู่หลายประการ มันเป็นหนึ่งในแนวทางปฏิบัติหลักของการเขียนโปรแกรมแบบเอ็กซ์ตรีม

แบบจำลองตามการพัฒนาต้นแบบ

โมเดลนี้มีพื้นฐานมาจากการพัฒนาต้นแบบและการสร้างต้นแบบผลิตภัณฑ์
การสร้างต้นแบบใช้ในช่วงแรกของวงจรชีวิตซอฟต์แวร์:

1. ชี้แจงข้อกำหนดที่ไม่ชัดเจน (ต้นแบบ UI)
2. เลือกหนึ่งในวิธีแก้ปัญหาเชิงแนวคิดจำนวนหนึ่ง (การนำสถานการณ์ไปใช้)
3. วิเคราะห์ความเป็นไปได้ของโครงการ

การจำแนกประเภทของต้นแบบ:

1. แนวนอนและแนวตั้ง
2. ทิ้งและวิวัฒนาการ
3. กระดาษและสตอรี่บอร์ด

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

โมเดลอยู่ในกลุ่มที่สอง

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

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

ข้อดี:

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

ข้อบกพร่อง:

• ขาดการควบคุมเวที

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

ขอบคุณมากสำหรับความสนใจของคุณ!

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

การแนะนำ.

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

การแนะนำ.

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

การแนะนำ.

1.1.1. การกำหนดปัญหา

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

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

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

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

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

1.2. การกำหนด คสช. ตามแนวทางของเลห์แมน

การแนะนำ.

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 วงจรชีวิตของซอฟต์แวร์

การแนะนำ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

คำอธิบายทั่วไป (สรุปโดยย่อของงาน);

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

ตัวอย่าง (ตัวอย่างที่ดีสามารถสื่อถึงแก่นแท้ของปัญหาและยังแสดงให้เห็นกรณีต่างๆ อีกด้วย)

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

ชื่อ

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

คำอธิบาย

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

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

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

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

ในกรณีทั่วไป ระบบซอฟต์แวร์นอกเหนือจากตัวโปรแกรมเองยังมีฮาร์ดแวร์ด้วย และโดยทั่วไปถือว่าล้อมรอบด้วยระบบซอฟต์แวร์และฮาร์ดแวร์อื่น ๆ

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

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

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

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

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

ตัวอย่างคำอธิบายวงจรชีวิต

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

ในเอกสารกำกับดูแลภายในประเทศ (เช่น GOST ESPD) มีการนำการแบ่งส่วนต่อไปนี้ออกเป็นขั้นตอนซึ่งระบุไว้พร้อมกับข้อบ่งชี้ของการเปรียบเทียบจากรายการที่ระบุในตอนต้นของส่วน:

การพัฒนาข้อกำหนดทางเทคนิค (ระยะที่ 1 และ 2)

การออกแบบทางเทคนิค (รวมระยะที่สามจนถึง 3.2.1)

ร่างการทำงาน (3.2.2, 4.2.1 และบางส่วน 4.2, 4.3)

การดำเนินการนำร่อง (4.2 และ 4.3)

การว่าจ้างเพื่อดำเนินการเชิงพาณิชย์ (ระยะที่ 5)

การดำเนินงานทางอุตสาหกรรม (ระยะที่ 6)

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

ข้าว. 1.1 ตัวอย่างวงจรชีวิตของระบบซอฟต์แวร์

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

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

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

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

การออกแบบซอฟต์แวร์เบื้องต้น (3.2.1) การกำหนดส่วนประกอบซอฟต์แวร์เฉพาะที่จะพัฒนาและนำไปใช้ในระบบขั้นสุดท้าย การตรวจสอบส่วนประกอบชุดนี้ว่าสอดคล้องกับข้อกำหนดซอฟต์แวร์ทั่วไป การกำหนดข้อกำหนดด้านการทำงาน การปฏิบัติงาน และการทดสอบสำหรับส่วนประกอบเฉพาะแต่ละส่วน

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

การเข้ารหัสและการทดสอบซอฟต์แวร์ (4.1.1 และ 4.1.2) การสร้าง การทดสอบแต่ละโมดูล เอกสารประกอบ และการยอมรับส่วนประกอบซอฟต์แวร์ที่ประกอบขึ้นเป็นระบบซอฟต์แวร์

บูรณาการซอฟต์แวร์ (ตอนที่ 4.2) การทดสอบประสิทธิภาพและความสมบูรณ์ของส่วนซอฟต์แวร์ของระบบในสภาพแวดล้อมที่คาดเดาได้ (ฮาร์ดแวร์และสภาพแวดล้อม)

บูรณาการระบบ (4.3) การทดสอบประสิทธิภาพและความสมบูรณ์ของการทำงานของส่วนต่าง ๆ ของระบบโดยรวมโดยรวม

การยอมรับและการส่งมอบระบบ (5) ระบบได้รับการยอมรับจากลูกค้าและระบบจัดส่งให้เขา

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

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

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

ขั้นตอนการวางแผนซึ่งกำหนดและประสานกิจกรรมการพัฒนาระบบซอฟต์แวร์ (ระยะที่ 1)

ขั้นตอนการพัฒนาที่สร้างระบบซอฟต์แวร์:

คำชี้แจงปัญหา (ระยะที่ 2)

การออกแบบ (3),

การเข้ารหัส (4.1.1)

รับรหัสปฏิบัติการ (4.1.1, 4.3);

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

ข้าว. 1.2 ตัวเลือกสำหรับวงจรชีวิตที่เรียบง่ายของระบบซอฟต์แวร์

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

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

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

ข้าว. 1.3 ลำดับขั้นตอนการพัฒนาส่วนประกอบซอฟต์แวร์

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

เกือบทุกขั้นตอนของวงจรชีวิตจะรวมกับการตรวจสอบยืนยัน

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

วงจรชีวิตในความหมายที่เป็นทางการคืออะไร?

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

พูดง่ายๆ ก็คือ ระบบข้อมูลในรูปแบบของโปรแกรม ฐานข้อมูล หรือแม้แต่ “ระบบปฏิบัติการ” นั้นเป็นที่ต้องการก็ต่อเมื่อข้อมูลและโอกาสที่ระบบให้นั้นเป็นข้อมูลที่ทันสมัยเท่านั้น

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

ข้อกำหนดเบื้องต้น

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

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

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

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

• GOST 34.601-90;
• ISO/IEC 12207:2008;
• ออราเคิล ซีดีเอ็ม.

สำหรับมาตรฐานสากลที่สองนั้นมีอะนาล็อกของรัสเซีย นี่คือ GOST R ISO/IEC 12207-2010 ซึ่งรับผิดชอบด้านวิศวกรรมระบบและซอฟต์แวร์ แต่วงจรชีวิตของซอฟต์แวร์ที่อธิบายไว้ในกฎทั้งสองนั้นเหมือนกันโดยพื้นฐานแล้ว นี่เป็นคำอธิบายที่ค่อนข้างง่าย

ประเภทของซอฟต์แวร์และการอัพเดต

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

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

ตัวอย่างจาก FL Studio

ในตอนแรก FL Studio เสมือนสตูดิโอซีเควนเซอร์ถูกเรียกว่า Fruity Loops วงจรชีวิตของซอฟต์แวร์ในการปรับเปลี่ยนครั้งแรกหมดอายุแล้ว แต่แอปพลิเคชันได้รับการเปลี่ยนแปลงบ้างและได้รับรูปแบบปัจจุบัน

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

• การสร้างโมดูลกลองที่คล้ายกับริทึมแมชชีนเช่น Yamaha RX แต่ใช้ตัวอย่างช็อตเดียวหรือซีเควนซ์ในรูปแบบ WAV ที่บันทึกสดในสตูดิโอ
• บูรณาการเข้ากับระบบปฏิบัติการ Windows
• ความสามารถในการส่งออกโครงการในรูปแบบ WAV, MP3 และ OGG
• ความเข้ากันได้ของโครงการกับแอพพลิเคชั่น Fruity Tracks เพิ่มเติม

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

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

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

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

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

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

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

แนวโน้มการพัฒนา

ขั้นตอนของวงจรชีวิตซอฟต์แวร์มีความชัดเจนอยู่แล้ว แต่การพัฒนาเทคโนโลยีดังกล่าวก็คุ้มค่าที่จะกล่าวถึงแยกกัน

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

แม้แต่ในกรณีของระบบปฏิบัติการ Windows ก็ยังสามารถมองเห็นแนวโน้มดังกล่าวได้ด้วยตาเปล่า ไม่น่าเป็นไปได้ที่ในปัจจุบันจะมีผู้ใช้อย่างน้อยหนึ่งรายที่ใช้ระบบเช่นการแก้ไข 3.1, 95, 98 หรือ Millennium วงจรชีวิตของพวกเขาสิ้นสุดลงหลังจากการเปิดตัว XP แต่เวอร์ชันเซิร์ฟเวอร์ที่ใช้เทคโนโลยี NT ยังคงมีความเกี่ยวข้อง แม้แต่ Windows 2000 ในปัจจุบันก็ไม่เพียงแต่มีความเกี่ยวข้องเท่านั้น แต่ในการติดตั้งหรือพารามิเตอร์ความปลอดภัยบางตัวยังเหนือกว่าการพัฒนาล่าสุดด้วยซ้ำ เช่นเดียวกับระบบ NT 4.0 เช่นเดียวกับการดัดแปลงพิเศษของ Windows Server 2012

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

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

คำถามเพิ่มเติมบางประการ

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

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

แต่ในเทคโนโลยีคอมพิวเตอร์ในปัจจุบันการตั้งค่าให้กับการพัฒนาระบบควบคุมอัตโนมัติ (ACS) ซึ่งใช้ในการผลิต แม้แต่ระบบปฏิบัติการเมื่อเปรียบเทียบกับโปรแกรมพิเศษก็ยังแพ้

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

แทนที่จะเป็นยอดรวม

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

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

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

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

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

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

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