ระบบปฏิสัมพันธ์ในกระบวนการพัฒนาซอฟต์แวร์ (Interaction System in Software Development Process)
•
1 like•904 views
ฝากติดตามกด Like กด Love ❤️ กด Share ⤴️ ที่ https://www.facebook.com/TouchPoint.in.th/ ------------------------------------------------------------------ ฝากกด Subscribe ช่อง YouTube TouchPoint ที่ https://www.youtube.com/c/TouchpointTH ------------------------------------------------------------------ เว็บไซต์ https://touchpoint.in.th/ ------------------------------------------------------------------ ดร.กฤษณพงศ์ เลิศบำรุงชัย
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to ระบบปฏิสัมพันธ์ในกระบวนการพัฒนาซอฟต์แวร์ (Interaction System in Software Development Process)
Similar to ระบบปฏิสัมพันธ์ในกระบวนการพัฒนาซอฟต์แวร์ (Interaction System in Software Development Process) (20)
More from Dr.Kridsanapong Lertbumroongchai
More from Dr.Kridsanapong Lertbumroongchai (20)
ระบบปฏิสัมพันธ์ในกระบวนการพัฒนาซอฟต์แวร์ (Interaction System in Software Development Process)
- 2. ในการจัดทาซอฟต์แวร์หรือโปรแกรมประยุกต์ จะพัฒนาภายใต้ กระบวนการที่เรียกว่า วิศวกรรมซอฟต์แวร์ (Software Engineering) โดยกรรมวิธีที่นามาใช้ในการพัฒนาระบบเรียกว่า วงจรชีวิตของ ซอฟต์แวร์ (Software Life Cycle) เริ่มตั้งแต่การสารวจความต้องการ ระบบ จนกระทั่งพัฒนาเสร็จสิ้น และถูกนาไปใช้งาน ในบทนี้จะเน้นที่ ขั้นตอนที่ระบบปฏิสัมพันธ์จะส่งผลต่อการใช้งานและประสิทธิภาพของ ระบบซึ่งเป็นวิธีการและกระบวนการที่ครอบคลุมอยู่ในกิจกรรมส่วน ใหญ่ของขั้นตอนการพัฒนาระบบ ระบบปฏิสัมพันธ์ในกระบวนการ พัฒนาซอฟต์แวร์
- 3. กระบวนการของการพัฒนารูปแบบการใช้งานระบบซึ่งเกี่ยวข้องกับ การออกแบบระบบปฏิสัมพันธ์นั้น อาจกล่าวได้ว่า ได้ถูกแทรกซึมใน เกือบทุกขั้นตอนของวงจรการพัฒนาซอฟต์แวร์ จนไม่สามารถที่จะ แยกพิจารณาโดยเฉพาะเจาะจงเพียงขั้นตอนใดขั้นตอนหนึ่งได้ กลุ่ม บุคคลที่เกี่ยวข้องกับขั้นตอนต่างๆ ข้างต้นแบ่งได้ 2 กลุ่ม คือกลุ่ม ผู้ใช้งานระบบและกลุ่มผู้พัฒนาระบบ แต่บางครั้งผู้ใช้งานระบบอาจทา หน้าที่ในการออกแบบระบบด้วย วงจรของซอฟต์แวร์
- 5. บางครั้งผู้ใช้งานระบบทั้ง 2 กลุ่ม อาจทาหน้าที่ร่วมกันได้บางกรณีที่ทั้งสองกลุ่มทางานแยกจากกัน อย่างชัดเจน เช่น การพัฒนาระบบโปรแกรมผ่านทางเว็บไซต์ หรือ ระบบพาณิชย์ อิเล็กทรอนิกส์ เป็น ต้น โดยทั่วไป วงจรในการพัฒนาระบบจะเป็นวงจรแบบลาดับขั้น (The waterfallmodel) Requirement Specification Architectural Design Codingand UnitTesting Detailed Design Integration and Testing Operationand Maintenance
- 6. Operationand Maintenance การปรับปรุงระบบ Integrationand Testing การรวมส่วนประกอบ และการทดสอบ Codingand UnitTesting การเขียนโปรแกรมและ การทดสอบส่วนย่อย ArchitecturalDesign ออกแบบสถาปัตยกรรมระบบ 04 การกาหนดมาตรฐานที่วัดมีดังนี้ 01 02 การออกแบบรายละเอียด DetailedDesign 03 05 06 RequirementSpecification การกาหนดความต้องการ ของระบบ
- 9. 03 การออกแบบรายละเอียด Detailed Design โดยกาหนดรายละเอียดให้กับทุกส่วนประกอบของระบบจาก ขั้นตอนที่ 2
- 10. Coding and Unit Testing โดยการแปลงรายละเอียดของการออกแบบมาสู่ของการ เขียนโปรแกรม และได้มีการกาหนดวิธีการทดสอบว่าในแต่ ละส่วนของโปรแกรมนั้นเป็นไปตามข้อกาหนดหรือไม่ หาก มีข้อผิดพลาดก็ดาเนินการแก้ไขต่อไป 04 การเขียนโปรแกรมและ การทดสอบส่วนย่อย
- 11. Integration and Testing เพื่อต้องการทดสอบในเรื่อง การใช้งานร่วมกันของ ทรัพยากรในระบบ ในขั้นตอนนี้ อาจการทดสอบเพื่อให้ ผู้ใช้งานยอมรับระบบด้วย เพราะก่อนที่ระบบจะถูกส่งมอบ ให้แก่ลูกค้า ก็ต้องผ่านการทดสอบเพื่อการยอมรับ เสียก่อน 05 การรวมส่วนประกอบ และการทดสอบ
- 12. Integration and Testing โดยได้มีการกาหนดมาตรฐานการทดสอบระบบ เช่น ISO 9421 ใช้ทดสอบการใช้งานระบบภายใต้สภาพแวดล้อม ของการปฏิบัติงานในสานักงานอันส่งผลต่อสุขภาพและ ความปลอดภัยของผู้ใช้ซึ่งก็จะเกี่ยวกับการออกแบบใน ส่วนของระบบปฏิสัมพันธ์ด้วย 05 การรวมส่วนประกอบ และการทดสอบ
- 13. 06 การปรับปรุงระบบ Operation and Maintenance เป็นขั้นตอนที่เกิดขึ้นภายหลังการส่งมอบระบบให้กับ ลูกค้าแล้ว ซึ่งอาจจะเป็นกรณีของการแก้ไขข้อผิดพลาด ที่ได้มีการตรวจพบในภายหลัง การเพิ่มเติมฟังก์ชันการ ทางานของระบบ หรือแม้กระทั่งการออกแบบระบบใหม่ เพื่อทดแทนระบบเดิมที่ล้าสมัย ขั้นตอนของการปรับปรุง ระบบนี้จะส่งผลให้กระทบขั้นตอนอื่น ๆ ระบบเกือบทุก ขั้นตอนนอกจากนี้ขั้นตอนของการปรับปรุงระบบ ยัง เป็นขั้นตอนที่ใช้เวลามากที่สุดในบรรดาขั้นตอนต่างๆ อีกด้วย Requirement Specification Architectural Design Coding and Unit Testing Detailed Design Integration and Testing Operationand Maintenance
- 15. การออกแบบด้านการใช้งานระบบ Usability Engineering จะต้องปฏิบัติตามข้อกาหนดด้านการใช้งานระบบอย่างชัดเจน และ ออกแบบระบบให้เป็นไปตามข้อกาหนด โดยการสังเกตการผู้ปฏิบัติงาน ซึ่งมักจะกาหนดให้เป็นเฉพาะช่วงที่ผู้ปฏิบัติงานมีปฏิสัมพันธ์กับระบบ ซึ่ง วิธีการนี้ถือว่าเป็นความสามารถด้านการใช้งานระบบ ไม่ได้จากัดอยู่ เพียงส่วนของการติดต่อกับผู้ใช้งานเท่านั้น แต่ยังมีส่วนของการออกแบบ โครงสร้าง รายการติดต่อระหว่างฟังก์ชันภายในระบบ ซึ่งล้วนแล้วแต่ ส่งผลถึงประสิทธิภาพในการใช้งานระบบทั้งสิ้น
- 16. ในวงจรชีวิตของการพัฒนาซอฟต์แวร์ ขั้นตอนที่เกี่ยวข้อง กับการออกแบบด้านการใช้งานระบบจะอยู่ในส่วนแรก คือ ขั้นตอนการวิเคราะห์ความต้องการของระบบ โดยมีการ กาหนดมาตรฐานในการวัดขึ้นเป็นพิเศษ เพื่อใช้ทดสอบ ระบบปฏิสัมพันธ์โดยเฉพาะ
- 17. มาตรฐาน ISO 9241 เคยมีคาแนะนาในเรื่องการกาหนด หัวข้อในการทดสอบความสามารถในการใช้งานระบบ เพื่อ จะได้นาไปเป็นส่วนหนึ่งในการวิเคราะห์ความต้องการของ ระบบได้ โดยการแยกพิจารณาออกเป็น 3 ส่วนคือ ทางด้านประสิทธิผลการใช้งาน(Effectivemeasures) ทางด้านประสิทธิภาพการใช้งาน(Efficiencymeasures) ทางความพึงพอใจในการใช้งาน(Satisfactionmeasures)
- 19. ความเหมาะสมของพนักงาน ประสิทธิผล ประสิทธิภาพ ความพึงพอใจ : ระดับความพึงพอใจที่มีต่อการฝึกอบรม : จานวนร้อยละของความต้องการที่ระบบ สามารถตอบสนองได้ : เวลาที่ใช้ไปเพื่อทาภาระงานมันได้สาเร็จ 01
- 20. 02 ความเหมาะสมเรื่องการฝึกอบรม ผู้ใช้งานระบบ ประสิทธิผล ประสิทธิภาพ ความพึงพอใจ : ความสามารถในการใช้งานเมื่อเปรียบเทียบกับผู้ใช้ ที่มีความชานาญ : ระดับความพึงพอใจที่มีต่อการฝึกอบรม : จานวนคาสั่งที่ได้มีการฝึกอบรม
- 21. ความสามารถในการเรียนรู้ระบบ 03 ประสิทธิผล ประสิทธิภาพ ความพึงพอใจ : เวลาที่ใช้ในการเรียนรู้ : ระดับความพึงพอใจต่อความง่ายในการเรียนรู้ : จานวนร้อยละของฟังก์ชันที่ได้มีการเรียนรู้
- 22. 04 ความทนทานต่อความบกพร่อง ของระบบ ประสิทธิผล ประสิทธิภาพ ความพึงพอใจ : เวลาที่ใช้ไปในการแก้ไขความผิดพลาด : ระดับความพึงพอใจต่อการจัดการ กับสถานการณ์ผิดพลาดของระบบ : จานวนร้อยละของความผิดพลาดที่สามารถแก้ไขได้
- 23. ข้อโต้แย้งเกี่ยวกับการประเมินความสามารถในการใช้งาน ระบบ คือ ถ้าหากใช้ในขั้นตอนของการวิเคราะห์ความต้องการ ของระบบแล้วอาจทาให้จานวนบางค่า ไม่สามารถกาหนดได้ ตามความเป็นจริง อย่างไรก็ตามหากได้มีการพิจารณา กาหนดกรอบของการวิเคราะห์การทางานของระบบร่วมกับ กรอบการปฏิบัติงานที่เหมาะสม ก็จะช่วยให้สามารถควบคุม ระบบให้ดาเนินการจัดทาไปตามแนวทางที่เหมาะสมได้
- 24. การสร้างระบบต้นแบบและการทาซ้า ต้นแบบ (Prototype) คือ ตัวแทนอย่างเป็นรูปประธรรมของการออกแบบ ซึ่งบางครั้งอาจจะแยกลาบากกับคาว่า sketch ซึ่งถ้าจะสามารถนาไปเสนอ ผ่านทางกระดาษหรือซอฟต์แวร์
- 25. ในขั้นตอนของการกาหนดความต้องการของระบบถึงแม้ว่า จะมีการใช้งานเครื่องมือเข้าช่วยในการวิเคราะห์เพื่อให้มี ความละเอียดรอบคอบเพียงใดก็ตาม ยังไม่สามารถเป็น หลักประกันได้ว่าสามารถวิเคราะห์ได้ครอบคลุมทุกความ ต้องการ และเป็นไปตามที่ผู้ใช้งานระบบต้องการ ดังนั้นใน การดาเนินการ จะมีการสร้างระบบต้นแบบสาหรับแต่ละส่วน การทางาน โดยอาจไม่จาเป็นต้องมีรายละเอียดครบทุก ฟังก์ชั่น หรือประมวลผลได้ครบถ้วนตามความเป็นจริง ระบบต้นแบบนี้จะถูกนาให้ผู้ใช้งานระบบได้ทาการทดสอบ เพื่อหาข้อผิดพลาดตลอดจนคาแนะนาในการใช้งานแล้วนา กลับมาแก้ไข ปรับปรุง แล้วนาไปทดสอบต่อไป ซึ่งเป็นขั้นตอน ที่ต้องมีการทาซ้าเพื่อให้สามารถตอบสนองต่อความ ต้องการและความพึงพอใจให้ดีที่สุด
- 26. วิธีการในการสร้างระบบต้นแบบมี 3 วิธีได้แก่ ต้นแบบชนิดทดสอบลบทิ้ง 01 Throw-away 02 ต้นแบบที่มีการเพิ่มเติมในทุก ขั้นตอนของการสร้างระบบ ArchitecturalDesign ต้นแบบที่มีการปรับปรุงให้เป็น ระบบที่สมบูรณ์ 03 Evolutionary
- 27. 01 ต้นแบบชนิดทดสอบลบทิ้ง Throw-away โดยมีการสร้างระบบต้นแบบ เพื่อทดสอบความต้องการ จนกว่าจะได้ระบบที่สนองตอบต่อความต้องการ หลังจาก นั้นก็จะมีการบันทึกความต้องการต่างๆ เพื่อนาไปใช้ใน กระบวนการของการสร้างระบบจึงต่อไป ซึ่งระบบต้นแบบที่ ใช้ในการทดสอบก็จะถูกยกเลิกไปในที่สุด
- 28. Evolutionary คือ การใช้ต้นแบบเดิมแล้วนามาสร้างต้นแบบเพิ่มเติมเข้าไป หลังจากมีการสารวจความต้องการเพิ่มขึ้น เมื่อทดสอบแต่ ละต้นแบบแล้วก็จะนาความต้องการนั้นไปสร้างระบบจริง ทันที โดยมีการเพิ่มเติมทั้งในระบบต้นแบบและเอารูปจริงไป พร้อมๆ กัน 02 ต้นแบบที่มีการเพิ่มเติมในทุก ขั้นตอนของการสร้างระบบ
- 29. Incremental จะถูกนามาใช้เป็นพื้นฐานในการสร้างระบบจริงในทุก ขั้นตอนของวงจรการพัฒนาระบบ คือหลังจากได้มีการ ทดสอบว่าตรงกับความต้องการของผู้ใช้ ทั้งในเรื่องความ ถูกต้องของการประมวลผลและความพึงพอใจในการใช้ งานแล้ว ก็จะนาต้นแบบนั้นไปพัฒนาให้เป็นโปรแกรมระบบ ข้อมูลผลที่สมบูรณ์เพื่อการใช้งานต่อไป 03 ต้นแบบที่มีการปรับปรุง ให้เป็นระบบที่สมบูรณ์
- 32. 01 ปัญหาด้านระยะเวลา Time คือ ถ้าหากใช้เวลามากเกินไปในการสร้างต้นแบบ แต่ในที่สุดต้นแบบ นั้นไม่ได้ถูกนามาใช้งาน ก็จะเกิดปัญหาการใช้เวลาให้สูญไปโดย เปล่าประโยชน์ จึงมีการพัฒนาระบบต้นแบบอย่างรวดเร็วขึ้นมา (Rapid Prototyping) เพื่อลดระยะเวลาในการสร้างแต่ในส่วนของ การตรวจสอบความถูกต้องและความพึงพอใจของผู้ใช้ยังต้องทา ด้วยความละเอียดรอบคอบวิธีการที่นามาใช้เพื่อลดระยะเวลาการ พัฒนาระบบต้นแบบ คือ
- 33. 01 การใช้โครงร่างเพื่ออธิบายระบบ Storyboards โดยการใช้โปรแกรมจาพวกการสร้างกราฟิกด้วยความรวดเร็ว สวยงาม โดยที่เมื่อนาไปใช้จะเสมือนของจริง ในการใช้โครงร่างที่จะ ไม่เกี่ยวข้องกับทรัพยากรระบบ เช่น ความเร็วในการประมวลผล โปรแกรมฐานข้อมูลเป็นต้น
- 35. High-level Programming support เพื่อช่วยให้ผู้ออกแบบสร้างระบบต้นแบบที่มีความคล้ายคลึงกับ ระบบจริง โดยสามารถทดสอบทั้งด้านการโต้ตอบเวลาในการ ตอบสนองและมีระบบจัดการติดต่อกับผู้ใช้งานระบบ (UIM a user interface management system) ที่ได้ออกแบบมาเพื่อสร้าง ระบบต้นแบบที่รองรับการตอบสนองต่อการใช้งานได้ดี 03 การใช้ความช่วยเหลือ จากโปรแกรมระดับสูง
- 36. ปัญหาด้านการวางแผน Planning การใช้งานระบบต้นแบบควบคู่ไปกับการพัฒนาระบบจริง อาจ เป็นสิ่งใหม่สาหรับผู้ควบคุมโครงการ (Project Manager) ซึ่งถ้า หากในแผนการปฏิบัติงานไม่ได้รวมขั้นตอนและระยะเวลาสาหรับ ระบบต้นแบบแล้ว อาจก่อให้เกิดความยุ่งยากได้ดังนั้นก่อนการ วางแผนเกี่ยวกับขั้นตอนและระยะเวลาในการปฏิบัติงาน ควร รวมขั้นตอนการสร้างระบบต้นแบบและเผื่อระยะเวลาไว้ใน แผนการปฏิบัติงาน 02
- 37. ปัญหาด้านการใช้งานที่ไม่เป็น Non-functional Features เช่น การทางานด้านการรักษาความปลอดภัยของระบบดาเนินการ เพื่อให้ระบบมีคุณสมบัติของความน่าเชื่อถือ การวิเคราะห์เวลาการ ตอบสนองของระบบ (Response Time) ไม่สามารถนาเสนอผ่าน ระบบต้นแบบได้ ฟังก์ชันหลัก 03
- 38. 04 ปัญหาด้านสัญญาการดาเนินงาน Contract ปกติในสัญญาว่าจ้างจะต้องมีการกาหนดข้อตกลงเกี่ยวกับ ลักษณะโปรแกรมไว้แล้ว การใช้งานระบบต้นแบบเพียงอย่างเดียว เพื่อสารวจความต้องการและความพึงพอใจของผู้ใช้ อาจก่อให้เกิด ปัญหาเรื่องขอบเขตความต้องการของผู้ใช้เกินว่าที่ได้มีการตกลง ไว้ในสัญญา เพื่อเป็นการลดปัญหาดังกล่าวการใช้งานระบบ ต้นแบบเพื่อสารวจความต้องการต้องดาเนินการอย่างรอบคอบ โดยพิจารณาถึงขอบเขตของสัญญาในการจ้างทาระบบด้วย
- 40. การตัดสินใจผิดพลาดในขั้นตอนแรกๆ ของการออกแบบ อาจทา ให้เกิดปัญหาต่อเนื่องไปยังขั้นตอนต่างๆ ในระบบจนบางครั้งยาก จะแก้ไขได้ เช่น การออกแบบส่วนของการแสดงข้อมูลเวลาเป็น ตัวเลข 2 กลุ่มคือ 00:00 ซึ่งถ้าเป็นไปตามระบบคอมพิวเตอร์แล้ว ตัวเลขนี้สามารถแสดงค่าได้ถึง 99:99 แต่จากการทดสอบและเป็น ที่รับรู้ในกลุ่มผู้ใช้ระบบนาฬิกาแบบ 12 ชม. ตัวเลขสูงสุดคือ 12:59 ซึ่งผู้ออกแบบและผู้ใช้งานต่างก็ยอมรับในข้อจากัดนี้แต่ ปรากฏว่าในการนาไปใช้งานจริงผู้ใช้บางกลุ่มใช้ระบบนาฬิกาแบบ 24 ชม. ทาให้ไม่สามารถกาหนดให้ระบบแสดงผลตามรูปแบบที่ ต้องการได้ เป็นต้น
- 41. ปัญหาที่พบในระหว่างการทดสอบระบบ เช่น จากตัวอย่างของ ปัญหาการจัดการด้านเวลาของระบบที่ใช้นาฬิกาแบบ 24 ชม. หากผู้ออกแบบคิดว่าผู้ใช้มีปัญหายุ่งยากในการตั้งเวลา ผู้ออกแบบอาจแก้ปัญหาด้วยการเปลี่ยนข้อจากัดเวลาเป็น 24:59 แทนที่จะแค่เพิ่มเติมข้อมูล AM,PM เพื่อให้ทั้งสองระบบใช้ งานร่วมกันได้ดี เป็นต้น