วงจรการพัฒนาระบบ (SDLC) คืออะไร มีกี่ขั้นตอน

 

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

แยกหัวข้อให้แล้วคลิกที่หัวข้อได้เลย วงจรการพัฒนาระบบคืออะไร วงจรการพัฒนาระบบมีกี่ขั้นตอน วงจรการพัฒนาระบบมีกี่รูปแบบ การนำวงจรการพัฒนาระบบมาใช้ในโปรเจคจบ

วงจรการพัฒนาระบบคืออะไร

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

รูปภาพแสดงแผนผังกระบวนการของวงจรการพัฒนาระบบ

วงจรการพัฒนาระบบมีกี่ขั้นตอน

        วงจรการพัฒนาระบบแบ่งออกเป็น 6 ขั้นตอนตามรูปภาพด้านล่าง

รูปภาพแสดงวงจรการพัฒนาระบบ 6 ขั้นตอน

ขั้นตอนที่ 1 การเข้าใจปัญหา (Problem Recognition) 

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

รูปภาพแสดงขั้นตอนการเก็บรวบรวมความต้องการมาวิเคราะห์ปัญหาและศึกษาการทำงานของธุรกิจ

1.1 การรวบรวมความต้องการ (Gathering Requirements)

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

1.2 การวิเคราะห์ความต้องการ (Analyzing Requirements)

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

1.3 การจัดทำเอกสารความต้องการ (Documenting Requirements)

การเขียนเอกสารข้อกำหนดซอฟต์แวร์ (Software Requirements Specification, SRS) ซึ่งเป็นเอกสารที่ระบุความต้องการของซอฟต์แวร์อย่างชัดเจนและละเอียด เอกสารนี้ใช้อ้างอิงในการออกแบบและพัฒนาซอฟต์แวร์

1.4 การตรวจสอบและยืนยันความต้องการ (Validation of Requirements)

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

ขั้นตอนที่ 2 การศึกษาความเป็นไปได้ (Feasibility Study)

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

2.1 ศึกษาความเป็นไปได้ทางเทคนิค

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

2.2 ศึกษาความเป็นไปได้ทางเศรษฐศาสตร์

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

2.3 ศึกษาความเป็นไปได้ด้านการปฏิบัติงาน

เป็นการศึกษาด้านการนำระบบที่พัฒนาไปใช้งานจริงๆ ภายในองค์กรโดยระบบต้องเป็นที่ยอมรับจากผู้มีส่วนเกี่ยวข้อง ก่อนการนำไปใช้งานจริง

2.4 ศึกษาความเป็นไปได้ด้านเวลา

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

ขั้นตอนที่ 3 การวิเคราะห์และออกแบบระบบ (System Analysis and Design)

3.1 การวิเคราะห์ระบบ

เป็นขั้นตอนที่นำข้อมูลความต้องการ (Requirements) ที่ได้รวบรวมมาศึกษาวิเคราะห์ผู้มีส่วนได้ส่วนเสียในระบบ (Stakeholder Analysis) และกระบวนการทางธุรกิจ เพื่อทำความเข้าใจกระบวนการทำงานของระบบเดิม (AS-IS System) ที่ระบุหน้าที่ในแต่ละกระบวนการและกิจกรรม ซึ่งอาจเขียนออกมาเป็นแผนผังงานระบบ (System Flowchart) หรือ แผนผังกระบวนการทำงาน (Workflow Diagrams) รวมถึงปัญหาข้อบกพร่องต่างๆ ที่เกิดขึ้น จากนั้นทำการกำหนดสิ่งที่ต้องปรับปรุงและความต้องการหรือความคาดหวังสำหรับออกแบบระบบใหม่ขึ้นมา (TO-BE System) ผ่านแผนผังกระบวนการทำงาน (Workflow Diagrams)  หรือแบบจำลองกระบวนการ (Data Flow Diagram: DFD) และแบบจำลองข้อมูล ซึ่งในการวิเคราะห์ระบบประกอบด้วย 4 กิจกรรมได้แก่

3.1.1 การคาดเดาความต้องการ

เป็นการคาดเดาล่วงหน้าเกี่ยวกับคุณสมบัติของระบบจากประสบการณ์ของนักวิเคราะห์ระบบ ซึ่งความแม่นยำขึ้นอยู่กับประสบการณ์ของนักวิเคราะห์ระบบ

3.1.2 การสำรวจความต้องการ

เป็นการเก็บข้อมูลความต้องการจากผู้มีส่วนได้ส่วนเสียกับระบบโดยใช้เทคนิคการสืบเสาะข้อเท็จจริง (Fact-Finding Technics)

3.1.3 การสร้างข้อกำหนดความต้องการ

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

รูปภาพแสดงขั้นตอนการวิเคราะห์ระบบ

3.1.4 การเขียนแบบจำลองกระบวนการและแบบจำลองข้อมูล

นักวิเคราะห์ระบบจะสร้างแบบจำลองที่เรียกว่า แบบจำลองเชิงตรรกะ (Logical Models) เพื่อนำมาใช้กับงานพัฒนาระบบ โดยแบบจำลองแต่ละชนิด ต่างนำเสนอมุมมองในรายละเอียดที่แตกต่างกันไปเพื่อนำไปใช้แก้ไขปัญหาตามลักษณะงานนั้น โดยใช้แผนภาพกระแสข้อมูล (Data Flow Diagram) ที่เป็นแบบจำลองกระบวนการตามแบบแผนวิธีการพัฒนาระบบแบบดั้งเดิม ในกรณีที่ใช้วิธีการพัฒนาระบบเชิงวัตถุจะใช้แบบจำลองแผนภาพยูสเคส (Use Case Diagram) ในการสร้างแบบจำลองข้อมูลเชิงแนวคิดจะใช้แผนภาพอีอาร์ (Entity Relationship Diagram) เพื่อใช้อธิบายความสัมพัน์ระหว่างข้อมูล และพจนานุกรมข้อมูล (Data Dictionary) เพื่ออธิบายรายละเอียดโครงสร้างแฟ้มข้อมูล

3.2 การออกแบบระบบ

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

รูปภาพแสดงขั้นตอนการออกแบบระบบ

จากรูปภาพสามารถแบ่งกิจกรรมการออกแบบระบบออกเป็น 6 กิจกรรมดังนี้

3.2.1 การจัดหาระบบ

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

3.2.2 การออกแบบสถาปัตยกรรมระบบ

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

3.2.3 การออกแบบอินพุต เอ้าต์พุต และยูสเซอร์อินเตอร์เฟซ

เป็นการออกแบบฟอร์มหรือหน้าจอระบบสำหรับรับข้อมูลที่ผู้ใช้งานป้อนเข้ามาในระบบ จากนั้นนำข้อมูลไปประมวลผล และแสดงผลออกมาทางรายงาน

3.2.4 การออกแบบฐานข้อมูล

เป็นขั้นตอนการนำแผนภาพอีอาร์ที่สร้างขึ้นมาแปลงเป็นรีเลชันที่เขียนอยู่ในรูปแบบสคีมา (Schema) เพื่อแสดงรูปแบบการจัดเก็บข้อมูล

3.2.5 การสร้างต้นแบบ

เป็นการจัดทำต้นแบบของระบบ (Prototype) เพื่อให้ผู้ใช้งานได้เห็นภาพและแนวทางการพัฒนาระบบว่าเป็นไปตามความต้องการหรือไม่

3.2.6 การออกแบบโปรแกรม

เป็นการออกแบบโปรแกรมในภาพรวม แล้วจึงออกแบบในระดับรายละเอียด อาจเขียนผังโครงสร้าง (Structure Chart) เพื่อให้เห็นโมดูลภายในระบบ และความสัมพันธ์แต่ละโมดูล

ขั้นตอนที่ 4 การพัฒนาและทดสอบระบบ (System Development and Testing)

รูปภาพแสดงขั้นตอนการพัฒนาและทดสอบระบบ

4.1 การพัฒนาระบบ

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

4.2 การทดสอบระบบ

เป็นการทดสอบระบบก่อนนำไปติดตั้ง เพื่อให้แน่ใจว่าระบบไม่มีข้อผิดพลาดที่ร้ายแรง และตรงตามความต้องการของผู้ใช้งาน ซึ่งในบางครั้งโปรแกรมเมอร์จะทดสอบระบบที่ตนเองเขียนในเบื้องต้น แต่หากจะทำการทดสอบแบบละเอียดต้องใช้นักทดสอบระบบที่มีความเชี่ยวชาญมากกว่า การทดสอบระบบในปัจจุบันยังนิยมใช้การทดสอบแบบกล่องดำ (Black Box Testing) ที่มุ่งเน้นการทดสอบผลลัพธ์ที่ได้จากการประมวลผล ว่าถูกต้องหรือไม่ และการทดสอบแบบกล่องขาว (White Box Testing) เป็นการทดสอบด้วยวีธีการเขียนโค้ดเพื่อทดสอบตรรกะการทำงานว่าถูกต้องหรือไม่

รูปภาพแสดงการทดสอบแบบกล่องดำ (Black Box Testing)

รูปภาพแสดงการทดสอบแบบกล่องขาว (White Box Testing)

ขั้นตอนที่ 5 การติดตั้งระบบและจัดทำเอกสาร (System Implement and Document)

5.1 การติดตั้งระบบ

เป็นการนำระบบไปติดตั้งบนสภาพแวดล้อมที่ได้เตรียมเอาไว้ โดยแบ่งเป็น 4 วิธีได้แก่ การติดตั้งเพื่อใช้ระบบใหม่ทันที การปรับเปลี่ยนแบบคู่ขนาน การติดตั้งแบบทีละเฟส และการติดตั้งแบบโครงการนำร่อง

5.2 การจัดทำเอกสารคู่มือการใช้งานและการจัดฝึกอบรม

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

ขั้นตอนที่ 6 การบำรุงรักษาระบบ (System Maintenance)

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

6.1 วิธีการแก้ไขระบบให้ถูกต้อง (Corrective Maintenance)

บางครั้งข้อผิดพลาดของระบบไม่ได้ถูกพบในระหว่างการพัฒนาและทดสอบระบบ แต่ถูกพบระหว่างการใช้งานจริงจากผู้ใช้งาน จึงต้องทำการแก้ไขระบบให้มีความถูกต้องจนกว่าระบบจะมีความเสถียร

6.2 วิธีการดัดแปลงระบบ (Adaptive Maintenance)

กรณีที่มีการเปลี่ยนแปลงฮาร์ดแวร์ และซอฟต์แวร์ระบบปฏิบัติการ อาจส่งผลกระทบถึงระบบ จึงต้องมีการดัดแปลงแก้ไข เพื่อให้ระบบสามารถทำงานได้อยุ่บนสภาพแวดล้อมใหม่

6.3 วิธีการปรับปรุงให้ดีขึ้น (Perfective Maintenance)

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

6.4 วิธีการป้องกัน (Preventive Maintenance)

เป็นการป้องกันปัญหาที่อาจเกิดขึ้นในอนาคต เพื่อหลีกเลี่ยงปัญหาเหล่านั้นที่เปิดขึ้นกับระบบ จนทำให้ระบบไม่สามารถทำงานได้ตามปกติ

วงจรการพัฒนาระบบมีกี่รูปแบบ

1. Build-and-Fix Model

รูปภาพแสดงการพัฒนาระบบแบบ Build-and-Fix Model

Build-and-Fix Model เป็นโมเดลการพัฒนาที่เก่าแก่ที่สุด โดยโปรแกรมเมอร์จะเขียนโปรแกรมและแก้ไขไปเรื่อยๆ จนกว่าจะพอใจ เหมาะกับโปรแกรมขนาดเล็กที่ไม่มีความซับซ้อน

2. Water Fall Model

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

รูปภาพแสดงการพัฒนาระบบแบบ Water Fall Model

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

3. Incremental Model

รูปภาพแสดงการพัฒนาระบบแบบ Incremental Model

Incremental Model เป็นโมเดลที่วิวัฒนาการมาจาก Water Fall Model โดยแบ่งระบบงานออกเป็นระบบย่อยๆ เรียกว่า Incremental และจะพัฒนาแกนหลักของระบบก่อนจากนั้นจึงค่อยพัฒนาแต่ละ Incremental โดยมีขั้นตอนแบบวนซ้ำจนกระทั่งได้ระบบที่สมบูรณ์ ซึ่งลูกค้าจะเห็นความคืบหน้าของระบบเป็นระยะๆ

4. Spiral Model

Spiral Model เป็นวิธีการพัฒนาแบบค่อยเป็นค่อยไปตามจำนวนรอบ มีหลักการทำงานแบบวนเป็นรอบคล้ายก้นหอย ซึ่งในแต่ละรอบจะมีการวิเคราะห์ความเสี่ยง เพื่อประเมินและวางแผนการทำงานในรอบถัดไป ตามรูปภาพ

รูปภาพแสดงการพัฒนาระบบแบบ Spiral Model

จากรูปภาพสามารถแบ่งการทำงานออกเป็น 4 ส่วนดังนี้

ส่วนที่ 1 เกี่ยวข้องกับการวางแผน กำหนดจุดมุ่งหมาย เงื่อนไข และนาวทางต่างๆ ที่นำมาแก้ไขปัญหา

ส่วนที่ 2 เกี่ยวข้องกับการวิเคราะห์ความเสี่ยง ด้วยการนำแนวทางในการแก้ไขปัญหาต่างๆ มาประเมินและคัดเลือกแนวทางที่ดีที่สุด

ส่วนที่ 3 เกี่ยวกับการพัฒนาและทดสอบระบบ

ส่วนที่ 4 เกี่ยวกับการประเมิน โดยจะทบทวนผลลัพธ์ที่ได้จากขั้นตอนที่ผ่านมา เพื่อเตรียมตัวดำเนินการในวงรอบถัดไป

5. Rapid Application Developer (RAD)

Rapid Application Developer เป็นวิธีการพัฒนาระบบแบบรวดเร็ว โดยการลดขั้นตอนการวิเคราะห์ ออกแบบ การสร้าง และการทดสอบ โดยนำเคสทูลส์มาช่วย ทำให้การพัฒนาระบบใช้เวลารวดเร็ว ใช้ทีมงานขนาดเล็กที่มีความเชี่ยวชาญเฉพาะทาง มีกระบวนการตามรูปภาพ

รูปภาพแสดงการพัฒนาระบบแบบ Rapid Application Developer (RAD)

6. Joint Application Development (JAD)

รูปภาพแสดงการพัฒนาระบบแบบ Joint Application Development (JAD)

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

7. Unified Process (UP)

Unified Process เป็นระเบียบวิธีการพัฒนาระบบเชิงวัตถุหรือที่เรียกกันว่า Unified Modeling Language: UML ถูกพัฒนาขึ้นมาจาก Rational Software เพื่อให้ทีมพัฒนาระบบสามารถพัฒนาระบบที่มีคุณภาพ ตรงตามความต้องการของผู้ใช้งาน ภายใต้งบประมาณและระยะเวลาที่ถูกกำหนดไว้ โดยในปัจจุบันโมเดล UML ได้รับความนิยมและใช้งานกันอย่างกว้างขวาง เหมาะกับโปรเจคการพัฒนาระบบที่มีขนาดใหญ่ ประกอบด้วย 4 ระยะได้แก่ ระยะเริ่มต้น ระยะกำหนดรายละเอียด ระยะการสร้างระบบ และระยะการเปลี่ยนผ่าน ตามรูปภาพ

รูปภาพแสดงการพัฒนาระบบแบบ Unified Process (UP)

8. Agile Methodologies

Agile Methodologies เป็นอีกวิธีการพัฒนาที่มุ่งเน้นการตอบสนองต่อความเปลี่ยนแปลงมากกว่าการปฏิบัติงานตามแผน ไม่สนับสนุนการจัดทำเอกสารที่ไม่จำเป็น พัฒนามาจากวิธีการแบบ Spiral Model ในด้านการนำเสนอลำดับของกิจกรรม และการทบทวนในแต่ละรอบ (การวางแผน การวิเคราะห์ความเสี่ยง การพัฒนา และการประเมิน) 

การนำวงจรการพัฒนาระบบมาใช้ในโปรเจคจบ

        วงจรการพัฒนาระบบมักจะถูกนำไปใช้เป็นแนวทางในการพัฒนากับโปรเจคจบที่เกี่ยวข้องกับการพัฒนาระบบสารสนเทศ เว็บไซต์ หรือแอปพลิเคชัน ซึ่งจะกล่าวถึงภาคทฤษฎีในส่วนของบทที่ 2 แนวคิดและทฤษฏีที่เกี่ยวข้อง ที่อธิบายถึงนิยามและรายละเอียดคร่าวๆ ในแต่ละขั้นตอน และอาจระบุถึงรูปแบบหรือโมเดลที่นำมาใช้ในการพัฒนาซึ่งต้องเลือกให้เหมาะสมกับโปรเจคจบที่กำลังทำอยู่ด้วย และใช้ระเบียบวิธีการปฏิบัติในส่วนของบทที่ 3 วิธีการดำเนินงาน โดยอธิบายขั้นตอนของวงจรการพัฒนาระบบที่ประกอบด้วย 6 ขั้นตอน ซึ่งในแต่ละขั้นตอนจะลงรายละเอียดว่าผู้วิจัยมีการดำเนินการอย่างไรบ้าง โดยนำเสนอออกมาในรูปแบบของแผนภาพต่างๆ และการออกแบบส่วนติดต่อกับผู้ใช้งาน (User Interface)

        หากกำลังมองหาที่ปรึกษาในการทำโปรเจคจบ เรามีทีมงานไว้คอยบริการให้คำแนะนำฟรี ไม่มีค่าใช้จ่าย แอดไลน์ไอดี makewebproject หรือกำลังมองหาโปรเจคจบพร้อมรูปเล่ม 5 บท ที่นำไปติดตั้งและใช้งานได้เลย (มีคู่มือสอนการติดตั้งให้ดูแบบละเอียด) สามารถนำไปแก้โค้ดหรือแก้ไขรายละเอียดในเล่มเอกสารได้เอง แก้ง่ายด้วยเพราะมีคอมเม้นบอกที่โค้ด หากไม่เข้าใจก็สามารถสอบถามได้ตลอดเวลา เริ่มต้นเพียงแค่ 1,000 บาท เท่านั้น คลิกเลย

หากต้องการศึกษาอย่างละเอียดแอดมินขอแนะนำหนังสือเรื่อง การวิเคราะห์และออกแบบระบบ (โอภาส เอี่ยมสิริวงศ์) มาอ่านนะครับ สำหรับบทความนี้ยาวมากๆ ถ้าชอบก็ช่วยกด Like กด ติดตามเอาไว้ทุกช่องทางนะครับ ถ้าไม่อยากพลาดบทความที่สอนเทคนิคการทำโปรเจคแบบฟรีๆ

อ่านข่าวอื่นๆเพิ่มเติมได้ที่ บทความและเทคนิคการทำวิจัย

 

กลับหน้าเทคนิคการทำโปรเจค