3 Problem Definition and Feasibility Study การกำหนดปัญหาและศึกษาความเป็นไปได้

1. 3 Problem Definition and Feasibility Study การกำหนดปัญหาและศึกษาความเป็นไปได้ Systems Analysis & Design

2. การกำหนดปัญหาและศึกษาความเป็นไปได้การกำหนดปัญหาและศึกษาความเป็นไปได้ ปัจจัยหรือแรงผลักดันที่ส่งผลต่อความต้องการเพื่อพัฒนาระบบใหม่อาจจะเกิดขึ้นได้ทั้งปัจจัยภายในและภายนอก ประกอบด้วย 1. ผู้ใช้ร้องขอให้ปรับปรุงระบบใหม่ 2. ผู้บริหารระดับสูงต้องการพัฒนาระบบใหม่ 3. ปัญหาและข้อผิดพลาดของระบบงานปัจจุบัน 4. แรงผลักดันจากภายนอก ส่งเสริมให้มีการปรับปรุงระบบ 5. ส่วนงานบริการสารสนเทศแนะนำให้มีการปรับปรุงระบบ Systems Analysis & Design

3. การกำหนดปัญหา (Problem Definition ) • Problem Definition (กำหนดปัญหา) สามารถตรวจสอบด้วยวิธีพื้นฐาน 2 ประการ คือ • ตรวจสอบปัญหาจากการปฏิบัติงาน • การทำงานล่าช้า มีข้อผิดพลาดสูง ทำงานไม่ถูกต้อง ไม่สมบูรณ์ ไม่บรรลุวัตถุประสงค์ที่ต้องการ • สังเกตพฤติกรรมของพนักงาน • อ้ตราการเจ็บป่วยสูง ไม่พอใจในงานที่ทำ ไม่กระตือรือล้น การลาออกสูง Systems Analysis & Design

4. ตัวอย่าง การกำหนดปัญหา (Problem Definition ) • กรณีศึกษา บริษัท BM Car Rent Service Center จำกัด • ความเป็นมาและปัญหา Systems Analysis & Design

5. การศึกษาความเป็นไปได้ของโครงการ (Feasibility Study) • 1. ความเป็นไปได้ทางเทคนิค (Technical Feasibility) • สิ่งสำคัญของการศึกษาความเป็นไปได้ทางเทคนิค คือ การวิเคราะห์ความเสี่ยงด้านเทคนิค เพื่อให้ได้คำตอบของคำถามที่ว่า “Can we build it” หมายความว่า พวกเราสามารถพัฒนาได้หรือไม่ ความเป็นไปได้ทางเทคนิคจะข้องเกี่ยวกับรายละเอียด ดังนี้ • จำเป็นต้องหาอุปกรณ์ใหม่หรือไม่ • อุปกรณ์ที่หามาเพื่อระบบใหม่สามารถรองรับเทคโนโลยีในอนาคตได้หรือไม่ • ความเข้ากันได้ของฮาร์ดแวร์ต่าง ๆ กับซอฟต์แวร์ใช้งานร่วมกันได้ดีหรือไม่ • ประสิทธิภาพของฮาร์ดแวร์และซอฟต์แวร์มีประสิทธิภาพที่ดีเพียงพอหรือไม่ • ระบบสามารถรองรับการขยายตัวของธุรกิจในอนาคตได้หรือไม่

6. การศึกษาความเป็นไปได้ของโครงการ (Feasibility Study) • 2. ความเป็นไปได้ทางเศรษฐศาสตร์ (Economical Feasibility) • คือ ความเป็นไปได้ในเชิงเศรษฐศาสตร์ ซึ่งมักเรียกว่า การวิเคราะห์ต้นทุนและผลกำไร ด้วยการกำหนดต้นทุนทางการเงินและผลตอบแทนที่ได้จากโครงการ และจะประเมินผลกระทบทางการเงิน 4 ประเภท ดังนี้ • ต้นทุนการพัฒนาระบบ (Development Costs) • ต้นทุนการปฏิบัติงาน (Operational Costs) • ผลตอบแทนที่สามารถประเมินค่าได้ (Tangible Benefits) • ผลตอบแทนที่ไม่สามารถประเมินค่าได้ (Intangible Benefits)

7. การศึกษาความเป็นไปได้ของโครงการ (Feasibility Study) • ผลตอบแทนที่สามารถประเมินค่าได้ (Tangible Benefits) • การเพิ่มยอดขายและมีรายได้เพิ่มขึ้น , การลดค่าใช้จ่ายเกี่ยวกับเอกสาร, การลดค่าล่วงเวลา • ผลตอบแทนที่ไม่สามารถประเมินค่าได้ (Intangible Benefits) • ลูกค้ามีทัศนะคติที่ดีต่อบริษัท, ระบบงานมีประสิทธิภาพมากขึ้น, ความพึงพอใจของพนักงาน

8. การศึกษาความเป็นไปได้ของโครงการ (Feasibility Study) 3. ความเป็นไปได้ทางการปฏิบัติงาน (Operational Feasibility) คือ ความเป็นไปได้ของระบบใหม่ที่นำเสนอสารสนเทศได้อย่างถูกต้อง และตรงตามความต้องการของผู้ใช้ สรุปได้ ดังนี้ ผู้ใช้งานเข้าใจในการเปลี่ยนระบบ และสนับสนุนระบบใหม่หรือไม่ ต้องเตรียมอะไรบ้างกับการฝึกอบรมการใช้งานระบบใหม่ให้พนักงาน ระบบใหม่ที่พัฒนาส่งผลกระทบต่อจำนวนพนักงาน หรือไม่ ผู้ใช้มีส่วนร่วมกับการวางแผนระบบใหม่หรือไม่ ขั้นตอนการปฏิบัติงานมีการเปลี่ยนแปลงไปจากเดิมหรือไม่ ผลกระทบจะส่งผลต่อลูกค้าที่มาใช้บริการหรือไม่ ใช้ระยะเวลาในการพัฒนาระบบใหม่ยาวนานเท่าไร

9. การวางแผนและการควบคุมกิจกรรม (Activity Planning and Control) การวางแผน (Planning) เป็นการวางแผนที่ประกอบไปด้วยกิจกรรมต่าง ๆ ที่ได้มีการมอบหมายและแจกจ่ายงานให้กับทีมงาน การคาดคะเนเวลาที่ต้องใช้ไปกับงานใด ๆ การกำหนดเวลาโครงการ (Project Scheduling) สามารถจัดทำขึ้นโดยการใช้เทคนิค “แกนท์ชาร์ต” (Gantt Charts) เป็นแผนภูมิอย่างง่ายที่ใช้สำหรับวางแผนและกำหนดเวลาการทำงานของโครงการ Systems Analysis & Design

10. Gantt Charts Activity งานที่ดำเนินการเสร็จแล้ว ดำเนินการสัมภาษณ์ งานที่ยังไม่ได้ดำเนินการ จัดทำแบบสอบถาม อ่านรายงานของบริษัท วิเคราะห์การไหลของข้อมูล จัดทำโพโตไทป์ สังเกตการณ์ด้านผลกระทบ กำหนดต้นทุนและผลตอบแทน จัดทำข้อเสนอของโครงการ นำเสนอผู้บริหารเพื่ออนุมัติ Weeks 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Current Weeks Systems Analysis & Design

11. Systems Analysis & Design

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

13. PERT and CPM เทคนิคการประเมินผลและทบทวนโครงการ(Program Evaluation and Review Technique : PERT) ระเบียบวิธีวิกฤต (Critical Path Method : CPM)เป็นเทคนิคเชิงปริมาณด้านการวิเคราะห์ข่ายงาน (Network analysis) ที่ใช้กันแพร่หลายในการวางแผนและควบคุมงานที่มีลักษณะเป็นงานโครงการ (งานที่มีจุดเริ่มต้นและจุดสิ้นสุด และสามารถกระจายเป็นงานย่อยที่มีความสัมพันธ์กันได้) ซึ่งจะช่วยให้ผู้บริหารโครงการสามารถดำเนินโครงการให้สำเร็จตามเวลาและในงบประมาณที่กำหนด Systems Analysis & Design

14. ความเป็นมาของ PERT PERT พัฒนาขึ้นเมื่อ พ.ศ. 2501โดยกองทัพเรือสหรัฐร่วมกับ บูซ แอลเลน และ แฮมิลตัน (Booz Allen and Hamilton) และ ล๊อกฮีด แอร์คราฟต์ (Lockheed Aircraft) เพื่อใช้ในการบริหารโครงการขีปนาวุธโพลาริส (Polaris) ซึ่งเป็นโครงการขนาด ลักษณะของโครงการเป็นการวิจัยและพัฒนา ดังนั้นการประมาณระยะเวลาในการดำเนินการต่างๆ ในโครงการจึงไม่สามารถกำหนดลงไปได้แน่นอน จำเป็นต้องนำเอาแนวความคิดของความน่าจะเป็นเข้ามาประกอบด้วย จึงอาจกล่าวได้ว่า จุดเด่นของ PERT คือ การสามารถนำไปใช้กับโครงการที่มีเวลาดำเนินงานไม่แน่นอน Systems Analysis & Design

15. ความเป็นมาของ CPM CPM พัฒนาขึ้นเมื่อ พ.ศ. 2500 โดเคลลี (J.E. Kelly) แห่งเรมิงตัน แรนด์ (Remington Rand) ร่วมกับวอล์กเกอร์ (M.R. Walker) แห่งบริษัทดูปองต์ (Dopont) เพื่อใช้ในโครงการก่อสร้างและซ่อมบำรุงเครื่องจักรในโรงงานเคมี โดยเน้นในด้านการวางแผนและควบคุมเวลา ตลอดจนค่าใช้จ่ายโครงการ CPM มักจะนำไปใช้กับโครงการที่ผู้บริหารเคยมีประสบการณ์มาก่อนและสามารถประมาณเวลารวมทั้งค่าใช้จ่ายในการดำเนินงานของโครงการได้แน่นอน Systems Analysis & Design

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

17. สัญลักษณ์ต่าง ๆ และความหมายที่ใช้ใน PERT สัญลักษณ์ ความหมาย จุดเชื่อมต่อหรือโหนด (Node) แสดงถึงเหตุการณ์ตั้งแต่เริ่มต้นจนจบโครงการ A 2 1 เส้นตรงที่เชื่อมต่อระหว่างโหนด แสดงกิจกรรมหรืองานที่ทำ ส่วนหัวลูกศรคือจุดเสร็จสิ้นของกิจกรรมหรืองานที่ทำ 3 เส้นปะที่เชื่อมต่อระหว่างโหนด แสดงกิจกรรมหรืองานสมมติ (Dummy Activity)ซึ่งเป็นกิจกรรมที่ไม่มีตัวตนในโครงการแต่จำเป็นต้องใส่ไว้เพื่อให้ถูกต้องตรงกับความเป็นจริง 4 Systems Analysis & Design

18. 3 B A 1 2 5 C D 4 6 ตัวอย่าง PERT แบบที่ 1

19. C งาน งานที่ต้องเสร็จก่อน A - B - C A D B E C,D 3 2 A 1 6 B D E 4 5 7 ตัวอย่าง PERT แบบที่ 2

20. งาน งานที่ต้องเสร็จก่อน A - B - C A D A,B C 2 A 5 D 1 4 B 4 ตัวอย่าง PERT แบบที่ 3

21. งาน งานที่ต้องเสร็จก่อน ระยะเวลา(สัปดาห์)A - 2 B - 1 C - 1 D A 3 E B 3 F C 2 G D 3 H F 2 D,3 3 2 G,3 A,2 E,3 B,1 1 4 7 C,1 F,2 H,2 5 6 ตัวอย่าง PERT แบบที่ 4 แสดงระยะเวลาของแต่ละงาน สายงานที่ 1 1-2-3-7=2+3+3=8 สายงานที่ 2 1-4-7 = 1+3=4 สายงานที่ 3 1-5-6-7 = 1+2+2 =5

22. สายงานวิกฤต (Critical Paths) เส้นทางงานวิกฤต (Critical Paths) จะพิจารณาจากเส้นทางงานที่มีเวลารวมยาวนานที่สุด ซึ่งในที่นี้ คือ เส้นทางงาน1-2-3-7 รวมเวลาทั้งสิ้น 11 วัน นั่นหมายถึงเส้นทางงานทุกอย่างในแต่ละขั้นตอน จะแล้วเสร็จโดยใช้เวลา 11 วันโดยในโครงการอาจมีเส้นทางงานวิกฤตมากกว่า 1 เส้นทางงานก็เป็นได้ การเร่งโครงการ สามารถทำได้ด้วยการเร่งกิจกรรมภายในสายงานวิกฤต

23. หลักเกณฑ์ในการสร้างข่ายงาน ดังนี้ 1. จุดเริ่มต้นของโครงการมีจุดเดียวอยู่ด้านซ้ายของข่ายงาน 2. จุดสิ้นสุดของโครงการมีจุดเดียว อยู่ด้านขวาของข่ายงาน 3. แต่ละกิจกรรมจะใช้แทนด้วยเส้นลูกศรเพียงเส้นเดียวในข่ายงาน 4. กิจกรรมมากกว่า 1 กิจกรรมจะเริ่มต้นที่จุดเดียวกันและแล้วเสร็จที่จุดเดียวกันไม่ได้ 5. จุดที่แสดงเหตุการณ์สิ้นสุดของกิจกรรมควรเขียนเยื้องมาทางขวา 6. พยายามหลีกเลี่ยงการเขียนเส้นลูกศรไขว้กัน 7. ระยะเวลาดำเนินงานของกิจกรรมไม่มีความสัมพันธ์กับความยาวของเส้นลูกศรที่ใช้แทนกิจกรรมนั้นๆ 8. การกำหนดหมายเลขจุดเชื่อมในข่ายงาน นิยมให้จุดเริ่มต้นของกิจกรรมมีตัวเลขต่ำกว่าจุดสิ้นสุดกิจกรรม

24. The End Chapter 3