SYSTEM ANALYST AND DESIGN

1. SYSTEM ANALYST AND DESIGN A Comprehensive Tutorial For RU MSIT5

2. SDLC • System Development Life Cycle • กระบวนการพัฒนาระบบสารสนเทศ โดยการ ออกแบบ จัดสร้าง และ ส่งมอบระบบสารสนเทศที่สามารถสนับสนุนความต้องการทางธุรกิจ • จุดประสงค์หลักไม่ใช่การสร้างระบบที่ยอดเยี่ยมที่สุดแต่เป็นการสร้าง สิ่งที่มีคุณค่าต่อองค์กร

3. SDLC • มี 4 Phase ที่สำคัญคือ • Planning (วางแผน) • Analysis (วิเคราะห์) • Design (ออกแบบ) • Implementation (จัดสร้าง) แต่ละ phase จะประกอบด้วยชุดของขั้นตอนซึ่งพึ่งพาเทคนิคต่าง ๆ เพื่อผลิตสิ่งที่สามารถส่งมอบได้ (deliverable) ซึ่งจะถูกนำไปเป็น input ของ phase ต่อไป

4. SDLC • Planningเป็นกระบวนการทำความเข้าใจว่า ทำไมถึงต้องจัดทำระบบและ กำหนดผู้รับผิดชอบในการจัดทำระบบ แบ่งออกเป็นสองขั้นตอน • ระหว่างเริ่มต้นโครงการ • มีการจัดทำ System Request • มีการตัดสินใจว่าควรจะจัดสร้างระบบหรือไม่ (Feasibility Analysis) - Technical Feasibility (ในทางเทคนิคเป็นไปได้หรือไม่?) - Economic Feasibility (ให้คุณค่าทางธุรกิจหรือไม่?) - Organizational Feasibility (สร้างแล้วมีคนใช้หรือไม่?) สิ่งที่ส่งมอบในขั้นตอนนี้ก็คือ System Requet, Feasibility Analysis

5. SDLC • Planning2. เมื่อระบบได้รับการอนุมัติให้จัดสร้างแล้ว เข้าสู่ขั้นตอนการบริหารจัดการโครงการ - จัดทำ (work plan) - จัดตั้งทีมงาน (staffing plan) - เลือกเทคนิคที่จะใช้ - กำกับดูแลโครงการตลอดกระบวนการ SDLC สิ่งที่สามารถส่งมอบได้ ที่ได้จากขั้นตอนนี้ก็คือ Project Plan

6. SDLC • Analysisเป็นกระบวนการกำหนดในขั้นรายละเอียดของโครงการ • ใครจะเป็นผู้ใช้ระบบ? • ระบบสามารถทำอะไรได้บ้าง? • ระบบถูกใช้ที่ไหน • ระบบจะถูกใช้เมื่อไหร่?

7. SDLC • Analysisแบ่งออกเป็นสามขั้นตอน • Analysis Strategy วิเคราะห์ว่าระบบที่มีอยู่เดิม (as is) เป็นอย่างไร และระบบที่จะจัดทำขึ้นใหม่ (to be) ควรจะเป็นอย่างไร • Requirement Gathering รวบรวมข้อมูล เช่น การใช้แบบ สอบถามหรือการสัมภาษณ์ • System Proposal จัดทำรายงานซึ่งประกอบด้วย แนวคิดของระบบ แผนดำเนินการ รวมถึงการวิเคราะห์ระบบด้วยโมเดลต่าง ๆ สิ่งที่สามารถส่งมอบได้จากขั้นตอนนี้ก็คือ System Proposal

8. SDLC • Designเป็นการตัดสินใจว่าระบบจะทำงานอย่างไร ทั้งในแง่มุมของซอฟท์แวร์และ ฮาร์ดแวร์ ฐานข้อมูลและระบบสาธารณูปโภคเครือข่ายที่จำเป็นต่อการทำงานของระบบ ประกอบด้วย 4 ขั้นตอนคือ • Design Strategy เลือกกลยุทธ์ในการพัฒนาระบบ • Architecture Design เลือกสถาปัตยกรรมที่จะใช้รองรับระบบ • Database and File Specification กำหนดว่าข้อมูลอะไรที่จะ ถูกจัดเก็บและจัดเก็บไว้ที่ไหน • Program Design กำหนดว่าโปรแกรมจะทำอะไรได้บ้าง

9. SDLC • Designสิ่งที่ได้จากขั้นตอนการออกแบบระบบคือ • Architecture Design (ออกแบบสถาปัตยกรรมระบบ) • Interface Design (ออกแบบการติดต่อระหว่างระบบกับผู้ใช้) • Database Design (ออกแบบฐานข้อมูล) • Program Design (ออกแบบโปรแกรม) ซึ่งรวมแล้วเรียกว่า System Specification ซึ่งเป็นสิ่งที่สามารถส่งมอบได้ ที่ได้จากขั้นตอนนี้

10. SDLC • Implementationดำเนินการจัดสร้างระบบ แบ่งออกเป็นสามขั้นตอน 1. จัดสร้างระบบ 2. ติดตั้งระบบ 3. จัดทำ Support Plan (แผนสนับสนุนที่บอกถึงผลการทำงาน ของระบบ ข้อดี ข้อบกพร่องและข้อแนะนำต่าง ๆ)

11. SDLC • System Development Methodologies(วิธีการที่ใช้ใน SDLC) วิธีการใช้ที่ใช้ใน SDLC แบ่งออกเป็นประเภทใหญ่ ๆ ได้สามประเภท • Structured Design - Waterfall Development - Parallel Development • Rapid Application Development (RAD) - Phased Development - Prototyping - Throwaway Prototyping • Agile Development - Extreme Programming

12. SDLC • Structured Design แบ่งออกเป็นสองวิธี 1. Waterfall Development 2. Parallel Development

13. SDLC • Structured Design • Waterfall Development เคลื่อนที่ไปข้างหน้าจากบนลงล่างเหมือนน้ำตก

14. SDLC • Structured Design • Waterfall Development ข้อดี - ใช้เวลาในการออกแบบนานมากก่อนที่จะเริ่มจัดทำระบบ - มีการเปลี่ยนแปลงเกิดขึ้นน้อยในระหว่างการพัฒนาระบบ ข้อเสีย - ต้องออกแบบให้เสร็จสมบูรณ์ก่อนถึงจะเริ่มพัฒนาระบบได้ - ใช้เวลาในการส่งมอบระบบนานมาก

15. SDLC • Structured Design • Parallel Development(การพัฒนาระบบแบบคู่ขนาน) - เพื่อลดความล่าช้าที่เกิดจากขั้นตอนการวิเคราะห์ระบบทำให้การส่งมอบ ระบบล่าช้า - แบ่งโครงการใหญ่ออกเป็นโครงการย่อยตามการจัดลำดับความสำคัญ แล้วพัฒนาโครงการที่ถูกย่อยแล้วไปพร้อม ๆ กัน

16. SDLC • Structured Design • Parallel Development(การพัฒนาระบบแบบคู่ขนาน) ข้อดี ลดเวลาในการส่งมอบระบบ ข้อเสีย บางครั้งโครงการย่อยบางโครงการขึ้นอยู่กับโครงการย่อยอื่น ๆ ทำให้ การรวมผลลัพทธ์ของโครงการต่าง ๆ เข้าเป็นระบบใหญ่ทำได้ยากและ ต้องใช้ความพยายามมาก

17. SDLC • Rapid Application Development (RAD) • ใช้เพื่อแก้ข้อบกพร่องของ Structured Design ในเรื่องความล่าช้า ในการส่งมอบระบบ • ปรับขั้นตอนของ SDLC ให้สามารถส่งมอบบางส่วนของระบบได้เร็วขึ้น • ผู้ใช้ระบบสามารถเข้าใจระบบได้มากขึ้นและให้คำแนะนำในการแก้ไข ปรับปรุงระบบให้ตรงกับความต้องการของผู้ใช้มากขึ้น

18. SDLC • Rapid Application Development (RAD) แบ่งออกเป็น 3 วิธี 1. Phased Development 2. Prototyping 3. Throwing Prototyping

19. SDLC • Phased Development แบ่งโครงการออกเป็นชุดหรือ version ซึ่งจะถูกพัฒนาเรียงตาม ลำดับความสำคัญจากมากไปหาน้อย สิ่งที่สำคัญมากจะถูกพัฒนา เป็น version แรก ส่วนที่มีความสำคัญน้อยจะถูกพัฒนาเป็น ลำดับต่อไปตามลำดับความสำคัญ

20. SDLC • Phased Development ข้อดี ส่งมอบระบบได้เร็ว ข้อเสีย ระบบที่ส่งมอบใน version แรก ๆ ยังไม่สมบูรณ์

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

22. SDLC • Prototyping ข้อดี ผู้ใช้ระบบสามารถมองเห็นระบบที่เป็นรูปเป็นร่างได้อย่างรวดเร็ว ข้อเสีย อาจขาดการวิเคราะห์ระบบที่รอบคอบเพียงพอ

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

24. SDLC • Throwaway Prototyping ข้อดี แก้ปัญหาที่ซับซ้อนได้ดี ช่วยให้วิเคราะห์ระบบได้ดีขึ้น ข้อเสีย ใช้เวลามากขึ้นในการส่งมอบระบบ

25. SDLC • Agile Development - ลดขั้นตอนของการออกแบบและเอกสารในกระบวนการ SDLC - เน้นที่กระบวนการพัฒนาระบบ ประกอบด้วยหลายวิธีเช่น - Extreme Programming (XP) - Scrum - Dynamic System Development Method (DSDM)

26. SDLC • Extreme Programming (XP) ประกอบด้วยการให้คุณค่าความสำคัญสี่ด้านคือ - Communication (การสื่อสาร) มีการสื่อสารระหว่างทีมพัฒนาระบบและผู้ที่เกี่ยวข้องตลอดเวลา - Simplicity (ความเรียบง่าย) เขียนโปรแกรมให้เรียบง่าย - Feedback (การป้อนกลับ) ให้ผลลัพธ์ตอบกลับผู้ใช้งานระบบอย่างรวดเร็ว - Courage (ความกล้าหาญ) ไม่กลัวการเปลี่ยนแปลงใหม่ ๆ

27. SDLC • Extreme Programming (XP) • ข้อดี เหมาะสำหรับโครงการเล็ก ๆ ที่ต้องการความรวดเร็วในการพัฒนาระบบ • ข้อเสีย มีโอกาสสำเร็จน้อยลง เมื่อนำไปใช้ในโครงการขนาดใหญ่

28. SDLC • การเลือกวิธีพัฒนาระบบที่เหมาะสม • ถ้าความต้องการของผู้ใช้งานระบบไม่ชัดเจนเลือกใช้วิธี RAD (Phased , Prototyping and Throwaway Prototyping) • ถ้าผู้พัฒนาระบบไม่คุ้นเคยกับเทคโนโลยี เลือกใช้วิธี Throwaway Prototyping • ถ้าระบบมีความซับซ้อนมาก ๆ เลือกใช้วิธี Throwaway Prototyping

29. SDLC • การเลือกวิธีพัฒนาระบบที่เหมาะสม • ถ้าต้องการระบบที่มีความน่าเชื่อถือสูง เลือกใช้วิธี Throwaway Prototyping • ถ้าต้องการส่งมอบระบบอย่างรวดเร็ว เลือกใช้วิธี Phased Development and Prototyping • ถ้าต้องการส่งมอบงานให้ตรงตามกำหนด เลือกใช้วิธี Phased Development

30. Object-Oriented Systems Analysis And Design (OOSAD) การวิเคราะห์และออกแบบระบบด้วย OOSAD มีความเกี่ยวข้องกับ วิธี Phased Development ใน RAD ในการนำปัญหามาแตก ออกเป็นประเด็นย่อย ๆ เพื่อง่ายต่อการวิเคราะห์ ประกอบด้วยองค์ประกอบสามส่วนคือ 1. Use-Case Driven 2. Architecture-Centric 3. Iterative And Incremental

31. Object-Oriented Systems Analysis And Design (OOSAD) • Use Case Driven - หมายถึงการใช้ Use Case เป็นเครื่องมือหลักในการออกแบบ - Use Case ใช้อธิบายว่า ผู้ใช้ระบบตอบโต้กับระบบเพื่อทำ กิจกรรมบางอย่างได้อย่างไร เช่น สั่งซื้อสินค้า จองที่พัก หรือ ค้นหาข้อมูล - Use Case ทำให้การออกแบบระบบเรียบง่าย เพราะแต่ละ Use Case จะสนใจเฉพาะกิจกรรมใดกิจกรรมหนึ่งในระบบ ณ ช่วงเวลาใดเวลาหนึ่งเท่านั้น

32. Object-Oriented Systems Analysis And Design (OOSAD) • Architecture Centric หมายถึงสถาปัตยกรรมที่รองรับระบบที่กำลังพัฒนาอยู่ เป็นตัวกำหนด คุณลักษณะ โครงสร้าง และรายละเอียดต่าง ๆ ของระบบ ซึ่งอย่างน้อยจะต้องรองรับสถาปัตยกรรม 3 แบบ ที่แยกออกจากกันแต่ มีความเกี่ยวข้องกัน คือ - Functional View - Structural View - Behavioral View

33. Object-Oriented Systems Analysis And Design (OOSAD) • Iterative and Incremental หมายถึงการ เพิ่ม เสริม เติมแต่ง ปรับปรุง และการทำซ้ำ ตลอดวงจร ชีวิตของการพัฒนาระบบ ผ่านกระบวนการ SDLC

34. Object-Oriented Systems Analysis And Design (OOSAD) • ประโยชน์ของ OOSAD - แยกระบบใหญ่ที่มีความซับซ้อนออกเป็นโมดูลย่อย ๆ ที่ สามารถจัดการได้ง่าย - นำโมดูลย่อยมาใช้ซ้ำได้ในระบบอื่น - สร้างความเข้าใจที่ตรงกันระหว่างทีมพัฒนาและ user เพราะ object มีความเหมือนกับวัตถุในโลกแห่งความ เป็นจริง

35. THE UNIFIED PROCESS • คือการนำเอา UML มาใช้ในการพัฒนาระบบแบบ Object- Oriented Analysis and Design (OOSAD) • ประกอบด้วยมิติของการพัฒนาระบบที่เกี่ยวข้องกันสองส่วนคือ - Phases - Workflow

36. THE UNIFIED PROCESS

37. THE UNIFIED MODELING LANGUAGE (UML) • คือภาษาที่เป็นที่เข้าใจร่วมกันสำหรับการการออกแบบระบบ แบบ OOSAD • ประกอบด้วยคำนิยามและชุดของ Diagram ซึ่งมีความสมบูรณ์ พอที่จะใช้ในการสร้างตัวแบบจากการวิเคราะห์และออกแบบตลอด จนถึงการพัฒนาระบบ

38. PLANNING

39. PROJECT IDENTIFICATION • System Request คือเอกสารที่บรรยายถึงเหตุผลทางธุรกิจที่ต้องสร้างระบบขึ้นมา และ ระบุคุณค่าที่คาดหวังว่าจะได้รับเมื่อระบบแล้วเสร็จ ประกอบด้วย - Project Sponsor (เจ้าของโครงการ) - Business Need (ความจำเป็น) - Business Requirement (ความต้องการ) - Business Value (คุณค่าทางธุรกิจ) - Special Issues or Constraints (ประเด็นที่เกี่ยวข้อง)

40. PROJECT IDENTIFICATION • Feasibility Analysis - Technical Feasibility (สร้างได้หรือไม่?) - Economic Feasibility (สร้างแล้วคุ้มค่าหรือไม่?) - Organization Feasibility (ได้รับการยอมรับจากผู้ใช้งาน ระบบหรือไม่?)

41. PROJECT MANAGEMENT • Identifying Project Size (ระบุขนาดของโครงการ) • Function Point Approach - Estimate system size (ประเมินขนาดของโปรแกรม) - Estimate required effort (เปลี่ยนขนาดของ โปรแกรมเป็นแรงงานคน/เดือน) - Estimate time required (ประเมินระยะเวลาที่ใช้)

42. PROJECT MANAGEMENT • Creating and Managing The Work Plan - work plan แสดงรายการงานแต่ละรายการพร้อมด้วยข้อมูล สำคัญที่เกี่ยวกับงานนั้น ๆ เช่น กำหนดการแล้วเสร็จ ผู้รับผิดชอบ - Project Manager จะต้องระบุงานที่ต้องทำและตัดสินใจ ว่าจะต้องใช้เวลาแต่ละงานเท่าไหร่ - Work Plan นำเสนอโดยใช้ Gantt chart หรือ PERT chart

43. PROJECT MANAGEMENT • Identifying Tasks (ระบุงานที่ต้องทำ) - ใช้ข้อมูลจากโครงการที่เคยทำมาแล้วว่าต้องมีงานอะไรบ้าง - ใช้วิธี Structured, top-down approach กำหนด ในภาพใหญ่ก่อน แล้วจึงแตกงานในภาพใหญ่ออกเป็นงานย่อย เรียกวิธีนี้ว่า Work breakdown structure (WBS)

44. PROJECT MANAGEMENT • PERT (Program Evaluation and Review Technique) - เป็น network analysis technique ซึ่งสามารถนำมาใช้ ในกรณีที่เวลาในการทำงานของแต่ละงานมีความไม่แน่นอน - PERT ใช้เวลา 3 ค่าในการประเมิน 1. เวลาที่คาดว่างานจะเสร็จเร็วที่สุด (optimistic) 2. เวลาที่คาดว่างานจะเสร็จโดยทั่วไป (most likely) 3. เวลาที่คาดว่างานจะเสร็จช้าที่สุด (pressimistic) ซึ่งเวลาทั้ง 3 ค่าจะถูกนำมาคำนวณเป็นเวลาเฉลี่ยของงานโดยใช้สูตร (optimistic estimate + (4xmostlikely) + pressimistic estimate) / 6

45. PROJECT MANAGEMENT • PERT (Program Evaluation and Review Technique) - เป็นวิธีที่ดีที่สุดในการแสดงการขึ้นต่อกันของงาน - สามารถระบุเส้นทางวิกฤติ (critical path method)ได้ (คือ เส้นทางงานที่ไม่อาจล่าช้าได้เพราะจะทำให้โครงการทั้งหมดล่าช้า) - งานที่อยู่ในเส้นทางวิกฤติเรียกว่า งานวิกฤติ (critical task)

46. PROJECT MANAGEMENT • Staffing Plan (การวางแผนกำลังคน) - กำหนดว่าจะต้องใช้จำนวนคนเท่าไหร่ในโครงการ - กำหนดบทบาทที่ต้องการในโครงการ - กำหนดว่าใครจะทำหน้าที่ในบทบาทใด บางครั้งหนึ่งคนอาจจะ ได้รับมากกว่าหนึ่งบทบาท

47. REQUIREMENT ANALYSIS • คำจำกัดความของ Requirement คือคำบรรยายที่เกี่ยวกับสิ่งที่ระบบจะต้องทำหรือคุณสมบัติที่ระบบ จะต้องมี ประกอบด้วย - Functional Requirement(หน้าที่) - Nonfunctional Requirement (คุณสมบัติ)

48. REQUIREMENT ANALYSIS • Requirement Analysis Strategies ขั้นตอนพื้นฐานของ requirement analysis แบ่งออกเป็น 3 ขั้นตอนคือ 1. ทำความเข้าใจกับ as-is system 2. ระบุจุดที่ต้องแก้ไขปรับปรุง 3. สร้าง requirement สำหรับ to-be system

49. REQUIREMENT ANALYSIS • Requirement Analysis Strategies Strategy (กลยุทธ์) ที่ใช้ในการวิเคราะห์ requierment มีอยู่ 3 วิธี 1. Business process automation 2. Business process improvement 3. Business process reengineering

50. REQUIREMENT ANALYSIS • เทคนิคในการรวบรวม Requirements - Interviews (การสัมภาษณ์) - Joint Application Development (JAD) จัดให้มีการประชุมร่วมระหว่าง ทีมพัฒนาระบบ ผู้ใช้ระบบ และผู้บริหารที่มีอำนาจในการตัดสินใจ - Questionnaires (สร้างแบบสอบถาม) - Observation (การสังเกตุการณ์)