SDLC - คู่มือฉบับย่อ
Software Development Life Cycle (SDLC) เป็นกระบวนการที่อุตสาหกรรมซอฟต์แวร์ใช้ในการออกแบบพัฒนาและทดสอบซอฟต์แวร์คุณภาพสูง SDLC มีวัตถุประสงค์เพื่อผลิตซอฟต์แวร์คุณภาพสูงที่ตรงตามหรือเกินความคาดหมายของลูกค้าบรรลุผลสำเร็จภายในเวลาและประมาณการค่าใช้จ่าย
SDLC เป็นคำย่อของวงจรชีวิตการพัฒนาซอฟต์แวร์
เรียกอีกอย่างว่าเป็นกระบวนการพัฒนาซอฟต์แวร์
SDLC เป็นกรอบการกำหนดงานที่ดำเนินการในแต่ละขั้นตอนในกระบวนการพัฒนาซอฟต์แวร์
ISO / IEC 12207 เป็นมาตรฐานสากลสำหรับกระบวนการตลอดอายุซอฟต์แวร์ มีจุดมุ่งหมายเพื่อเป็นมาตรฐานที่กำหนดงานทั้งหมดที่จำเป็นสำหรับการพัฒนาและบำรุงรักษาซอฟต์แวร์
SDLC คืออะไร?
SDLC เป็นกระบวนการที่ตามมาสำหรับโครงการซอฟต์แวร์ภายในองค์กรซอฟต์แวร์ ประกอบด้วยแผนโดยละเอียดที่อธิบายถึงวิธีการพัฒนาบำรุงรักษาเปลี่ยนและแก้ไขหรือปรับปรุงซอฟต์แวร์เฉพาะ วงจรชีวิตกำหนดวิธีการในการปรับปรุงคุณภาพของซอฟต์แวร์และกระบวนการพัฒนาโดยรวม
รูปต่อไปนี้เป็นการแสดงกราฟิกของขั้นตอนต่างๆของ SDLC ทั่วไป
วงจรชีวิตของการพัฒนาซอฟต์แวร์โดยทั่วไปประกอบด้วยขั้นตอนต่อไปนี้ -
ขั้นตอนที่ 1: การวางแผนและการวิเคราะห์ความต้องการ
การวิเคราะห์ความต้องการเป็นขั้นตอนที่สำคัญที่สุดและเป็นพื้นฐานใน SDLC ดำเนินการโดยสมาชิกอาวุโสของทีมพร้อมข้อมูลจากลูกค้าฝ่ายขายการสำรวจตลาดและผู้เชี่ยวชาญด้านโดเมนในอุตสาหกรรม จากนั้นข้อมูลนี้จะใช้ในการวางแผนแนวทางโครงการพื้นฐานและดำเนินการศึกษาความเป็นไปได้ของผลิตภัณฑ์ในด้านเศรษฐกิจการปฏิบัติงานและด้านเทคนิค
นอกจากนี้การวางแผนสำหรับข้อกำหนดการประกันคุณภาพและการระบุความเสี่ยงที่เกี่ยวข้องกับโครงการยังทำในขั้นตอนการวางแผน ผลลัพธ์ของการศึกษาความเป็นไปได้ทางเทคนิคคือการกำหนดแนวทางทางเทคนิคต่างๆที่สามารถปฏิบัติตามเพื่อให้โครงการประสบความสำเร็จโดยมีความเสี่ยงขั้นต่ำ
ขั้นตอนที่ 2: การกำหนดข้อกำหนด
เมื่อการวิเคราะห์ความต้องการเสร็จสิ้นขั้นตอนต่อไปคือกำหนดและจัดทำเอกสารข้อกำหนดของผลิตภัณฑ์อย่างชัดเจนและได้รับการอนุมัติจากลูกค้าหรือนักวิเคราะห์ตลาด สิ่งนี้ทำได้ผ่านไฟล์SRS (Software Requirement Specification) เอกสารซึ่งประกอบด้วยข้อกำหนดของผลิตภัณฑ์ทั้งหมดที่ต้องออกแบบและพัฒนาในช่วงวงจรชีวิตของโครงการ
ขั้นตอนที่ 3: การออกแบบสถาปัตยกรรมผลิตภัณฑ์
SRS คือข้อมูลอ้างอิงสำหรับสถาปนิกผลิตภัณฑ์เพื่อให้ได้สถาปัตยกรรมที่ดีที่สุดสำหรับผลิตภัณฑ์ที่จะพัฒนา ตามข้อกำหนดที่ระบุไว้ใน SRS โดยปกติจะมีการเสนอแนวทางการออกแบบมากกว่าหนึ่งวิธีสำหรับสถาปัตยกรรมผลิตภัณฑ์และจัดทำเป็นเอกสารใน DDS - Design Document Specification
DDS นี้ได้รับการตรวจสอบโดยผู้มีส่วนได้ส่วนเสียที่สำคัญทั้งหมดและพิจารณาจากพารามิเตอร์ต่างๆเช่นการประเมินความเสี่ยงความทนทานของผลิตภัณฑ์การออกแบบโมดูลาร์ข้อ จำกัด ด้านงบประมาณและเวลาแนวทางการออกแบบที่ดีที่สุดจะถูกเลือกสำหรับผลิตภัณฑ์
แนวทางการออกแบบกำหนดโมดูลสถาปัตยกรรมทั้งหมดของผลิตภัณฑ์อย่างชัดเจนพร้อมกับการสื่อสารและการแสดงกระแสข้อมูลด้วยโมดูลภายนอกและของบุคคลที่สาม (ถ้ามี) การออกแบบภายในของโมดูลทั้งหมดของสถาปัตยกรรมที่นำเสนอควรกำหนดไว้อย่างชัดเจนโดยมีรายละเอียดน้อยที่สุดใน DDS
ขั้นตอนที่ 4: การสร้างหรือพัฒนาผลิตภัณฑ์
ในขั้นตอนของ SDLC นี้การพัฒนาจริงจะเริ่มต้นและสร้างผลิตภัณฑ์ รหัสการเขียนโปรแกรมถูกสร้างขึ้นตาม DDS ในขั้นตอนนี้ หากการออกแบบดำเนินการอย่างละเอียดและเป็นระบบการสร้างโค้ดสามารถทำได้โดยไม่ต้องยุ่งยากมากนัก
นักพัฒนาต้องปฏิบัติตามแนวทางการเข้ารหัสที่กำหนดโดยองค์กรของตนและใช้เครื่องมือการเขียนโปรแกรมเช่นคอมไพเลอร์ล่ามตัวแก้จุดบกพร่อง ฯลฯ เพื่อสร้างรหัส ภาษาโปรแกรมระดับสูงต่างๆเช่น C, C ++, Pascal, Java และ PHP ใช้สำหรับการเขียนโค้ด ภาษาการเขียนโปรแกรมถูกเลือกตามประเภทของซอฟต์แวร์ที่กำลังพัฒนา
ขั้นตอนที่ 5: การทดสอบผลิตภัณฑ์
ขั้นตอนนี้มักเป็นส่วนย่อยของขั้นตอนทั้งหมดเช่นเดียวกับในโมเดล SDLC ที่ทันสมัยกิจกรรมการทดสอบส่วนใหญ่เกี่ยวข้องกับทุกขั้นตอนของ SDLC อย่างไรก็ตามขั้นตอนนี้หมายถึงขั้นตอนการทดสอบเฉพาะของผลิตภัณฑ์ที่มีการรายงานติดตามแก้ไขและทดสอบใหม่จนกว่าผลิตภัณฑ์จะได้มาตรฐานคุณภาพที่กำหนดไว้ใน SRS
ขั้นตอนที่ 6: การปรับใช้ในตลาดและการบำรุงรักษา
เมื่อผลิตภัณฑ์ได้รับการทดสอบและพร้อมที่จะนำไปใช้งานแล้วจะมีการวางจำหน่ายอย่างเป็นทางการในตลาดที่เหมาะสม บางครั้งการปรับใช้ผลิตภัณฑ์จะเกิดขึ้นเป็นขั้นตอนตามกลยุทธ์ทางธุรกิจขององค์กรนั้น ๆ ผลิตภัณฑ์อาจวางจำหน่ายในกลุ่มที่ จำกัด ก่อนและทดสอบในสภาพแวดล้อมทางธุรกิจจริง (UAT- การทดสอบการยอมรับของผู้ใช้)
จากผลตอบรับผลิตภัณฑ์อาจได้รับการเผยแพร่ตามที่เป็นอยู่หรือมีการปรับปรุงที่แนะนำในกลุ่มตลาดเป้าหมาย หลังจากที่ผลิตภัณฑ์ออกสู่ตลาดแล้วการบำรุงรักษาจะดำเนินการสำหรับฐานลูกค้าเดิม
โมเดล SDLC
มีการกำหนดและออกแบบแบบจำลองวงจรชีวิตของการพัฒนาซอฟต์แวร์ต่างๆซึ่งตามมาในระหว่างขั้นตอนการพัฒนาซอฟต์แวร์ แบบจำลองเหล่านี้เรียกอีกอย่างว่าแบบจำลองกระบวนการพัฒนาซอฟต์แวร์ "แต่ละรูปแบบกระบวนการจะทำตามลำดับขั้นตอนเฉพาะสำหรับประเภทของมันเพื่อให้แน่ใจว่ากระบวนการพัฒนาซอฟต์แวร์ประสบความสำเร็จ
ต่อไปนี้เป็นโมเดล SDLC ที่สำคัญและเป็นที่นิยมที่สุดตามมาในอุตสาหกรรม -
- น้ำตกจำลอง
- แบบจำลองซ้ำ
- แบบเกลียว
- V-Model
- บิ๊กแบงโมเดล
วิธีการอื่น ๆ ที่เกี่ยวข้อง ได้แก่ Agile Model, RAD Model, Rapid Application Development และ Prototyping Models
Waterfall Model เป็นแบบจำลองกระบวนการแรกที่นำมาใช้ นอกจากนี้ยังเรียกว่าไฟล์linear-sequential life cycle model. มันง่ายมากที่จะเข้าใจและใช้ ในแบบจำลองน้ำตกแต่ละเฟสจะต้องเสร็จสิ้นก่อนที่จะเริ่มเฟสถัดไปและไม่มีการทับซ้อนกันในเฟส
แบบจำลอง Waterfall เป็นแนวทาง SDLC ที่เก่าแก่ที่สุดที่ใช้สำหรับการพัฒนาซอฟต์แวร์
Waterfall Model แสดงขั้นตอนการพัฒนาซอฟต์แวร์ในลำดับขั้นตอนเชิงเส้น ซึ่งหมายความว่าเฟสใด ๆ ในกระบวนการพัฒนาจะเริ่มต้นก็ต่อเมื่อเฟสก่อนหน้านี้เสร็จสมบูรณ์ ในแบบจำลองน้ำตกนี้เฟสจะไม่ทับซ้อนกัน
แบบจำลองน้ำตก - การออกแบบ
วิธีน้ำตกเป็นแบบจำลอง SDLC แรกที่ใช้กันอย่างแพร่หลายในวิศวกรรมซอฟต์แวร์เพื่อให้แน่ใจว่าโครงการจะประสบความสำเร็จ ในแนวทาง "น้ำตก" กระบวนการทั้งหมดของการพัฒนาซอฟต์แวร์จะแบ่งออกเป็นขั้นตอนแยกกัน ในแบบจำลอง Waterfall นี้โดยทั่วไปแล้วผลลัพธ์ของเฟสเดียวจะทำหน้าที่เป็นอินพุตสำหรับเฟสถัดไปตามลำดับ
ภาพประกอบต่อไปนี้เป็นการแสดงระยะต่างๆของ Waterfall Model
ขั้นตอนตามลำดับในแบบจำลองน้ำตกคือ -
Requirement Gathering and analysis - ข้อกำหนดที่เป็นไปได้ทั้งหมดของระบบที่จะพัฒนาถูกบันทึกไว้ในขั้นตอนนี้และบันทึกไว้ในเอกสารข้อกำหนดข้อกำหนด
System Design- มีการศึกษาข้อกำหนดข้อกำหนดจากเฟสแรกในระยะนี้และเตรียมการออกแบบระบบ การออกแบบระบบนี้ช่วยในการระบุข้อกำหนดของฮาร์ดแวร์และระบบและช่วยในการกำหนดสถาปัตยกรรมระบบโดยรวม
Implementation- ด้วยอินพุตจากการออกแบบระบบระบบได้รับการพัฒนาครั้งแรกในโปรแกรมขนาดเล็กที่เรียกว่าหน่วยซึ่งจะรวมอยู่ในเฟสถัดไป แต่ละหน่วยได้รับการพัฒนาและทดสอบการทำงานซึ่งเรียกว่าการทดสอบหน่วย
Integration and Testing- หน่วยทั้งหมดที่พัฒนาในขั้นตอนการใช้งานจะรวมเข้ากับระบบหลังจากการทดสอบของแต่ละหน่วย โพสต์การรวมระบบทั้งหมดได้รับการทดสอบเพื่อหาข้อบกพร่องและความล้มเหลว
Deployment of system- เมื่อทำการทดสอบการทำงานและไม่ทำงานแล้ว ผลิตภัณฑ์ถูกนำไปใช้งานในสภาพแวดล้อมของลูกค้าหรือออกสู่ตลาด
Maintenance- มีปัญหาบางอย่างที่เกิดขึ้นในสภาพแวดล้อมไคลเอนต์ ในการแก้ไขปัญหาเหล่านั้นแพตช์จะถูกปล่อยออกมา นอกจากนี้เพื่อปรับปรุงผลิตภัณฑ์บางรุ่นที่ดีขึ้นจะถูกปล่อยออกมา ทำการบำรุงรักษาเพื่อส่งมอบการเปลี่ยนแปลงเหล่านี้ในสภาพแวดล้อมของลูกค้า
ขั้นตอนทั้งหมดเหล่านี้เรียงต่อกันซึ่งความคืบหน้าจะถูกมองว่าไหลลงอย่างต่อเนื่อง (เหมือนน้ำตก) ผ่านขั้นตอน ขั้นตอนต่อไปจะเริ่มต้นหลังจากบรรลุเป้าหมายที่กำหนดไว้สำหรับเฟสก่อนหน้าและมีการลงชื่อออกเท่านั้นดังนั้นจึงใช้ชื่อว่า "Waterfall Model" ในรุ่นนี้เฟสจะไม่ทับซ้อนกัน
Waterfall Model - แอปพลิเคชัน
ซอฟต์แวร์ทุกตัวที่พัฒนาขึ้นมีความแตกต่างกันและต้องใช้แนวทาง SDLC ที่เหมาะสมโดยพิจารณาจากปัจจัยภายในและภายนอก บางสถานการณ์ที่การใช้ Waterfall model เหมาะสมที่สุด ได้แก่ -
ข้อกำหนดได้รับการบันทึกไว้เป็นอย่างดีชัดเจนและคงที่
คำจำกัดความของผลิตภัณฑ์มีเสถียรภาพ
เทคโนโลยีเป็นที่เข้าใจและไม่หยุดนิ่ง
ไม่มีข้อกำหนดที่คลุมเครือ
มีทรัพยากรเพียงพอพร้อมความเชี่ยวชาญที่จำเป็นเพื่อสนับสนุนผลิตภัณฑ์
โครงการมีระยะสั้น
แบบจำลองน้ำตก - ข้อดี
ข้อดีของการพัฒนาน้ำตกคือช่วยให้สามารถแบ่งแผนกและควบคุมได้ สามารถกำหนดตารางเวลาพร้อมกำหนดเวลาสำหรับแต่ละขั้นตอนของการพัฒนาและผลิตภัณฑ์สามารถดำเนินการผ่านขั้นตอนแบบจำลองกระบวนการพัฒนาทีละขั้นตอน
การพัฒนาเปลี่ยนจากแนวคิดผ่านการออกแบบการใช้งานการทดสอบการติดตั้งการแก้ไขปัญหาและจบลงที่การดำเนินการและการบำรุงรักษา การพัฒนาแต่ละขั้นตอนดำเนินไปอย่างเข้มงวด
ข้อดีที่สำคัญบางประการของ Waterfall Model มีดังนี้ -
ง่ายและเข้าใจง่ายและใช้งาน
ง่ายต่อการจัดการเนื่องจากความแข็งแกร่งของแบบจำลอง แต่ละขั้นตอนจะมีการส่งมอบที่เฉพาะเจาะจงและกระบวนการตรวจสอบ
ขั้นตอนต่างๆจะถูกประมวลผลและเสร็จสิ้นทีละขั้นตอน
ทำงานได้ดีสำหรับโครงการขนาดเล็กที่เข้าใจข้อกำหนดเป็นอย่างดี
ขั้นตอนที่กำหนดไว้อย่างชัดเจน
เข้าใจเหตุการณ์สำคัญ
จัดเรียงงานได้ง่าย
กระบวนการและผลลัพธ์ได้รับการบันทึกไว้อย่างดี
แบบจำลองน้ำตก - ข้อเสีย
ข้อเสียของการพัฒนาน้ำตกคือไม่อนุญาตให้มีการสะท้อนหรือแก้ไขมากนัก เมื่อแอปพลิเคชันอยู่ในขั้นตอนการทดสอบแล้วจะเป็นการยากมากที่จะย้อนกลับไปและเปลี่ยนแปลงสิ่งที่ไม่ได้รับการบันทึกไว้อย่างดีหรือคิดไว้ในขั้นตอนแนวคิด
ข้อเสียที่สำคัญของ Waterfall Model มีดังนี้ -
ไม่มีการผลิตซอฟต์แวร์ที่ใช้งานได้จนกว่าจะถึงช่วงปลายวงจรชีวิต
ความเสี่ยงและความไม่แน่นอนจำนวนมาก
ไม่ใช่รูปแบบที่ดีสำหรับโครงการที่ซับซ้อนและเชิงวัตถุ
รูปแบบที่ไม่ดีสำหรับโครงการที่ยาวนานและต่อเนื่อง
ไม่เหมาะสำหรับโครงการที่ข้อกำหนดมีความเสี่ยงในการเปลี่ยนแปลงปานกลางถึงสูง ดังนั้นความเสี่ยงและความไม่แน่นอนจึงสูงในรูปแบบกระบวนการนี้
เป็นการยากที่จะวัดความก้าวหน้าภายในระยะ
ไม่สามารถรองรับข้อกำหนดที่เปลี่ยนแปลงได้
การปรับขอบเขตระหว่างวงจรชีวิตสามารถยุติโครงการได้
การบูรณาการเป็น "บิ๊กแบง" ในตอนท้ายซึ่งไม่อนุญาตให้ระบุคอขวดหรือความท้าทายใด ๆ ในช่วงต้น
ในรูปแบบการทำซ้ำกระบวนการซ้ำเริ่มต้นด้วยการนำข้อกำหนดซอฟต์แวร์ชุดเล็ก ๆ ไปใช้อย่างง่าย ๆ และปรับปรุงเวอร์ชันที่พัฒนาซ้ำ ๆ จนกว่าระบบจะเสร็จสมบูรณ์และพร้อมที่จะนำไปใช้งาน
แบบจำลองวงจรชีวิตแบบวนซ้ำไม่ได้พยายามเริ่มต้นด้วยข้อกำหนดเต็มรูปแบบ แต่การพัฒนาเริ่มต้นด้วยการระบุและใช้งานซอฟต์แวร์เพียงบางส่วนซึ่งจะถูกตรวจสอบเพื่อระบุข้อกำหนดเพิ่มเติม จากนั้นกระบวนการนี้จะถูกทำซ้ำโดยสร้างซอฟต์แวร์เวอร์ชันใหม่เมื่อสิ้นสุดการทำซ้ำแต่ละรุ่น
แบบจำลองซ้ำ - การออกแบบ
กระบวนการทำซ้ำเริ่มต้นด้วยการใช้งานชุดย่อยของข้อกำหนดซอฟต์แวร์อย่างง่าย ๆ และปรับปรุงเวอร์ชันที่กำลังพัฒนาซ้ำ ๆ จนกว่าจะนำระบบเต็มรูปแบบมาใช้ ในการทำซ้ำแต่ละครั้งจะมีการปรับเปลี่ยนการออกแบบและเพิ่มความสามารถในการทำงานใหม่ ๆ แนวคิดพื้นฐานที่อยู่เบื้องหลังวิธีนี้คือการพัฒนาระบบผ่านวงจรซ้ำ ๆ (วนซ้ำ) และในส่วนที่เล็กลงในแต่ละครั้ง (เพิ่มขึ้น)
ภาพประกอบต่อไปนี้เป็นการแสดงรูปแบบการทำซ้ำและแบบเพิ่มหน่วย -
การพัฒนาแบบวนซ้ำและการพัฒนาแบบเพิ่มหน่วยเป็นการผสมผสานระหว่างการออกแบบซ้ำหรือวิธีการวนซ้ำและรูปแบบการสร้างส่วนเพิ่มสำหรับการพัฒนา "ในระหว่างการพัฒนาซอฟต์แวร์อาจมีการทำซ้ำวงจรการพัฒนาซอฟต์แวร์มากกว่าหนึ่งครั้งในเวลาเดียวกัน" กระบวนการนี้อาจเรียกได้ว่าเป็นแนวทาง "การได้มาซึ่งวิวัฒนาการ" หรือ "การสร้างแบบเพิ่มหน่วย" "
ในโมเดลที่เพิ่มขึ้นนี้ข้อกำหนดทั้งหมดจะถูกแบ่งออกเป็นรุ่นต่างๆ ในระหว่างการทำซ้ำแต่ละครั้งโมดูลการพัฒนาจะดำเนินการตามข้อกำหนดการออกแบบการใช้งานและขั้นตอนการทดสอบ แต่ละรุ่นที่ตามมาของโมดูลจะเพิ่มฟังก์ชันให้กับรุ่นก่อนหน้า กระบวนการดำเนินต่อไปจนกว่าระบบที่สมบูรณ์จะพร้อมตามความต้องการ
กุญแจสำคัญในการใช้วงจรชีวิตการพัฒนาซอฟต์แวร์แบบวนซ้ำให้ประสบความสำเร็จคือการตรวจสอบข้อกำหนดอย่างเข้มงวดและการตรวจสอบและทดสอบซอฟต์แวร์แต่ละเวอร์ชันกับข้อกำหนดเหล่านั้นภายในแต่ละรอบของโมเดล ในขณะที่ซอฟต์แวร์พัฒนาไปตามวัฏจักรที่ต่อเนื่องกันจะต้องมีการทดสอบซ้ำและขยายเวลาเพื่อตรวจสอบซอฟต์แวร์แต่ละเวอร์ชัน
แบบจำลองซ้ำ - แอปพลิเคชัน
เช่นเดียวกับ SDLC รุ่นอื่น ๆ การพัฒนาซ้ำและการพัฒนาแบบเพิ่มหน่วยมีแอปพลิเคชันเฉพาะบางอย่างในอุตสาหกรรมซอฟต์แวร์ โมเดลนี้มักใช้ในสถานการณ์ต่อไปนี้ -
ข้อกำหนดของระบบที่สมบูรณ์มีการกำหนดและเข้าใจอย่างชัดเจน
ต้องกำหนดข้อกำหนดหลัก อย่างไรก็ตามฟังก์ชันการทำงานบางอย่างหรือการปรับปรุงที่ร้องขออาจพัฒนาไปตามกาลเวลา
มีเวลาในการ จำกัด ตลาด
ทีมพัฒนากำลังใช้เทคโนโลยีใหม่และกำลังเรียนรู้ในขณะที่ทำงานในโครงการ
ทรัพยากรที่มีชุดทักษะที่จำเป็นไม่มีให้ใช้งานและมีการวางแผนให้ใช้ตามสัญญาสำหรับการทำซ้ำเฉพาะ
มีคุณสมบัติและเป้าหมายที่มีความเสี่ยงสูงซึ่งอาจเปลี่ยนแปลงได้ในอนาคต
แบบจำลองซ้ำ - ข้อดีข้อเสีย
ข้อดีของรุ่นนี้คือมีรูปแบบการทำงานของระบบในช่วงแรกของการพัฒนาซึ่งทำให้ง่ายต่อการค้นหาข้อบกพร่องในการใช้งานหรือการออกแบบ การค้นหาปัญหาในช่วงเริ่มต้นของการพัฒนาทำให้สามารถใช้มาตรการแก้ไขได้ในงบประมาณที่ จำกัด
ข้อเสียของโมเดล SDLC นี้คือใช้ได้กับโครงการพัฒนาซอฟต์แวร์ขนาดใหญ่และเทอะทะเท่านั้น เนื่องจากเป็นการยากที่จะแบ่งระบบซอฟต์แวร์ขนาดเล็กออกเป็นส่วนเพิ่ม / โมดูลที่สามารถให้บริการได้เพิ่มเติม
ข้อดีของแบบจำลอง SDLC แบบวนซ้ำและแบบเพิ่มหน่วยมีดังนี้ -
ฟังก์ชันการทำงานบางอย่างสามารถพัฒนาได้อย่างรวดเร็วและในช่วงต้นของวงจรชีวิต
ผลลัพธ์จะได้รับในช่วงต้นและเป็นระยะ
การพัฒนาแบบคู่ขนานสามารถวางแผนได้
ความคืบหน้าสามารถวัดได้
หักค่าใช้จ่ายในการเปลี่ยนขอบเขต / ข้อกำหนด
การทดสอบและการดีบักในระหว่างการทำซ้ำขนาดเล็กทำได้ง่าย
มีการระบุและแก้ไขความเสี่ยงในระหว่างการทำซ้ำ และการทำซ้ำแต่ละครั้งเป็นเหตุการณ์สำคัญที่จัดการได้ง่าย
จัดการความเสี่ยงได้ง่ายขึ้น - ส่วนที่มีความเสี่ยงสูงต้องทำก่อน
ทุกครั้งที่เพิ่มขึ้นจะมีการส่งมอบผลิตภัณฑ์ปฏิบัติการ
ประเด็นปัญหาความท้าทายและความเสี่ยงที่ระบุจากการเพิ่มแต่ละครั้งสามารถนำไปใช้ประโยชน์ / นำไปใช้กับการเพิ่มครั้งต่อไปได้
การวิเคราะห์ความเสี่ยงจะดีกว่า
รองรับการเปลี่ยนแปลงข้อกำหนด
เวลาในการทำงานเริ่มต้นน้อยกว่า
เหมาะสำหรับโครงการขนาดใหญ่และมีความสำคัญต่อภารกิจ
ในช่วงวงจรชีวิตซอฟต์แวร์จะถูกผลิตขึ้นในช่วงต้นซึ่งอำนวยความสะดวกในการประเมินและข้อเสนอแนะของลูกค้า
ข้อเสียของแบบจำลอง SDLC แบบวนซ้ำและแบบเพิ่มหน่วยมีดังนี้ -
อาจต้องใช้ทรัพยากรเพิ่มเติม
แม้ว่าค่าใช้จ่ายในการเปลี่ยนแปลงจะน้อยกว่า แต่ก็ไม่เหมาะสำหรับการเปลี่ยนแปลงข้อกำหนด
ต้องการความเอาใจใส่ในการจัดการมากขึ้น
ปัญหาสถาปัตยกรรมระบบหรือการออกแบบอาจเกิดขึ้นเนื่องจากความต้องการทั้งหมดไม่ได้ถูกรวบรวมในช่วงเริ่มต้นของวงจรชีวิตทั้งหมด
การกำหนดส่วนเพิ่มอาจต้องใช้คำจำกัดความของระบบที่สมบูรณ์
ไม่เหมาะสำหรับโครงการขนาดเล็ก
ความซับซ้อนในการจัดการมีมากขึ้น
อาจไม่ทราบการสิ้นสุดโครงการซึ่งเป็นความเสี่ยง
จำเป็นต้องใช้ทรัพยากรที่มีทักษะสูงสำหรับการวิเคราะห์ความเสี่ยง
ความคืบหน้าของโครงการขึ้นอยู่กับขั้นตอนการวิเคราะห์ความเสี่ยง
แบบจำลองเกลียวผสมผสานแนวคิดของการพัฒนาแบบวนซ้ำกับแง่มุมที่เป็นระบบและมีการควบคุมของแบบจำลองน้ำตก แบบจำลอง Spiral นี้เป็นการผสมผสานระหว่างแบบจำลองกระบวนการพัฒนาแบบวนซ้ำและแบบจำลองการพัฒนาเชิงเส้นตามลำดับเช่นแบบจำลองน้ำตกที่เน้นการวิเคราะห์ความเสี่ยงสูงมาก ช่วยให้สามารถเปิดตัวผลิตภัณฑ์เพิ่มขึ้นหรือปรับแต่งเพิ่มเติมผ่านการวนซ้ำแต่ละครั้งรอบ ๆ เกลียว
Spiral Model - การออกแบบ
แบบจำลองเกลียวมีสี่เฟส โครงการซอฟต์แวร์จะผ่านขั้นตอนเหล่านี้ซ้ำ ๆ ในการทำซ้ำที่เรียกว่า Spirals
การระบุ
ขั้นตอนนี้เริ่มต้นด้วยการรวบรวมข้อกำหนดทางธุรกิจในเกลียวพื้นฐาน ในเกลียวที่ตามมาเมื่อผลิตภัณฑ์ครบกำหนดการระบุความต้องการของระบบข้อกำหนดของระบบย่อยและข้อกำหนดของหน่วยทั้งหมดจะทำในขั้นตอนนี้
ระยะนี้ยังรวมถึงการทำความเข้าใจข้อกำหนดของระบบโดยการสื่อสารอย่างต่อเนื่องระหว่างลูกค้าและนักวิเคราะห์ระบบ ในตอนท้ายของเกลียวผลิตภัณฑ์จะถูกนำไปใช้ในตลาดที่ระบุ
ออกแบบ
ขั้นตอนการออกแบบเริ่มต้นด้วยการออกแบบแนวความคิดในเกลียวพื้นฐานและเกี่ยวข้องกับการออกแบบสถาปัตยกรรมการออกแบบเชิงตรรกะของโมดูลการออกแบบผลิตภัณฑ์ทางกายภาพและการออกแบบขั้นสุดท้ายในเกลียวที่ตามมา
สร้างหรือสร้าง
ขั้นตอนการสร้างหมายถึงการผลิตผลิตภัณฑ์ซอฟต์แวร์จริงในทุกๆเกลียว ในขั้นพื้นฐานเมื่อนึกถึงผลิตภัณฑ์และการออกแบบกำลังได้รับการพัฒนา POC (Proof of Concept) ได้รับการพัฒนาในขั้นตอนนี้เพื่อรับคำติชมของลูกค้า
จากนั้นในเกลียวที่ตามมาด้วยความชัดเจนที่สูงขึ้นเกี่ยวกับข้อกำหนดและรายละเอียดการออกแบบโมเดลการทำงานของซอฟต์แวร์ที่เรียกว่า build นั้นถูกสร้างขึ้นด้วยหมายเลขเวอร์ชัน งานสร้างเหล่านี้จะถูกส่งไปยังลูกค้าเพื่อขอความคิดเห็น
การประเมินผลและการวิเคราะห์ความเสี่ยง
การวิเคราะห์ความเสี่ยงรวมถึงการระบุการประมาณและการตรวจสอบความเป็นไปได้ทางเทคนิคและความเสี่ยงด้านการจัดการเช่นการเลื่อนหลุดของกำหนดการและต้นทุนที่ล้น หลังจากทดสอบบิลด์เมื่อสิ้นสุดการทำซ้ำครั้งแรกลูกค้าจะประเมินซอฟต์แวร์และแสดงความคิดเห็น
ภาพประกอบต่อไปนี้เป็นการแสดง Spiral Model ซึ่งแสดงรายการกิจกรรมในแต่ละเฟส
จากการประเมินของลูกค้าขั้นตอนการพัฒนาซอฟต์แวร์จะเข้าสู่การทำซ้ำครั้งต่อไปและต่อมาเป็นไปตามแนวทางเชิงเส้นเพื่อใช้คำติชมที่ลูกค้าแนะนำ กระบวนการของการทำซ้ำตามเกลียวจะดำเนินต่อไปตลอดอายุของซอฟต์แวร์
แอพพลิเคชั่น Spiral Model
Spiral Model ใช้กันอย่างแพร่หลายในอุตสาหกรรมซอฟต์แวร์เนื่องจากสอดคล้องกับกระบวนการพัฒนาตามธรรมชาติของผลิตภัณฑ์ใด ๆ นั่นคือการเรียนรู้อย่างมีวุฒิภาวะซึ่งเกี่ยวข้องกับความเสี่ยงขั้นต่ำสำหรับลูกค้าและ บริษัท ผู้พัฒนา
คำแนะนำต่อไปนี้อธิบายการใช้งาน Spiral Model โดยทั่วไป -
เมื่อมีข้อ จำกัด ด้านงบประมาณและการประเมินความเสี่ยงเป็นสิ่งสำคัญ
สำหรับโครงการที่มีความเสี่ยงปานกลางถึงสูง
ความมุ่งมั่นของโครงการในระยะยาวเนื่องจากการเปลี่ยนแปลงที่อาจเกิดขึ้นกับลำดับความสำคัญทางเศรษฐกิจเมื่อความต้องการเปลี่ยนแปลงไปตามเวลา
ลูกค้าไม่แน่ใจในความต้องการของตนซึ่งมักจะเป็นเช่นนั้น
ข้อกำหนดมีความซับซ้อนและจำเป็นต้องมีการประเมินเพื่อให้ได้ความชัดเจน
กลุ่มผลิตภัณฑ์ใหม่ซึ่งควรออกเป็นระยะเพื่อให้ได้รับความคิดเห็นจากลูกค้าอย่างเพียงพอ
คาดว่าจะมีการเปลี่ยนแปลงที่สำคัญในผลิตภัณฑ์ระหว่างรอบการพัฒนา
Spiral Model - ข้อดีข้อเสีย
ข้อได้เปรียบของแบบจำลองวงจรการใช้งานแบบเกลียวคือช่วยให้สามารถเพิ่มองค์ประกอบของผลิตภัณฑ์ได้เมื่อพร้อมใช้งานหรือเป็นที่รู้จัก สิ่งนี้ทำให้มั่นใจได้ว่าไม่มีความขัดแย้งกับข้อกำหนดและการออกแบบก่อนหน้านี้
วิธีนี้สอดคล้องกับแนวทางที่มีการสร้างและเผยแพร่ซอฟต์แวร์หลายตัวซึ่งช่วยให้สามารถเปลี่ยนไปใช้กิจกรรมการบำรุงรักษาได้อย่างเป็นระเบียบ อีกแง่มุมที่ดีของวิธีนี้คือแบบจำลองเกลียวบังคับให้ผู้ใช้มีส่วนร่วมในช่วงแรกในความพยายามในการพัฒนาระบบ
ในอีกด้านหนึ่งต้องใช้การจัดการที่เข้มงวดมากในการผลิตผลิตภัณฑ์ดังกล่าวให้เสร็จสมบูรณ์และมีความเสี่ยงที่จะหมุนวนเป็นวงรอบที่ไม่มีกำหนด ดังนั้นวินัยของการเปลี่ยนแปลงและขอบเขตของการร้องขอการเปลี่ยนแปลงจึงมีความสำคัญมากในการพัฒนาและปรับใช้ผลิตภัณฑ์ให้สำเร็จ
ข้อดีของ Spiral SDLC Model มีดังนี้ -
การเปลี่ยนแปลงข้อกำหนดสามารถรองรับได้
อนุญาตให้ใช้งานต้นแบบได้อย่างกว้างขวาง
สามารถจับความต้องการได้แม่นยำยิ่งขึ้น
ผู้ใช้เห็นระบบตั้งแต่เนิ่นๆ
การพัฒนาสามารถแบ่งออกเป็นส่วนย่อย ๆ และส่วนที่มีความเสี่ยงสามารถพัฒนาได้ก่อนหน้านี้ซึ่งช่วยในการบริหารความเสี่ยงที่ดีขึ้น
ข้อเสียของ Spiral SDLC Model มีดังนี้ -
การจัดการมีความซับซ้อนมากขึ้น
อาจไม่ทราบจุดสิ้นสุดของโครงการในช่วงต้น
ไม่เหมาะสำหรับโครงการขนาดเล็กหรือมีความเสี่ยงต่ำและอาจมีราคาแพงสำหรับโครงการขนาดเล็ก
กระบวนการมีความซับซ้อน
Spiral อาจดำเนินไปเรื่อย ๆ
ขั้นตอนกลางจำนวนมากต้องใช้เอกสารมากเกินไป
V-model เป็นแบบจำลอง SDLC ที่การดำเนินการของกระบวนการเกิดขึ้นในลักษณะตามลำดับในรูปตัว V เป็นที่รู้จักกันในชื่อVerification and Validation model.
V-Model เป็นส่วนขยายของแบบจำลองน้ำตกและขึ้นอยู่กับความสัมพันธ์ของขั้นตอนการทดสอบสำหรับแต่ละขั้นตอนการพัฒนาที่เกี่ยวข้อง ซึ่งหมายความว่าสำหรับทุกๆเฟสในวงจรการพัฒนามีขั้นตอนการทดสอบที่เกี่ยวข้องโดยตรง นี่เป็นรูปแบบที่มีวินัยสูงและขั้นตอนต่อไปจะเริ่มหลังจากเสร็จสิ้นขั้นตอนก่อนหน้านี้เท่านั้น
V-Model - การออกแบบ
ภายใต้ V-Model จะมีการวางแผนขั้นตอนการทดสอบที่สอดคล้องกันของขั้นตอนการพัฒนาควบคู่กันไป ดังนั้นจึงมีขั้นตอนการยืนยันที่ด้านหนึ่งของขั้นตอน 'V' และขั้นตอนการตรวจสอบอีกด้านหนึ่ง Coding Phase เชื่อมต่อทั้งสองด้านของ V-Model
ภาพประกอบต่อไปนี้แสดงถึงระยะต่างๆใน V-Model ของ SDLC
V-Model - ขั้นตอนการยืนยัน
มีขั้นตอนการยืนยันหลายขั้นตอนใน V-Model แต่ละขั้นตอนเหล่านี้มีรายละเอียดอธิบายไว้ด้านล่าง
การวิเคราะห์ความต้องการทางธุรกิจ
นี่เป็นช่วงแรกของวงจรการพัฒนาที่เข้าใจความต้องการของผลิตภัณฑ์จากมุมมองของลูกค้า ขั้นตอนนี้เกี่ยวข้องกับการสื่อสารโดยละเอียดกับลูกค้าเพื่อให้เข้าใจถึงความคาดหวังและความต้องการที่แน่นอนของเขา นี่เป็นกิจกรรมที่สำคัญมากและต้องได้รับการจัดการที่ดีเนื่องจากลูกค้าส่วนใหญ่ไม่แน่ใจว่าต้องการอะไรกันแน่ acceptance test design planning เสร็จสิ้นในขั้นตอนนี้เนื่องจากข้อกำหนดทางธุรกิจสามารถใช้เป็นข้อมูลสำหรับการทดสอบการยอมรับได้
การออกแบบระบบ
เมื่อคุณมีข้อกำหนดของผลิตภัณฑ์ที่ชัดเจนและมีรายละเอียดแล้วก็ถึงเวลาออกแบบระบบที่สมบูรณ์ การออกแบบระบบจะมีความเข้าใจและรายละเอียดเกี่ยวกับการตั้งค่าฮาร์ดแวร์และการสื่อสารที่สมบูรณ์สำหรับผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนา แผนการทดสอบระบบได้รับการพัฒนาตามการออกแบบระบบ การทำเช่นนี้ในขั้นตอนก่อนหน้านี้จะทำให้มีเวลามากขึ้นสำหรับการดำเนินการทดสอบจริงในภายหลัง
การออกแบบสถาปัตยกรรม
ข้อกำหนดทางสถาปัตยกรรมได้รับการทำความเข้าใจและออกแบบในขั้นตอนนี้ โดยปกติจะมีการเสนอแนวทางทางเทคนิคมากกว่าหนึ่งวิธีและขึ้นอยู่กับความเป็นไปได้ทางเทคนิคและทางการเงินการตัดสินใจขั้นสุดท้ายจะดำเนินการ การออกแบบระบบแบ่งออกเป็นโมดูลที่มีฟังก์ชันการทำงานที่แตกต่างกันออกไป นี้เรียกอีกอย่างว่าHigh Level Design (HLD).
การถ่ายโอนข้อมูลและการสื่อสารระหว่างโมดูลภายในและกับโลกภายนอก (ระบบอื่น ๆ ) เป็นที่เข้าใจและกำหนดไว้อย่างชัดเจนในขั้นตอนนี้ ด้วยข้อมูลนี้การทดสอบการรวมสามารถออกแบบและจัดทำเป็นเอกสารในขั้นตอนนี้
การออกแบบโมดูล
ในขั้นตอนนี้จะมีการระบุการออกแบบภายในโดยละเอียดสำหรับโมดูลระบบทั้งหมดซึ่งเรียกว่า Low Level Design (LLD). สิ่งสำคัญคือการออกแบบจะเข้ากันได้กับโมดูลอื่น ๆ ในสถาปัตยกรรมระบบและระบบภายนอกอื่น ๆ การทดสอบหน่วยเป็นส่วนสำคัญของกระบวนการพัฒนาใด ๆ และช่วยขจัดข้อบกพร่องและข้อผิดพลาดสูงสุดในระยะเริ่มต้น การทดสอบหน่วยเหล่านี้สามารถออกแบบได้ในขั้นตอนนี้โดยอาศัยการออกแบบโมดูลภายใน
เฟสการเข้ารหัส
การเข้ารหัสจริงของโมดูลระบบที่ออกแบบในขั้นตอนการออกแบบจะถูกนำมาใช้ในเฟสการเข้ารหัส ภาษาโปรแกรมที่เหมาะสมที่สุดจะพิจารณาจากข้อกำหนดของระบบและสถาปัตยกรรม
การเข้ารหัสจะดำเนินการตามหลักเกณฑ์และมาตรฐานการเข้ารหัส รหัสผ่านการตรวจสอบโค้ดจำนวนมากและได้รับการปรับแต่งเพื่อประสิทธิภาพสูงสุดก่อนที่จะตรวจสอบบิลด์สุดท้ายในที่เก็บ
ขั้นตอนการตรวจสอบ
ขั้นตอนการตรวจสอบที่แตกต่างกันใน V-Model มีรายละเอียดอธิบายไว้ด้านล่าง
การทดสอบหน่วย
การทดสอบหน่วยที่ออกแบบในขั้นตอนการออกแบบโมดูลจะดำเนินการกับรหัสในระหว่างขั้นตอนการตรวจสอบความถูกต้องนี้ การทดสอบหน่วยเป็นการทดสอบในระดับรหัสและช่วยกำจัดจุดบกพร่องในระยะเริ่มต้นแม้ว่าการทดสอบหน่วยจะไม่สามารถเปิดเผยข้อบกพร่องทั้งหมดได้
การทดสอบการผสานรวม
การทดสอบการรวมมีความเกี่ยวข้องกับขั้นตอนการออกแบบสถาปัตยกรรม การทดสอบการรวมจะดำเนินการเพื่อทดสอบการอยู่ร่วมกันและการสื่อสารของโมดูลภายในภายในระบบ
การทดสอบระบบ
การทดสอบระบบเกี่ยวข้องโดยตรงกับขั้นตอนการออกแบบระบบ การทดสอบระบบจะตรวจสอบการทำงานของระบบทั้งหมดและการสื่อสารของระบบที่อยู่ระหว่างการพัฒนากับระบบภายนอก ปัญหาความเข้ากันได้ของซอฟต์แวร์และฮาร์ดแวร์ส่วนใหญ่สามารถพบได้ในระหว่างการดำเนินการทดสอบระบบนี้
การทดสอบการยอมรับ
การทดสอบการยอมรับเกี่ยวข้องกับขั้นตอนการวิเคราะห์ความต้องการทางธุรกิจและเกี่ยวข้องกับการทดสอบผลิตภัณฑ์ในสภาพแวดล้อมของผู้ใช้ การทดสอบการยอมรับจะเปิดเผยปัญหาความเข้ากันได้กับระบบอื่น ๆ ที่มีอยู่ในสภาพแวดล้อมของผู้ใช้ นอกจากนี้ยังค้นพบปัญหาที่ไม่สามารถใช้งานได้เช่นข้อบกพร่องด้านโหลดและประสิทธิภาพในสภาพแวดล้อมของผู้ใช้จริง
V- รุ่น─แอปพลิเคชัน
แอปพลิเคชัน V- Model นั้นเกือบจะเหมือนกับโมเดลน้ำตกเนื่องจากทั้งสองโมเดลเป็นประเภทลำดับ ข้อกำหนดจะต้องชัดเจนมากก่อนที่โครงการจะเริ่มเพราะโดยปกติแล้วการกลับไปแก้ไขจะมีราคาแพง แบบจำลองนี้ใช้ในด้านการพัฒนาทางการแพทย์เนื่องจากเป็นโดเมนที่มีระเบียบวินัยอย่างเคร่งครัด
คำแนะนำต่อไปนี้เป็นสถานการณ์ที่เหมาะสมที่สุดในการใช้แอปพลิเคชัน V-Model
ข้อกำหนดได้รับการกำหนดไว้อย่างดีมีเอกสารชัดเจนและคงที่
คำจำกัดความของผลิตภัณฑ์มีเสถียรภาพ
เทคโนโลยีไม่หยุดนิ่งและเป็นที่เข้าใจกันดีของทีมงานโครงการ
ไม่มีข้อกำหนดที่คลุมเครือหรือไม่ได้กำหนดไว้
โครงการมีระยะสั้น
V-Model - ข้อดีข้อเสีย
ข้อดีของวิธี V-Model คือเข้าใจและนำไปใช้ได้ง่ายมาก ความเรียบง่ายของรุ่นนี้ยังช่วยให้จัดการได้ง่ายขึ้น ข้อเสียคือโมเดลไม่ยืดหยุ่นต่อการเปลี่ยนแปลงและในกรณีที่มีการเปลี่ยนแปลงข้อกำหนดซึ่งเป็นเรื่องปกติมากในโลกที่ไม่หยุดนิ่งในปัจจุบันการเปลี่ยนแปลงจะมีราคาแพงมาก
ข้อดีของวิธี V-Model มีดังนี้ -
นี่เป็นโมเดลที่มีระเบียบวินัยสูงและขั้นตอนจะเสร็จสมบูรณ์ทีละขั้นตอน
ทำงานได้ดีสำหรับโครงการขนาดเล็กที่เข้าใจข้อกำหนดเป็นอย่างดี
ง่ายและเข้าใจง่ายและใช้งาน
ง่ายต่อการจัดการเนื่องจากความแข็งแกร่งของแบบจำลอง แต่ละขั้นตอนจะมีการส่งมอบที่เฉพาะเจาะจงและกระบวนการตรวจสอบ
ข้อเสียของวิธี V-Model มีดังนี้ -
มีความเสี่ยงและความไม่แน่นอนสูง
ไม่ใช่รูปแบบที่ดีสำหรับโครงการที่ซับซ้อนและเชิงวัตถุ
รูปแบบที่ไม่ดีสำหรับโครงการที่ยาวนานและต่อเนื่อง
ไม่เหมาะสำหรับโครงการที่ข้อกำหนดมีความเสี่ยงในการเปลี่ยนแปลงปานกลางถึงสูง
เมื่อแอปพลิเคชันอยู่ในขั้นตอนการทดสอบแล้วจะเป็นการยากที่จะย้อนกลับและเปลี่ยนฟังก์ชันการทำงาน
ไม่มีการผลิตซอฟต์แวร์ที่ใช้งานได้จนกว่าจะถึงช่วงปลายวงจรชีวิต
โมเดลบิ๊กแบงเป็นโมเดล SDLC ที่เราไม่ได้ทำตามกระบวนการใด ๆ โดยเฉพาะ การพัฒนาเริ่มต้นด้วยเงินที่ต้องการและความพยายามเป็นอินพุตและผลลัพธ์คือซอฟต์แวร์ที่พัฒนาขึ้นซึ่งอาจเป็นหรือไม่ก็ได้ตามความต้องการของลูกค้า โมเดลบิ๊กแบงนี้ไม่เป็นไปตามกระบวนการ / ขั้นตอนและต้องมีการวางแผนเพียงเล็กน้อย แม้แต่ลูกค้าเองก็ไม่แน่ใจว่าเขาต้องการอะไรและมีการนำข้อกำหนดไปปฏิบัติทันทีโดยไม่ต้องวิเคราะห์มากนัก
โดยปกติโมเดลนี้จะใช้สำหรับโครงการขนาดเล็กที่ทีมพัฒนามีขนาดเล็กมาก
Big Bang Model ─การออกแบบและการประยุกต์ใช้
โมเดลบิ๊กแบงประกอบด้วยการมุ่งเน้นทรัพยากรที่เป็นไปได้ทั้งหมดในการพัฒนาซอฟต์แวร์และการเข้ารหัสโดยมีการวางแผนน้อยมากหรือไม่มีเลย ข้อกำหนดได้รับการทำความเข้าใจและนำไปใช้ตามที่มา การเปลี่ยนแปลงใด ๆ ที่จำเป็นอาจจำเป็นหรือไม่จำเป็นต้องปรับปรุงซอฟต์แวร์ทั้งหมด
แบบจำลองนี้เหมาะอย่างยิ่งสำหรับโครงการขนาดเล็กที่มีนักพัฒนาหนึ่งหรือสองคนทำงานร่วมกันและยังมีประโยชน์สำหรับโครงการด้านวิชาการหรือการฝึกปฏิบัติ เป็นรุ่นที่เหมาะสำหรับผลิตภัณฑ์ที่ไม่เข้าใจข้อกำหนดและไม่ระบุวันวางจำหน่ายสุดท้าย
โมเดลบิ๊กแบง - ข้อดีข้อเสีย
ข้อดีของโมเดลบิ๊กแบงนี้คือง่ายมากและต้องการการวางแผนน้อยมากหรือไม่มีเลย ง่ายต่อการจัดการและไม่จำเป็นต้องมีขั้นตอนที่เป็นทางการ
อย่างไรก็ตามโมเดลบิ๊กแบงเป็นโมเดลที่มีความเสี่ยงสูงมากและการเปลี่ยนแปลงข้อกำหนดหรือข้อกำหนดที่เข้าใจผิดอาจนำไปสู่การกลับรายการหรือยกเลิกโครงการโดยสิ้นเชิง เหมาะสำหรับงานที่ทำซ้ำ ๆ หรือโครงการขนาดเล็กที่มีความเสี่ยงน้อยที่สุด
ข้อดีของ Big Bang Model มีดังนี้ -
นี่เป็นแบบจำลองที่เรียบง่ายมาก
จำเป็นต้องมีการวางแผนเพียงเล็กน้อยหรือไม่มีเลย
ง่ายต่อการจัดการ
ต้องการทรัพยากรน้อยมาก
ให้ความยืดหยุ่นแก่นักพัฒนา
เป็นเครื่องมือช่วยในการเรียนรู้ที่ดีสำหรับผู้มาใหม่หรือนักเรียน
ข้อเสียของ Big Bang Model มีดังนี้ -
มีความเสี่ยงและความไม่แน่นอนสูงมาก
ไม่ใช่รูปแบบที่ดีสำหรับโครงการที่ซับซ้อนและเชิงวัตถุ
รูปแบบที่ไม่ดีสำหรับโครงการที่ยาวนานและต่อเนื่อง
อาจมีราคาแพงมากหากความต้องการเข้าใจผิด
แบบจำลอง Agile SDLC เป็นการผสมผสานระหว่างแบบจำลองกระบวนการซ้ำและแบบเพิ่มหน่วยโดยมุ่งเน้นที่ความสามารถในการปรับตัวของกระบวนการและความพึงพอใจของลูกค้าด้วยการส่งมอบผลิตภัณฑ์ซอฟต์แวร์ที่ใช้งานได้อย่างรวดเร็ว วิธีการแบบ Agile จะแบ่งผลิตภัณฑ์ออกเป็นงานสร้างทีละน้อย งานสร้างเหล่านี้มีให้ในการทำซ้ำ โดยทั่วไปการทำซ้ำแต่ละครั้งจะใช้เวลาประมาณหนึ่งถึงสามสัปดาห์ การทำซ้ำทุกครั้งเกี่ยวข้องกับทีมข้ามสายงานที่ทำงานพร้อมกันในพื้นที่ต่างๆเช่น -
- Planning
- การวิเคราะห์ความต้องการ
- Design
- Coding
- การทดสอบหน่วยและ
- การทดสอบการยอมรับ
ในตอนท้ายของการทำซ้ำผลิตภัณฑ์ที่ใช้งานได้จะแสดงต่อลูกค้าและผู้มีส่วนได้ส่วนเสียที่สำคัญ
Agile คืออะไร?
Agile model เชื่อว่าทุกโครงการต้องได้รับการจัดการที่แตกต่างกันและวิธีการที่มีอยู่จำเป็นต้องได้รับการปรับแต่งให้เหมาะสมกับความต้องการของโครงการมากที่สุด ใน Agile งานจะแบ่งออกเป็นกล่องเวลา (กรอบเวลาขนาดเล็ก) เพื่อส่งมอบคุณลักษณะเฉพาะสำหรับรุ่น
ใช้วิธีการทำซ้ำและการสร้างซอฟต์แวร์ที่ใช้งานได้จะถูกส่งมอบหลังจากการทำซ้ำแต่ละครั้ง แต่ละรุ่นจะเพิ่มขึ้นในแง่ของคุณสมบัติ โครงสร้างสุดท้ายมีคุณสมบัติทั้งหมดที่ลูกค้าต้องการ
นี่คือภาพประกอบแบบกราฟิกของ Agile Model -
กระบวนการคิดแบบ Agile เริ่มต้นในช่วงแรกของการพัฒนาซอฟต์แวร์และเริ่มเป็นที่นิยมเมื่อเวลาผ่านไปเนื่องจากความยืดหยุ่นและความสามารถในการปรับตัว
วิธีการแบบ Agile ที่ได้รับความนิยมมากที่สุด ได้แก่ Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development และ Dynamic Systems Development Method (DSDM) (1995) สิ่งเหล่านี้เรียกรวมกันว่าAgile Methodologiesหลังจากที่ Agile Manifesto ตีพิมพ์ในปี 2544
ต่อไปนี้เป็นหลักการของ Agile Manifesto -
Individuals and interactions - ในการพัฒนาแบบ Agile การจัดระเบียบตนเองและแรงจูงใจเป็นสิ่งสำคัญเช่นเดียวกับการโต้ตอบเช่นตำแหน่งร่วมและการเขียนโปรแกรมคู่
Working software - ซอฟต์แวร์สาธิตการทำงานถือเป็นวิธีที่ดีที่สุดในการสื่อสารกับลูกค้าเพื่อทำความเข้าใจความต้องการของพวกเขาแทนที่จะขึ้นอยู่กับเอกสารประกอบ
Customer collaboration - เนื่องจากไม่สามารถรวบรวมความต้องการได้อย่างสมบูรณ์ในช่วงเริ่มต้นของโครงการเนื่องจากปัจจัยต่างๆการปฏิสัมพันธ์กับลูกค้าอย่างต่อเนื่องจึงมีความสำคัญมากเพื่อให้ได้ข้อกำหนดของผลิตภัณฑ์ที่เหมาะสม
Responding to change - Agile Development มุ่งเน้นไปที่การตอบสนองอย่างรวดเร็วต่อการเปลี่ยนแปลงและการพัฒนาอย่างต่อเนื่อง
โมเดล SDLC ดั้งเดิมของ Agile Vs
Agile ขึ้นอยู่กับไฟล์ adaptive software development methodsในขณะที่แบบจำลอง SDLC แบบดั้งเดิมเช่นแบบจำลองน้ำตกจะขึ้นอยู่กับวิธีการคาดการณ์ ทีมคาดการณ์ในโมเดล SDLC แบบเดิมมักจะทำงานร่วมกับการวางแผนโดยละเอียดและมีการคาดการณ์ที่สมบูรณ์เกี่ยวกับงานและคุณสมบัติที่แน่นอนที่จะส่งมอบในอีกไม่กี่เดือนข้างหน้าหรือในช่วงอายุของผลิตภัณฑ์
วิธีการทำนายทั้งหมดขึ้นอยู่กับ requirement analysis and planningทำในช่วงเริ่มต้นของวงจร การเปลี่ยนแปลงใด ๆ ที่จะรวมเข้าด้วยกันต้องผ่านการจัดการควบคุมการเปลี่ยนแปลงที่เข้มงวดและการจัดลำดับความสำคัญ
Agile ใช้ไฟล์ adaptive approachในกรณีที่ไม่มีการวางแผนโดยละเอียดและมีความชัดเจนเกี่ยวกับงานในอนาคตในส่วนของคุณลักษณะที่ต้องพัฒนาเท่านั้น มีการพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะและทีมงานปรับให้เข้ากับความต้องการของผลิตภัณฑ์ที่เปลี่ยนแปลงแบบไดนามิก ผลิตภัณฑ์ได้รับการทดสอบบ่อยมากผ่านการทำซ้ำเพื่อลดความเสี่ยงที่จะเกิดความล้มเหลวครั้งใหญ่ในอนาคต
Customer Interactionเป็นกระดูกสันหลังของระเบียบวิธี Agile นี้และการสื่อสารแบบเปิดพร้อมเอกสารขั้นต่ำเป็นคุณสมบัติทั่วไปของสภาพแวดล้อมการพัฒนา Agile ทีมที่คล่องตัวทำงานด้วยความร่วมมืออย่างใกล้ชิดซึ่งกันและกันและส่วนใหญ่มักตั้งอยู่ในตำแหน่งทางภูมิศาสตร์เดียวกัน
Agile Model - ข้อดีข้อเสีย
วิธีการแบบ Agile กำลังได้รับการยอมรับอย่างกว้างขวางในโลกซอฟต์แวร์เมื่อเร็ว ๆ นี้ อย่างไรก็ตามวิธีนี้อาจไม่เหมาะกับผลิตภัณฑ์ทั้งหมดเสมอไป นี่คือข้อดีข้อเสียบางประการของโมเดล Agile
ข้อดีของ Agile Model มีดังนี้ -
เป็นแนวทางในการพัฒนาซอฟต์แวร์ที่เหมือนจริงมาก
ส่งเสริมการทำงานเป็นทีมและการฝึกอบรมข้ามสาย
ฟังก์ชันการทำงานสามารถพัฒนาได้อย่างรวดเร็วและแสดงให้เห็น
ความต้องการทรัพยากรเป็นขั้นต่ำ
เหมาะสำหรับความต้องการคงที่หรือเปลี่ยนแปลง
นำเสนอโซลูชันการทำงานบางส่วนในช่วงต้น
แบบอย่างที่ดีสำหรับสภาพแวดล้อมที่เปลี่ยนแปลงไปเรื่อย ๆ
กฎน้อยที่สุดเอกสารใช้งานได้ง่าย
เปิดใช้งานการพัฒนาและการส่งมอบพร้อมกันภายในบริบทที่วางแผนไว้โดยรวม
จำเป็นต้องมีการวางแผนเพียงเล็กน้อยหรือไม่มีเลย
ง่ายต่อการจัดการ
ให้ความยืดหยุ่นแก่นักพัฒนา
ข้อเสียของ Agile Model มีดังนี้ -
ไม่เหมาะสำหรับการจัดการการอ้างอิงที่ซับซ้อน
มีความเสี่ยงมากขึ้นต่อความยั่งยืนการบำรุงรักษาและความสามารถในการขยาย
แผนโดยรวมผู้นำที่คล่องตัวและการปฏิบัติ PM แบบว่องไวเป็นสิ่งจำเป็นโดยที่แผนดังกล่าวจะไม่ได้ผล
การจัดการการจัดส่งที่เข้มงวดกำหนดขอบเขตฟังก์ชันการทำงานที่จะจัดส่งและการปรับเปลี่ยนเพื่อให้เป็นไปตามกำหนดเวลา
ขึ้นอยู่กับปฏิสัมพันธ์ของลูกค้าเป็นอย่างมากดังนั้นหากลูกค้าไม่ชัดเจนทีมอาจขับเคลื่อนไปในทิศทางที่ไม่ถูกต้อง
มีการพึ่งพาส่วนบุคคลสูงมากเนื่องจากมีการสร้างเอกสารขั้นต่ำ
การถ่ายโอนเทคโนโลยีให้กับสมาชิกในทีมใหม่อาจเป็นเรื่องที่ท้าทายมากเนื่องจากขาดเอกสารประกอบ
RAD (Rapid Application Development)แบบจำลองขึ้นอยู่กับการสร้างต้นแบบและการพัฒนาซ้ำโดยไม่มีการวางแผนเฉพาะที่เกี่ยวข้อง กระบวนการเขียนซอฟต์แวร์นั้นเกี่ยวข้องกับการวางแผนที่จำเป็นสำหรับการพัฒนาผลิตภัณฑ์
การพัฒนาแอปพลิเคชันอย่างรวดเร็วมุ่งเน้นไปที่การรวบรวมความต้องการของลูกค้าผ่านการประชุมเชิงปฏิบัติการหรือกลุ่มเป้าหมายการทดสอบต้นแบบโดยลูกค้าในระยะเริ่มต้นโดยใช้แนวคิดแบบวนซ้ำการนำต้นแบบที่มีอยู่มาใช้ซ้ำ (ส่วนประกอบ) การผสานรวมอย่างต่อเนื่องและการจัดส่งที่รวดเร็ว
RAD คืออะไร?
การพัฒนาแอปพลิเคชันอย่างรวดเร็วเป็นวิธีการพัฒนาซอฟต์แวร์ที่ใช้การวางแผนเพียงเล็กน้อยเพื่อสนับสนุนการสร้างต้นแบบอย่างรวดเร็ว ต้นแบบคือรูปแบบการทำงานที่เทียบเท่ากับส่วนประกอบของผลิตภัณฑ์
ในรุ่น RAD โมดูลการทำงานได้รับการพัฒนาควบคู่กันไปในรูปแบบต้นแบบและถูกรวมเข้าด้วยกันเพื่อสร้างผลิตภัณฑ์ที่สมบูรณ์เพื่อการจัดส่งผลิตภัณฑ์ที่รวดเร็วขึ้น เนื่องจากไม่มีการวางแผนล่วงหน้าโดยละเอียดจึงทำให้รวมการเปลี่ยนแปลงภายในกระบวนการพัฒนาได้ง่ายขึ้น
โครงการ RAD เป็นไปตามแบบจำลองซ้ำ ๆ และแบบเพิ่มหน่วยและมีทีมงานขนาดเล็กซึ่งประกอบด้วยนักพัฒนาผู้เชี่ยวชาญด้านโดเมนตัวแทนลูกค้าและทรัพยากรไอทีอื่น ๆ ที่ทำงานอย่างก้าวหน้าในองค์ประกอบหรือต้นแบบของพวกเขา
สิ่งสำคัญที่สุดที่จะทำให้โมเดลนี้ประสบความสำเร็จคือต้องแน่ใจว่าต้นแบบที่พัฒนานั้นสามารถนำกลับมาใช้ใหม่ได้
การออกแบบโมเดล RAD
แบบจำลอง RAD จะกระจายขั้นตอนการวิเคราะห์การออกแบบการสร้างและการทดสอบเป็นชุดของวงจรการพัฒนาแบบวนซ้ำสั้น ๆ
ต่อไปนี้เป็นขั้นตอนต่างๆของ RAD Model -
การสร้างแบบจำลองทางธุรกิจ
รูปแบบธุรกิจสำหรับผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนาได้รับการออกแบบในแง่ของการไหลเวียนของข้อมูลและการกระจายข้อมูลระหว่างช่องทางธุรกิจต่างๆ การวิเคราะห์ธุรกิจที่สมบูรณ์จะดำเนินการเพื่อค้นหาข้อมูลที่สำคัญสำหรับธุรกิจวิธีการรับข้อมูลวิธีการและเวลาที่ประมวลผลข้อมูลและอะไรคือปัจจัยที่ผลักดันการไหลของข้อมูลที่ประสบความสำเร็จ
การสร้างแบบจำลองข้อมูล
ข้อมูลที่รวบรวมในขั้นตอนการสร้างแบบจำลองทางธุรกิจจะถูกตรวจสอบและวิเคราะห์เพื่อสร้างชุดของออบเจ็กต์ข้อมูลที่มีความสำคัญต่อธุรกิจ มีการระบุและกำหนดคุณลักษณะของชุดข้อมูลทั้งหมด ความสัมพันธ์ระหว่างออบเจ็กต์ข้อมูลเหล่านี้ถูกสร้างและกำหนดโดยละเอียดตามความเกี่ยวข้องกับโมเดลธุรกิจ
การสร้างแบบจำลองกระบวนการ
ชุดออบเจ็กต์ข้อมูลที่กำหนดไว้ในขั้นตอนการสร้างแบบจำลองข้อมูลจะถูกแปลงเพื่อสร้างโฟลว์ข้อมูลทางธุรกิจที่จำเป็นในการบรรลุวัตถุประสงค์ทางธุรกิจที่เฉพาะเจาะจงตามรูปแบบธุรกิจ รูปแบบกระบวนการสำหรับการเปลี่ยนแปลงหรือการปรับปรุงชุดออบเจ็กต์ข้อมูลถูกกำหนดไว้ในเฟสนี้ คำอธิบายกระบวนการสำหรับการเพิ่มการลบการเรียกหรือการแก้ไขอ็อบเจ็กต์ข้อมูลจะได้รับ
การสร้างแอปพลิเคชัน
ระบบจริงถูกสร้างขึ้นและการเข้ารหัสทำได้โดยใช้เครื่องมืออัตโนมัติในการแปลงกระบวนการและแบบจำลองข้อมูลเป็นต้นแบบจริง
การทดสอบและการหมุนเวียน
เวลาในการทดสอบโดยรวมจะลดลงในโมเดล RAD เนื่องจากต้นแบบได้รับการทดสอบอย่างอิสระในระหว่างการทำซ้ำทุกครั้ง อย่างไรก็ตามการไหลของข้อมูลและการเชื่อมต่อระหว่างส่วนประกอบทั้งหมดจะต้องได้รับการทดสอบอย่างละเอียดพร้อมการครอบคลุมการทดสอบที่สมบูรณ์ เนื่องจากส่วนประกอบการเขียนโปรแกรมส่วนใหญ่ได้รับการทดสอบแล้วจึงช่วยลดความเสี่ยงของปัญหาหลัก ๆ
ภาพประกอบต่อไปนี้อธิบายถึง RAD Model โดยละเอียด
RAD Model กับ SDLC แบบดั้งเดิม
SDLC แบบดั้งเดิมเป็นไปตามแบบจำลองกระบวนการที่เข้มงวดโดยเน้นที่การวิเคราะห์ความต้องการและการรวบรวมก่อนเริ่มการเข้ารหัส สร้างแรงกดดันให้กับลูกค้าในการลงนามในข้อกำหนดก่อนที่โครงการจะเริ่มขึ้นและลูกค้าไม่ได้รับความรู้สึกของผลิตภัณฑ์เนื่องจากไม่มีงานสร้างมาเป็นเวลานาน
ลูกค้าอาจต้องการการเปลี่ยนแปลงบางอย่างหลังจากที่เขาได้เห็นซอฟต์แวร์ อย่างไรก็ตามกระบวนการเปลี่ยนแปลงค่อนข้างเข้มงวดและอาจไม่สามารถรวมการเปลี่ยนแปลงที่สำคัญในผลิตภัณฑ์ใน SDLC แบบเดิมได้
โมเดล RAD มุ่งเน้นไปที่การส่งมอบโมเดลการทำงานซ้ำ ๆ และแบบเพิ่มขึ้นให้กับลูกค้า ส่งผลให้เกิดการส่งมอบอย่างรวดเร็วไปยังลูกค้าและการมีส่วนร่วมของลูกค้าในระหว่างวงจรการพัฒนาผลิตภัณฑ์ที่สมบูรณ์ช่วยลดความเสี่ยงจากการไม่เป็นไปตามข้อกำหนดของผู้ใช้
RAD Model - แอปพลิเคชัน
แบบจำลอง RAD สามารถนำไปใช้กับโครงการที่สามารถทำการแยกส่วนที่ชัดเจนได้ หากไม่สามารถแยกโครงการออกเป็นโมดูลได้ RAD อาจล้มเหลว
ตัวชี้ต่อไปนี้อธิบายสถานการณ์ทั่วไปที่สามารถใช้ RAD ได้ -
ควรใช้ RAD เฉพาะเมื่อระบบสามารถโมดูลาร์เพื่อส่งมอบในลักษณะที่เพิ่มขึ้น
ควรใช้หากมีนักออกแบบที่มีความพร้อมสูงสำหรับการสร้างแบบจำลอง
ควรใช้ในกรณีที่งบประมาณอนุญาตให้ใช้เครื่องมือสร้างโค้ดอัตโนมัติเท่านั้น
ควรเลือกแบบจำลอง RAD SDLC ก็ต่อเมื่อผู้เชี่ยวชาญด้านโดเมนมีความรู้ทางธุรกิจที่เกี่ยวข้องเท่านั้น
ควรใช้ในกรณีที่ข้อกำหนดมีการเปลี่ยนแปลงในระหว่างโครงการและต้นแบบการทำงานจะถูกนำเสนอให้กับลูกค้าในการทำซ้ำเล็กน้อยภายใน 2-3 เดือน
RAD Model - ข้อดีข้อเสีย
แบบจำลอง RAD ช่วยให้จัดส่งได้อย่างรวดเร็วเนื่องจากช่วยลดเวลาในการพัฒนาโดยรวมเนื่องจากความสามารถในการนำกลับมาใช้ใหม่ของส่วนประกอบและการพัฒนาแบบขนาน RAD ทำงานได้ดีก็ต่อเมื่อมีวิศวกรที่มีทักษะสูงและลูกค้ายังมุ่งมั่นที่จะบรรลุต้นแบบตามเป้าหมายในกรอบเวลาที่กำหนด หากขาดความมุ่งมั่นในด้านใดด้านหนึ่งโมเดลอาจล้มเหลว
ข้อดีของ RAD Model มีดังนี้ -
การเปลี่ยนแปลงข้อกำหนดสามารถรองรับได้
ความคืบหน้าสามารถวัดได้
เวลาในการทำซ้ำอาจสั้นโดยใช้เครื่องมือ RAD ที่มีประสิทธิภาพ
ผลผลิตที่มีคนจำนวนน้อยลงในเวลาอันสั้น
ลดเวลาในการพัฒนา
เพิ่มความสามารถในการใช้ซ้ำของส่วนประกอบ
การตรวจสอบเบื้องต้นเกิดขึ้นอย่างรวดเร็ว
กระตุ้นความคิดเห็นของลูกค้า
การบูรณาการตั้งแต่เริ่มต้นช่วยแก้ปัญหาการผสานรวมได้มากมาย
ข้อเสียของ RAD Model มีดังนี้ -
การพึ่งพาสมาชิกในทีมที่แข็งแกร่งทางเทคนิคในการระบุความต้องการทางธุรกิจ
เฉพาะระบบที่สามารถสร้างโมดูลาร์ได้โดยใช้ RAD
ต้องการนักพัฒนา / นักออกแบบที่มีทักษะสูง
การพึ่งพาทักษะการสร้างแบบจำลองสูง
ไม่สามารถใช้กับโครงการที่ถูกกว่าได้เนื่องจากต้นทุนในการสร้างแบบจำลองและการสร้างรหัสอัตโนมัตินั้นสูงมาก
ความซับซ้อนในการจัดการมีมากขึ้น
เหมาะสำหรับระบบที่เป็นส่วนประกอบและปรับขนาดได้
ต้องมีส่วนร่วมของผู้ใช้ตลอดวงจรชีวิต
เหมาะสำหรับโครงการที่ต้องการเวลาในการพัฒนาสั้นลง
การสร้างต้นแบบซอฟต์แวร์หมายถึงการสร้างต้นแบบแอปพลิเคชันซอฟต์แวร์ซึ่งแสดงฟังก์ชันการทำงานของผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนา แต่อาจไม่ได้ยึดตรรกะที่แน่นอนของซอฟต์แวร์ดั้งเดิม
การสร้างต้นแบบซอฟต์แวร์กำลังได้รับความนิยมอย่างมากในฐานะรูปแบบการพัฒนาซอฟต์แวร์เนื่องจากช่วยให้เข้าใจความต้องการของลูกค้าในช่วงแรกของการพัฒนา ช่วยรับข้อเสนอแนะที่มีคุณค่าจากลูกค้าและช่วยให้นักออกแบบซอฟต์แวร์และนักพัฒนาเข้าใจเกี่ยวกับสิ่งที่คาดหวังจากผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนา
Software Prototyping คืออะไร?
Prototype เป็นรูปแบบการทำงานของซอฟต์แวร์ที่มีฟังก์ชันการทำงานที่ จำกัด ต้นแบบไม่ได้ยึดตรรกะที่แน่นอนที่ใช้ในแอปพลิเคชันซอฟต์แวร์จริงเสมอไปและเป็นความพยายามพิเศษที่จะต้องพิจารณาภายใต้การประมาณค่าความพยายาม
การสร้างต้นแบบใช้เพื่อให้ผู้ใช้ประเมินข้อเสนอของนักพัฒนาและทดลองใช้ก่อนนำไปใช้งาน นอกจากนี้ยังช่วยทำความเข้าใจข้อกำหนดที่เฉพาะเจาะจงของผู้ใช้และผู้พัฒนาอาจไม่ได้รับการพิจารณาในระหว่างการออกแบบผลิตภัณฑ์
ต่อไปนี้เป็นแนวทางขั้นตอนที่อธิบายเพื่อออกแบบต้นแบบซอฟต์แวร์
การระบุความต้องการขั้นพื้นฐาน
ขั้นตอนนี้เกี่ยวข้องกับการทำความเข้าใจข้อกำหนดพื้นฐานของผลิตภัณฑ์โดยเฉพาะในแง่ของอินเทอร์เฟซผู้ใช้ รายละเอียดที่ซับซ้อนมากขึ้นของการออกแบบภายในและลักษณะภายนอกเช่นประสิทธิภาพและความปลอดภัยสามารถละเลยได้ในขั้นตอนนี้
การพัฒนา Prototype เริ่มต้น
Prototype เริ่มต้นได้รับการพัฒนาในขั้นตอนนี้ซึ่งมีการจัดแสดงข้อกำหนดพื้นฐานและอินเทอร์เฟซสำหรับผู้ใช้ คุณสมบัติเหล่านี้อาจไม่ทำงานในลักษณะเดียวกันกับภายในซอฟต์แวร์ที่พัฒนาขึ้นจริง ในขณะที่วิธีแก้ปัญหานั้นใช้เพื่อให้รูปลักษณ์และความรู้สึกเหมือนกันกับลูกค้าในต้นแบบที่พัฒนาขึ้น
การทบทวนต้นแบบ
จากนั้นต้นแบบที่พัฒนาขึ้นจะถูกนำเสนอต่อลูกค้าและผู้มีส่วนได้ส่วนเสียที่สำคัญอื่น ๆ ในโครงการ ความคิดเห็นจะถูกรวบรวมในลักษณะที่เป็นระเบียบและใช้สำหรับการปรับปรุงเพิ่มเติมในผลิตภัณฑ์ที่อยู่ระหว่างการพัฒนา
แก้ไขและปรับปรุงต้นแบบ
ข้อเสนอแนะและข้อคิดเห็นของบทวิจารณ์จะมีการหารือในขั้นตอนนี้และการเจรจาบางอย่างเกิดขึ้นกับลูกค้าโดยพิจารณาจากปัจจัยต่างๆเช่นข้อ จำกัด ด้านเวลาและงบประมาณและความเป็นไปได้ทางเทคนิคของการนำไปใช้จริง การเปลี่ยนแปลงที่ยอมรับจะรวมอยู่ใน Prototype ใหม่ที่พัฒนาขึ้นอีกครั้งและวงจรจะทำซ้ำจนกว่าจะตรงตามความคาดหวังของลูกค้า
ต้นแบบสามารถมีขนาดแนวนอนหรือแนวตั้ง ต้นแบบแนวนอนแสดงอินเทอร์เฟซผู้ใช้สำหรับผลิตภัณฑ์และให้มุมมองที่กว้างขึ้นของระบบทั้งหมดโดยไม่เน้นที่ฟังก์ชันภายใน อีกด้านหนึ่งต้นแบบแนวตั้งคือการอธิบายรายละเอียดของฟังก์ชันเฉพาะหรือระบบย่อยในผลิตภัณฑ์
วัตถุประสงค์ของต้นแบบทั้งแนวนอนและแนวตั้งนั้นแตกต่างกัน ต้นแบบแนวนอนใช้เพื่อรับข้อมูลเพิ่มเติมเกี่ยวกับระดับอินเทอร์เฟซผู้ใช้และข้อกำหนดทางธุรกิจ มันยังสามารถนำเสนอในการสาธิตการขายเพื่อให้ธุรกิจในตลาด ต้นแบบแนวตั้งเป็นลักษณะทางเทคนิคและใช้เพื่อดูรายละเอียดของการทำงานที่แน่นอนของระบบย่อย ตัวอย่างเช่นข้อกำหนดของฐานข้อมูลการโต้ตอบและการประมวลผลข้อมูลโหลดในระบบย่อยที่กำหนด
การสร้างต้นแบบซอฟต์แวร์ - ประเภท
มีประเภทของซอฟต์แวร์ต้นแบบที่ใช้ในอุตสาหกรรม ต่อไปนี้เป็นประเภทการสร้างต้นแบบซอฟต์แวร์ที่สำคัญที่ใช้กันอย่างแพร่หลาย -
การทิ้ง / การสร้างต้นแบบอย่างรวดเร็ว
การสร้างต้นแบบแบบโยนทิ้งเรียกอีกอย่างว่าการสร้างต้นแบบที่สิ้นสุดลงอย่างรวดเร็วหรือปิด การสร้างต้นแบบประเภทนี้ใช้ความพยายามเพียงเล็กน้อยกับการวิเคราะห์ความต้องการขั้นต่ำเพื่อสร้างต้นแบบ เมื่อเข้าใจข้อกำหนดที่แท้จริงแล้วต้นแบบจะถูกทิ้งและระบบจริงได้รับการพัฒนาโดยมีความเข้าใจที่ชัดเจนมากเกี่ยวกับความต้องการของผู้ใช้
การสร้างต้นแบบเชิงวิวัฒนาการ
การสร้างต้นแบบเชิงวิวัฒนาการหรือที่เรียกว่าการสร้างต้นแบบ breadboard นั้นขึ้นอยู่กับการสร้างต้นแบบที่ใช้งานได้จริงโดยมีฟังก์ชันการทำงานน้อยที่สุดในช่วงแรก ต้นแบบที่พัฒนาขึ้นเป็นหัวใจสำคัญของต้นแบบในอนาคตซึ่งระบบทั้งหมดถูกสร้างขึ้น ด้วยการใช้การสร้างต้นแบบวิวัฒนาการข้อกำหนดที่เข้าใจกันดีจะรวมอยู่ในต้นแบบและข้อกำหนดจะถูกเพิ่มตามและเมื่อมีความเข้าใจ
การสร้างต้นแบบที่เพิ่มขึ้น
การสร้างต้นแบบแบบเพิ่มหน่วยหมายถึงการสร้างต้นแบบที่ใช้งานได้หลายระบบของระบบย่อยต่างๆแล้วรวมต้นแบบที่มีอยู่ทั้งหมดเข้าด้วยกันเพื่อสร้างระบบที่สมบูรณ์
การสร้างต้นแบบที่รุนแรง
การสร้างต้นแบบขั้นสูงสุดใช้ในโดเมนการพัฒนาเว็บ ประกอบด้วยสามขั้นตอนตามลำดับ ขั้นแรกต้นแบบพื้นฐานที่มีหน้าที่มีอยู่ทั้งหมดจะถูกนำเสนอในรูปแบบ HTML จากนั้นการประมวลผลข้อมูลจะถูกจำลองโดยใช้ชั้นบริการต้นแบบ ในที่สุดบริการจะถูกนำไปใช้และรวมเข้ากับต้นแบบขั้นสุดท้าย กระบวนการนี้เรียกว่า Extreme Prototyping ซึ่งใช้เพื่อดึงดูดความสนใจไปยังขั้นตอนที่สองของกระบวนการซึ่ง UI ที่ใช้งานได้เต็มรูปแบบได้รับการพัฒนาโดยคำนึงถึงบริการจริงเพียงเล็กน้อย
การสร้างต้นแบบซอฟต์แวร์ - แอปพลิเคชัน
Software Prototyping มีประโยชน์มากที่สุดในการพัฒนาระบบที่มีปฏิสัมพันธ์กับผู้ใช้ในระดับสูงเช่นระบบออนไลน์ ระบบที่ต้องการให้ผู้ใช้กรอกแบบฟอร์มหรือผ่านหน้าจอต่างๆก่อนที่จะประมวลผลข้อมูลสามารถใช้การสร้างต้นแบบได้อย่างมีประสิทธิภาพเพื่อให้ได้รูปลักษณ์ที่แน่นอนก่อนที่จะพัฒนาซอฟต์แวร์จริง
ซอฟต์แวร์ที่เกี่ยวข้องกับการประมวลผลข้อมูลมากเกินไปและฟังก์ชันส่วนใหญ่อยู่ภายในโดยมีอินเทอร์เฟซผู้ใช้น้อยมากมักไม่ได้รับประโยชน์จากการสร้างต้นแบบ การพัฒนาต้นแบบอาจเป็นค่าใช้จ่ายเพิ่มเติมในโครงการดังกล่าวและอาจต้องใช้ความพยายามมากเป็นพิเศษ
การสร้างต้นแบบซอฟต์แวร์ - ข้อดีข้อเสีย
การสร้างต้นแบบซอฟต์แวร์ถูกนำมาใช้ในกรณีทั่วไปและควรใช้การตัดสินใจอย่างรอบคอบเพื่อให้ความพยายามในการสร้างต้นแบบเพิ่มมูลค่าให้กับซอฟต์แวร์ขั้นสุดท้ายที่พัฒนาขึ้น แบบจำลองมีข้อดีข้อเสียของตัวเองดังต่อไปนี้
ข้อดีของ Prototyping Model มีดังนี้ -
การมีส่วนร่วมของผู้ใช้ที่เพิ่มขึ้นในผลิตภัณฑ์ก่อนการใช้งาน
เนื่องจากมีการแสดงรูปแบบการทำงานของระบบผู้ใช้จะได้รับความเข้าใจที่ดีขึ้นเกี่ยวกับระบบที่กำลังพัฒนา
ลดเวลาและค่าใช้จ่ายเนื่องจากสามารถตรวจพบข้อบกพร่องได้เร็วกว่ามาก
คำติชมของผู้ใช้ที่รวดเร็วขึ้นจะนำไปสู่การแก้ปัญหาที่ดี
ฟังก์ชันที่ขาดหายไปสามารถระบุได้อย่างง่ายดาย
สามารถระบุฟังก์ชันที่สับสนหรือยากได้
ข้อเสียของ Prototyping Model มีดังนี้ -
ความเสี่ยงจากการวิเคราะห์ความต้องการไม่เพียงพอเนื่องจากการพึ่งพาต้นแบบมากเกินไป
ผู้ใช้อาจสับสนในต้นแบบและระบบจริง
ในทางปฏิบัติวิธีการนี้อาจเพิ่มความซับซ้อนของระบบเนื่องจากขอบเขตของระบบอาจขยายไปไกลกว่าแผนเดิม
นักพัฒนาอาจพยายามนำต้นแบบที่มีอยู่กลับมาใช้ใหม่เพื่อสร้างระบบจริงแม้ว่าจะไม่สามารถทำได้ในทางเทคนิคก็ตาม
ความพยายามในการสร้างต้นแบบอาจมากเกินไปหากไม่ได้รับการตรวจสอบอย่างเหมาะสม