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

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

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

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

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

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

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

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

แบบจำลองสไปรัล (The Spiral Model) แบบจำลองสไปรัลเป็นผลงงานของ Boehm [BOE88] เป็นแบบจำลองกระบวนการเชิงวิวัฒน์ที่ รวมเอาลักษณะวนซ้ำของการสร้างต้นแบบกับการทำงานอย่างเป็นขั้นตอน และมีการควบคุมแบบจำลอง น้ำตกเข้าด้วยกัน แบบจำลองสไปรัลเหมาะสมกับการพัฒนาระบบขนาดใหญ่ เพราะซอฟต์แวร์วิวัฒน์ไปเมื่อ กระบวนการก้าวหน้าไปทั้งลูกค้าและผู้พัฒนามีความเข้าใจดีขึ้น

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

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

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

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

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

ความกังวลข้ามส่วน ความต้องการทางแง่มุม นิยามกังวลข้าม ส่วนที่มีผลต่อสถาปัตยกรรมซอฟต์แวร์โดยรวม บางครั้งการพัฒนาเชิง แง่มุมก็ถูกเรียกว่าการโปรแกรมเชิงแง่มุมซึ่งเป็นศัพท์ทางวิศวกรรม ซอฟต์แวร์ใหม่ที่กำหนดกระบวนการสำหรับการนิยามการกำหนดการ การออกแบบและการสร้างแง่มุม อันเป็นกลไกเหนือไปจากซับรูทีนและ การถ่ายทอดคุณสมบัติ สำหรับจำกัดที่ของการแสดงออกซึ่งความกังวล ข้ามส่วน กระบวนการยูนิฟายด์ (The Unified Process-UP) ผู้ประดิษฐ์กระบวนการยูนิฟายด์ Ivar Jacobson,Grady Booch,Jambaugh [JAC99] ได้กล่าวถึงความจำนวนการเป็นในการใช้ กระบวนการ ที่ขับเคลื่อนด้วยยูสเคส รวมศูนย์สถาปัตยกรรม มี ลักษณะทำวนซ้ำและค่อยเพิ่มขึ้น กระบวนการยูนิฟายด์ เป็นความพยายามดึงเอาลักษณะที่ดีที่สุด ของกระบวนการดั้งเดิมออกมา แต่ปรับใช้ในลักษณะที่อิมพลีเม้นต์ หลักการของการพัฒนาซอฟต์แวร์อาไจล์กระบวนการยูนิฟายด์ให้ ความสำคัญกับสื่อสารลูกค้า และวิธีนำเอาระบบจากแง่มุมลูกค้าคือ ยูส เคสมาสร้างระบบ เน้นบทบาทสำคัญสถาปัตยกรรมซอฟต์แวร์ และ ช่วยวิศวกรให้มองเห็นเป้าหมายที่ถูกต้อ

ประวัติโดยย่อ ช่วงเวลาระหว่างทศวรรษ 1980 และต้น 1990 วิธีการใช้เชิงวัตถุ ภาษาได้รับความนิยมในหมู่วิศวกรซอฟต์แวร์มาก ในช่วงเวลานี้มีการ นำเสนอวิธีการอันหลากหลายของการวิเคราะห์เชิงวัตถุ และการออกแบบ วัตถุ ช่วงต้นทศวรรษ 1990 Jame Rumbaugh,Grady Booch,Ivar Jacobsom เริ่มงานที่รวมเอาลักษณะที่ดีที่สุดของแต่ละวิธีคือ วิธีการยูนิ ฟายด์ และเอาลักษณะเพิ่มเติมที่แนะนำโดยผู้เชียวชาญด้านวัตถุ ผลลัพธ์ที่ได้คือ ยูเอ็มแอล UML ที่มีสัญลักษณ์สำหรับใช้ในการสร้าง แบบจำลองและการพัฒนาระบบเชิงวัตถุในปี 1997 ยูเอ็มแอล กลายเป็นมาตรฐานอุตสาากรรมสำหรับพัฒนาซอฟต์แวร์เชิงวัตถุ ใน ขณะเดียวกันบริษัท แรชั่นแนล และผผู้ค้าอื่นๆต่างพัฒนาเครื่องมือ อัตโนมัติ เพื่อสนับสนุนวิธีการ UML ยูเอ็มแอล เป็นเทคโนโลยีในการสร้างซอฟต์แวร์ในเชิงวัตถุแต่ ไม่ได้ให้กรอบงานกระบวนการที่จะนำทางทีมงานในการประยุกต์ใช้ เทคโนโลยี

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

เฟสระยะขยายรายละเอียด (Elaboration Phase) ประกอบด้วยการสื่อสารกับลูกค้าและกิจกรรมการสร้างแบบจำลอง การขยายรายละเอียด ปรับปรุงยูสเคสเบื้องต้นที่ได้สร้างขึ้นในเฟส ระยะเริ่มต้น และขยายสถาปัตยกรรมให้ครอบคลุมมุมองทั้งห้าของ ซอฟต์แวร์ได้แก่ แบบจำลองยูสเคส แบบจำลองการวิเคราะห์ แบบจำลองการออกแบบ แบบจำลองการอิมพลีเม้นต์ และแบบจำลอง การใช้งาน นอกจากนี้จะมีการทบกวนการวางแผนงานอย่างรายละเอียดใน ตอนท้ายของเฟสเพื่อให้มั่นใจในขอบเขตงานความเสี่ยง และกำหนด วันส่งมอบ ว่ายังทำได้ตามกำหนด เฟสระยะก่อสร้าง (Construction Phase) มีกอจกรรมก่อสร้าง เช่นเดียวกับที่กำหนดสำหรับกระบวนการซอฟต์แวร์ทั่วไป มีการ พัฒนาจัดหาคอมโพเม้นท์ที่ทำงานตามยูสเคสได้ เฟสระยะส่งมอบ (The Transition Phase)ประกอบด้วยระย ท้ายๆของกิจกรรมก่อสร้างและระยะต้นของกิจกรรมการใช้งานผู้ใช้จะ ได้รับซอฟต์แวร์เพื่อทดสอบแบบเบต้า เฟสระยะการทำงาน (The Production Phase) มีกิจกรรมการ ใช้งานทั่วไปมีการเผาดูการใช้งานการสนับสนุนช่วยเหลือและการ รายงานจุดบกพร่อง พร้อมทั้งมีการร้องขอให้ปรับปรุงและประเมินคำ ร้องขอ

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

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

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