290355 Software Engineering

1. 290355Software Engineering อ.ธารารัตน์ พวงสุวรรณ คณะวิทยาศาสตร์และศิลปศาสตร์ มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี บทที่2กระบวนการทางวิศวกรรมซอฟต์แวร์

2. เนื้อหา • กระบวนการซอฟต์แวร์ (Software Process) • กิจกรรมพื้นฐานของกระบวนการทางวิศวกรรมซอฟแวร์ • วงจรการพัฒนาซอฟต์แวร์ (Software Development Life Cycle) • โมเดลการพัฒนาซอฟต์แวร์ • เทคนิคและเครื่องมือในการพัฒนาซอฟต์แวร์ • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model: CMM)

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

4. กระบวนการ (Process) กระบวนการโดยทั่วไปจะมีลักษณะ ดังนี้ 1. กระบวนการจะต้องระบุกิจกรรมทั้งหมดอย่างชัดเจน 2. กระบวนการจะใช้ทรัพยากรภายใต้ข้อจำกัดต่างๆ เพื่อผลิตเป็นผลิตภัณฑ์ที่แล้วเสร็จ 3. กระบวนการหนึ่ง อาจประกอบขึ้นจากกระบวนการย่อยอื่นๆ ที่มีความสัมพันธ์กัน 4

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

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

7. กระบวนการซอฟต์แวร์ (Software Process) เพื่อให้บรรลุวัตถุประสงค์ในการสร้างซอฟต์แวร์จึงต้องมีการกำหนดกระบวนการสร้างซอฟต์แวร์ สิ่งที่ได้จากกระบวนการสร้างซอฟต์แวร์ คือ ผลิตภัณฑ์ซอฟต์แวร์ (Software Product) วิศวกรรมซอฟต์แวร์ จะเรียกกระบวนการสร้างซอฟต์แวร์ว่า “Software Process” 7

8. Software Process กระบวนการซอฟต์แวร์ คือ กรอบการดำเนินกิจกรรมในการสร้างซอฟต์แวร์ที่มีคุณภาพ [Pressman, 2005] กระบวนการซอฟต์แวร์ คือ กลุ่มของกิจกรรมและผลลัพธ์ของแต่ละกิจกรรมเพื่อการผลิตเป็นผลิตภัณฑ์ที่เรียกว่า “ซอฟต์แวร์” [Sommerville, 2007] 8

9. กิจกรรมพื้นฐานของ กระบวนการทางวิศวกรรมซอฟต์แวร์ 1. ข้อกำหนดซอฟต์แวร์ (Software Specification) 2. การพัฒนาซอฟต์แวร์ (Software Development) 3. การตรวจสอบความถูกต้อง (Software Validation) 4. วิวัฒนาการของซอฟต์แวร์ (Software Evolution)

10. 1. software specification นิยามหน้าที่ต่างๆที่ต้องมีในซอฟต์แวร์ และระบุข้อจำกัดต่างๆ ที่เกี่ยวข้องกับกระบวนพัฒนาซอฟต์แวร์ 2. Software Development ทำการสร้าง / พัฒนาซอฟต์แวร์ให้ตรงกับข้อกำหนด (specification) 3. software validation ทำการตรวจสอบความถูกต้องของซอฟต์แวร์ เพื่อให้เกิดความมั่นใจ ว่าซอฟต์แวร์ที่ผลิตขึ้นได้ตรงกับความต้องการของลูกค้า 4. software evolution ในทางปฏิบัติ เมื่อซอฟต์แวร์ใช้งานได้ระยะหนึ่งแล้ว ผู้ใช้หรือลูกค้าอาจมีความต้องการเพิ่มเติมหรือเปลี่ยนแปลงความต้องการบางอย่าง ดังนั้นขั้นตอนการพัฒนาซอฟต์แวร์ ต้องมีการเตรียมการบางอย่างเพื่อจัดการกับเหตุการณ์ที่คาดหมายว่าจะเกิดขึ้นในอนาคต 10

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

12. Software Process กระบวนการซอฟต์แวร์ (Software Process) = กระบวนการพัฒนาซอฟต์แวร์ (Software Development Process) กระบวนการทำหน้าที่เป็นกรอบในการสร้างผลิตภัณฑ์ใด ๆ หรือเรียกกระบวนการ ได้อีกอย่างว่า “วงจรชีวิตหรือวัฏจักรชีวิต (Life Cycle)” ของผลิตภัณฑ์ กระบวนการซอฟต์แวร์ หรือ กระบวนการพัฒนาซอฟต์แวร์ เรียกอีกอย่างหนึ่งว่า “วัฏจักรชีวิตของซอฟต์แวร์ (Software Life Cycle)” หรือ วงจรการพัฒนาซอฟต์แวร์ (Software Development Life Cycle : SDLC) 12

13. Software Development Life Cycle : SDLC คุณสมบัติเด่น • มีการแบ่งกระบวนการทำงานออกเป็นขั้นตอน • มีการทำงานที่เป็นลำดับขั้นตอนที่ต่อเนื่อง

14. Software Development Life Cycle : SDLC ระยะที่ 1: การวางแผนโครงการ (Project Planning Phase) ระยะที่ 2: การวิเคราะห์ (Analysis Phase) ระยะที่ 3: การออกแบบ (Design Phase) ระยะที่ 4: การนำไปใช้ (Implementation Phase) ระยะที่ 5: การบำรุงรักษา (Maintenance Phase)

15. วงจรการพัฒนาระบบ (System Development Life Cycle: SDLC) ระยะที่ 1: การวางแผนโครงการ ระยะที่ 2: การวิเคราะห์ ระยะที่ 3: การออกแบบ ระยะที่ 4: การนำไปใช้ ระยะที่ 5: การบำรุงรักษา

17. ระยะที่ 1 Project Planning ประกอบด้วยกิจกรรม ดังนี้ • กำหนดปัญหา (Problem Definition) • ศึกษาความเป็นไปได้ของโครงการ (Feasibility Study) • จัดทำตารางกำหนดเวลาโครงการ (Project Scheduling) • จัดตั้งทีมงานโครงการ (Staff the project) • ดำเนินการโครงการ (Launch the project)

18. กำหนดปัญหา (Problem Definition) ค้นหาปัญหา โอกาสและเป้าหมาย (Identifying Problems, Opportunity and Objective) ระบบสารสนเทศจะเกิดขึ้นได้ก็ต่อเมื่อผู้บริหารหรือผู้ใช้ตระหนักว่าต้องการระบบสารสนเทศ หรือต้องแก้ไขระบบเดิม โดยมีขั้นตอนดังนี้ 1.1 นักวิเคราะห์และออกแบบระบบ ต้องศึกษาระบบโดยละเอียด เพื่อให้เข้าใจถึงปัญหาที่เกิดขึ้นในองค์กร ตัวอย่างปัญหา 1.2 พยายามหาโอกาสในการปรับปรุงวิธีการทำงานโดยการใช้ระบบคอมพิวเตอร์ 1.3 นักวิเคราะห์และออกแบบระบบ ต้องมองเป้าหมายให้ชัดเจน

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

20. ศึกษาความเป็นไปได้ (Feasibility Study) • เมื่อกำหนดว่าปัญหาคืออะไร และตัดสินใจว่าจะพัฒนาสร้างระบบสารสนเทศใหม่หรือการแก้ไขระบบสารสนเทศเดิมมีความเป็นไปได้หรือไม่ โดยเสียค่าใช้จ่ายและเวลาน้อยที่สุด • นักวิเคราะห์และออกแบบระบบ ต้องกำหนดให้ได้ว่าการแก้ปัญหานั้น 2.2.1 มีความเป็นไปได้ทางเทคนิคหรือไม่ 2.2.2 มีความเป็นไปได้ทางบุคลากรหรือไม่ 2.2.3 มีความเป็นไปได้ทางเศรษฐศาสตร์หรือไม่ (ต้นทุนค่าใช้จ่าย)

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

22. ระยะที่ 2Analysis Phase • จะมีคำตอบกับคำถามว่า ใคร(Who) เป็นผู้ใช้งานระบบ และมีอะไรบ้าง (What) ที่ระบบต้องทำ • ดำเนินการวิเคราะห์ระบบปัจจุบัน เพื่อพัฒนาแนวความคิดสำหรับระบบใหม่ • วัตถุประสงค์หลัก คือ ศึกษาทำความเข้าใจความต้องการต่าง ๆ ที่ได้รวบรวมมา • ดังนั้น การรวบรวมความต้องการ (Requirement Gathering) จึงเป็นงานส่วนพื้นฐานของการวิเคราะห์ ซึ่งนักวิเคราะห์ระบบจะประเมินว่าควรมีอะไรบ้างที่ระบบใหม่ต้องดำเนินการ • ดังนั้น การกำหนดรายละเอียดเกี่ยวกับความต้องการของผู้ใช้ (User Requirement) จะมีความสำคัญมาก

23. ระยะที่ 2Analysis Phase • นักวิเคราะห์ระบบรวบรวมความต้องการได้จาก • การสังเกต • การสัมภาษณ์ • การทำแบบสอบถาม • การอ่านเอกสารเกี่ยวกับการปฏิบัติงานของระบบ • ระเบียบกฏเกณฑ์ • จากนั้นจึงสรุปออกมาเป็นข้อกำหนด (Requirement Specification) ที่ชัดเจน อ่านแล้วตีความหมายได้ตรงกัน

24. ระยะที่ 2Analysis Phase • หลังจากนั้น นักวิเคราะห์ระบบต้องนำข้อกำหนดไปพัฒนาเป็นความต้องการของระบบใหม่ เทคนิคที่ใช้คือ การพัฒนาแบบจำลองกระบวนการ (Process Model) เพื่ออธิบายกระบวนการที่ต้องทำในระบบ และจากนั้น ก็ดำเนินการพัฒนาแบบจำลองข้อมูล (Data Model) เพื่ออธิบายสารสนเทศที่ต้องจัดเก็บเอาไว้สนับสนุนกระบวนการต่าง ๆ • เทคนิคที่ใช้ในการวิเคราะห์ระบบ อาจปรับเปลี่ยนไปตามเทคนิคที่เลือกใช้ในการวิเคราะห์ระบบ

25. ระยะที่ 3Design Phase • พิจารณาว่า ระบบจะดำเนินการไปได้อย่างไร (How)จะพัฒนาระบบใหม่ด้วยแนวทางใด • เกี่ยวข้องกับการออกแบบสถาปัตยกรรมระบบ เกี่ยวกับอุปกรณ์ฮาร์ดแวร์ ซอฟต์แวร์ เครือข่าย การออกแบบรายงาน การออกแบบหน้าจอ ออกแบบผังงานระบบ รายละเอียดโปรแกรม ฐานข้อมูล แฟ้มข้อมูลที่เกี่ยวข้อง

26. ระยะที่ 3Design Phase • ประกอบด้วยกิจกรรม ดังนี้ • พิจารณาแนวทางในการพัฒนาระบบ • Architectural Design • Database Design • Output Design • Input Design • User Interface Design • Prototype • ออกแบบโปรแกรม (Structure chart)

27. ระยะที่ 5 Implementation Phase • เขียนโปรแกรม • ตรวจสอบความถูกต้อง • Verificationตรวจสอบว่า ระบบทำงานตามที่กำหนดไว้หรือไม่ • Validationตรวจสอบว่า ระบบสามารถทำงานตามความต้องการของผู้ใช้หรือไม่ • เตรียมสถานที่และการติดตั้งเครื่องคอมพิวเตอร์ • จัดทำคู่มือการใช้โปรแกรมและการฝึกอบรมผู้ใช้ที่เกี่ยวข้องในระบบ

28. กรรมวิธีการพัฒนาระบบ (System Development Methodology) นักวิเคราะห์ระบบ สามารถนำเครื่องมือต่าง ๆ มาประยุกต์ใช้กับการวิเคราะห์และออกแบบ ซึ่งเรียกว่า “Methodology” โดย Methodology เป็นแนวทางที่มีการนำโมเดล (Model), เครื่องมือ (Tools) และเทคนิค (Techniques) ต่าง ๆ มาใช้กับการพัฒนาซอฟต์แวร์ ซึ่งจัดเป็นแนวทางในการแก้ปัญหาด้วยวิธีการพัฒนาซอฟต์แวร์

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

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

31. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach) • เทคนิควิธีการพัฒนาระบบดั้งเดิมนั้นมีเทคนิคที่หลากหลาย ซึ่งตั้งอยู่บนพื้นฐานของการพัฒนาระบบสารสนเทศด้วยวิธีโครงสร้าง และการโปรแกรมแบบโมดูล โดยมักเรียกวิธีนี้ว่า การพัฒนาระบบเชิงโครงสร้าง • การโปรแกรมเชิงโครงสร้างนอกจากจะช่วยให้การเขียนโปรแกรมมีคุณภาพแล้ว ยังมีส่วนช่วยให้โปรแกรมเมอร์สามารถอ่านโปรแกรมเพื่อทำการตรวจสอบและทำการแก้ไขปรับปรุงโปรแกรมได้ง่ายขึ้น โดยแนวทางการโปรแกรมเชิงโครงสร้าง ประกอบด้วย ชุดคำสั่งที่เรียงลำดับ (Sequence) ชุดคำสั่งที่มีการตัดสินใจ (Decision) และชุดคำสั่งที่มีการทำงานเป็นลูปหรือการทำซ้ำ (Repetition)

32. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach)

33. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach)

34. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบแบบดั้งเดิม (The Traditional Approach) • การวิเคราะห์เชิงโครงสร้างสมัยใหม่ เป็นเทคนิคที่ช่วยให้นักพัฒนากำหนดได้ว่าระบบจะต้องดำเนินการทำอะไรบ้าง มีข้อมูลใดบ้างที่ระบบต้องจัดเก็บ มีอินพุต และเอาต์พุตใด และต้องดำเนินการอย่างไรให้ระบบโดยรวมสำเร็จลงด้วยดี

35. วิธีการพัฒนาระบบ มี 2 วิธี

36. วิธีการพัฒนาระบบ มี 2 วิธี

37. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบเชิงวัตถุ (The Object-Oriented Approach) จัดเป็นวิธีใหม่ของการพัฒนาระบบ

38. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบเชิงวัตถุ (The Object-Oriented Approach) จัดเป็นวิธีใหม่ของการพัฒนาระบบ • จะประกอบไปด้วย 3 แนวทางด้วยกัน คือ1. การวิเคราะห์ระบบด้วยวิธีเชิงวัตถุ (Object-Oriented Analysis: OOA) • 2. การออกแบบระบบด้วยวิธีเชิงวัตถุ (Object-Oriented Design: OOD) • 3. การเขียนโปรแกรมเชิงวัตถุ (Object-Oriented Programming: OOP)

39. วิธีการพัฒนาระบบ มี 2 วิธี • วิธีการพัฒนาระบบเชิงวัตถุ (The Object-Oriented Approach) จัดเป็นวิธีใหม่ของการพัฒนาระบบ

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

41. Model การพัฒนาซอฟต์แวร์ • Waterfall • Adapted Waterfall • Evolutionary • Incremental • Spiral • Rapid Prototype • Rapid Application Development (RAD) • Joint Application Development (JAD) • Relational Unified Process (RUP)

42. Waterfall Model

43. Adapted Waterfall Model Adapted WaterfallModelพัฒนามาจากแบบ Waterfall โดยในแต่ละขั้นตอนสามารถแก้ไขข้อผิดพลาดหรือสามารถย้อนกลับ ได้

44. Evolutionary Model Evolutionary Modelจะพัฒนาระบบงานจนเสร็จสิ้นในVersion ที่ 1 ก่อน จากนั้นจะพิจารณาถึงข้อดีข้อเสียใน Version ที่ 1 และนำข้อดีข้อเสียเหล่านั้นมาพัฒนาระบบในVersion ที่ 2 และ Version ต่อ ๆ ไป

45. Incremental Model Incremental Modelจะมีลักษณะคล้ายคลึงแบบ Evolutionary แต่มีข้อแตกต่างกัน ตรงที่ตัว Product (ระบบ) ที่พัฒนาขึ้นจะเป็นส่วนแรกเท่านั้น และพัฒนาในส่วนที่ 2 และส่วนอื่น ๆ เพิ่มเติมเพื่อ Product (ระบบ) ที่สมบูรณ์

46. Spiral Model • เหมาะกับการพัฒนาซอฟต์แวร์ขนาดใหญ่ • ทำแต่ละขั้นตอนหลายรอบตามความต้องการของผู้ใช้ • แต่ละขั้นตอนต้องทำต้นแบบ • มีการวิเคราะห์ความเสี่ยงทุกขั้นตอน • มีลักษณะเป็นวงจรวิเคราะห์-ออกแบบ-พัฒนา-ทดสอบ (Analysis-Design-Implementation-Testing) และจะวนกลับมาในแนวทางเดิมไปเรื่อย ๆ จนกระทั่งได้ Product ที่สมบูรณ์ - เหมาะสำหรับระบบงานที่มีโอกาสเปลี่ยนแปลงบ่อยเนื่องจากในแต่ละเฟสนั้นจะมีการวิเคราะห์ความต้องการใหม่ และวิเคราะห์ความเสี่ยงว่าจะทำการพัฒนาต่อไปอีกหรือไม่ หรือจะเพียงพอแล้วกับเฟสนี้เท่านั้น

47. Spiral Model

48. Rapid Prototype Model - ใช้ในกรณีที่ Requirement ไม่ชัดเจน - สร้าง Rapid Prototype ในการหา Requirement ที่ต้องการจริง ๆ เพื่อสร้าง ความมั่นใจระหว่างลูกค้าและผู้พัฒนา - ลักษณะของ Prototype - นำข้อมูลที่เก็บได้มาสร้างซอฟต์แวร์แบบไม่ละเอียด - มีการสร้างหน้าจอผู้ใช้ การป้อนข้อมูลเข้า การแสดงผลข้อมูล

49. Rapid Application Development - การพัฒนาแอพพลิเคชั่นอย่างรวดเร็วโดยกระบวนการที่สำคัญ และใช้ เครื่องมือสนับสนุน เช่น CASE Tools - เน้นการลดต้นทุนและเวลา - จำเป็นต้องมีทีมงานขนาดเล็กที่มีความรู้ความสามารถเฉพาะ - การนำเทคนิค RAD มาใช้ในโครงการเพื่อมุ่งหวังพัฒนาระบบงานให้สำเร็จ อย่างรวดเร็ว และใช้งานได้ภายในระยะเวลาจำกัดมากกว่าที่จะให้ระบบ สมบูรณ์แบบ หรือมีเทคนิคที่ดีเลิศ

50. Joint Application Development - เป็นการพัฒนาแอพพลิเคชั่นร่วมกัน โดยกลุ่มคนในองค์กร ผู้เชี่ยวชาญด้าน IT เข้าร่วมประชุมเชิงปฏิบัติการ - จุดประสงค์ คือ เพื่อพัฒนาระบบงานที่ใช้เวลาสั้นและมีความ สมบูรณ์ในโครงการ - มีห้องปฏิบัติการที่ใช้เป็นศูนย์การทำงาน