Decision Support System Development อาจารย์สุรินทร์ทิพ ศักดิ์ภูวดล ผู้สอน สำนักเทคโนโลยีสารสนเทศและการสื่อสาร มหาวิทยาลัยนเรศวร วิทยาเขตสารสนเทศพะเยา

เนื้อหา (1/2) แนวทางการพัฒนาระบบสนับสนุนการตัดสินใจ ทีมงานในการพัฒนาระบบสนับสนุนการตัดสินใจ ระบบสนับสนุนการตัดสินใจที่พัฒนาโดยผู้ใช้ระดับต่าง ๆ การติดตั้งระบบสนับสนุนการตัดสินใจ เครื่องมือที่ใช้ในการพัฒนาระบบสนับสนุนการตัดสินใจ แนวทางสู่ความสำเร็จในการพัฒนาระบบสนับสนุนการตัดสินใจ ปัจจัยที่มีผลต่อการพัฒนาระบบสนับสนุนการตัดสินใจ

เนื้อหา (2/2) กลยุทธ์ในการพัฒนาระบบสนับสนุนการตัดสินใจ การรวมระบบ (System Integration) รูปแบบทั่วไปของการรวมระบบสนับสนุนการตัดสินใจ รูปแบบการรวมระบบ ES และ DSS ระบบ DSS ที่ชาญฉลาด การจัดการแบบจำลอง และสร้างแบบจำลองที่ชาญฉลาด

แนวทางการพัฒนาระบบสนับสนุนการตัดสินใจ วงจรการพัฒนาระบบ (System Development Life Cycle: SDLC) Parallel Development Methodology Rapid Application Development-based Methodology (RAD) Phased Development-based Methodology Prototyping-based Methodology Throwaway Prototyping-based Methodology

วงจรการพัฒนาระบบ (System Development Life Cycle: SDLC) การวางแผน (Planning) การวิเคราะห์ (Analysis) การออกแบบ (Design) การพัฒนาระบบ (Implementation) การทดสอบ (Testing) การตรวจสอบข้อผิดพลาด (Debugging) การติดตั้งระบบ (Installation) การดูแลรักษาระบบ (Maintenance)

วงจรการพัฒนาระบบ Planning Analysis Design Implementation Testing Debugging Installation Maintenance

Computer-Aided System Engineering Tools: CASE Tools โปรแกรมประยุกต์ หรือ ซอฟต์แวร์ชนิดหนึ่งของเทคโนโลยีสารสนเทศ ที่ช่วยพัฒนาระบบ คอยสนับสนุนการทำงานในแต่ละขั้นตอนของการพัฒนา ด้วยการเตรียมฟังก์ชันการทำงานต่าง ๆ ที่ช่วยให้การทำงานแต่ละขั้นตอนมีความรวดเร็ว และมีคุณภาพมากขึ้น เช่น Oracle Enterprise Development Suit, Rational Rose, Logic Works Suite เป็นต้น โดยที่ CASE Tools ถูกแบ่งออกเป็น 2 ช่วง อ้างอิงจาก SDLC คือ Upper-CASE ช่วยงานในขั้นตอนต้นๆของการพัฒนาระบบ เช่น การวางแผน การวิเคราะห์ และการออกแบบ Lower-CASE ช่วยงานในขั้นตอนสุดท้ายในการพัฒนาระบบ เช่น การออกแบบ การพัฒนา การตรวจสอบ และการดูแลรักษาระบบหลังการติดตั้ง

ตัวอย่างของ Rational Rose Tools สำหรับการวิเคราะห์ระบบ https://www.modeliosoft.com/en/services/rational-rose-to-modelio.html

แนวทางอื่นๆ ในการพัฒนาระบบสนับสนุนการตัดสินใจที่ประยุกต์มาจากวงจรการพัฒนาระบบ (Development Methodology) นักพัฒนาระบบสามารถประยุกต์เอาแนวทางของ SDLC มาพัฒนาระบบสนับสนุนการตัดสินใจในลักษณะต่างๆ โดยมี Methodology ที่นิยมใช้กันดังนี้ Parallel Development Methodology Rapid Application Development-based Methodology (RAD) Phased Development-based Methodology Prototyping-based Methodology Throwaway Prototyping-based Methodology

Parallel Development Methodology เป็นการพัฒนาระบบย่อยไปพร้อมๆกัน (Parallel Development) แบ่งระบบทั้งหมดออกเป็นระบบย่อย จำแนกตามองค์ประกอบหลักของระบบสนับสนุนการตัดสินใจ ได้แก่ ระบบการจัดการข้อมูล (Data Management System) ระบบการจัดการแบบจำลอง (Model Management System) ระบบจัดการองค์ความรู้ (Knowledge Management System) ระบบจัดการสื่อประสานกับผู้ใช้ (User Interface Management System) จากนั้นเริ่มพัฒนาระบบย่อยไปพร้อมๆกัน หรือทำขนานกัน จนเสร็จ แล้วนำมารวมเป็นระบบใหญ่ 1 ระบบ

Rapid Application Development-based Methodology (RAD) Rapid Application Development-based Methodology เป็น Methodology ที่ว่าด้วยการปรับระยะในวงจรการพัฒนาระบบ ให้มีขั้นตอนการทำงานที่รวบรัดมากขึ้น มีการเลือกเครื่องมือ (Tools) และเทคนิค (Techniques) ต่างๆ เพื่อช่วยในการพัฒนาระบบสนับสนุนการตัดสินใจนั้น ดำเนินการได้อย่างรวดเร็ว อีกทั้งผู้ใช้ระบบยังสามารถทดลองใช้โปรแกรมต้นแบบเพื่อบอกนักพัฒนาระบบได้ว่า ระบบที่ออกแบบมานั้นถูกต้องหรือไม่ และมีข้อผิดพลาดใดเกิดขึ้นบ้าง ข้อเสีย คือ การเปลี่ยนแปลงความต้องการของผู้ใช้อยู่ตลอดเวลา เนื่องจากผู้ใช้ได้ทดลองใช้โปรแกรมต้นแบบที่สามารถสร้างและแก้ไขได้โดยง่าย

Phased Development-based Methodology Analysis Planning Design Analysis Implementation Analysis Design System Vorsion 1 Implementation System Vorsion 2

Phased Development-based Methodology เป็นวิธีการพัฒนาโดยแบ่งระบบออกเป็น Version เพื่อพัฒนาครั้งละ Version ตามลำดับ Version 1 จะพัฒนาตามความต้องการที่สำคัญที่สุดก่อน โดยนำความต้องการเหล่านั้นมาวิเคราะห์ (Analysis) ออกแบบ (Design) และพัฒนาระบบ (Implement) จนเป็น Version 1 ที่สามารถติดตั้งและใช้งานจริงได้ แล้วจึงเริ่มพัฒนาระบบ Version 2 ต่อไป Version 2 จะนำระบบจาก Version 1 มาวิเคราะห์ความต้องการอีกครั้ง และเพิ่มความต้องการใหม่เข้าไป จากนั้นจึงออกแบบ และพัฒนาเป็น Version 2 ปฏิบัติเช่นนี้ไปจนกระทั่งได้ Version ที่สมบูรณ์ที่สุด ข้อดี ผู้ใช้สามารถใช้ระบบได้อย่างรวดเร็ว แม้ว่าระบบ Version 1 จะยังไม่สามารถทำงานได้ครอบคลุมหน้าที่ทุกส่วนงานก็ตาม ข้อเสีย ผู้ใช้ต้องรอระบบที่สมบูรณ์จาก Version 2 (ต่อจาก Version 1 เพราะ Version 1 พัฒนาเฉพาะส่วนที่สำคัญก่อนแต่ไม่ใช่ทั้งหมดของระบบงาน) ตัวอย่างเช่น บริษัทเห็นว่า DSS ของระบบบัญชีสำคัญที่สุด ดังนั้น Version 1 จึงเป็นระบบบัญชี สำหรับ Version 2 นั้นจึงจะมีระบบอื่นๆ ตามมาเช่น ระบบการตลาด, ระบบการผลิต

Prototyping-based Methodology

ตัวอย่าง Prototype ของการพัฒนาระบบสารสนเทศ

สาเหตุของการนำ Prototype มาใช้พัฒนาระบบ สามารถพัฒนาได้ตรงตามความต้องการของผู้ใช้ การยอมรับจากผู้ใช้งานระบบ การพัฒนาระบบแบบมีส่วนร่วม (Joint Application Development Method: JAD) ระหว่าง ผู้ใช้ ผู้พัฒนาระบบ และผู้บริหาร ต้นทุนต่ำ และใช้เวลาในการพัฒนาระบบน้อย

Prototyping –based Methodology วิธีการพัฒนาที่นักพัฒนาระบบสามารถดำเนินการในขั้นตอน วิเคราะห์ ออกแบบ พัฒนาระบบไปพร้อมๆ กันแล้วสร้างเป็นตัวต้นแบบของระบบ (System Prototype) ที่สามารถทำงานได้จริงในบางส่วนของระบบหรือทีละส่วน ซึ่งอาจเรียกว่า “ระบบต้นแบบ” แล้วนำตัวต้นแบบของระบบนั้นเสนอให้ผู้ใช้ระบบได้ทดลองใช้งาน เพื่อเก็บรวบรวมความต้องการเพิ่ม และเก็บข้อคิดเห็นจากผู้ทดลองใช้งานตัวต้นแบบนั้น จากนั้นนำความต้องการที่เพิ่ม และข้อคิดเห็นมาวิเคราะห์ ออกแบบ และพัฒนาต้นแบบส่วนที่ 2 ที่เพิ่มเติมความสามารถในการทำงานของระบบให้มากขึ้น จากนั้นจึงนำไปให้ผู้ใช้งานทดลองใช้ และปรับปรุงไปเรื่อยๆจนกว่าจะเสร็จสิ้นสมบูรณ์เป็นต้นแบบที่ทำงานได้สมบูรณ์ จนผู้ใช้ยอมรับ ว่าสามารถทำงานได้ครบทุกส่วนของระบบ จึงนำต้นแบบที่ยอมรับนั้นไปติดตั้งให้ผู้ใช้งานใช้จริง จึงเรียกต้นแบบนั้นว่า “ระบบใหม่”

Prototyping–based Methodology ระบบใหม่ ได้มาจากการนำ Prototype ไปปรับปรุงแก้ไขหลายๆ รอบจน Prototype ใช้งานได้จริง Planning Analysis ยอมรับ Accept System Prototype Design Implementation Implementation System (ระบบใหม่) ไม่ยอมรับ (Reject) ข้อสังเกต จากรูปพบว่าหลังจากแก้ไข Prototype หลายรอบแล้ว จะนำ Prototype ที่ยอมรับจากผู้ใช้งาน ไปพัฒนาต่อจนได้ระบบใหม่ Ref. (Turban P683)

Prototyping –based Methodology ข้อดี คือ ใช้เวลาน้อยในการพัฒนาระบบ เนื่องจากขั้นตอน วิเคราะห์ ออกแบบ และพัฒนาระบบสามารถทำไปพร้อมๆกันได้ด้วยการสร้างต้นแบบของระบบ (System Prototype) ผู้ใช้งานสามารถทดลองใช้งานต้นแบบก่อนติดตั้งระบบจริง ทำให้สามารถระบุข้อผิดพลาดและความต้องการที่แท้จริงได้เร็วขึ้น ข้อเสีย การสร้างต้นแบบของระบบทีละส่วนด้วยความเร็วในขณะที่มีการรวบรวม วิเคราะห์ และออกแบบไปพร้อมๆกัน ทำให้ขาดความรอบคอบในการตระหนักถึงปัญหาที่จะเกิดขึ้นตามมา เมื่อติดตั้งและใช้งานระบบทั้งหมดทุกส่วน

Throwaway Prototyping-based Methodology Accept Planning Design Analysis Design Prototype Design Implementation Implementation System Reject ข้อสังเกต จากรูป Prototype ทำขึ้นมาเพื่อเก็บรวบรวมข้อมูลความคิดเห็นและความต้องการของผู้ใช้เท่านั้น จากรูปพบว่าหลังจากแก้ไข Prototype หลายรอบแล้ว จนเก็บข้อมูลความต้องการของระบบได้ครบ และผู้ใช้ยอมรับแล้ว จึงจะเริ่มพัฒนาระบบจริง โดยออกแบบหน้าจอใช้งานจริง และพัฒนาระบบตามความต้องการที่เก็บข้อมูลมา ส่วน Prototype ที่สร้างขึ้นมานั้นจะถูกยกเลิก หรือทิ้งไป Ref. (Turban P684)

Throwaway Prototyping-based Methodology เป็นต้นแบบ (Design Prototype) ที่ใช้เพื่อเก็บรวบรวมความคิดเห็น และความต้องการของผู้ใช้ (User Requirement) ในบางส่วน ดังนั้น Prototype จึงสร้างเพียงบางส่วนเท่านั้น โดยที่จะใช้ Prototype แสดงให้ผู้ใช้เห็นถึงส่วนที่ได้รับการออกแบบมาว่ามีลักษณะอย่างไร และระบบจะมีการทำงานแบบไหน ถูกต้องหรือไม่ หรือควรได้รับการแก้ไขในส่วนใดบ้าง ซึ่งในการเก็บรวบรวมข้อมูลความต้องการนั้นผู้ใช้งานสามารถเปลี่ยนแปลงแก้ไข Prototype ตามความต้องการของระบบจนถูกต้อง เมื่อ Prototype นั้นได้รับการยอมรับจากผู้ใช้งานแล้วว่าระบบที่ออกแบบมานั้นถูกต้องแล้ว จึงเข้าสู่ขั้นตอนการพัฒนาระบบจริง โดยจะออกแบบหน้าจอใช้งานจริง และพัฒนาระบบจริง ตามความต้องการที่ถูกต้องนั้น ส่วนต้นแบบ (Prototype) ที่สร้างมานั้นจะไม่ถูกนำมาพัฒนาต่อแต่อย่างใด แต่จะถูกยกเลิกหรือทิ้งไป จึงเรียกแนวทางนี้ว่า “ต้นแบบใช้แล้วทิ้ง (Throwaway Prototype)”

Throwaway Prototyping-based Methodology เป็นการพัฒนาแบบ Prototyping ในส่วนของ การสร้างต้นแบบระบบ โดย Prototype ที่ได้จะไม่ใช่ต้นแบบระบบที่จะนำไปใช้งานจริง แต่เป็นต้นแบบ (Design Prototype) ที่ทำเพื่อเก็บรวบรวมข้อมูลความคิดเห็นและความต้องการของผู้ใช้ อาจเรียกว่า “ต้นแบบใช้แล้วทิ้ง (Throwaway Prototype)” ข้อดี คือระบบถูกออกแบบมาตรงตามความต้องการของผู้ใช้งาน ลดความผิดพลาด เพราะยืนยันความเข้าใจกับผู้ใช้ก่อนการพัฒนาระบบจริง ข้อเสีย คือ ใช้ระยะเวลาในการพัฒนาระบบจริงนานกว่าวิธี Prototyping –based Methodology เนื่องจากไม่ใช้ตัวต้นแบบ (Prototype) นั้นมาทำเป็นระบบจริง

การจัดทำต้นแบบ (Prototyping) เหตุผลที่นักพัฒนาระบบสนับสนุนการตัดสินใจใช้ Prototype ในการพัฒนาระบบ เพราะผู้ใช้งานสามารถเห็นลักษณะของระบบโดยใช้ Prototype แสดง ก่อนที่จะลงมือพัฒนาระบบจริง ผู้ใช้สามารถแก้ไขความต้องการได้ทัน หรือเพิ่มเติมความต้องการของระบบได้ทัน และจะมีการแก้ไข Prototype ได้หลายครั้งจนถูกต้อง และยอมรับ Prototype นั้น จึงจะทำการพัฒนาระบบจริง เป็นการการพัฒนาระบบแบบมีส่วนร่วม (Joint Application Development method: JAD) ระบบงานที่ได้ผ่านการยอมรับจากผู้ใช้แล้ว เนื่องจากแต่ละขั้นตอนของการพัฒนา Prototype ต้องอาศัยความร่วมมือระหว่างนักพัฒนาระบบ ผู้ใช้ และผู้บริหาร

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

ทีมงานในการพัฒนาระบบสนับสนุนการตัดสินใจ ผู้ใช้งานระบบ (Users) นักวิเคราะห์ระบบและออกแบบระบบ (System Analyst) โปรแกรมเมอร์ (Programmer) ผู้เชี่ยวชาญทางด้านเทคนิค (Technical Expert) ผู้บริหารโครงการ (Project Manager)

ระบบสนับสนุนการตัดสินใจที่พัฒนาโดยผู้ใช้ระดับต่าง ๆ ระบบสนับสนุนการตัดสินใจที่พัฒนาโดยผู้ใช้ (End User-Developed DSS) เช่น ผู้ใช้งานใช้ MS Excel ในการช่วยตัดสินใจ เหมาะสำหรับปัญหาที่ไม่มีความซับซ้อน หรือเป็นปัญหาที่มีโครงสร้าง ระบบสนับสนุนการตัดสินใจที่พัฒนาโดยทีมงานเฉพาะ (Team-Developed DSS) เหมาะสำหรับระบบขนาดใหญ่ ที่ใช้แก้ปัญหาที่มีความซับซ้อนสูง ปัญหาที่ไม่มีโครงสร้าง และปัญหากึ่งโครงสร้าง

การติดตั้งระบบสนับสนุนการตัดสินใจ (DSS Installation) การติดตั้งแบบทันทีทันใด (Direct Installation) การติดตั้งแบบขนาน (Parallel Installation) การติดตั้งแบบนำร่อง (Pilot Installation) การติดตั้งแบบทยอยติดตั้งเป็นระยะ (Phase Installation)

การติดตั้งแบบทันทีทันใด (Direct Installation) เป็นวิธีการติดตั้งระบบงานใหม่ทันที และยกเลิกการใช้งานระบบเก่าโดยทันทีเช่นเดียวกัน ข้อดี เสียค่าใช้จ่ายน้อย ข้อเสีย มีความเสี่ยงสูง ยกเลิกการใช้งานระบบเดิม ระบบเก่า ระบบใหม่ เวลา ติดตั้งระบบใหม่

การติดตั้งแบบขนาน (Parallel Installation) เป็นวิธีการที่หลังจากมีการติดตั้งระบบใหม่แล้ว จะมีการใช้ระบบงานใหม่ไปพร้อมกับระบบงานเก่าไปสักระยะหนึ่ง เมื่อมั่นใจว่าระบบงานใหม่ สามารถทำงานได้อย่างถูกต้อง และสมบูรณ์แบบแล้วจึงยกเลิกการใช้งานระบบเก่า เป็นวิธีการติดตั้งที่มีค่าใช้จ่ายค่อนข้างสูง เนื่องจากมีการดำเนินการ 2 ระบบไปพร้อม ๆ กัน ยกเลิกการใช้งานระบบเก่า ระบบเก่า ติดตั้งระบบใหม่ ระบบใหม่ เวลา ใช้ระบบใหม่พร้อมกับระบบเก่า

การติดตั้งแบบนำร่อง (Pilot Installation) เป็นวิธีการที่มีการใช้งานระบบใหม่เพียงหน่วยเดียวขององค์กร เพื่อเป็นการนำร่อง แล้วค่อยปรับเปลี่ยนทั้งองค์กร เมื่อระบบใหม่ลงตัวแล้ว เช่นแรกๆ ใช้ระบบใหม่ในแผนกจัดซื้อแผนกเดียวก่อน หรือสาขาเดียวก่อน ข้อดี เสียค่าใช้จ่ายน้อยกว่า 2 วิธีแรก เมื่อเกิดความผิดพลาดขึ้นจะเกิดเฉพาะแผนก หรือสาขาที่นำร่องเท่านั้น ระบบเก่า ติดตั้งระบบใหม่ ระบบใหม่ เวลา ใช้ระบบใหม่แต่ระบบเก่ายังคงใช้งานอยู่

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

การติดตั้งแบบทยอยติดตั้งเป็นระยะ (Phase Installation) ระบบเก่า B ระบบใหม่ Phase 2 ติดตั้งระบบใหม่ ระบบใหม่ Phase 3 เวลา เริ่มใช้ระบบใหม่ Phase 1 เริ่มใช้งานระบบใหม่ Phase 3 ขนานกับ Phase 2 เริ่มใช้งาน Phase 2 ขนานกับระบบเก่า และระบบใหม่ Phase 3

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

เครื่องมือที่ใช้ในการพัฒนาระบบสนับสนุนการตัดสินใจ ระดับของเครื่องมือสำหรับพัฒนาระบบ DSS (DSS Primary Tools) (DSS Generator Tools) (Specific DSS) ประเภทของเครื่องมือที่ใช้พัฒนาระบบ DSS การคัดเลือกเครื่องมือที่ใช้พัฒนาระบบ DSS

เครื่องมือเริ่มต้นสำหรับพัฒนาระบบสนับสนุนการตัดสินใจ (DSS Primary Tools) ภาษาโปรแกรม (Programming Language) เช่น Java, Python, Visual Basic, C โปรแกรมทางด้านกราฟิก (Graphic Program) โปรแกรมในการเรียบเรียงและรวบรวมสารสนเทศ (Editor Program) ระบบสอบถามข้อมูล (Query System) เครื่องมือสร้างตัวเลขสุ่ม (Random Number Generator) ฯลฯ

เครื่องมือสำหรับสร้างระบบสนับสนุนการตัดสินใจ (DSS Generator Tools) เป็นซอฟต์แวร์สำเร็จรูปที่ใช้พัฒนาระบบ DSS ได้อย่างง่ายดาย รวดเร็ว และประหยัด โดยซอฟต์แวร์จะมีความสามารถในการสร้างแบบจำลอง สร้างรายงาน และแสดงผลกราฟิก เช่น Microsoft Excel, OLAP System, LINGO, LINDO เป็นต้น

โปรแกรมระบบสนับสนุนการตัดสินใจ (Specific DSS) “Specific DSS” หรือเรียกว่า “DSS Application” ซอฟต์แวร์ที่ได้จากการดำเนินการพัฒนาระบบจนครบทุกขั้นตอน ซึ่งจะได้โปรแกรมสำหรับสนับสนุนการตัดสินใจโดยเฉพาะ เช่น มีการเก็บรวบรวมความต้องการกับผู้บริหาร มีการวิเคราะห์ ออกแบบระบบ และพัฒนาซอฟต์แวร์ระบบ DSS ของการผลิต สำหรับสนับสนุนการตัดสินใจโดยเฉพาะ

DSS Generator Tools (Spreadsheet…) DSS Primary Tools (Language…) ความสัมพันธ์ระหว่างเครื่องมือสามระดับที่ใช้พัฒนาระบบสนับสนุนการตัดสินใจ Specific DSS DSS Generator Tools (Spreadsheet…) DSS Primary Tools (Language…) รูปแสดงความสัมพันธ์ระหว่างเครื่องมือทั้ง 3 ระดับ ที่ใช้ในการพัฒนาระบบ DSS

ความสัมพันธ์ระหว่างเครื่องมือสามระดับที่ใช้พัฒนาระบบสนับสนุนการตัดสินใจ จากรูปภาพ ความสัมพันธ์ระหว่างเครื่องมือสามระดับที่ใช้พัฒนาระบบสนับสนุนการตัดสินใจ แบ่งเป็น 2 แนวทางดงนี้ แนวทางแรก นักพัฒนาระบบ DSS ใช้ DSS Primary Tools เพื่อพัฒนา DSS Generator Tools ขึ้นมาก่อน หลังจากนั้นจึงนำ DSS Generator Tools มาสร้าง Specific DSS เช่นใช้ DSS Primary Tools พัฒนา LINGO จากนั้นใช้ LINGO พัฒนาระบบ DSS การแก้ไขปัญหาการขนส่ง หรือปัญหาการผลิต ของบริษัทโดยเฉพาะ แนวทางที่สอง นักพัฒนาระบบ ใช้ DSS Primary Tools สร้าง Specific DSS ได้โดยตรง เช่นใช้ ภาษา Visual Basic พัฒนาระบบ DSS การแก้ไขปัญหาการขนส่ง หรือปัญหาการผลิต ของบริษัทโดยเฉพาะ จาก สองแนวทางข้างต้นจะพบว่าแนวทางที่สองนั้นสามารถเปลี่ยนแปลงแก้ไขได้ง่าย เพราะไม่มีการใช้เครื่องมือหลายระดับ และประหยัดเวลาในการพัฒนาระบบ

ประเภทของเครื่องมือที่ใช้พัฒนาระบบ DSS พัฒนา DSS โดยใช้โปรแกรมภาษาทั่ว ๆ ไป (Programming Language) Visual Basic, COBOL, …, Etc. ภาษายุค 4 GL โปรแกรมภาษาเชิงวัตถุ (Object-Oriented Language) โปรแกรมกระดาษคำนวณ (Spreadsheet) โปรแกรมภาษาทางด้านการเงิน (Financial Language) การประมวลผลเชิงวิเคราะห์แบบออนไลน์ (Online Analytical Processing: OLAP)

ประเภทของเครื่องมือที่ใช้พัฒนาระบบ DSS เครื่องมือสำหรับสร้างระบบสนับสนุนการตัดสินใจ (DSS Generator tools) เป็นเครื่องมือสำเร็จรูปที่ใช้ในการพัฒนาโปรแกรมระบบสนับสนุนการตัดสินใจ ตัวอย่างเครื่องมือเช่น Microsoft Excel, LINGO, Lotus Note 1-2-3 เครื่องมือสำหรับใช้สร้าง Specific DSS เป็นเครื่องมือสำเร็จรูปที่ใช้พัฒนา โปรแกรมระบบสนับสนุนการตัดสินใจเพื่อแก้ปัญหาเฉพาะอย่าง (Specific DSS) ตัวอย่างของ Specific DSS เช่น ระบบสนับสนุนการตัดสินใจที่ใช้ในการวิเคราะห์ด้านการเงิน การตลาด หรือ การผลิต เป็นต้น CASE Tools เป็นเครื่องมือที่ใช้พัฒนาระบบ DSS ที่มีขนาดใหญ่และมีความซับซ้อนมาก เครื่องมือผสมผสาน (Mixed Tools) เป็นการนำเครื่องมือต่าง ๆ ข้างต้นมาประยุกต์ใช้เพื่อสร้างโปรแกรมระบบสนับสนุนการตัดสินใจ

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

แนวทางสู่ความสำเร็จในการพัฒนาระบบสนับสนุนการตัดสินใจ การวัดผลความสำเร็จของการพัฒนาระบบสนับสนุนการตัดสินใจ สาเหตุของความล้มเหลวในการพัฒนาระบบสนับสนุนการตัดสินใจ

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

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

ปัจจัยที่มีผลต่อการพัฒนาระบบสนับสนุนการตัดสินใจ ปัจจัยทางด้านเทคนิค (Technical Factor) ระบบที่ดีต้องไม่ซับซ้อน ระบบที่ดีควรมีการประมวลผลเร็ว และต้องมีความถูกต้อง ปัจจัยทางด้านพฤติกรรม (Behavioral Factor) พฤติกรรมของผู้ใช้ต่อระบบงาน บางองค์กรบุคลากรที่คุ้ยเคยกับเทคโนโลยีจะสามารถเรียนรู้ระบบใหม่เร็ว นอกจากนี้ยังรวมถึงการยอมรับ และการต่อต่อต้านระบบใหม่ของ User ปัจจัยขั้นตอนการทำงาน (Process Factor) เช่น พัฒนาระบบที่เป็นไปได้ และมีความสำคัญก่อน ปัจจัยด้านการมีส่วนร่วมของผู้ใช้ระบบ (User Involvement) การที่องค์กรส่งเสริมให้ผู้ใช้ระบบมีส่วนร่วมในการพัฒนาระบบในขั้นตอนที่เหมาะสม ระบบจะได้รับการยอมรับจากผู้ใช้หลังจากพัฒนาเสร็จ

ปัจจัยที่มีผลต่อการพัฒนาระบบสนับสนุนการตัดสินใจ จริยธรรม (Ethic) สภาพแวดล้อมภายนอก (External Environment) ข้อมูลกฎหมาย เศรษฐกิจ การเมือง ที่มีผลต่อการพัฒนาระบบงาน ปัจจัยด้านโครงสร้างขององค์กร (Organizational Factor) แหล่งทรัพยากรในองค์กร เช่น LAN, Client, Server ความสัมพันธ์ระหว่าง User และทีมงามพัฒนาระบบ ปัจจัยทุกด้านที่เกี่ยวกับโครงการ (Project-Related Factor)

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

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

วัตถุประสงค์ของการรวมระบบ เพื่อเพิ่มประสิทธิภาพการทำงานของเครื่องมือสนับสนุนการทำงานใด ๆ ให้มากขึ้น เพื่อยกระดับความสามารถของโปรแกรมประยุกต์ใดๆ ให้เพิ่มมากขึ้น

ตัวอย่างรูปแบบการรวมระบบ ES (Expert System) และ DSS DSS (Decision Support System) คือ ระบบสนับสนุนการตัดสินใจ ฐานข้อมูล ฐานองค์ความรู้ ฐานแบบจำลอง Intelligence ระบบจัดการ ฐานแบบจำลอง กลไก การสรุปความ ระบบจัดการ ฐานข้อมูล Supervisor ระบบค้นหา องค์ความรู้ ศูนย์จัดการความฉลาด ส่วนประสานกับผู้ใช้ ด้วยภาษามนุษย์ ตัวอย่างแสดงการรวมของระบบ ES เป็นองค์ประกอบแยกส่วนอยู่ภายใน DSS โดย ES เป็นศูนย์กลาง Knowledge Engineer ผู้ใช้

ระบบ DSS ที่ชาญฉลาด (1/3) Active (Symbiotic) DSS เป็นการพัฒนาให้ระบบ DSS ฉลาดมากขึ้น ไม่ได้เป็นเพียงเครื่องมือที่ใช้ในการคำนวณหาผลลัพธ์ หรือแสดงผลเท่านั้น (Passive DSS) โดยที่ Active DSS สามารถเป็นผู้ช่วยที่ชาญฉลาด ในหลายหน้าที่ด้วยกัน ดังนี้ สามารถทำความเข้าใจขอบเขตทั้งหมดของปัญหาได้ สามารถประมวลผลปัญหาที่เกิดขึ้นได้ เชื่อมโยงปัญหาไปสู่แนวทางแก้ปัญหาได้ สามารถแปลผลลัพธ์ได้ สามารถอธิบายผลลัพธ์และการตัดสินใจได้

ระบบ DSS ที่ชาญฉลาด (2/3) Self-Evolving DSS เป็นแนวทางการพัฒนา DSS ที่อยู่บนพื้นฐานการใช้งานของผู้ใช้ระบบ ด้วยการทำให้ระบบสามารถตระหนักได้ว่าสถานการณ์ในปัจจุบันของตน คือ อะไร และควรมีการปรับปรุงแก้ไขอย่างไร เพื่อให้สอดคล้องกับการใช้งานของผู้ใช้แต่ละคน โดยมีเครื่องมือดังนี้ มีเมนูคำสั่งแบบไดนามิค (Dynamic Menu) เพื่อรองรับผู้ใช้แต่ละระดับ มีส่วนประสานกับผู้ใช้แบบไดนามิค (Dynamic User Interface) เพื่อสามารถโต้ตอบ และนำเสนอต่อผู้ใช้ในแต่ละระดับได้ มีระบบจัดการฐานแบบจำลองที่สามารเลือกแบบจำลองได้เหมาะสมกับปัญหา

ระบบ DSS ที่ชาญฉลาด (3/3) การจัดการปัญหา (Problem Management) การค้นหาสาเหตุของปัญหา (Problem Finding) อาศัยระบบจัดการองค์ความรู้ การนำเสนอปัญหา (Problem Representation) อาศัยระบบจัดการแบบจำลอง การตรวจสอบสารสนเทศ (Information Surveillance) อาศัยระบบจัดการองค์ความรู้ และแบบจำลอง การสร้างแนวทางแก้ปัญหา (Solution Generation) อาศัยระบบจัดการองค์ความรู้ และการสร้างแนวความคิดทำหน้าที่ในการสร้างแนวทางแก้ไขปัญหา การประเมินแนวทางเลือกในการแก้ปัญหา (Solution Evaluation) อาศัยระบบจัดการองค์ความรู้

การจัดการแบบจำลอง และสร้างแบบจำลองที่ชาญฉลาด การวิเคราะห์ปัญหาและเลือกแบบจำลอง เป็นการวิเคราะห์ถึงปัญหาที่เกิดขึ้นแล้วทำการเลือกแบบจำลองที่จะใช้ในการอธิบายและแก้ไขปัญหาได้อย่างถูกต้องเหมาะสม ไม่ว่าจะเป็นแบบจำลองทางคณิตศาสตร์ หรือทางด้านสถิติ ปัจจุบันมีระบบผู้เชี่ยวชาญที่มีความสามารถดังกล่าวแล้ว การสร้างแบบจำลอง แบบจำลองแบบ Normative เช่น การหาค่าผลลัพธ์ที่ดีที่สุด (Optimization) แบบจำลองเชิงบรรยาย (Descriptive) เช่น การจำลองสถานการณ์ (Simulation) ในขั้นตอนนี้ การพัฒนาระบบอาจใช้เทคนิคในการค้นพบองค์ความรู้ (Knowledge Discovery) การใช้แบบจำลอง ในขั้นตอนนี้ จำเป็นต้องมีการกำหนดค่าพารามิเตอร์ตัวแปรที่ใช้ตัดสินใจ หรือฟังก์ชันที่เกี่ยวข้อง ดังนั้นผู้พัฒนาระบบ DSS สามารถใช้ระบบผู้เชี่ยวชาญเป็นเครื่องมือช่วยแนะนำผู้ตัดสินใจระหว่างการใช้งานแบบจำลองได้ การแปลผลลัพธ์ ผลลัพธ์ที่ได้อาจอยู่ในรูปของตัวเลขแสดงค่าต่างๆ มากมาย หากเป็นระบบ DSS แบบธรรมดา ผู้ตัดสินใจจะต้องแปลผลลัพธ์เอง แต่สำหรับการเพิ่มความฉลาดให้กับการแปลผลลัพธ์นั้น ผู้พัฒนาสามารถใช้ระบบผู้เชี่ยวชาญ (ES) ช่วยในการแปลหรืออธิบายผลลัพธ์ได้ *******ปรับปรุง

สอนวันพุธที่ 03/04/2562 References 1. กิตติ ภักดีวัฒนะกุล. “คัมภีร์ ระบบสนับสนุนการตัดสินใจ และระบบผู้เชี่ยวชาญ” 2. Turban E. et al. “Decision Support and Business Intelligence Systems”, 8th 3. Anand Jayakumar A, Raghunayagan P. “Solving a Simple Transportation Problem Using LINGO”. IJISET, 5(4), 2018: P 267-269.