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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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