การสร้างต้นแบบ (Prototyping)
การสร้างต้นแบบ เป็นพัฒนาการที่รวดเร็วและเป็นการทดสอบการทำงานของแบบจำลอง (Model) หรือต้นแบบของระบบงานใหม่ ในการโต้ตอบและกระบวนการทำซ้ำประโยคคำสั่งในโปรแกรมที่เรียกว่า การวนรอบ (Interactive หรือ Iterative) โดยนักวิเคราะห์ระบบและผู้ใช้ การทำต้นแบบสามารถทำให้กระบวนการพัฒนาเร็วและง่ายขึ้น โดยเฉพาะอย่างยิ่งโครงการที่ความต้องการของผู้ใช้นั้นยากแก่การเข้าใจอย่างชัดเจน การสร้างต้นแบบแบ่งออกเป็น 2 ประเภทใหญ่ๆ คือ
1. Operational Prototype เป็นต้นแบบที่สามารถทำงานและเข้าถึงแฟ้มข้อมูลได้จริง สามารถรับข้อมูลเข้าและนำข้อมูลเหล่านั้นมาคำนวณเปรียบเทียบและแสดงผลลัพธ์จริง
2. Nonoperational Prototype เป็นต้นแบบจำลอง โดยทั่วไปมักรวมถึงข้อมูลต่างๆ ที่นำเข้าและข้อมูลที่แสดงผลลัพธ์ออกมา ข้อมูลที่แสดงผลลัพธ์ออกมาจะอยู่ในรูปแบบของรายงานและทางจอภาพ ข้อมูลที่นำเข้าจะแสดงถึงวิธีที่ข้อมูลถูกจับ ผู้ใช้คำสั่งอะไรต้องเข้าไป และวิธีเข้าถึงระบบแฟ้มข้อมูลอื่นๆ
การพัฒนาโดยการทำต้นแบบจะใช้เวลาน้อยกว่าวิธีศึกษาแบบดั้งเดิม เป้าหมายของการทำต้นแบบก็เพื่อการสร้างระบบขนาดเล็กที่ไม่แพงแต่รวดเร็ว และเพื่อการเพิ่มหรือทดแทนระบบเชิงปฏิบัติงานแบบเต็มขนาด ขณะที่ผู้ใช้ได้ทำงานร่วมกับระบบก็สามารถให้คำแนะนำที่สามารถเป็นประโยชน์ให้กับต้นแบบอื่นๆ ได้ แม้ว่าต้นแบบที่จะไปเป็นระบบขั้นสุดท้ายต้องถูกทิ้งไป แต่ความรู้ที่ได้จากการสร้างต้นแบบนั้นก็ยังคงนำไปสร้างให้เป็นระบบจริงขึ้นมาใหม่อีกได้
การเลือกใช้การพัฒนาแบบการสร้างต้นแบบควรเลือกใช้ในกรณีต่อไปนี้
1. ผู้ใช้ยังไม่ทราบความต้องการระบบที่แน่ชัด
2. ความต้องการของผู้ใช้มีการเปลี่ยนแปลงอย่างต่อเนื่อง
3. ผู้ใช้มีประสบการณ์เกี่ยวกับระบบที่กำลังพัฒนาอยู่น้อยมาก
4. มีความจำเป็นจะต้องพัฒนาระบบในระยะเวลาอันสั้นและใช้ค่าใช้จ่ายน้อย
5. การดำเนินการหรือการประมวลผลไม่มีกฎเกณฑ์แน่ชัด
กระบวนการสร้างต้นแบบ (Prototyping Process)
การสร้างต้นแบบจะไม่พัฒนาทั้งระบบทีเดียวทั้งหมด แต่จะพัฒนาโดยใช้ต้นแบบ ซึ่งประกอบด้วยส่วนต่างๆ ของระบบใหม่แต่จำลองให้มีขนาดเล็กเพื่อให้ผู้ใช้ได้ทดลองใช้ก่อน และให้ข้อเสนอแนะเพื่อใช้ในการปรับปรุงต้นแบบนี้ให้เหมาะสมต่อไป กระบวนการนี้จะปฏิบัติการซ้ำๆ จนกระทั่งผู้ใช้ยอมรับระบบ จึงจะนำต้นแบบนั้นไปพัฒนาให้เต็มรูปแบบต่อไป
ขั้นตอนของวิธีการสร้างต้นแบบมี 5 ขั้นตอนดังนี้
1. กำหนดความต้องการ เป็นการหาความต้องการพื้นฐานของผู้ใช้ระบบ นักออกแบบระบบจะต้องมีเวลาเพียงพอในการศึกษาหาความต้องการด้านสารสนเทศพื้นฐานของผู้ใช้
2. ออกแบบต้นแบบ นักพัฒนาระบบสามารถใช้เครื่องมือในการพัฒนาต้นแบบออกแบบระบบ เพื่อให้เกิดความรวดเร็ว
3. นำต้นแบบไปใช้ ผู้ใช้จะนำต้นแบบไปทดลองใช้ว่าสามารถตอบสนองความต้องการของผู้ใช้เพียงใด โดยผู้ใช้สามารถให้ข้อคิดเห็นเกี่ยวกับปัญหาหรือข้อแนะนำในการปรับปรุงต้นแบบได้
4. การปรับแต่งต้นแบบ เป็นการนำความเห็นของผู้ใช้มาปรับปรุงต้นแบบให้มีประสิทธิภาพมากขึ้น ขั้นตอนนี้จะเกิดซ้ำไปซ้ำมาจนกระทั่งผู้ใช้เกิดความพอใจ แล้วจึงจะสามารถนำต้นแบบไปใช้งานได้ (Operational Prototype)
ภาพที่ 1 ขั้นตอนการสร้างต้นแบบ (Prototyping Process)
เครื่องมือในการพัฒนาต้นแบบ (Prototyping Tools) มีดังนี้
- CASE Tools เรียกอีกชื่อหนึ่งว่า Computer Aided Software Engineering คือซอฟต์แวร์พิเศษสำหรับช่วยในการเขียนโปรแกรม เคสหรือเครื่องมือช่วยพัฒนาซอฟต์แวร์นี้จะสามารถสร้างโปรแกรมต่างๆ จากข้อกำหนดเช่น โปรแกรมบันทึกข้อมูล โปรแกรมแสดงรายงาน โปรแกรมค้นฐานข้อมูล โปรแกรมคำนวณ ฯลฯ ได้อย่างรวดเร็ว
- Report generators เรียกอีกชื่อหนึ่งว่า ตัวเขียนรายงาน (Report Writer) คือตัวสร้างรายงาน เป็นเครื่องมือสำหรับการออกแบบรูปแบบของรายงาน ผู้ใช้จะสามารถมองเห็นได้ล่วงหน้าก่อนที่จะมีการตัดสินใจออกแบบรายงานขั้นสุดท้าย
- Screen generators เรียกอีกชื่อหนึ่งว่า ตัวสร้างฟอร์ม (Forms Generator) คือตัวสร้างหน้าจอภาพ เป็นเครื่องมือประเภทซอฟต์แวร์ที่ช่วยออกแบบส่วนต่อประสานตามสั่ง สร้างหน้าจอภาพ และจัดการกับกระบวนการป้อนข้อมูล ควบคุมจอภาพ โดยการแสดงคำบรรยายภาพ เขตข้อมูล ข้อมูล และคุณลักษณะประจำอื่นๆ ที่สามารถมองเห็นได้
- Application generators เรียกอีกชื่อหนึ่งว่า ตัวสร้างชุดคำสั่ง (Code Generator) คือตัวสร้างระบบประยุกต์ ช่วยพัฒนาโปรแกรมคอมพิวเตอร์อย่างรวดเร็ว โดยการแปลแบบจำลอง
เชิงตรรกะเป็นรหัสคำสั่งยุคที่สี่
- Fourth-generation languages (4GLs) หรือภาษายุคที่สี่ ส่วนใหญ่เป็นภาษาไร้กระบวนคำสั่ง (Nonprocedural Languages) ที่กระตุ้นให้ผู้ใช้และโปรแกรมเมอร์กำหนดผลลัพธ์ที่ต้องการ ขณะที่คอมพิวเตอร์กำหนดลำดับของคำสั่งที่ทำให้ผลลัพธ์นั้นสำเร็จลุล่วงได้ ผู้ใช้และโปรแกรมเมอร์ไม่ต้องใช้เวลาในการพัฒนาอย่างมากอีกต่อไป
ภาพที่ 2 เครื่องมือการพัฒนาต้นแบบ (Prototyping Tools)
ข้อดีของการพัฒนาต้นแบบ
- สามารถหลีกเลี่ยงการเข้าใจผิดระหว่างผู้ใช้และผู้พัฒนา
- นักพัฒนาระบบสามารถสร้างข้อกำหนดสำหรับระบบที่ต้องการได้อย่างถูกต้องแม่นยำโดยมีมูลฐานมาจากต้นแบบ
- ผู้จัดการระบบสามารถประเมินแบบจำลองที่ใช้งานได้อย่างมีประสิทธิภาพมากกว่าข้อกำหนดที่เขียนเป็นเอกสาร
- นักวิเคราะห์ระบบสามารถใช้ตัวต้นแบบในการพัฒนาการทดสอบ การฝึกอบรม ก่อนที่ระบบจริงจะเสร็จสมบูรณ์และพร้อมที่จะใช้งาน
- ต้นแบบสามารถลดความเสี่ยงในความล้มเหลวการพัฒนาระบบได้
ปัญหาที่อาจเกิดในการพัฒนาต้นแบบ
- การทำต้นแบบที่รวดเร็วและดีเกินไปอาจทำให้เกิดปัญหาที่ไม่สามารถมองเห็น จะเห็นอีกครั้งเมื่อระบบได้พัฒนาเสร็จแล้วถูกนำมาใช้ จึงทำให้แก้ไขได้ยาก
- การทำงานบางอย่างอาจไม่สามารถทดสอบได้ในต้นแบบ เช่น ความเชื่อถือได้ การบำรุงรักษาระบบ เป็นต้น
- ต้นแบบที่ซับซ้อนจะทำให้ระบบเทอะทะและยากต่อการจัดการ
Rapid Application Development (RAD)
Rapid Application Development- based Methodology เป็นแนวทางการพัฒนาระบบแนวใหม่ที่พัฒนาขึ้นในช่วงปี ค.ศ. 1990 เพื่อแก้ไขจุดอ่อนของแนวทางการพัฒนาระบบแบบ Structured System Analysis and Design Methodology (SSADM) ด้วยการปรับระยะในวงจรการพัฒนาระบบ ให้มีขั้นตอนการทำงานที่รวบรัดมากขึ้น มีการเลือกใช้เครื่องมือ (Tools) เทคนิค (Techniques) และเทคโนโลยี (Technology) ต่าง ๆ เพื่อช่วยให้การพัฒนาระบบนั้นดำเนินการได้อย่างรวดเร็ว อีกทั้งผู้ใช้ระบบยังสามารถทดลองใช้โปรแกรมต้นแบบเพื่อบอกนักวิเคราะห์ระบบได้ว่าระบบที่ออกแบบมานั้นถูกต้องหรือไม่ และมีข้อผิดพลาดใดเกิดขึ้นบ้าง จากที่กล่าวไว้ข้างต้นว่า แนวทางการพัฒนาระบบแบบ RAD นี้ได้มีการนำเทคนิคและเครื่องมือชนิดต่างๆ เข้ามาสนับสนุนการพัฒนาระบบให้สามารถดำเนินการในขั้นตอนต่างๆ ใน SDLC ได้ด้วยการใช้ระยะเวลาที่น้อยกว่าแบบ SSADM ยกตัวอย่างเทคนิคและเครื่องมือดังกล่าว เช่น CASE Tools, JAD และโปรแกรมภาษาที่ช่วยสร้างโค้ดโปรแกรม ช่วยออกแบบหน้าจอ รายงานและแบบฟอร์มต่าง ๆ ได้อย่างรวดเร็ว
ขั้นตอนการทำงานของวงจรการพัฒนาแบบ RAD ประกอบไปด้วย 4 ส่วน ดังนี้
1. การกำหนดความต้องการ เป็นการกำหนดหน้าที่และงานต่าง ๆ ภายในระบบ โดยผู้ใช้และบริหารร่วมสัมมนา
2. การออกแบบโดยผู้ใช้ ผู้ใช้มีส่วนในการออกแบบระบบที่ไม่ใช่ทางเทคนิคคอมพิวเตอร์ เช่น ฟอร์ม หน้าจอ
3. การสร้างระบบ โดยการใช้ตัวซอฟต์แวร์ประยุกต์อย่างเร็ว (RAD Software) ในการสร้างโปรแกรม
4. การเปลี่ยนระบบ ทำการทดสอบระบบให้เสร็จสิ้นก่อน ฝึกอบรม แล้วจึงมีการเปลี่ยนแปลงเครื่องมือในการพัฒนาระบบงานอย่างเร็ว
การรวมขั้นตอนการทำงานของวงจรการพัฒนาระบบ (SDLC) เพื่อให้เป็นวงจรการพัฒนาแบบ RAD สามารถแสดงได้ดังนี้
จากรูปจะสังเกตว่ามีการรวบรวมขั้นตอน Project Identification and Selection เข้ากับ Project Initiation and Planning ให้เหลือเพียงขั้นตอน Planning เพียงขั้นตอนเดียว ส่วน Analysis และ Logical Design ถูกรวมเข้าเป็นขั้นตอน Design เพียงขั้นตอนเดียว และ Implementation กับ Maintenance ถูกรวมให้เป็น Cutover เพียงขั้นตอนเดียว ดังนั้นการใช้เทคนิค RAD จะช่วยให้การพัฒนาระบบดำเนินการได้อย่างรวดเร็วและมีประสิทธิภาพ
อย่างไรก็ตาม ถึงแม้ว่าแนวทางการพัฒนาระบบแบบ RAD จะพัฒนาระบบดำเนินการได้รวดเร็วเพียงใด นักวิเคราะห์ระบบที่เลือกวิธีการนี้จะต้องพบกับปัญหาซึ่งเป็นข้อเสียของแนวทางการพัฒนาระบบแบบ RAD นั่นคือ การเปลี่ยนแปลงความต้องการของผู้ใช้อยู่ตลอดเวลา เนื่องจากผู้ใช้ได้ทดลองใช้โปรแกรมต้นแบบที่สามารถสร้างและแก้ไขง่ายนั่นเอง นอกจากนี้วิธีการพัฒนาระบบที่มีแนวทางในการพัฒนาตามแบบ RAD ยังมีการแตกแขนงออกไปอีกหลายวิธี ในที่นี้ขอยกตัวอย่างเพียง 3 วิธี ดังนี้
1. Phased Development-based Methodology เป็นวิธีการพัฒนาโดยแบ่งระบบออกเป็น Version เพื่อพัฒนาครั้งละ Version ตามลำดับ โดยเริ่มที่ขั้นตอนการวางแผน(Planning) และตามด้วยขั้นตอนการวิเคราะห์ความต้องการของผู้ใช้ (User Requirements) ทั้งหมดที่รวบรวมได้ เพื่อแบ่งจำนวน Version ของระบบตามลำดับความสำคัญของความต้องการของผู้ใช้
การพัฒนาระบบใน Version ที่ 1 จะพัฒนาความต้องการที่สำคัญที่สุดก่อน โดยนำเอาความต้องการเหล่านั้นมาวิเคราะห์ (Analysis) ออกแบบ (Design) และพัฒนา (Implementation) จนกลายเป็นระบบ Version 1 (System Version 1) ที่สามารถติดตั้งและใช้งานได้จริง แล้วจึงเริ่มพัฒนา Version 2 ต่อไป ระบบ Version 2 จะเริ่มด้วยการนำระบบที่พัฒนาใน Version 1 มาวิเคราะห์
ความต้องการอีกครั้ง พร้อมทั้งเพิ่มความต้องการใหม่ที่ได้จากผู้ใช้ได้ทดลองใช้ Version 1 มาแล้วและต้องการเพิ่มรายละเอียดอื่นๆ อีก จากนั้นจึงออกแบบและพัฒนาจนกลายเป็น Version 2 และปฏิบัติเช่นนี้ไปจนกระทั่งได้ Version ที่สมบูรณ์ที่สุด
ความต้องการอีกครั้ง พร้อมทั้งเพิ่มความต้องการใหม่ที่ได้จากผู้ใช้ได้ทดลองใช้ Version 1 มาแล้วและต้องการเพิ่มรายละเอียดอื่นๆ อีก จากนั้นจึงออกแบบและพัฒนาจนกลายเป็น Version 2 และปฏิบัติเช่นนี้ไปจนกระทั่งได้ Version ที่สมบูรณ์ที่สุด
ข้อดี ของ Phased Development-based Methodology คือ ผู้ใช้สามารถใช้ระบบได้เร็วกว่า SSADM ถึงแม้ว่าระบบ Version 1 นั้นยังไม่สามารถครอบคลุมหน้าที่ทุกส่วนก็ตาม
ข้อเสีย คือ ผู้ใช้จะได้ใช้ระบบ Version 1 ที่ไม่สามารถทำงานได้ครอบคลุมทุกหน้าที่หรือทุกความต้องการได้ เนื่องจากระบบ Version 1 นั้นสามารถทำงานได้ตามหน้าที่หรือความต้องการที่จำเป็นและสำคัญที่สุดก่อน และต้องใช้เวลาในการรอระบบ Version 2 เพื่อเพิ่มเติมความสามารถในการทำงานของระบบ
ภาพที่ 5 กระบวนการทำงานแบบ Phased Development-based Methodology
2. Prototyping-based Methodology เป็นวิธีการพัฒนาระบบใน SDLC ที่นักวิเคราะห์สามารถดำเนินการในขั้นตอนการวิเคราะห์ ออกแบบ และขั้นตอนการสร้างหรือพัฒนาระบบพร้อมกันได้ และสร้างเป็นต้นแบบของระบบ (System Prototype) ที่สามารถทำงานได้จริงในบางส่วนของระบบ หรืออาจเรียกว่าเป็น “ระบบเทียม” แล้วนำตัวต้นแบบนั้นเสนอให้ผู้ใช้ระบบได้ทดลองใช้งาน เพื่อเก็บความคิดเห็นและข้อติชมจากผู้ทดลองใช้งานตัวต้นแบบนั้น จากนั้นจึงนำความคิดเห็นและข้อติชมมาวิเคราะห์ ออกแบบ และพัฒนาต้นแบบส่วนที่ 2 ที่เพิ่มเติมความสามารถในการทำงานของระบบให้มากขึ้น จากนั้นจึงเสนอให้ผู้ใช้ทดลองใช้และเก็บความคิดเห็นเพื่อนำมาวิเคราะห์ ออกแบบ และพัฒนาเป็นต้นแบบในลำดับถัดไปจนกระทั่งได้ต้นแบบที่ผู้ใช้ยอมรับ สามารถทำงานได้ครบทุกส่วนของระบบพร้อมที่จะติดตั้ง จึงสามารถเรียกต้นแบบนั้นว่า “ระบบ” และนำต้นแบบนั้นมาติดตั้งเป็น “ระบบใหม่”
ข้อดี Prototyping-based Methodology คือ ใช้เวลาน้อยในการพัฒนาเพื่อให้เป็นระบบที่สามารถใช้งานได้ เนื่องจากขั้นตอนการวิเคราะห์ ออกแบบ และพัฒนาสามารถดำเนินการไปพร้อมกันได้ด้วยการสร้างต้นแบบของระบบ (System Prototype) โดยผู้ใช้สามารถทดลองใช้ต้นแบบของระบบก่อนการติดตั้ง ทำให้สามารถระบุข้อผิดพลาดและความต้องการที่แท้จริงได้เร็วขึ้น
ข้อเสียที่เกิดจากวิธีนี้คือ เนื่องจากเป็นวิธีที่มีการสร้างต้นแบบของระบบทีละส่วนด้วยความรวดเร็ว ในขณะที่มีการเก็บรวบรวม วิเคราะห์ และออกแบบไปพร้อมๆ กัน ทำให้ขาดความรอบคอบในการตระหนักถึงปัญหาที่ตามมาเมื่อติดตั้งและใช้งานระบบทั้งหมดทุกส่วน เช่น ความยากต่อการใช้งานและการเรียนรู้ เป็นต้น จึงอาจทำให้ถูกมองว่า การออกแบบระบบนั้นไม่ดีพอ
ดังนั้นวิธีการนี้จึงเหมาะกับระบบงานที่มีขนาดเล็ก มีความซับซ้อนไม่มากนัก จึงจะทำให้วิธีนี้มีประสิทธิภาพพอที่จะนำมาใช้ในการพัฒนาระบบ
ดังนั้นวิธีการนี้จึงเหมาะกับระบบงานที่มีขนาดเล็ก มีความซับซ้อนไม่มากนัก จึงจะทำให้วิธีนี้มีประสิทธิภาพพอที่จะนำมาใช้ในการพัฒนาระบบ
ภาพที่ 6 กระบวนการทำงานแบบ Prototyping-based Methodology
3. Throw -Away Prototyping-based Methodology เป็นวิธีการพัฒนาระบบคล้ายๆ Prototyping-based Methodology ในส่วนการสร้างตัวต้นแบบ (Prototype) เพื่อเป็นตัวอย่างแสดงต่อผู้ใช้งาน แต่การใช้ตัวต้นแบบสามารถใช้เพื่อวัตถุประสงค์ที่แตกต่างกันหลายๆ ประการ และสามารถใช้ในขั้นตอนใดก็ได้ สำหรับวิธีการ Throw -Away Prototype นี้จะไม่ใช่ต้นแบบของระบบงานที่สามารถทดลองใช้งานได้จริง แต่เป็นตัวต้นแบบเพื่อเก็บรวบรวมความคิดเห็นและความต้องการของผู้ใช้ (Design Prototype) โดยแสดงให้ผู้ใช้เห็นถึงระบบที่ได้รับการออกแบบว่ามีการทำงานอย่างไร ถูกต้องหรือไม่และควรได้รับการแก้ไขในส่วนใดบ้าง เมื่อได้รับการยอมรับจากผู้ใช้แล้วว่าระบบที่ออกมานั้นถูกต้องแล้ว จึงเข้าสู่ขั้นตอนการสร้างและพัฒนาจริงโดยยุติการใช้ต้นแบบที่เคยสร้างมา และใช้ความถูกต้องนั้นมาสร้างระบบจริง
ข้อดีของวิธีนี้คือจะช่วยให้นักวิเคราะห์ระบบมั่นใจได้ว่า ระบบที่ออกมานั้นตรงตามความต้องการของผู้ใช้ ซึ่งทำให้สามารถลดความเสี่ยง ในการเกิดความผิดพลาดของระบบ ด้วยการสร้างความเข้าใจให้กับผู้ใช้ก่อนการสร้างระบบจริง แต่วิธีนี้จะใช้ระยะเวลาในการสร้างระบบจริงนานกว่าแบบ Prototyping-based Methodology เนื่องจากไม่ใช้ตัวต้นแบบนั้นมาเป็นระบบจริง อย่างไรก็ตามวิธีการนี้จะมีความถูกต้องและมีความน่าเชื่อถือมากกว่าวิธีอื่นๆ
ภาพที่ 7 กระบวนการทำงานแบบ Throw -Away Prototyping-based Methodology
ไม่มีความคิดเห็น:
แสดงความคิดเห็น