Transcript SYSTEM ANALYST AND DESIGN

SYSTEM ANALYST AND DESIGN
A Comprehensive Tutorial For
RU MSIT5
SDLC
• System Development Life Cycle
o กระบวนการพัฒนาระบบสารสนเทศ โดยการ ออกแบบ จัดสร้ าง และ
ส่งมอบระบบสารสนเทศที่สามารถสนับสนุนความต้ องการทางธุรกิจ
o
จุดประสงค์หลักไม่ใช่การสร้ างระบบที่ยอดเยี่ยมที่สดุ แต่เป็ นการสร้ าง
สิ่งที่มีคณ
ุ ค่าต่อองค์กร
SDLC
• มี 4 Phase ที่สาคัญคือ
o
o
o
o
Planning (วางแผน)
Analysis (วิเคราะห์)
Design (ออกแบบ)
Implementation (จัดสร้ าง)
แต่ละ phase จะประกอบด้ วยชุดของขันตอนซึ
้
ง่ พึง่ พาเทคนิคต่าง ๆ
เพื่อผลิตสิ่งที่สามารถส่งมอบได้ (deliverable) ซึง่ จะถูกนาไปเป็ น
input ของ phase ต่อไป
SDLC
• Planning
เป็ นกระบวนการทาความเข้ าใจว่า ทาไมถึงต้ องจัดทาระบบและ
กาหนดผู้รับผิดชอบในการจัดทาระบบ แบ่งออกเป็ นสองขันตอน
้
1. ระหว่างเริ่ มต้ นโครงการ
o มีการจัดทา System Request
o มีการตัดสินใจว่าควรจะจัดสร้ างระบบหรื อไม่ (Feasibility Analysis)
- Technical Feasibility (ในทางเทคนิคเป็ นไปได้ หรื อไม่?)
- Economic Feasibility (ให้ คณ
ุ ค่าทางธุรกิจหรื อไม่?)
- Organizational Feasibility (สร้ างแล้ วมีคนใช้ หรื อไม่?)
สิง่ ที่สง่ มอบในขันตอนนี
้
้ก็คือ System Requet, Feasibility Analysis
SDLC
• Planning
2. เมื่อระบบได้ รับการอนุมตั ิให้ จดั สร้ างแล้ ว
เข้ าสูข่ นตอนการบริ
ั้
หารจัดการโครงการ
- จัดทา (work plan)
- จัดตังที
้ มงาน (staffing plan)
- เลือกเทคนิคที่จะใช้
- กากับดูแลโครงการตลอดกระบวนการ SDLC
สิง่ ที่สามารถส่งมอบได้ ที่ได้ จากขันตอนนี
้
้ก็คือ Project Plan
SDLC
• Analysis
เป็ นกระบวนการกาหนดในขันรายละเอี
้
ยดของโครงการ
o ใครจะเป็ นผู้ใช้ ระบบ?
o ระบบสามารถทาอะไรได้ บ้าง?
o ระบบถูกใช้ ที่ไหน
o ระบบจะถูกใช้ เมื่อไหร่ ?
SDLC
• Analysis
แบ่งออกเป็ นสามขันตอน
้
1. Analysis Strategy วิเคราะห์วา่ ระบบที่มีอยู่เดิม (as is) เป็ นอย่างไร
และระบบที่จะจัดทาขึ ้นใหม่ (to be) ควรจะเป็ นอย่างไร
2. Requirement Gathering รวบรวมข้ อมูล เช่น การใช้ แบบ
สอบถามหรื อการสัมภาษณ์
3. System Proposal จัดทารายงานซึง่ ประกอบด้ วย แนวคิดของระบบ
แผนดาเนินการ รวมถึงการวิเคราะห์ระบบด้ วยโมเดลต่าง ๆ
สิ่งที่สามารถส่งมอบได้ จากขันตอนนี
้
้ก็คือ System Proposal
SDLC
• Design
เป็ นการตัดสินใจว่าระบบจะทางานอย่างไร ทังในแง่
้
มมุ ของซอฟท์แวร์ และ
ฮาร์ ดแวร์ ฐานข้ อมูลและระบบสาธารณูปโภคเครื อข่ายที่จาเป็ นต่อการ
ทางานของระบบ ประกอบด้ วย 4 ขันตอนคื
้
อ
o Design Strategy เลือกกลยุทธ์ในการพัฒนาระบบ
o Architecture Design เลือกสถาปั ตยกรรมที่จะใช้ รองรับระบบ
o Database and File Specification กาหนดว่าข้ อมูลอะไรที่จะ
ถูกจัดเก็บและจัดเก็บไว้ ที่ไหน
o Program Design กาหนดว่าโปรแกรมจะทาอะไรได้ บ้าง
SDLC
• Design
สิง่ ที่ได้ จากขันตอนการออกแบบระบบคื
้
อ
o Architecture Design (ออกแบบสถาปั ตยกรรมระบบ)
o Interface Design (ออกแบบการติดต่อระหว่างระบบกับผู้ใช้ )
o Database Design (ออกแบบฐานข้ อมูล)
o Program Design (ออกแบบโปรแกรม)
ซึง่ รวมแล้ วเรี ยกว่า System Specification ซึง่ เป็ นสิ่งที่สามารถส่งมอบ
ได้ ที่ได้ จากขันตอนนี
้
้
SDLC
• Implementation
ดาเนินการจัดสร้ างระบบ แบ่งออกเป็ นสามขันตอน
้
1. จัดสร้ างระบบ
2. ติดตังระบบ
้
3. จัดทา Support Plan (แผนสนับสนุนที่บอกถึงผลการทางาน
ของระบบ ข้ อดี ข้ อบกพร่องและข้ อแนะนาต่าง ๆ)
SDLC
• System Development Methodologies (วิธีการที่ใช้ ใน SDLC)
วิธีการใช้ ที่ใช้ ใน SDLC แบ่งออกเป็ นประเภทใหญ่ ๆ ได้ สามประเภท
o Structured Design
- Waterfall Development
- Parallel Development
o Rapid Application Development (RAD)
- Phased Development
- Prototyping
- Throwaway Prototyping
o Agile Development
- Extreme Programming
SDLC
• Structured Design
แบ่งออกเป็ นสองวิธี
1. Waterfall Development
2. Parallel Development
SDLC
• Structured Design
o Waterfall Development
เคลื่อนที่ไปข้ างหน้ าจากบนลงล่างเหมือนน ้าตก
SDLC
• Structured Design
o Waterfall Development
ข้ อดี
- ใช้ เวลาในการออกแบบนานมากก่อนที่จะเริ่มจัดทาระบบ
- มีการเปลี่ยนแปลงเกิดขึ ้นน้ อยในระหว่างการพัฒนาระบบ
ข้ อเสีย
- ต้ องออกแบบให้ เสร็จสมบูรณ์ก่อนถึงจะเริ่มพัฒนาระบบได้
- ใช้ เวลาในการส่งมอบระบบนานมาก
SDLC
• Structured Design
o Parallel Development (การพัฒนาระบบแบบคูข่ นาน)
- เพื่อลดความล่าช้ าที่เกิดจากขันตอนการวิ
้
เคราะห์ระบบทาให้ การส่งมอบ
ระบบล่าช้ า
- แบ่งโครงการใหญ่ออกเป็ นโครงการย่อยตามการจัดลาดับความสาคัญ
แล้ วพัฒนาโครงการที่ถกู ย่อยแล้ วไปพร้ อม ๆ กัน
SDLC
• Structured Design
o Parallel Development (การพัฒนาระบบแบบคูข่ นาน)
ข้ อดี
ลดเวลาในการส่งมอบระบบ
ข้ อเสีย
บางครัง้ โครงการย่อยบางโครงการขึ ้นอยูก่ บั โครงการย่อยอื่น ๆ ทาให้
การรวมผลลัพทธ์ของโครงการต่าง ๆ เข้ าเป็ นระบบใหญ่ทาได้ ยากและ
ต้ องใช้ ความพยายามมาก
SDLC
• Rapid Application Development (RAD)
- ใช้ เพื่อแก้ ข้อบกพร่องของ Structured Design ในเรื่ องความล่าช้ า
ในการส่งมอบระบบ
- ปรับขันตอนของ
้
SDLC ให้ สามารถส่งมอบบางส่วนของระบบได้ เร็วขึ ้น
- ผู้ใช้ ระบบสามารถเข้ าใจระบบได้ มากขึ ้นและให้ คาแนะนาในการแก้ ไข
ปรับปรุงระบบให้ ตรงกับความต้ องการของผู้ใช้ มากขึ ้น
SDLC
• Rapid Application Development (RAD)
แบ่งออกเป็ น 3 วิธี
1. Phased Development
2. Prototyping
3. Throwing Prototyping
SDLC
• Phased Development
แบ่งโครงการออกเป็ นชุดหรื อ version ซึง่ จะถูกพัฒนาเรี ยงตาม
ลาดับความสาคัญจากมากไปหาน้ อย สิง่ ที่สาคัญมากจะถูกพัฒนา
เป็ น version แรก ส่วนที่มีความสาคัญน้ อยจะถูกพัฒนาเป็ น
ลาดับต่อไปตามลาดับความสาคัญ
SDLC
• Phased Development
ข้ อดี
ส่งมอบระบบได้ เร็ว
ข้ อเสีย
ระบบที่สง่ มอบใน version แรก ๆ ยังไม่สมบูรณ์
SDLC
• Prototyping
วิเคราะห์ ออกแบบ และพัฒนาระบบไปพร้ อม ๆ กัน โดยการจัดทา
system prototype หรื อตัวแบบของระบบแบบหยาบ ๆ เพื่อ
ให้ ผ้ ใู ช้ งานระบบและผู้ที่เกี่ยวข้ องเห็นระบบที่เป็ นรูปเป็ นร่างแล้ ว และ
สามารถให้ คาแนะในการจัดทาระบบให้ ตรงตามความต้ องการของ
ผู้ใช้ ซึง่ คาแนะนาจะถูกนามา วิเคราะห์ ออกแบบ และพัฒนา เป็ น
วงจรซ ้าไปเรื่ อย ๆ จนกว่าผู้ใช้ ระบบจะเห็นชอบกับตัวแบบสุดท้ าย
ซึง่ จะถูกนามาใช้ งานเป็ นระบบจริ งที่ถือว่าเสร็ จสมบูรณ์
SDLC
• Prototyping
ข้ อดี
ผู้ใช้ ระบบสามารถมองเห็นระบบที่เป็ นรูปเป็ นร่างได้ อย่างรวดเร็ว
ข้ อเสีย
อาจขาดการวิเคราะห์ระบบที่รอบคอบเพียงพอ
SDLC
• Throwaway Prototyping
- คล้ าย ๆ กับวิธี Prototyping แต่ใช้ ในจุดประสงค์ที่ตา่ งกัน
- ใช้ เพื่อนาเสนอบางแง่มมุ หรื อบางส่วนของระบบที่มีความซับซ้ อน
มาก ๆ เพื่อให้ ผ้ ใู ช้ ระบบสามารถมองเห็นระบบที่เป็ นรูปเป็ นร่ าง
ในทุก ๆ แง่มมุ และเข้ าใจในระบบได้ ดียิ่งขึ ้น
- เป็ นตัวอย่างระบบที่ไม่มีฟังก์ชนั การทางานรองรับ ไม่สามารถ
นาไปใช้ งานได้ จริ ง
- เหมือนใช้ แล้ วจะถูกโยนทิ ้งไป ไม่ถกู นามาใช้ พฒ
ั นาต่อเหมือน
Prototyping
SDLC
• Throwaway Prototyping
ข้ อดี
แก้ ปัญหาที่ซบั ซ้ อนได้ ดี ช่วยให้ วิเคราะห์ระบบได้ ดีขึ ้น
ข้ อเสีย
ใช้ เวลามากขึ ้นในการส่งมอบระบบ
SDLC
• Agile Development
- ลดขันตอนของการออกแบบและเอกสารในกระบวนการ
้
SDLC
- เน้ นที่กระบวนการพัฒนาระบบ
ประกอบด้ วยหลายวิธีเช่น
- Extreme Programming (XP)
- Scrum
- Dynamic System Development Method
(DSDM)
SDLC
• Extreme Programming (XP)
ประกอบด้ วยการให้ คณ
ุ ค่าความสาคัญสี่ด้านคือ
- Communication (การสื่อสาร)
มีการสื่อสารระหว่างทีมพัฒนาระบบและผู้ที่เกี่ยวข้ องตลอดเวลา
- Simplicity (ความเรี ยบง่าย)
เขียนโปรแกรมให้ เรี ยบง่าย
- Feedback (การป้อนกลับ)
ให้ ผลลัพธ์ตอบกลับผู้ใช้ งานระบบอย่างรวดเร็ ว
- Courage (ความกล้ าหาญ)
ไม่กลัวการเปลี่ยนแปลงใหม่ ๆ
SDLC
• Extreme Programming (XP)
- ข้ อดี
เหมาะสาหรับโครงการเล็ก ๆ ที่ต้องการความรวดเร็วในการพัฒนาระบบ
- ข้ อเสีย
มีโอกาสสาเร็จน้ อยลง เมื่อนาไปใช้ ในโครงการขนาดใหญ่
SDLC
• การเลือกวิธีพฒ
ั นาระบบที่เหมาะสม
o ถ้ าความต้ องการของผู้ใช้ งานระบบไม่ชดั เจน
เลือกใช้ วิธี RAD (Phased , Prototyping and Throwaway
Prototyping)
o ถ้ าผู้พฒ
ั นาระบบไม่ค้ นุ เคยกับเทคโนโลยี
เลือกใช้ วิธี Throwaway Prototyping
o ถ้ าระบบมีความซับซ้ อนมาก ๆ
เลือกใช้ วิธี Throwaway Prototyping
SDLC
• การเลือกวิธีพฒ
ั นาระบบที่เหมาะสม
o ถ้ าต้ องการระบบที่มีความน่าเชื่อถือสูง
เลือกใช้ วิธี Throwaway Prototyping
o ถ้ าต้ องการส่งมอบระบบอย่างรวดเร็ว
เลือกใช้ วิธี Phased Development and Prototyping
o ถ้ าต้ องการส่งมอบงานให้ ตรงตามกาหนด
เลือกใช้ วิธี Phased Development
Object-Oriented Systems Analysis
And Design (OOSAD)
การวิเคราะห์และออกแบบระบบด้ วย OOSAD มีความเกี่ยวข้ องกับ
วิธี Phased Development ใน RAD ในการนาปั ญหามาแตก
ออกเป็ นประเด็นย่อย ๆ เพื่อง่ายต่อการวิเคราะห์
ประกอบด้ วยองค์ประกอบสามส่วนคือ
1. Use-Case Driven
2. Architecture-Centric
3. Iterative And Incremental
Object-Oriented Systems Analysis
And Design (OOSAD)
• Use Case Driven
- หมายถึงการใช้ Use Case เป็ นเครื่ องมือหลักในการออกแบบ
- Use Case ใช้ อธิบายว่า ผู้ใช้ ระบบตอบโต้ กบั ระบบเพื่อทา
กิจกรรมบางอย่างได้ อย่างไร เช่น สัง่ ซื ้อสินค้ า จองที่พกั หรื อ
ค้ นหาข้ อมูล
- Use Case ทาให้ การออกแบบระบบเรี ยบง่าย เพราะแต่ละ
Use Case จะสนใจเฉพาะกิจกรรมใดกิจกรรมหนึง่ ในระบบ
ณ ช่วงเวลาใดเวลาหนึง่ เท่านัน้
Object-Oriented Systems Analysis
And Design (OOSAD)
• Architecture Centric
หมายถึงสถาปั ตยกรรมที่รองรับระบบที่กาลังพัฒนาอยู่ เป็ นตัวกาหนด
คุณลักษณะ โครงสร้ าง และรายละเอียดต่าง ๆ ของระบบ
ซึง่ อย่างน้ อยจะต้ องรองรับสถาปั ตยกรรม 3 แบบ ที่แยกออกจากกันแต่
มีความเกี่ยวข้ องกัน คือ
- Functional View
- Structural View
- Behavioral View
Object-Oriented Systems Analysis
And Design (OOSAD)
• Iterative and Incremental
หมายถึงการ เพิ่ม เสริม เติมแต่ง ปรับปรุง และการทาซ ้า ตลอดวงจร
ชีวิตของการพัฒนาระบบ ผ่านกระบวนการ SDLC
Object-Oriented Systems Analysis
And Design (OOSAD)
• ประโยชน์ของ OOSAD
- แยกระบบใหญ่ที่มีความซับซ้ อนออกเป็ นโมดูลย่อย ๆ ที่
สามารถจัดการได้ ง่าย
- นาโมดูลย่อยมาใช้ ซ ้าได้ ในระบบอื่น
- สร้ างความเข้ าใจที่ตรงกันระหว่างทีมพัฒนาและ user
เพราะ object มีความเหมือนกับวัตถุในโลกแห่งความ
เป็ นจริง
THE UNIFIED PROCESS
• คือการนาเอา UML มาใช้ ในการพัฒนาระบบแบบ ObjectOriented Analysis and Design (OOSAD)
• ประกอบด้ วยมิตขิ องการพัฒนาระบบที่เกี่ยวข้ องกันสองส่วนคือ
- Phases
- Workflow
THE UNIFIED PROCESS
THE UNIFIED MODELING LANGUAGE
(UML)
• คือภาษาที่เป็ นที่เข้ าใจร่วมกันสาหรับการการออกแบบระบบ
แบบ OOSAD
• ประกอบด้ วยคานิยามและชุดของ Diagram ซึง่ มีความสมบูรณ์
พอที่จะใช้ ในการสร้ างตัวแบบจากการวิเคราะห์และออกแบบตลอด
จนถึงการพัฒนาระบบ
PLANNING
PROJECT IDENTIFICATION
• System Request
คือเอกสารที่บรรยายถึงเหตุผลทางธุรกิจที่ต้องสร้ างระบบขึ ้นมา และ
ระบุคณ
ุ ค่าที่คาดหวังว่าจะได้ รับเมื่อระบบแล้ วเสร็ จ ประกอบด้ วย
- Project Sponsor (เจ้ าของโครงการ)
- Business Need (ความจาเป็ น)
- Business Requirement (ความต้ องการ)
- Business Value (คุณค่าทางธุรกิจ)
- Special Issues or Constraints (ประเด็นที่เกี่ยวข้ อง)
PROJECT IDENTIFICATION
• Feasibility Analysis
- Technical Feasibility (สร้ างได้ หรื อไม่?)
- Economic Feasibility (สร้ างแล้ วคุ้มค่าหรื อไม่?)
- Organization Feasibility (ได้ รับการยอมรับจากผู้ใช้ งาน
ระบบหรื อไม่?)
PROJECT MANAGEMENT
• Identifying Project Size (ระบุขนาดของโครงการ)
o Function Point Approach
- Estimate system size (ประเมินขนาดของโปรแกรม)
- Estimate required effort (เปลี่ยนขนาดของ
โปรแกรมเป็ นแรงงานคน/เดือน)
- Estimate time required (ประเมินระยะเวลาที่ใช้ )
PROJECT MANAGEMENT
• Creating and Managing The Work Plan
- work plan แสดงรายการงานแต่ละรายการพร้ อมด้ วยข้ อมูล
สาคัญที่เกี่ยวกับงานนัน้ ๆ เช่น กาหนดการแล้ วเสร็จ ผู้รับผิดชอบ
- Project Manager จะต้ องระบุงานที่ต้องทาและตัดสินใจ
ว่าจะต้ องใช้ เวลาแต่ละงานเท่าไหร่
- Work Plan นาเสนอโดยใช้ Gantt chart หรื อ PERT
chart
PROJECT MANAGEMENT
• Identifying Tasks (ระบุงานที่ต้องทา)
- ใช้ ข้อมูลจากโครงการที่เคยทามาแล้ วว่าต้ องมีงานอะไรบ้ าง
- ใช้ วิธี Structured, top-down approach กาหนด
ในภาพใหญ่ก่อน แล้ วจึงแตกงานในภาพใหญ่ออกเป็ นงานย่อย
เรี ยกวิธีนี ้ว่า Work breakdown structure (WBS)
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
PROJECT MANAGEMENT
• PERT (Program Evaluation and Review Technique)
- เป็ นวิธีที่ดีที่สดุ ในการแสดงการขึ ้นต่อกันของงาน
- สามารถระบุเส้ นทางวิกฤติ (critical path method)ได้ (คือ
เส้ นทางงานที่ไม่อาจล่าช้ าได้ เพราะจะทาให้ โครงการทังหมดล่
้
าช้ า)
- งานที่อยูใ่ นเส้ นทางวิกฤติเรี ยกว่า งานวิกฤติ (critical task)
PROJECT MANAGEMENT
• Staffing Plan (การวางแผนกาลังคน)
- กาหนดว่าจะต้ องใช้ จานวนคนเท่าไหร่ในโครงการ
- กาหนดบทบาทที่ต้องการในโครงการ
- กาหนดว่าใครจะทาหน้ าที่ในบทบาทใด บางครัง้ หนึง่ คนอาจจะ
ได้ รับมากกว่าหนึง่ บทบาท
REQUIREMENT ANALYSIS
• คาจากัดความของ Requirement
คือคาบรรยายที่เกี่ยวกับสิง่ ที่ระบบจะต้ องทาหรื อคุณสมบัติที่ระบบ
จะต้ องมี ประกอบด้ วย
- Functional Requirement (หน้ าที่)
- Nonfunctional Requirement (คุณสมบัติ)
REQUIREMENT ANALYSIS
• Requirement Analysis Strategies
ขันตอนพื
้
้นฐานของ requirement analysis แบ่งออกเป็ น 3
ขันตอนคื
้
อ
1. ทาความเข้ าใจกับ as-is system
2. ระบุจดุ ที่ต้องแก้ ไขปรับปรุง
3. สร้ าง requirement สาหรับ to-be system
REQUIREMENT ANALYSIS
• Requirement Analysis Strategies
Strategy (กลยุทธ์) ที่ใช้ ในการวิเคราะห์ requierment
มีอยู่ 3 วิธี
1. Business process automation
2. Business process improvement
3. Business process reengineering
REQUIREMENT ANALYSIS
• เทคนิคในการรวบรวม Requirements
- Interviews (การสัมภาษณ์)
- Joint Application Development (JAD)
จัดให้ มีการประชุมร่วมระหว่าง ทีมพัฒนาระบบ ผู้ใช้ ระบบ
และผู้บริหารที่มีอานาจในการตัดสินใจ
- Questionnaires (สร้ างแบบสอบถาม)
- Observation (การสังเกตุการณ์)
ANALYSIS
Analysis Modeling
•
Functional Models
- Activity Diagrams
- Use Case Diagrams
• Structural Models
- CRC cards
- Class Diagrams
- Object Diagrams
• Behavioral Models
- Sequence Diagrams
- Communication Diagrams
- Behavioral State Machines
- CRUD matrix
Use Case Diagrams
•
•
•
•
•
•
เป็ น Functional Model
ใช้ เพื่ออธิบาย Business Function (หน้ าที่ทางธุรกิจ) ของ
ระบบ ทังระบบที
้
่ใช้ งานอยู่ (as is system) และระบบที่กาลังจะ
พัฒนาขึ ้นมาใหม่ (to be system)
แต่ละ Use Case จะใช้ เพื่อบอกหน้ าที่เพียงหนึ่งหน้ าที่เท่านัน้
ใช้ แสดงถึงมุมมองภายนอก (External View) ของหน้ าที่ทาง
ธุรกิจ
เป็ น Logical Models เพื่อใช้ บอกกิจกรรมทางธุรกิจโดยไม่แสดงถึง
รายละเอียดของกิจกรรมใน Use Case ว่ามีกระบวนการอย่างไร
การตังชื
้ ่อ Use Case จะต้ องเป็ น Verb-Noun (กิริยานาม)
Use Case Modeling : Core Elements
Construct Description
use case
actor
A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with
actors of the system.
A coherent set of roles that users
of use cases play when interacting
with these use cases.
Syntax
UseCaseName
ActorName
system
boundary
Represents the boundary between
the physical system and the actors
who interact with the physical
system.
Object-Oriented Technology
Use Case Modeling : Core Relationships
Construct
Description
The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
A relationship from an extension use
extend
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.
Syntax
association
Object-Oriented Technology
<<extend>>
Use Case Modeling : Core Relationships (cont’d)
Construct
Description
include
An relationship from a base use case
to an inclusion use case, specifying
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.
Object-Oriented Technology
Syntax
<<include>>
Use Case Diagrams
• Use Case มีความสัมพันธ์อยู่ 4 ประเภท
1. Association
- แสดงการสื่อสารระหว่าง Use Case กับ Actor
- ไม่มีหวั ลูกศรที่ปลายเส้ น แสดงถึงการสื่อสารสองทาง
2. Extend
- ใช้ แสดงถึงส่วนขยายจากหน้ าที่ปกติของ Use Case
ซึง่ เกิดขึ ้นโดยมีเงื่อนไข (optional)
Use Case Diagrams
• Use Case มีความสัมพันธ์อยู่ 4 ประเภท
3. Include
-ใช้ แสดงถึงการรวมหน้ าที่งานอื่นมาไว้ ใน Use Case
- ใช้ เพื่อลดความซับซ้ อนของ Use Case ที่มีขนาดใหญ่
- ใช้ เพื่อให้ สามารถใช้ บาง Use Case ร่วมกับ Use Case
อื่น ๆ ได้ หรื อสามารถนา Use Case นันกลั
้ บมาใช้ ใหม่ได้
4. Generalization
- ใช้ เพื่อสนับสนุนการทางานแบบสืบทอด (inheritance)
Use Case Diagrams
Actors
• Actors สามารถอธิบายโดยใช้ Specialization Relationship
specialization
relationship
Customer
ATM Customer
Cashier Customer
• อาจพิจารณา Actors เป็ นคลาส ใน UML เนื่องจากมีrelationships
เช่ นเดียวกับที่คลาสมี
Object-Oriented Technology
Use Case Descriptions
•
•
•
•
ใช้ อธิบายถึงรายละเอียดของ Use Case Diagram
คาอธิบายต้ องสามารถเข้ าใจได้ ง่าย
ต้ องเขียนให้ อยูใ่ นลักษณะ SVPDI form (ประธาน กิริยา กรรม)
ประกอบด้ วยสามส่วนใหญ่ ๆ คือ
1. Overview Information
2. Relationship
3. Flow of events
Use Case Descriptions
• Overview Information
ให้ รายละเอียดความเป็ นมาที่เกี่ยวกับ Use Case
• Relationships
ใช้ อธิบายความสัมพันธ์ระหว่าง Use Case
• Flow of Events
ใช้ อธิบายถึงกระบวนการต่าง ๆ ที่เกิดขึ ้นใน Use Case
- Normal Flows
- Subflows
- Exceptional Flows
Use Case Descriptions
Activity Diagrams
• ใช้ เพื่ออธิบายกระบวนการที่เกิดขึ ้นใน Use Case
• เป็ น Functional Model (บอกหน้ าที่ทางธุรกิจ)
• เป็ น Logical Model (ไม่ลงรายละเอียดทางเทคนิค)
Activity Diagrams
Class Diagrams
• ใช้ อธิบายโครงสร้ างของข้ อมูลที่ใช้ สนับสนุนกระบวนการทางธุรกิจ
• เป็ น Structural Models
• ประกอบด้ วย
- Attributes (คุณสมบัติ)
- Operations (การกระทา)
• แบ่งออกเป็ นสองประเภท
- Concrete (ใช้ เพื่อสร้ าง Object)
- Abstract (ใช้ เพื่อเป็ นแม่แบบให้ Class อื่น ๆ)
• ชื่อของ Class ต้ องเป็ น Noun (คานาม)
Class Diagrams
• ความสัมพันธ์สามประเภทของ Class
1. Generalization
A-kind-of (เป็ นประเภทหนึง่ ของ)
2. Aggregation
A-part-of (เป็ นส่วนหนึง่ ของ)
3. Association
เกี่ยวข้ องกับ
Class Diagrams
• Generalization (a-kind-of) เป็ นประเภทหนึง่ ของ
Class Diagrams
• Aggregation (a-part-of) เป็ นส่วนหนึง่ ของ
Class Diagrams
• Association (เกี่ยวข้ องกับ)
Class Diagrams
• Responsibilities and Collaborations
Responsibilities (ความรับผิดชอบ) แบ่งออกเป็ นสองชนิดคือ
- Knowing (Attributes)
- Doing (Operations)
Collaboration (ความร่วมมือ)
- Client-Server-Contract (การให้ บริ การและการรับบริ การ)
Class Diagrams
• CRC Card (Class Responsibility and Collaboration)
ใช้ เพื่อบอกถึงรายละเอียดของ
o Responsibility
- Attributes (คุณสมบัต)ิ
- Operations (การกระทา)
o Collaboration
- Clients (เป็ นผู้ขอรับบริ การ)
- Servers (เป็ นผู้ให้ บริ การ)
Class Diagrams
• CRC Card (Class Responsibility and Collaboration)
Class Diagrams
• ส่วนประกอบของ Class
- Class Name
- Attributes
- Operations
Class Diagrams
• ส่วนประกอบของ Class
- Class Name
- Attributes
- Operations
• Class Visibility (การเข้ าถึง Class)
+ Public (มองเห็นได้ จาก Class อื่น)
- Private (ไม่สามารถมองเห็นได้ จาก Class อื่น)
# Protected (มองเห็นได้ จากเฉพาะ Subclass)
Class Diagrams
• ส่วนประกอบของ Class
- Composition
เป็ นส่วนประกอบที่ไม่สามารถแยกออกมาได้
- Aggregation
เป็ นส่วนประกอบที่สามารถแยกออกมาได้
Class Diagrams
•
Class Multiplicity (จานวนของความสัมพันธ์)
1
หนึง่
0..*
ศูนย์ถงึ หลาย
1..*
หนึง่ ถึงหลาย
0..1
ศูนย์ถงึ หนึง่
2..4
สองถึงสี่
1..3,5
หนึง่ ถึงสาม หรื อห้ า
Class Diagrams
Interaction Diagrams
• ใช้ เพื่อบอกกระบวนการทางานภายในของระบบซึง่ สนับสนุนกระบวนการทาง
ธุรกิจขององค์กร
• เป็ น Behavioral Models
• ประกอบด้ วย Diagram ดังต่อไปนี ้
- Sequence Diagram
- Communication Diagram
Interaction Diagrams
• Sequence Diagram
- ใช้ แสดงถึง Object ที่ประกอบอยูใ่ น Use Case
- ใช้ แสดงถึง Message (ข้ อมูล) ที่รับส่งระหว่าง Object
- จะแสดงในภาพรวมการทางานของ Use Case หรื อแสดงเฉพาะ
Scenario (กรณีเหตุการณ์) หนึง่ ก็ได้
Interaction Diagrams
• ส่วนประกอบของ Sequence Diagram
- Actor
- Object
- Lifeline
- Execution
Occurrence
- Message
- Guard Condition
Interaction Diagrams
• Communication Diagrams
- ใช้ แสดงถึงภาพรวมของ message ที่รับส่งระหว่าง object โดยไม่สนใจ
ในเรื่ องลาดับของเวลาเหมือน sequence diagram
Interaction Diagrams
• ส่วนประกอบของ Communication Diagrams
- Actor
- Object
- Association
- Message
- Guard Condition
Behavioral Sate Machine Diagrams
• เป็ น Model ที่ใช้ แสดงสถานะที่เปลี่ยนแปลงไปเมื่อ Object หนึง่ ผ่าน
การตอบสนองต่อเหตุการณ์ตา่ ง ๆ ที่เกิดขึ ้นในวงจรชีวิตของ Object
• State (สถานะ) เป็ นชุดของค่าข้ อมูลใน Attribute ที่ใช้ ระบุสถานะของ
Object หนึง่ ณ ช่วงเวลาใดช่วงเวลาหนึง่ ตามเงื่อนไขที่ถกู กาหนดไว้
Behavioral Sate Machine Diagrams
• องค์ประกอบของ State Machine Diagrams
- State
- Initial State
- Final State
- Event
- Transition
CRUD Analysis
• เป็ นเทคนิคในการวิเคราะห์หาความสัมพันธ์ระหว่าง Object
• ใช้ ตารางเพื่อจับคูค่ วามสัมพันธ์ระหว่าง Object
C : Create
R : Read
U : Update
D : Delete
Receptionist PatientList
Receptionist
PatientList
Patient
RU
Patient
CRUD
R
DESIGN
System Design
• Class and Method Design
ออกแบบ class และ method
• Database Design
ออกแบบฐานข้ อมูล
• User Interface Design
ออกแบบส่วนติดต่อกับผู้ใช้ ระบบ
• Architecture
ออกแบบสถาปั ตยกรรมที่รองรับระบบ
System Design
Class and Method Design
ออกแบบ class และ method โดยใช้ method specification ซึง่
ประกอบด้ วย
- General Information ข้ อมูลทัว่ ไป
- Events เหตุการณ์ที่ทาให้ เกิดการใช้ งาน method
- Message Passing ข้ อมูลที่สง่ ผ่านระหว่าง method
- Algorithm Specification วิธีการทางานของ method
System Design
Database Design การออกแบบฐานข้ อมูล
Mapping Problem-Domain Objects To ObjectPersistence Formats การจับคู่ object กับ ตารางในฐานข้ อมูลมีสองวิธี
1. Mapping Problem-Domain Objects to
an OODBMS Format จับคูห่ นึง่ object ต่อหนึง่ ตาราง
2. Mapping Problem Domain Objects to
and ORDBMS Format จับคูโ่ ดยต้ องดาเนินการตามกฎเกณฑ์
ของระบบฐานข้ อมูลเชิงสัมพันธ์ (RDBMS)
System Design
User Interface Design การออกแบบส่วนติดต่อกับผู้ใช้
User Interface Design Process
กระบวนการในการออกแบบประกอบด้ วย
- Use Scenario Development การจาลองสถานการณ์
- Interface Structure Design ออกแบบโครงสร้ างของส่วนติดต่อ
กับผู้ใช้
- Interface Standard Design วางมาตรฐานของการออกแบบ
- Interface Design Prototyping สร้ างตัวแบบของส่วนติดต่อ
- Navigation Design ออกแบบส่วนนาทางผู้ใช้
- Input Design ออกแบบส่วนป้อนข้ อมูล
System Design
Architecture Design การออกแบบสถาปั ตยกรรม
- Server-Based Architecture
เช่นระบบ mainframe
- Client-Server-Architecture
เช่นระบบ LAN
- Client-Server-Tiers
เช่นระบบ web application
System Design
Infrastructure Design
- Deployment Diagram
Deployment diagrams ถูกใช้ เพื่อแสดงถึงความสัมพันธ์ระหว่าง
ส่วนประกอบที่เป็ น Hardware ต่าง ๆ ซึง่ เป็ ฯโครงสร้ างทางกายภาพของระบบ
IMPLEMENTATION
Managing Programming
- Assigning Programmers
มอบหมายงานให้ กบั programmers โดยแบ่งเป็ นโมดูล ซึง่ แต่โมดูล
ควรจะเป็ นโมดูลที่ทางานเป็ นอิสระต่อกันไม่มีการทางานที่ต้องขึ ้นต่อกัน
- Coordinating Activities
ประสานการทางานและกิจกรรมต่าง ๆ อาจใช้ วิธีจดั ประชุมรายสัปดาห์
เพื่อปรึกษาหารื อกันและดูความคืบหน้ าของงาน
- Managing the Schedule
บริหารงานให้ เป็ นไปตามกาหนดการที่ได้ วางไว้ ซึง่ อาจจะมีการปรับปรุ ง
กาหนดการต่าง ๆ ตามความจาเป็ นของสถานการณ์ที่เปลี่ยนไป
Testing
การทดสอบแบ่งออกเป็ น
Unit Tests : ใช้ ทดสอบการทางานของ classes และ methods แบ่งออกเป็ น
- black-box testing : ทดสอบ class ว่าทางานได้ ถกู ต้ องตามที่กาหนด
specification ไว้ ใน CRC cards หรื อไม่
- white-box texting : ทดสอบ method ในแต่ละ class ว่าทางานได้
ถูกต้ องตามที่กาหนดไว้ ใน method specification หรื อไม่
Integration Tests : ใช้ ทดสอบการทางานร่วมกันของกลุม่ classes
System Tests : ใช้ ทดสอบการทางานร่วมกันของ classes ทังหมด
้
Acceptance Tests : ทดสอบโดย user เพื่อดูว่าระบบทางานได้ ตรงตามความต้ องการ
ทางธุรกิจที่ทาให้ ต้องสร้ างระบบขึ ้นมาแบ่งออกเป็ น
- alpha testing : ทดสอบโดยใช้ ข้อมูลสมมติ
- beta testing : ทดสอบโดยใช้ ข้อมูลจริ ง
Development Documentation
Three Types of Documentation
- Reference Documents
ใช้ เมื่อ user ต้ องการเรี ยนรู้วา่ จะใช้ งาน function ใด function หนึง่
ในระบบได้ อย่างไร เช่น แก้ ไขข้ อมูลในช่อง field หรื อเพิ่ม record ใหม่
- Procedures Manuals
ใช้ อธิบายว่าจะดาเนินงานทางธุรกิจได้ อย่างไร เช่น พิมพ์รายงานประจาเดือน
- Tutorials
ใช้ สอนการใช้ งานส่วนประกอบหลักของระบบ
Conversion
Conversion เป็ นกระบวนการทางเทคนิคในการแทนที่ระบบเดิมด้ วยระบบ
ใหม่ โดยต้ องมีการวางแผนกระบวนการหลักสามขันตอน
้
ก่อนที่จะเริ่มดาเนินการ
ซึง่ ทังสามขั
้
นตอนประกอบด้
้
วย
- Install Hardware
- Install Software
- Convert Data
Conversion
Conversion Style
Conversion style เป็ นวิธีการซึง่ user จะถูกสลับการใช้ งานจากระบบ
เก่ามายังระบบใหม่ โดยมีวิธีที่แตกต่างกันโดยมูลฐานอยูส่ องวิธี คือ
- Direct Conversion
- Parallel Conversion
Conversion
Conversion Style
Direct Conversion
วิธี direct conversion (บางครัง้ ก็เรี ยกว่า cold turkey, big bang
หรื อ abrupt cutover) ระบบเก่าจะถูกแทนที่โดยระบบใหม่ทนั ที
วิธีนี ้เป็ นวิธีที่เรี ยบง่ายและตรงไปตรงมา แต่ก็เป็ นวิธีที่มีความเสี่ยงสูง เพราะว่า
อาจจะมีปัญหาต่าง ๆ ของระบบใหม่ที่หลุดรอดจากการตรวจสอบเกิดขึ ้นได้ ซึ่งอาจจะ
ก่อให้ เกิดความเสียหายอย่างร้ ายแรงต่อองค์กร
Conversion
Conversion Styles
Parallel Conversion
โดยวิธี parallel conversion ระบบใหม่จะถูกใช้ งานคูข่ นานไปกับระบบ
เก่าพร้ อม ๆ กัน โดย user จะต้ องป้อนข้ อมูลทังระบบเก่
้
าและระบบใหม่ แล้ วทา
การเปรี ยบเทียบผลลัพธ์ที่ได้ ว่าระบบใหม่ทางานได้ ถกู ต้ องหรื อไม่
หลังจากผ่านไปชัว่ ระยะเวลาหนึง่ ประมาณหนึง่ หรื อสองเดือน ถ้ าระบบใหม่ทา
งานได้ ถกู ต้ องสมบูรณ์ ระบบเก่าก็จะถูกปิ ดระบบและใช้ งานแต่เพียงระบบใหม่เพียง
ระบบเดียว
วิธีนี ้ช่วยลดความเสี่ยงในการใช้ งานระบบใหม่ ถ้ าเกิดปั ญหาในระบบใหม่ ระบบใหม่ก็จะถูกปิ ด
และนาไปแก้ ไขปั ญหาที่เกิดขึ ้น เมื่อแก้ ปัญหาเสร็จแล้ วจึงนากลับใช้ งานแบบคู่ขนานอีกครัง้
ข้ อเสียของวิธีนี ้ก็คือ มีภาระค่าใช้ จ่ายในการทางานถึงสองระบบพร้ อม ๆ กัน ในงานเรื่ อง
เดียวกัน
Conversion
Conversion Location
Conversion location ก็คือหน่วยงานต่าง ๆ ขององค์กรที่จะถูกเปลี่ยนไปใช้
ระบบใหม่ ณ เวลาหนึง่ เมื่อการ conversion เกิดขึ ้น
บ่อยครัง้ ที่หน่วยงานขององค์กรตังอยู
้ ่ในต่างสานักงานกัน แต่ในกรณีอื่นแล้ ว
Location จะหมายถึงหน่วยงานในองค์กรที่ตงอยู
ั ้ ่ในพื ้นที่ ที่ต่างกันในสานักงาน
แห่งเดียวกัน
มีวิธีการที่แตกต่างกันโดยมูลฐานอยู่อย่างน้ อยสามวิธีในการเปลี่ยนหน่วยงานที่ตงอยู
ั้ ่
ในพื ้นต่าง ๆ ขององค์กรไปใช้ งานระบบใหม่ ดังต่อไปนี ้
- Pilot Conversion
- Phased Conversion
- Simultaneous Conversion
Conversion
Conversion Location
Pilot Conversion
โดยวิธี pilot conversion หน่วยงานใดหน่วยงานหนึ่งหรื อกลุม่ งาน
(workgroup) ในพื ้นที่งานขององค์กร จะถูกเลือกให้ ถกู converted เป็ นอันดับแรก
โดยเป็ นส่วนหนึ่งของการทดสอบแบบนาร่อง (pilot test)
พื ้นที่งานที่ถกู เลือกจะถูกเปลี่ยนให้ ไปใช้ งานระบบใหม่ ไม่ว่าจะโดยวิธี direct
หรื อ parallel ถ้ าการทดสอบนาร่องผ่านไปได้ ด้วยดี ระบบก็ถกู นาไปติดตังในพื
้ ้น
ที่งานขององค์ที่เหลืออยู่
ข้ อดีของวิธีนี ้ก็คือเพิ่มการทดสอบอีกระดับหนึง่ ก่อนที่ระบบจะถูกใช้ งานจริ งทัว่ ทังองค์
้ กร
ข้ อเสียก็คือต้ องใช้ เวลามากขึ ้นก่อนที่ระบบจะถูกใช้ งานจริ งทัว่ องค์กร อีกทังมั
้ นยัง
หมายถึงว่า หน่วยงานที่อยู่ในพื ้นที่งานทีต่ ่างกัน กาลังใช้ งานระบบที่แตกต่างกันซึง่ ทาให้ เกิด
ความยุ่งยากในการแลกเปลี่ยนข้ อมูลระหว่างหน่วยงานต่าง ๆ
Conversion
Conversion Location
Phased Conversion
โดยวิธี phased conversion ระบบจะถูกติดตังตามล
้
าดับที่พื ้นที่งานที่
ต่างกัน พื ้นที่งานกลุม่ แรกจะถูกเปลี่ยนระบบก่อน จากนันจึ
้ งเป็ นกลุม่ ที่สองและกลุม่
ที่สามและต่อไปเรื่ อย ๆ จนกว่าครบทังองค์
้ กร ถ้ าเกิดปั ญหา ปั ญหาต่าง ๆ จะถูกตรวจ
พบก่อนที่จะมีผลกระทบทัว่ ทังองค์
้ กร แต่ถ้าไม่มีปัญหาระบบก็จะถูกติดตังไปที
้ ละ
พื ้นที่งานไปเรื่ อย ๆ
วิธีนี ้มีทงข้
ั ้ อดีและข้ อเสียเหมือนกับวิธี pilot conversion แต่ในขณะเดียว
กันวิธีนี ้ก็ใช้ บคุ ลากรเพื่อการทา conversion น้ อยกว่าการทา conversion
ทังองค์
้ กรพร้ อม ๆ กัน
Conversion
Conversion Location
Simultaneous Conversion
Simultaneous conversion หมายถึงทุก ๆ พื ้นในองค์กร ถูก
converted พร้ อม ๆ กัน ระบบจะถูกติดตังและพร้
้
อมใช้ งานในทุก ๆ พื ้นที่งาน
เมื่อถึงเวลาที่กาหนดไว้ user ก็จะเริ่มใช้ ระบบใหม่ วิธีนี ้มักจะใช้ กบั วิธี
direct conversion แต่ก็สามารถใช้ กบั วิธี parallel conversion ได้
เช่นกัน
ข้ อเสียคือต้ องใช้ บคุ ลากรจานวนมากเพื่อดาเนินการ conversion และ
ฝึ กอบรม users ทัว่ ทังองค์
้ กร
Conversion
Conversion Modules
ไม่เสมอไปที่ระบบจะถูกติดตังพร้
้ อมกันทังระบบ
้
ระบบอาจจะถูกแบ่งออกเป็ น
Modules ย่อย เพื่อติดตังก็
้ ได้ โดยเราแบ่งวิธีการติดตังส่
้ วนต่าง ๆ ของระบบ
ได้ เป็ นสองวิธีคือ
- Whole-System Conversion ติดตังพร้
้ อม ๆ กันทังระบบในเวลา
้
เดียวกัน ซึง่ เป็ นวิธีที่พบเห็นทัว่ ไป แต่ถ้าระบบมีขนาดใหญ่และซับซ้ อนมาก user
อาจจะประสบความยากลาบากในการเรี ยนรู้การใช้ งานทังระบบขั
้
นตอนการ
้
conversion
- Modular Conversion คือการเลือกติดตังครั
้ ง้ ละหนึง่ module
ซึง่ ความยากง่ายของวิธีนี ้ก็ขึ ้นอยูก่ บั ระดับความเกี่ยวพันของ module ต่าง ๆ ใน
ระบบ ข้ อดีของวิธีนี ้ก็คือช่วยลดปริ มาณการฝึ กอบรม user เพื่อเริ่ มใช้ ระบบใหม่
แต่ข้อเสียก็คือต้ องใช้ เวลามากขึ ้นในการติดตังระบบทั
้
งระบบให้
้
เสร็จสมบูรณ์
Conversion
Selecting the Appropriate Conversion Strategy
มีปัจจัยที่ต้องคานึงอยู่สามประการ ในการเลือกกลยุทธ์การ conversion ที่เหมาะสม
ประกอบด้ วย
- Risk (ความเสี่ยง)
ระบบที่ได้ รับการทดสอบมาดีมีแนวโน้ มที่จะมีความเสี่ยงน้ อย สามารถเลือกใช้ วิธี
direct conversion และวิธี simultaneous conversion ได้ แต่ถ้าไม่ใช่
ก็ต้องใช้ วิธีอื่นๆ ที่กล่าวมาข้ างต้ นซึง่ สามารถช่วยลดความเสี่ยง
- Cost (ค่าใช้ จ่าย)
ค่าใช้ จ่ายของวิธีการ conversion แต่ละวิธีไม่เท่ากัน วิธีที่สามารถลดความเสี่ยง
มีค่าใช้ จ่ายสูงกว่าวิธีที่มีความเสี่ยงสูง
- Time (เวลา)
วิธีที่มีความเสี่ยงสูงจะใช้ เวลาในการ conversion น้ อยกว่าวิธีที่ช่วยลดความเสี่ยง