1 / 107

SYSTEM ANALYST AND DESIGN

SYSTEM ANALYST AND DESIGN. A Comprehensive Tutorial For RU MSIT5. SDLC. System Development Life Cycle กระบวนการพัฒนาระบบสารสนเทศ โดยการ ออกแบบ จัดสร้าง และ ส่งมอบระบบสารสนเทศที่สามารถสนับสนุนความต้องการทางธุรกิจ จุดประสงค์หลักไม่ใช่การสร้างระบบที่ยอดเยี่ยมที่สุดแต่เป็นการสร้าง

thisbe
Download Presentation

SYSTEM ANALYST AND DESIGN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 (การสังเกตุการณ์)

More Related