Rational Unified Process in System Development Life Cycle โดย นายสิรินันท์ นายโกสินทร์ นางสาวอรชุมา นายกันตนาท นายนฤเทพ นางสาวนลินี

วรรณธนพงศ์ ทองดี พนมเริงศักดิ์ วัฒนศรานนท์ เย็นใจ ศิริเมฆา

553080369-5 563080031-3 563080056-7 563080333-7 563080342-6 563080343-4

เสนอ ผู้ช่วยศาสตราจารย์ ดร. วิศปัตย์ ชัยช่วย รายวิชา 412347 INFORMATION SYSTEM ANALYSIS AND DESIGN ภาคเรียนที่ 2 ปีการศึกษา 2558 สาขาวิชาสารสนเทศและการสื่อสาร คณะมนุษยศาสตร์และสังคมศาสตร์ มหาวิทยาลัยขอนแก่น

วงจรการพัฒนาระบบ (System Development Life Cycle : SDLC) วงจรการพัฒนาระบบสารสนเทศ เป็นขั้นตอนการพัฒนาซอฟต์แวร์แบบพื้นฐานที่มักถูกนาไปใช้ใน หลายๆ องค์กร ประกอบไปด้วยกลุ่มกิจกรรม 3 ส่วนหลัก คือ การวิเคราะห์ การออกแบบ และการนาไปใช้ โดยกิจกรรมทั้ง 3 เหล่านี้สามารถนามาใช้งานได้ดีกับโครงการหรือซอฟต์แวร์ขนาดเล็ก ในขณะที่โ ครงการ ซอฟต์แวร์ขนาดใหญ่ มักจาเป็นต้องใช้แบบแผนการพัฒนาซอฟต์แวร์ตามแนวทาง SDLC จนครบทุกกิจกรรม ดังภาพที่ 1

ภาพที่ 1 SDLC Model โดยขั้นตอนในการพัฒนาระบบมีอยู่ด้วยกัน 5 ระยะด้วยกัน ดังนี้ ระยะที่ 1 การวางแผนโครงการ (Project Planning) การวางแผนโครงการเป็นกระบวนการพื้นฐานของความเข้าใจว่าทาไม (Why) ระบบสารสนเทศ จึง ควรสร้างขึ้นมา และต้อ งก าหนดที ม งานขึ้นมาเพื่อดาเนินการสร้างระบบนี้อย่างไร โดยในช่วงการเริ่ม โครงการ (Project Initiate) จะต้องมีการกาหนดคุณค่าทางธุรกิจของระบบที่มีต่อองค์กร เช่น ระบบใหม่จะ สามารถช่ว ยลดต้ นทุ น หรื อ เพิ่ ม รายได้ ใ ห้แ ก่ องค์ ก รได้อ ย่ างไร ซึ่ ง ค าเรี ย กร้ อ งให้ พัฒ นาระบบใหม่ อ าจ มาจากนอกเขตพื้นที่ของแผนกพัฒนาระบบก็ได้ เช่น แผนกการตลาด แผนกบัญชี หรือมาจากแบบฟอร์มคา ร้องขอระบบ (System Request) จากนั้น แผนกพัฒนาระบบก็จะทางานร่วมกับเจ้าของระบบ เพื่อศึกษาและ วิเคราะห์ความเป็นไปได้ ทั้งนี้โครงการจะได้รับการสนับสนุนหรือไม่ ต้องได้รับความเห็นชอบจากผู้บริหารหรื อ ผ่านการรับรองจากคณะกรรมการ กิจกรรมในระยะการวางแผนโครงการประกอบด้วย 1. กาหนดปัญหา 2. กาหนดระยะเวลาโครงการ 3. ยืนยันความเป็นไปได้ของโครงการ 4. จัดตั้งทีมงาน 5. ดาเนินโครงการ

ระยะที่ 2 การวิเคราะห์ (Analysis) ระยะการวิเคราะห์จะตอบคาถามเกี่ยวกับ ใคร (Who) เป็นผู้ใช้ระบบ มีอะไรบ้าง (What) ที่จะต้องทา และทาที่ไหน (Where) เมื่อไร (When) โดยในระยะนี้ ทีมงานจะทาการศึกษาระบบงานปัจจุบัน พร้อมระบุ แนวทางในการปรับปรุงกระบวนการที่ดีขึ้น เพื่อพัฒนาเป็นแนวคิดสาหรับระบบใหม่ขึ้นมา สิ่งที่สาคัญในระยะ นี้ก็คือ การรวบรวมความต้องการ (Requirement Gathering) ซึ่งสามารถรวบรวมความต้องการได้จากการ สัง เกตการท างานของผู้ ใ ช้ การสั ม ภาษณ์ การท าแบบสอบถาม ซึ่ง ตลอดระยะเวลาของการรวบรวม ความต้องการ ทีมพัฒนาจะได้พบปะกับผู้ใช้ในระดับต่างๆ ที่ทาให้ทรายถึงกระบวนการทางาน ปัญหาที่เกิดขึ้น และแนวทางในการแก้ ไขปัญ หาที่ แนะน าโดยผู้ ใช้ ภายหลั ง จากการนาความต้ องการต่างๆ มาสรุป เป็ น ข้อ ก าหนดที่ ชัด เจนแล้ ว ขั้น ต่ อ ไปคื อ การนาแนวคิด เกี่ ยวกั บ ระบบ และแบบจ าลองมารวมเข้ าด้ วยกั น เป็นเอกสารที่เรียกว่า ข้อเสนอระบบ (System Proposal) เพื่อเสนอแก่ผู้บริหารหรือผู้สนับสนุนโครงการ กิจกรรมในระยะการวิเคราะห์ประกอบด้วย 1. วิเคราะห์งานปัจจุบัน 2. รวบรวมข้อ มู ล และความต้องการในด้านต่างๆ จากนั้นนามาวิเ คราะห์เ พื่อสรุป เป็ น ข้อกาหนดให้มีความถูกต้องชัดเจน 3. นาข้อกาหนดมาพัฒนาเป็นความต้องการของระบบใหม่ 4. สร้างแบบจาลองกระบวนการ (Data Flow Diagram: DFD) 5. สร้างแบบจาลองข้อมูล (Entity Relationship Diagram: ERD) 6. รวบรวมเอกสารที่ สร้างขึ้นมาจัดทาเป็นข้อเสนอระบบ (System Proposal) เพื่อยื่นต่อ คณะกรรมการหรือผู้มีอานาจตัดสินใจให้รับรองหรืออนุมัติโครงการพัฒนาระบบ ระยะที่ 3 การออกแบบ (Design) ระยะการออกแบบจะเป็นการตัดสินใจว่าระบบจะดาเนินการไปได้อย่างไร (How) ในด้านการจัดหา อุปกรณ์ฮาร์ดแวร์ ซอฟต์แวร์ โครงสร้างเครือข่ายที่จะนามาใช้ การ ปฏิสัมพันธ์ระหว่างผู้ใช้กับระบบ รวมถึง แบบฟอร์ม และรายงานต่างๆ แม้ว่าการตัดสินใจเชิงกลยุท ธ์ โดยส่วนใหญ่แล้วจะเกี่ยวข้องกั บ ระบบที่ ถูก พัฒนาขึ้นในระหว่างระยะการวิเคราะห์ แต่ขั้นตอนในระหว่างการออกแบบนั้น จะมุ่งเน้นประเด็นเกี่ยวกั บ วิธีการดาเนินงานระบบด้วยการนาแบบจาลองเชิงตรรกะ (Logical Model) ที่ได้จากระยะการวิเคราะห์มา พัฒนาเป็นแบบจาลองแบบกายภาพ (Physical model) กิจกรรมในระยะการออกแบบประกอบด้วย 1. การจัดหาระบบ 2. ออกแบบสถาปัตยกรรมของระบบ (Architecture Design) 3. ออกแบบเอาต์พุตและยูสเซอร์อินเตอร์เฟส 4. การออกแบบฐานข้อมูล 5. การสร้างต้นแบบ 6. ออกแบบโปรแกรม

ระยะที่ 4 การนาไปใช้ (Implementation Phase) กิ จ กรรมต่ า งๆ ในระยะการน าไปใช้ จ ะเกี่ ย วข้ อ งกั บ การสร้ า งระบบ การทดสอบระบบและ การติดตั้งระบบ โดยมี จุดประสงค์หลักที่ ไม่ ใช่มีเ พียงแต่การสร้างผลิตภัณฑ์ให้มี ความน่าเชื่อถือ แต่ระบบ สารสนเทศจะต้อ งสามารถตอบสนองฟั ง ก์ ชันการท างานทางธุร กิ จ ตามหน่วยงานต่างๆ ได้อย่างสมบรูณ์ และรวมถึงความมั่ นใจว่าผู้ใช้ทุก ๆคนได้ผ่านการฝึก อบรมใช้ง าน เพื่อเตรียมความพร้อมต่อการใช้ร ะบบ สารสนเทศให้เกิดประโยชน์ต่อองค์กรดังที่คาดหวัง โดยกิจกรรมก่อนๆ ที่ได้ดาเนินการมาแล้วนั้นจะถูกนามา รวมเข้าด้วยกันเพื่อนาไปสู่การปฏิบัติงานในที่สุด กิจกรรมในระยะการนาไปใช้ประกอบด้วย 1. สร้างส่วนประกอบซอฟต์แวร์ 2. ตรวจสอบความถูกต้องและทดสอบระบบ 3. แปลงข้อมูล 4. ติดตั้งระบบ 5. จัดทาเอกสารระบบ 6. ฝึกอบรมและสนับสนุนผู้ใช้ 7. ทบทวนและประเมินผลระบบภายหลังการติดตั้ง ระยะที่ 5 การบารุงรักษา (Maintenance) โดยปกติแล้วระยะการบารุงรักษาจะไม่ถูกนาเข้าไปรวมไว้ในขั้นตอนของ SDLC จนกระทั่งภายหลัง จากระบบได้มีการติดตั้งเพื่อใช้งานแล้วเท่านั้น ระยะนี้จะใช้เวลายาวนานที่สุดเมื่อเทียบกับระยะอื่นๆ ที่ผ่านมา เนื่องจากระบบจะต้องได้รับการบารุงรักษาตลอดระยะเวลาที่มีการใช้งาน โดยสิ่งที่คาดหวังขององค์กรก็คือ ระบบจะสามารถใช้ ง านได้ ยาวนานและรองรับ เทคโนโลยี ใ หม่ ๆ ในอนาคตได้ ดัง นั้ น ในช่ วงระยะของ การบารุงรักษาจึงสามารถเพิ่มเติมคุณสมบัติใหม่ๆ เข้าไปเพื่อเพิ่มประสิทธิภาพในการทางานให้กับระบบได้ กิจกรรมในระยะการบารุงรักษาประกอบด้วย 1. การบารุงรักษาระบบ 2. การเพิ่มเติมคุณสมบัติใหม่ๆ เข้าไปในระบบ 3. การสนับสนุนผู้ใช้

Development Methodology Rational Unified Process (RUP) The Rational Unified Process (RUP) คือระเบียบวิธีการพัฒนาระบบเชิงวัตถุโดยใช้ภาษา UML (Unified Modeling Language) มีจุดประสงค์เพื่อพัฒนาซอฟต์แวร์ที่มีคุณภาพสูง ตรงความต้องการของผู้ใช้ ภายใต้งบประมาณและระยะเวลาที่กาหนดไว้ในโครงการ

ภาพที่ 2 แบบจาลองกระบวนการ RUP Phase, Iterations และ Discipline จากภาพที่ 2 แสดงให้เห็นถึงกระบวนการที่เป็นจุดสาคัญของ RUP ในแต่ละช่วงเวลา (Phase) เช่น ในช่วงแรกของการทางานจะเน้นที่ก ารท างานที่เ กี่ยวข้องกั บ Requirement และหลัง จากนั้นก็ จะมาเน้น การทางานที่ส่วนการ Implement coding และ Configuration & Change เป็นต้น ซึ่ง RUP จะมีมุมมอง แบบ 2 มิติด้วยกัน ได้แก่ มิติที่ 1 มุมมองแกนแนวนอน (Horizontal Axis) จะแสดงให้เห็นถึงเวลาและวงจรการพัฒนา ในแต่ละช่วงของโครงการ การเปลี่ยนแปลงของกระบวนการทางาน โดยจะนาเสนอออกมาในรูปแบบของ ช่วงการทางาน (Phase) การแบ่งการทางานออกเป็นงานย่อยๆ (Iteration) และ ระยะการทางาน หรือ หลัก ไมล์การทางาน (milestone) ซึ่งเป็นจุดของเวลาที่ทีมงานต้องตัดสินใจในเรื่องผลผลิตของงานที่จะต้องได้รับ การตรวจสอบและติดตามให้เ ป็นไปตามแผนที่ ก าหนดไว้ เพื่อให้ดาเนินโครงการในระยะต่อไปได้ส าเร็จ ดังภาพที่ 2

ภาพที่ 3 ระยะต่างๆ ของการพัฒนาซอฟต์แวร์โดยใช้ระเบียบวิธี RUP การท างานในแต่ ล ะช่ ว งจะมี ก ารเปลี่ ย นแปลงขึ้ น อยู่ อ งค์ ป ระกอบต่ า งๆของโครงการ หรื อ ความต้องการของลูกค้า โดยขั้นตอนการทางานของ RUP แบ่งออกเป็น 4 ขั้นตอน ดังนี้ 1. Inception เป็นระยะเริ่มต้นการดาเนินงาน เพื่อกาหนดขอบเขต หน้าที่การทางานหลัก และวิสัยทัศน์ รวมไปถึงกาหนดขีดความสามารถในการพัฒนาระบบของทีมงาน เป้าหมายของระยะนี้คือการ จัดทา Business Case โดยการจาแนกกลุ่มบุคคลภายนอกหรือระบบอื่น (External Entity) ที่มีปฏิสัมพันธ์กับ ระบบ จากนั้นทาการประเมินระบบว่ามีส่วนช่วยธุรกิจได้มากน้อยเพียงใด หากมีส่วนช่วยน้อยมาก โครงการ ผลิตซอฟต์แวร์ที่กาลังจะจัดตั้งขึ้นจะถูกยกเลิกทันทีหลักจากจบงานในระยะนี้ 2. Elaboration เป้าหมายของระยะนี้คือ การทาความเข้าใจปัญหาของระบบ จัดทากรอบ การท างานของสถาปัตยกรรมของระบบ จัดท าแผนงานโครงการและค้นคว้าหาความเสี่ยงของโครงการ สิ่ง ที่ ได้จ ากระยะนี้คือ แบบจ าลองความต้องการของระบบ (Use case diagram) รายละเอียดของ สถาปัตยกรรม และจัดทาแผนงานพัฒนาซอฟต์แวร์ 3. Construction เป็นระยะที่เ กี่ยวข้องกั บงานออกแบบ เขียนโปรแกรม และทดสอบ โปรแกรม โดยการแบ่งส่วนระบบให้โปรแกรมเมอร์แต่ละคนช่วยกันเขียนโปรแกรม แล้วนามาผนวกรวมกัน สิ่ง ที่ได้จากระยะนี้คือ ซอฟต์แวร์และเอกสารของซอฟต์แวร์ที่พร้อมส่งมอบให้กับลูกค้า 4. Transition ระยะสุดท้ายของ RUP เป็นการส่งมอบระบบให้กับ ลูกค้า และท าให้ ปฏิบัติงานได้จริง พร้อมกับจัดให้มีการฝึกอบรมการใช้งานระบบใหม่ เตรียมผู้เชี่ยวชาญไว้คอยให้คาปรึกษา ระหว่างการใช้งานและคอยบารุงรักษาระบบตามแผนงานจนกว่าลูกค้าจะพอใจกับระบบใหม่ มิติที่ 2 มุมมองแกนแนวตั้ง (Vertical Axis) จะแสดงถึงขั้นตอนการทางาน (Workflows) หรือกลุ่ม กิจกรรมต่างๆ ที่เกิดขึ้นในระยะนั้นๆ ซึ่งปริม าณงานที่เกิดขึ้นในแต่ละระยะ จะมีจุดเน้นของปริม าณงานที่ แตกต่ า งกั น ตามบทบาทหน้ า ที่ ข องผู้ ป ฏิ บั ติ ง านในส่ว นนั้ น ๆ โดยแบ่ ง กระบวนการหลั ก ๆ ออกเป็ น 9 กระบวนการ ดังนี้ 1. การสร้างแบบจาลองธุรกิจ (Business Modeling) 2. การค้นหาความต้องการ (Requirements) 3. การวิเคราะห์และออกแบบ (Analysis and Design) 4. การพัฒนา/การนาไปใช้ (Implementation) 5. การทดสอบระบบ (Testing) 6. การติดตั้งระบบ (Deployment)

7. การคอนฟิกระบบและการจัดการความเปลี่ยนแปลง (Configuration and Change Management) 8. การบริหารโครงการ (Project Management) 9. การดาเนินการเกี่ยวกับสภาพแวดล้อม (Environment) โดยใน 6 ขั้นตอนแรก จะถือเป็นขั้นตอนของกระบวนการหลักที่ทีมงานต้องดาเนินการในทุกๆระยะ ในขณะที่ 3 ขั้ น ตอนสุ ด ท้ า ย จะเป็ น ขั้ น ตอนของกระบวนการสนั บ สนุ น และจากรายละเอี ย ด ตามมิติแกนแนวนอนและแนวตั้ง จะพบว่าระเบียบวิธีได้มี การแยกระยะ (Phase) กับ ขั้นตอนการทางาน (Work flows) ออกจากกัน โดยมี การคานึง ถึง สภาพแวดล้อ มของผู้ ใช้เป็นสาคัญ โดยที่ แต่ละระยะจะมี เป้าหมายเป็นตัวกาหนด เพื่อตัดสินใจถึงความสามารถในการดาเนินงานในระยะถัดไป ส่วนขั้นตอนการทางาน จะเป็ น การท างานเชิ ง เทคนิ ค ที่ มิ ไ ด้ ผู ก ติ ด กั บ ระยะใดระยะหนึ่ ง แต่ จ ะถู ก ด าเนิ น การได้ ใ นทุ ก ๆระยะ ตลอดทั้งกระบวนการ กล่าวคือ ทุกขั้นตอนสามารถทางานพร้อมกันได้

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

ตารางเปรียบเทียบข้อดีข้อเสียระเบียบวิธีการพัฒนาระบบสารสนเทศตามหลักการ SDLC

Model

Waterfall

ข้อดี  เป็ น โมเดลที่ มี ร ะเบี ย บแบบแผนและมี ก ารก าหนด Milestone ชัดเจน  การพั ฒ นายึดเอกสาร (Document-driven) และ การ ตรวจสอบ(Verification) เป็นสาคัญ ทาให้การบารุงรักษา สามารถท าได้ ง่ า ยและลดค่ า ใช้ จ่ า ยเนื่ อ งจากมี เ อกสาร ประกอบ  มี ลั ก ษณะการด าเนิ น งานโดยจะท างานจนครบถ้ ว น กระบวนการทีละขั้นตอนจากนั้น จึงจะเริ่มงานในขั้นตอน ต่อไป  ใช้ทรัพยากรในการดาเนินการพัฒนาระบบหรือซอฟต์แวร์ จานวนน้อย

ข้อเสีย  ลูก ค้าไม่ ส ามารถแน่ใจได้ว่าจะได้ร ะบบที่ ตรงตามที่ต้องการจริง หรื อ ไม่ เนื่ อ งจาก Waterfall Model ยึ ด เอกสารเป็ น หลั ก (Document driven) เพราะสิ่ ง ที่ ลู ก ค้ า เข้ า ใจจากเอกสาร ข้อกาหนดอาจไม่ใช่สิ่งที่ลูกค้าต้องการเสมอไป  หากเกิดกรณีที่ลูกค้าต้องการที่จะเปลี่ยนแปลงขั้นตอนในระบบนั้น Waterfall Model จะไม่ส ามารถดาเนินการพัฒนาปรับปรุงได้ ในทั น ที เ พราะการแก้ ไ ขเปลี่ ย นแปลงใดใด แม้ ว่ า จะเล็ ก น้ อ ย เพี ย งไหน จะท าได้ ก็ ต่ อ เมื่ อ เอกสารสมบู ร ณ์ เนื่ อ งจากเป็ น กระบวนการที่ยึดเอกสารเป็นหลัก(Document-driven) ทีมพัฒนา จะใช้เวลากับการทา เอกสารมาก  ข้อเสียของ Waterfall Model คือเมื่ อขั้นตอนหนึ่งไม่ สามารถ ท างานให้เ สร็จ ได้อย่างต่อเนื่ อ งก็ จ ะส่ง ผลต่อไปยัง ขั้นตอนอื่น ๆ ทาให้ระบบไม่สามารถทางานได้  ค่า ใช้จ่ า ยในการดูแ ลระบบนั้น มี ร าคาสู ง มากไม่ เ หมาะส าหรั บ หน่วยงานหรือโครงการขนาดเล็ก

Model

ข้อดี

ข้อเสีย

Spiral

 Spiral Model ผ่านการใช้งานเพื่อพัฒนาซอฟต์แวร์หลาย ประเภทอย่ า งประสบความส าเร็ จ จากการส ารวจ 25 โครงการ พบว่าทุ ก โครงการมี ความสามารถในการผลิ ต (Productivity) สูงขึ้นอย่างน้อย 50 %  Spiral Model เป็ น โมเดลที่ มี ค วามยื ด หยุ่ น ส าหรั บ การพั ฒ นาระบบ ซึ่ง จะช่วยในการก าหนดและปรับ ปรุ ง ในขั้ น ตอนของการพั ฒ นาโดยขึ้ น อยู่ กั บ ความซั บ ซ้ อ น ของแต่ละโครงการ  เหมาะส าหรั บ โครงการใหม่ โครงการที่ ต้ อ งการการ ปรับ เปลี่ยนได้ โครงการที่มี ความเสี่ยงสูงหรือธุร กิจที่ ไม่ มี ความมั่นคง

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

RAD

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

 RAD Model เป็นการลดขนาดระบบลง (Reduced Scalability) มีความยืดหยุ่นน้อยลงเนื่องจากพัฒนาจากต้นแบบ  เมื่อคุณลักษณะลดลง (Reduced Features) เนื่องจากถูกจากัด ด้วยเวลา จึงอาจได้ระบบที่ไม่สมบูรณ์  การพัฒนาอย่างรวดเร็วอาจส่งผลเสียต่อคุณภาพของผลผลิต  ผู้พัฒนาและดูแลระบบต้องมีประสบการณ์สูง  ควรนาไปใช้กับหน่วยงานหรือโครงการใหญ่เท่านั้น  การพัฒนาระบบมัก จะจะเกิดข้อผิดพลาดหรือล้มเหลวหากไม่ มี

Model

ข้อดี

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

JAD

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

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

RUP

 เป็นระเบียบวิธีการที่มีความสมบรูณ์ในตัวเอง โดยเน้นไปที่ การจัดการเอกสารให้มีความถูกต้อง  สามารถลดปั ญ หาความเสี่ ย งของโครงการที่ เ กิ ด จาก ความต้อ งการของลูก ค้าที่ เ กิดขึ้นในภายหลัง ด้วยการใช้ Software application ในการทดสอบความสามารถ ของระบบ

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

Model

ข้อดี  ใช้เวลาในการพัฒนาน้อย เนื่องจากเป็นการนาส่วนประกอบ เดิมมาใช้เพื่อพัฒนาใหม่  มี ก ารฝึ ก อบรมและสอนแบบออนไลน์ ส าหรั บ การใช้ ระเบียบวิธีการ RUP นี้  ระเบี ย บวิ ธี ก าร RUP เป็ น แนวทางการพั ฒ นาที่ มี ความยื ด หยุ่ น สู ง เป็ น ส่ ว นหนึ่ ง ที่ ท าให้ อ งค์ ก รเกิ ด Best Practice

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

บรรณานุกรม นเรศร์ บุญเลิศ. (ม.ป.ป). วงจรการพัฒนาระบบ. ค้นเมื่อ 15 กุมภาพันธ์ 255, จาก http://www.mcucr. com/home/includes/editor/assets/nares%20t7.pdf. มหาวิทยาลัยรัตนบัณฑิต. (ม.ป.ป.). การพัฒนาระบบสารสนเทศ (Information System Development). ค้นเมื่อ 15 กุมภาพันธ์ 2559, จาก http://www.rbac.ac.th/site/ assets/Science/Multimedia/data/bc304/lession2.ppt. โอภาส เอี่ยมสิริวงศ์. (2555). การวิเคราะห์และออกแบบระบบ (ฉบับปรับปรุงเพิ่มเติม). กรุงเทพ: ซีเอ็ด ยูเคชั่น. Amigo G. (2010). Spiral Model: Advantages and Disadvantages. Retrieved February 14, 2016, from http://www.buzzle.com/articles/spiral-modeladvantages-and-disadvantages.html. Carmara Royster. (ม.ป.ป). Joint Application Development (JAD) Technique. Retrieved February 14, 2016, from https://workstory.s3.amazonaws.com/ assets/81661/Requirement_Gather_JAD_Process_1_original.pdf. Dinesh Thankur. (ม.ป.ป). Rapid Application Development (RAD) Model and its Advantages and Disadvantages of RAD Model. Retrieved February 14, 2016, from http://ecomputernotes.com/software-engineering/rapid-application-development. Gerry Coleman and Renaat Verbruggen. (1998). A quality software process for rapid application development. Retrieved February 14, 2016, from http://www.itu.dk/people/katten/speciale/RAD_a_quality_software_process.pdf. Nabil Mohammed Ali Munassar and A. Govardhan. (2010). A Comparison between Five Models Of Software Engineering. International Journal of Computer Science Issues, (7). 94-101. Retrieved February 15, 2016, from http://www.ijcsi.org/papers/7-5-94101.pdf. Penna Sparrow. (2012). Spiral Model: Advantages and Disadvantages. Retrieved February 14, 2016, from http://www.ianswer4u.com/2011/12/spiral-model-advantagesand.html#axzz40X5LNxTc. Sophia Kuchmistaya. (2001). INCORPORATION OF JOINT APPLICATION DESIGN (JAD) IN SYSTEMS REQUIREMENT DETERMINATION. Retrieved February 14, 2016, from http://www.umsl.edu/~sauterv/analysis/488_f01_papers/kuchmistaya.htm. Sundararajan Murugaiyan. (2012).WATERFALL Vs V-MODEL Vs AGILE: A COMPARATIVE STUDY ON SDLC. Retrieved February 14, 2016, from http://www.jitbm.com/ Volume2No1/waterfall.pdf. Susan Sousa. (ม.ป.ป). The Advantages and Disadvantages/Best Practices of RUP Software Development. Retrieved February 14, 2016, from http://www.my-projectmanagement-expert.com /the-advantages-and-disadvantages-of-rup-softwaredevelopment.html.