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 Planning (วางแผน)o Analysis (ว!เคราะห#)o Design (ออกแบบ) o Implementation (จัดสร�าง)

แต้�ละ phase จัะประกอบด�วยช่�ดของข/นต้อนซึ่1�ง พั1�งพัาเทคน!คต้�าง ๆ

เพั,�อผล!ต้ส!�งท��สามารถส�งมอบได� (deliverable) ซึ่1�งจัะ ถ3กน*าไปเป(น input ของ phase ต้�อไป

SDLC

• Planning เป(นกระบวนการท*าความเข�าใจัว�า ท*าไมถ1งต้�องจัดท*าระบบและ

ก*าหนดผ3�ร บผ!ดช่อบในการจัดท*าระบบ แบ�งออกเป(นสองข/นต้อน1. ระหว�างเร!�มต้�นโครงการ

o ม�การจัดท*า System Request o ม�การต้ดส!นใจัว�าควรจัะจัดสร�างระบบหร,อไม� (Feasibility Analysis)

- Technical Feasibility (ในทางเทคน!คเป(นไปได�หร,อไม�?) - Economic Feasibility (ให�ค�ณค�าทางธุ�รก!จัหร,อไม�?) - Organizational Feasibility (สร�างแล�วม�คนใช่�หร,อไม�?)

ส!�งท��ส�งมอบในข/นต้อนน�/ก4ค,อ System Requet, Feasibility Analysis

SDLC

• Planning2. เม,�อระบบได�รบการอน�มต้!ให�จัดสร�างแล�ว เข�าส3�ข /นต้อนการบร!หารจัดการโครงการ - จัดท*า (work plan) - จัดต้/งท�มงาน (staffing plan) - เล,อกเทคน!คท��จัะใช่� - ก*ากบด3แลโครงการต้ลอดกระบวนการ SDLC

ส!�งท��สามารถส�งมอบได� ท��ได�จัากข/นต้อนน�/ก4ค,อProject Plan

SDLC

• Analysisเป(นกระบวนการก*าหนดในข/นรายละเอ�ยดของโครงการo ใครจัะเป(นผ3�ใช่�ระบบ?o ระบบสามารถท*าอะไรได�บ�าง?o ระบบถ3กใช่�ท��ไหนo ระบบจัะถ3กใช่�เม,�อไหร�?

SDLC

• Analysisแบ�งออกเป(นสามข/นต้อน1. Analysis Strategy ว!เคราะห#ว�าระบบท��ม�อย3�เด!ม (as is) เป(น

อย�างไร และระบบท��จัะจัดท*าข1/นใหม� (to be) ควรจัะเป(นอย�างไร2. Requirement Gathering รวบรวมข�อม3ล เช่�น การใช่�แบบ สอบถามหร,อการสมภาษณ#3. System Proposal จัดท*ารายงานซึ่1�งประกอบด�วย แนวค!ดของ

ระบบ แผนด*าเน!นการ รวมถ1งการว!เคราะห#ระบบด�วยโมเดลต้�าง ๆ

ส!�งท��สามารถส�งมอบได�จัากข/นต้อนน�/ก4ค,อ System Proposal

SDLC

• Design เป(นการต้ดส!นใจัว�าระบบจัะท*างานอย�างไร ท/งในแง�ม�มของ

ซึ่อฟท#แวร#และ ฮาร#ดแวร# ฐานข�อม3ลและระบบ สาธุารณ3ปโภคเคร,อข�ายท��จั*าเป(นต้�อการท*างานของระบบ

ประกอบด�วย 4 ข/นต้อนค,อo Design Strategy เล,อกกลย�ทธุ#ในการพัฒนาระบบo Architecture Design เล,อกสถาป:ต้ยกรรมท��จัะใช่�รองรบระบบo Database and File Specification ก*าหนดว�าข�อม3ลอะไรท��จัะ ถ3กจัดเก4บและจัดเก4บไว�ท��ไหนo Program Design ก*าหนดว�าโปรแกรมจัะท*าอะไรได�บ�าง

SDLC

• Designส!�งท��ได�จัากข/นต้อนการออกแบบระบบค,อo Architecture Design (ออกแบบสถาป:ต้ยกรรมระบบ)o Interface Design (ออกแบบการต้!ดต้�อระหว�างระบบกบผ3�ใช่�)

o Database Design (ออกแบบฐานข�อม3ล)o Program Design (ออกแบบโปรแกรม)

ซึ่1�งรวมแล�วเร�ยกว�า System Specification ซึ่1�งเป(นส!�งท�� สามารถส�งมอบได� ท��ได�จัากข/นต้อนน�/

SDLC

• Implementation ด*าเน!นการจัดสร�างระบบ แบ�งออกเป(นสามข/นต้อน

1. จัดสร�างระบบ 2. ต้!ดต้/งระบบ 3. จัดท*า Support Plan (แผนสนบสน�นท��บอกถ1งผลการท*างาน ของระบบ ข�อด� ข�อบกพัร�องและข�อแนะน*าต้�างๆ)

SDLC

• System Development Methodologies ( ว!ธุ�การท��ใช่�ใน SDLC) ว!ธุ�การใช่�ท��ใช่�ใน SDLC แบ�งออกเป(นประเภทใหญ� ๆ ได�สามประเภท

o Structured Design - Waterfall Development - Parallel Developmento Rapid Application Development (RAD) - Phased Development - Prototyping - Throwaway Prototypingo Agile Development - Extreme Programming

SDLC

• Structured Design แบ�งออกเป(นสองว!ธุ� 1. Waterfall Development 2. Parallel Development

SDLC

• Structured Designo Waterfall Development เคล,�อนท��ไปข�างหน�าจัากบนลงล�างเหม,อนน*/าต้ก

SDLC

• Structured Designo Waterfall Development ข�อด� - ใช่�เวลาในการออกแบบนานมากก�อนท��จัะเร!�มจัดท*าระบบ - ม�การเปล��ยนแปลงเก!ดข1/นน�อยในระหว�างการพัฒนาระบบ ข�อเส�ย - ต้�องออกแบบให�เสร4จัสมบ3รณ#ก�อนถ1งจัะเร!�มพัฒนาระบบได� - ใช่�เวลาในการส�งมอบระบบนานมาก

SDLC

• Structured Designo Parallel Development (การพัฒนาระบบแบบค3�ขนาน) - เพั,�อลดความล�าช่�าท��เก!ดจัากข/นต้อนการว!เคราะห#ระบบ

ท*าให�การส�งมอบ ระบบล�าช่�า - แบ�งโครงการใหญ�ออกเป(นโครงการย�อยต้ามการจัดล*าดบความส*าคญ แล�วพัฒนาโครงการท��ถ3กย�อยแล�วไปพัร�อม ๆ กน

SDLC

• Structured Designo Parallel Development (การพัฒนาระบบแบบค3�ขนาน) ข�อด� ลดเวลาในการส�งมอบระบบ ข�อเส�ย บางคร/งโครงการย�อยบางโครงการข1/นอย3�กบโครงการ

ย�อยอ,�น ๆ ท*าให� การรวมผลลพัทธุ#ของโครงการต้�าง ๆ เข�าเป(นระบบใหญ�ท*าได�ยากและ ต้�องใช่�ความพัยายามมาก

SDLC

• Rapid Application Development (RAD)- ใช่�เพั,�อแก�ข�อบกพัร�องของ Structured Design ในเร,�องความล�าช่�า

ในการส�งมอบระบบ- ปรบข/นต้อนของ SDLC ให�สามารถส�งมอบบางส�วนของระบบได�เร4วข1/น

- ผ3�ใช่�ระบบสามารถเข�าใจัระบบได�มากข1/นและให�ค*าแนะน*าในการแก�ไข

ปรบปร�งระบบให�ต้รงกบความต้�องการของผ3�ใช่�มากข1/น

SDLC

• Rapid Application Development (RAD) แบ�งออกเป(น 3 ว!ธุ� 1. Phased Development 2. Prototyping 3. Throwing Prototyping

SDLC

• Phased Development แบ�งโครงการออกเป(นช่�ดหร,อ version ซึ่1�งจัะถ3กพัฒนาเร�ยงต้าม ล*าดบความส*าคญจัากมากไปหาน�อย ส!�งท��ส*าคญมากจัะถ3กพัฒนา เป(น version แรก ส�วนท��ม�ความส*าคญน�อยจัะถ3กพัฒนาเป(น ล*าดบต้�อไปต้ามล*าดบความส*าคญ

SDLC

• Phased Development ข�อด� ส�งมอบระบบได�เร4ว

ข�อเส�ย ระบบท��ส�งมอบใน version แรก ๆ ยงไม�สมบ3รณ#

SDLC

• Prototyping ว!เคราะห# ออกแบบ และพัฒนาระบบไปพัร�อม ๆ กน โดยการจัดท*า system prototype หร,อต้วแบบของระบบแบบหยาบ ๆ เพั,�อ ให�ผ3�ใช่�งานระบบและผ3�ท��เก��ยวข�องเห4นระบบท��เป(นร3ปเป(นร�างแล�ว และ สามารถให�ค*าแนะในการจัดท*าระบบให�ต้รงต้ามความต้�องการของ ผ3�ใช่� ซึ่1�งค*าแนะน*าจัะถ3กน*ามา ว!เคราะห# ออกแบบ และพัฒนา เป(น วงจัรซึ่*/าไปเร,�อย ๆ จันกว�าผ3�ใช่�ระบบจัะเห4นช่อบกบต้วแบบส�ดท�าย ซึ่1�งจัะถ3กน*ามาใช่�งานเป(นระบบจัร!งท��ถ,อว�าเสร4จัสมบ3รณ#

SDLC

• Prototyping ข�อด� ผ3�ใช่�ระบบสามารถมองเห4นระบบท��เป(นร3ปเป(นร�างได�อย�างรวดเร4ว

ข�อเส�ย อาจัขาดการว!เคราะห#ระบบท��รอบคอบเพั�ยงพัอ

SDLC

• Throwaway Prototyping - คล�าย ๆ กบว!ธุ� Prototyping แต้�ใช่�ในจั�ดประสงค#ท��ต้�างกน - ใช่�เพั,�อน*าเสนอบางแง�ม�มหร,อบางส�วนของระบบท��ม�ความซึ่บซึ่�อน มาก ๆ เพั,�อให�ผ3�ใช่�ระบบสามารถมองเห4นระบบท��เป(นร3ปเป(นร�าง ในท�ก ๆ แง�ม�ม และเข�าใจัในระบบได�ด�ย!�งข1/น - เป(นต้วอย�างระบบท��ไม�ม�ฟ:งก#ช่นการท*างานรองรบ ไม�สามารถ น*าไปใช่�งานได�จัร!ง - เหม,อนใช่�แล�วจัะถ3กโยนท!/งไป ไม�ถ3กน*ามาใช่�พัฒนาต้�อเหม,อน Prototyping

SDLC

• Throwaway Prototyping ข�อด� แก�ป:ญหาท��ซึ่บซึ่�อนได�ด� ช่�วยให�ว!เคราะห#ระบบได�ด�ข1/น

ข�อเส�ย ใช่�เวลามากข1/นในการส�งมอบระบบ

SDLC

• Agile Development - ลดข/นต้อนของการออกแบบและเอกสารใน

กระบวนการ SDLC - เน�นท��กระบวนการพัฒนาระบบ ประกอบด�วยหลายว!ธุ�เช่�น - Extreme Programming (XP) - Scrum - Dynamic System Development Method (DSDM)

SDLC

• Extreme Programming (XP) ประกอบด�วยการให�ค�ณค�าความส*าคญส��ด�านค,อ - Communication (การส,�อสาร) ม�การส,�อสารระหว�างท�มพัฒนาระบบและผ3�ท��เก��ยวข�องต้ลอดเวลา - Simplicity (ความเร�ยบง�าย) เข�ยนโปรแกรมให�เร�ยบง�าย - Feedback (การป;อนกลบ) ให�ผลลพัธุ#ต้อบกลบผ3�ใช่�งานระบบอย�างรวดเร4ว - Courage (ความกล�าหาญ) ไม�กลวการเปล��ยนแปลงใหม� ๆ

SDLC

• Extreme Programming (XP) - ข�อด� เหมาะส*าหรบโครงการเล4ก ๆ ท��ต้�องการความรวดเร4วในการพัฒนาระบบ

- ข�อเส�ย ม�โอกาสส*าเร4จัน�อยลง เม,�อน*าไปใช่�ในโครงการขนาดใหญ�

SDLC

• การเล,อกว!ธุ�พัฒนาระบบท��เหมาะสม o ถ�าความต้�องการของผ3�ใช่�งานระบบไม�ช่ดเจัน

เล,อกใช่�ว!ธุ� RAD (Phased , Prototyping and Throwaway Prototyping)

o ถ�าผ3�พัฒนาระบบไม�ค��นเคยกบเทคโนโลย� เล,อกใช่�ว!ธุ� Throwaway Prototypingo ถ�าระบบม�ความซึ่บซึ่�อนมาก ๆ เล,อกใช่�ว!ธุ� Throwaway Prototyping

SDLC

• การเล,อกว!ธุ�พัฒนาระบบท��เหมาะสม o ถ�าต้�องการระบบท��ม�ความน�าเช่,�อถ,อส3ง เล,อกใช่�ว!ธุ� Throwaway Prototypingo ถ�าต้�องการส�งมอบระบบอย�างรวดเร4ว เล,อกใช่�ว!ธุ� Phased Development and Prototypingo ถ�าต้�องการส�งมอบงานให�ต้รงต้ามก*าหนด เล,อกใช่�ว!ธุ� Phased Development

Object-Oriented Systems Analysis And Design (OOSAD)

การว!เคราะห#และออกแบบระบบด�วย OOSAD ม�ความเก��ยวข�องกบ

ว!ธุ� Phased Development ใน RAD ในการน*าป:ญหามาแต้ก ออกเป(นประเด4นย�อย ๆ เพั,�อง�ายต้�อการว!เคราะห#

ประกอบด�วยองค#ประกอบสามส�วนค,อ 1. Use-Case Driven 2. Architecture-Centric 3. Iterative And Incremental


• Use Case Driven - หมายถ1งการใช่� Use Case เป(นเคร,�องม,อหลกในการ

ออกแบบ - Use Case ใช่�อธุ!บายว�า ผ3�ใช่�ระบบต้อบโต้�กบระบบเพั,�อท*า ก!จักรรมบางอย�างได�อย�างไร เช่�น ส�งซึ่,/อส!นค�า จัองท��พักหร,อ ค�นหาข�อม3ล - Use Case ท*าให�การออกแบบระบบเร�ยบง�าย เพัราะแต้�ละ Use Case จัะสนใจัเฉพัาะก!จักรรมใดก!จักรรมหน1�งในระบบ ณ ช่�วงเวลาใดเวลาหน1�งเท�าน/น


• Architecture Centric หมายถ1งสถาป:ต้ยกรรมท��รองรบระบบท��ก*าลงพัฒนาอย3�เป(นต้วก*าหนด ค�ณลกษณะ โครงสร�าง และรายละเอ�ยดต้�าง ๆ ของระบบ ซึ่1�งอย�างน�อยจัะต้�องรองรบสถาป:ต้ยกรรม 3 แบบ ท��แยกออกจัากกนแต้� ม�ความเก��ยวข�องกน ค,อ - Functional View - Structural View - Behavioral View


• Iterative and Incremental หมายถ1งการ เพั!�ม เสร!ม เต้!มแต้�ง ปรบปร�ง และ

การท*าซึ่*/า ต้ลอดวงจัร ช่�ว!ต้ของการพัฒนาระบบ ผ�านกระบวนการ SDLC


• ประโยช่น#ของ OOSAD - แยกระบบใหญ�ท��ม�ความซึ่บซึ่�อนออกเป(นโมด3ลย�อย ๆท�� สามารถจัดการได�ง�าย - น*าโมด3ลย�อยมาใช่�ซึ่*/าได�ในระบบอ,�น - สร�างความเข�าใจัท��ต้รงกนระหว�างท�มพัฒนาและ user เพัราะ object ม�ความเหม,อนกบวต้ถ�ในโลกแห�งความ เป(นจัร!ง

THE UNIFIED PROCESS

• ค,อการน*าเอา UML มาใช่�ในการพัฒนาระบบแบบ Object-

Oriented Analysis and Design (OOSAD)• ประกอบด�วยม!ต้!ของการพัฒนาระบบท��เก��ยวข�อง

กนสองส�วนค,อ - Phases - Workflow

THE UNIFIED PROCESS

THE UNIFIED MODELING LANGUAGE (UML)

• ค,อภาษาท��เป(นท��เข�าใจัร�วมกนส*าหรบการการออกแบบระบบ

แบบ OOSAD • ประกอบด�วยค*าน!ยามและช่�ดของ Diagram ซึ่1�งม�ความสมบ3รณ#

พัอท��จัะใช่�ในการสร�างต้วแบบจัากการว!เคราะห#และออกแบบต้ลอด จันถ1งการพัฒนาระบบ

PLANNING

PROJECT IDENTIFICATION

• System Request ค,อเอกสารท��บรรยายถ1งเหต้�ผลทางธุ�รก!จัท��ต้�องสร�างระบบ

ข1/นมา และ ระบ�ค�ณค�าท��คาดหวงว�าจัะได�รบเม,�อระบบแล�วเสร4จั ประกอบ

ด�วย - Project Sponsor (เจั�าของโครงการ) - Business Need (ความจั*าเป(น) - Business Requirement (ความต้�องการ) - Business Value (ค�ณค�าทางธุ�รก!จั) - Special Issues or Constraints (ประเด4นท��เก��ยวข�อง)

PROJECT IDENTIFICATION

• Feasibility Analysis - Technical Feasibility (สร�างได�หร,อไม�?) - Economic Feasibility (สร�างแล�วค��มค�าหร,อไม�?) - Organization Feasibility (ได�รบการยอมรบจัากผ3�ใช่�งาน ระบบหร,อไม�?)

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 แสดงรายการงานแต้�ละรายการพัร�อมด�วยข�อม3ล ส*าคญท��เก��ยวกบงานน/น ๆ เช่�น ก*าหนดการ

แล�วเสร4จั ผ3�ร บผ!ดช่อบ - Project Manager จัะต้�องระบ�งานท��ต้�องท*าและต้ดส!นใจั ว�าจัะต้�องใช่�เวลาแต้�ละงานเท�าไหร� - Work Plan น*าเสนอโดยใช่� Gantt chart หร,อPERT chart

PROJECT MANAGEMENT

• Identifying Tasks (ระบ�งานท��ต้�องท*า) - ใช่�ข�อม3ลจัากโครงการท��เคยท*ามาแล�วว�าต้�องม�งานอะไรบ�าง - ใช่�ว!ธุ� Structured, top-down approach ก*าหนด ในภาพัใหญ�ก�อน แล�วจั1งแต้กงานในภาพัใหญ�ออกเป(นงานย�อย เร�ยกว!ธุ�น�/ว�า Work breakdown structure (WBS)

PROJECT MANAGEMENT

• PERT (Program Evaluation and Review Technique) - เป(น network analysis technique ซึ่1�งสามารถน*ามาใช่� ในกรณ�ท��เวลาในการท*างานของแต้�ละงานม�ความไม�แน�นอน - PERT ใช่�เวลา 3 ค�าในการประเม!น 1. เวลาท��คาดว�างานจัะเสร4จัเร4วท��ส�ด (optimistic) 2. เวลาท��คาดว�างานจัะเสร4จัโดยท�วไป (most likely) 3. เวลาท��คาดว�างานจัะเสร4จัช่�าท��ส�ด (pressimistic)

ซึ่1�งเวลาท/ง 3 ค�าจัะถ3กน*ามาค*านวณเป(นเวลาเฉล��ยของงานโดยใช่�ส3ต้ร(optimistic estimate + (4xmostlikely) + pressimistic estimate) / 6

PROJECT MANAGEMENT

• PERT (Program Evaluation and Review Technique) - เป(นว!ธุ�ท��ด�ท��ส�ดในการแสดงการข1/นต้�อกนของงาน - สามารถระบ�เส�นทางว!กฤต้! (critical path method) ได� (ค,อ เส�นทางงานท��ไม�อาจัล�าช่�าได�เพัราะจัะท*าให�โครงการท/งหมดล�าช่�า) - งานท��อย3�ในเส�นทางว!กฤต้!เร�ยกว�า งานว!กฤต้!(critical task)

PROJECT MANAGEMENT

• Staffing Plan (การวางแผนก*าลงคน) - ก*าหนดว�าจัะต้�องใช่�จั*านวนคนเท�าไหร�ในโครงการ - ก*าหนดบทบาทท��ต้�องการในโครงการ - ก*าหนดว�าใครจัะท*าหน�าท��ในบทบาทใด บางคร/งหน1�งคนอาจัจัะ ได�รบมากกว�าหน1�งบทบาท

REQUIREMENT ANALYSIS

• ค*าจั*ากดความของ Requirement ค,อค*าบรรยายท��เก��ยวกบส!�งท��ระบบจัะต้�องท*าหร,อค�ณสมบต้!ท��ระบบ จัะต้�องม� ประกอบด�วย - Functional Requirement (หน�าท��) - Nonfunctional Requirement (ค�ณสมบต้!)


• Requirement Analysis Strategies ข/นต้อนพั,/นฐานของ requirement analysis แบ�ง

ออกเป(น 3 ข/นต้อนค,อ 1. ท*าความเข�าใจักบ as-is system 2. ระบ�จั�ดท��ต้�องแก�ไขปรบปร�ง 3. สร�าง requirement ส*าหรบ to-be system


• Requirement Analysis Strategies Strategy (กลย�ทธุ#) ท��ใช่�ในการว!เคราะห#requierment ม�อย3� 3 ว!ธุ� 1. Business process automation 2. Business process improvement 3. Business process reengineering


• เทคน!คในการรวบรวม Requirements - Interviews (การสมภาษณ#) - Joint Application Development (JAD) จัดให�ม�การประช่�มร�วมระหว�าง ท�มพัฒนาระบบ ผ3�ใช่�ระบบ และผ3�บร!หารท��ม�อ*านาจัในการต้ดส!นใจั - 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 (หน�าท��ทางธุ�รก!จั) ของ ระบบ ท/งระบบท��ใช่�งานอย3� (as is system) และระบบท��ก*าลงจัะ พัฒนาข1/นมาใหม� (to be system)• แต้�ละ Use Case จัะใช่�เพั,�อบอกหน�าท��เพั�ยงหน1�งหน�าท��เท�าน/น• ใช่�แสดงถ1งม�มมองภายนอก (External View) ของหน�าท��ทาง ธุ�รก!จั• เป(น Logical Models เพั,�อใช่�บอกก!จักรรมทางธุ�รก!จัโดยไม�แสดงถ1ง รายละเอ�ยดของก!จักรรมใน Use Case ว�าม�กระบวนการอย�างไร• การต้/งช่,�อ Use Case จัะต้�องเป(น Verb-Noun (ก!ร!ยานาม)

Object-Oriented Technology

Use Case Modeling : Core ElementsConstruct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

actor A coherent set of roles that users of use cases play when interacting with these use cases.

system boundary

Represents the boundary between the physical system and the actors who interact with the physical system.

UseCaseNam e

ActorNam e


Construct Description Syntax

association 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.

extend A relationship from an extension use 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.

Use Case Modeling : Core Relationships

<<extend>>


Construct Description Syntax

include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.

Use Case Modeling : Core Relationships (cont’d)

<<include>>

Use Case Diagrams

• Use Case ม�ความสมพันธุ#อย3� 4 ประเภท 1. Association - แสดงการส,�อสารระหว�าง Use Case กบ Actor - ไม�ม�หวล3กศรท��ปลายเส�น แสดงถ1งการส,�อสารสองทาง 2. Extend - ใช่�แสดงถ1งส�วนขยายจัากหน�าท��ปกต้!ของ Use Case ซึ่1�งเก!ดข1/นโดยม�เง,�อนไข (optional)

Use Case Diagrams

• Use Case ม�ความสมพันธุ#อย3� 4 ประเภท 3. Include - ใช่�แสดงถ1งการรวมหน�าท��งานอ,�นมาไว�ใน Use Case - ใช่�เพั,�อลดความซึ่บซึ่�อนของ Use Case ท��ม�ขนาดใหญ� - ใช่�เพั,�อให�สามารถใช่�บาง Use Case ร�วมกบ Use Case อ,�น ๆ ได� หร,อสามารถน*า Use Case น/นกลบมาใช่�ใหม�ได� 4. Generalization - ใช่�เพั,�อสนบสน�นการท*างานแบบส,บทอด (inheritance)

Use Case Diagrams


Actors• Actors สามารถอธิ�บายโดยใช้� Specialization

Relationship

• อาจพิ�จารณา Actors เป็�นคลาส ใน UML เน��องจากม�relationships เช้�นเด�ยวก!บที่��คลาสม�

specialization relationship

Customer

ATM Customer Cashier Customer

Use Case Descriptions

• ใช่�อธุ!บายถ1งรายละเอ�ยดของ Use Case Diagram• ค*าอธุ!บายต้�องสามารถเข�าใจัได�ง�าย• ต้�องเข�ยนให�อย3�ในลกษณะ SVPDI form ( ประธุาน

ก!ร!ยา กรรม)• ประกอบด�วยสามส�วนใหญ� ๆ ค,อ 1. Overview Information 2. Relationship 3. Flow of events


• Overview Information ให�รายละเอ�ยดความเป(นมาท��เก��ยวกบ Use Case

• Relationships ใช่�อธุ!บายความสมพันธุ#ระหว�าง Use Case• Flow of Events ใช่�อธุ!บายถ1งกระบวนการต้�าง ๆ ท��เก!ดข1/นใน Use Case - Normal Flows - Subflows - Exceptional Flows

Activity Diagrams

• ใช่�เพั,�ออธุ!บายกระบวนการท��เก!ดข1/นใน Use Case• เป(น Functional Model (บอกหน�าท��ทางธุ�รก!จั)• เป(น Logical Model (ไม�ลงรายละเอ�ยดทางเทคน!ค)

Activity Diagrams

Class Diagrams

• ใช่�อธุ!บายโครงสร�างของข�อม3ลท��ใช่�สนบสน�นกระบวนการทางธุ�รก!จั

• เป(น Structural Models• ประกอบด�วย - Attributes (ค�ณสมบต้!) - Operations (การกระท*า)• แบ�งออกเป(นสองประเภท - Concrete ( ใช่�เพั,�อสร�าง Object) - Abstract ( ใช่�เพั,�อเป(นแม�แบบให� Class อ,�น ๆ)• ช่,�อของ Class ต้�องเป(น Noun (ค*านาม)

Class Diagrams

• ความสมพันธุ#สามประเภทของ Class 1. Generalization A-kind-of (เป(นประเภทหน1�งของ) 2. Aggregation A-part-of (เป(นส�วนหน1�งของ) 3. Association เก��ยวข�องกบ

Class Diagrams

• Generalization (a-kind-of) เป(นประเภทหน1�งของ

Class Diagrams

• Aggregation (a-part-of) เป(นส�วนหน1�งของ

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)

ใช่�เพั,�อบอกถ1งรายละเอ�ยดของo Responsibility - Attributes (ค�ณสมบต้!)

- Operations (การกระท*า)o Collaboration - Clients (เป(นผ3�ขอรบบร!การ) - Servers (เป(นผ3�ให�บร!การ)

Class Diagrams• CRC Card (Class Responsibility and Collaboration)

Class Diagrams• ส�วนประกอบของ Class

- Class Name - Attributes - Operations

Class Diagrams

• ส�วนประกอบของ Class - Class Name

- Attributes - Operations

• Class Visibility ( การเข�าถ1ง Class) + Public ( มองเห4นได�จัาก Class อ,�น) - Private ( ไม�สามารถมองเห4นได�จัาก Class อ,�น) # Protected ( มองเห4นได�จัากเฉพัาะ Subclass)

Class Diagrams• ส�วนประกอบของ Class

- Composition เป(นส�วนประกอบท��ไม�สามารถแยกออกมาได�

- Aggregation

เป(นส�วนประกอบท��สามารถแยกออกมาได�

Class Diagrams• Class Multiplicity (จั*านวนของความสมพันธุ#) 1 หน1�ง 0..* ศ3นย#ถ1งหลาย 1..* หน1�งถ1งหลาย 0..1 ศ3นย#ถ1งหน1�ง 2..4 สองถ1งส�� 1..3,5 หน1�งถ1งสาม หร,อห�า

Class Diagrams

Interaction Diagrams

• ใช่�เพั,�อบอกกระบวนการท*างานภายในของระบบซึ่1�งสนบสน�นกระบวนการทางธุ�รก!จัขององค#กร

• เป(น Behavioral Models• ประกอบด�วย Diagram ดงต้�อไปน�/ - Sequence Diagram - Communication Diagram

Interaction Diagrams• Sequence Diagram - ใช่�แสดงถ1ง Object ท��ประกอบอย3�ใน Use Case - ใช่�แสดงถ1ง Message (ข�อม3ล) ท��ร บส�งระหว�าง Object - จัะแสดงในภาพัรวมการท*างานของ Use Case หร,อแสดงเฉพัาะ Scenario (กรณ�เหต้�การณ#) หน1�งก4ได�

Interaction Diagrams• ส�วนประกอบของ Sequence Diagram - Actor - Object - Lifeline - Execution Occurrence - Message - Guard Condition

Interaction Diagrams• Communication Diagrams

- ใช่�แสดงถ1งภาพัรวมของ message ท��ร บส�งระหว�างobject โดยไม�สนใจั

ในเร,�องล*าดบของเวลาเหม,อน sequence diagram

Interaction Diagrams• ส�วนประกอบของ Communication Diagrams - Actor - Object - Association - Message - Guard Condition

Behavioral Sate Machine Diagrams• เป(น Model ท��ใช่�แสดงสถานะท��เปล��ยนแปลงไปเม,�อ

Object หน1�ง ผ�าน การต้อบสนองต้�อเหต้�การณ#ต้�าง ๆ ท��เก!ดข1/นในวงจัร

ช่�ว!ต้ของ Object• State (สถานะ) เป(นช่�ดของค�าข�อม3ลใน Attribute ท��ใช่�ระบ�

สถานะของ Object หน1�ง ณ ช่�วงเวลาใดช่�วงเวลาหน1�งต้ามเง,�อนไขท��ถ3กก*าหนดไว�

Behavioral Sate Machine Diagrams• องค#ประกอบของ State Machine Diagrams

- State- Initial State

- Final State - Event - Transition

CRUD Analysis• เป(นเทคน!คในการว!เคราะห#หาความสมพันธุ#ระหว�าง

Object• ใช่�ต้ารางเพั,�อจับค3�ความสมพันธุ#ระหว�าง Object C : Create R : Read U : Update D : Delete

Receptionist PatientList PatientReceptionist RU CRUD

PatientList R

Patient

DESIGN

System Design• Class and Method Design ออกแบบ class และ method• Database Design ออกแบบฐานข�อม3ล• User Interface Design ออกแบบส�วนต้!ดต้�อกบผ3�ใช่�ระบบ• Architecture ออกแบบสถาป:ต้ยกรรมท��รองรบระบบ

System DesignClass and Method Design

ออกแบบ class และ method โดยใช่� method specification ซึ่1�งประกอบด�วย

- General Information ข�อม3ลท�วไป - Events เหต้�การณ#ท��ท*าให�เก!ดการใช่�งาน method - Message Passing ข�อม3ลท��ส�งผ�านระหว�างmethod - Algorithm Specification ว!ธุ�การท*างานของmethod

System DesignDatabase Design การออกแบบฐานข�อม3ลMapping Problem-Domain Objects To Object-Persistence Formats การจับค3� object กบ ต้ารางในฐานข�อม3ลม�สองว!ธุ� 1. Mapping Problem-Domain Objects to an OODBMS Format จับค3�หน1�ง object ต้�อหน1�งต้าราง 2. Mapping Problem Domain Objects to and ORDBMS Format จับค3�โดยต้�องด*าเน!นการต้ามกฎเกณฑ์# ของระบบฐานข�อม3ลเช่!งสมพันธุ# (RDBMS)

System DesignUser Interface Design การออกแบบส�วนต้!ดต้�อกบผ3�ใช่� User Interface Design Process กระบวนการในการออกแบบประกอบด�วย - Use Scenario Development การจั*าลองสถานการณ# - Interface Structure Design ออกแบบโครงสร�างของส�วนต้!ดต้�อ กบผ3�ใช่� - Interface Standard Design วางมาต้รฐานของการออกแบบ - Interface Design Prototyping สร�างต้วแบบของส�วนต้!ดต้�อ - Navigation Design ออกแบบส�วนน*าทางผ3�ใช่� - Input Design ออกแบบส�วนป;อนข�อม3ล

System DesignArchitecture Design การออกแบบสถาป:ต้ยกรรม - Server-Based Architecture เช่�นระบบ mainframe - Client-Server-Architecture เช่�นระบบ LAN - Client-Server-Tiers เช่�นระบบ web application

System DesignInfrastructure Design - Deployment Diagram Deployment diagrams ถ3กใช่�เพั,�อแสดงถ1งความสมพันธุ#ระหว�าง

ส�วนประกอบท��เป(น Hardware ต้�าง ๆ ซึ่1�งเป(ฯโครงสร�างทางกายภาพัของระบบ

IMPLEMENTATION

Managing Programming- Assigning Programmers มอบหมายงานให�กบ programmers โดยแบ�งเป(นโมด3ล ซึ่1�งแต้�โมด3ล ควรจัะเป(นโมด3ลท��ท*างานเป(นอ!สระต้�อกนไม�ม�การท*างานท��ต้�องข1/นต้�อกน- Coordinating Activities ประสานการท*างานและก!จักรรมต้�าง ๆ อาจัใช่�ว!ธุ�จัดประช่�มรายสปดาห# เพั,�อปร1กษาหาร,อกนและด3ความค,บหน�าของงาน- Managing the Schedule บร!หารงานให�เป(นไปต้ามก*าหนดการท��ได�วางไว� ซึ่1�งอาจัจัะม�การปรบปร�ง ก*าหนดการต้�าง ๆ ต้ามความจั*าเป(นของสถานการณ#ท��เปล��ยนไป

Testing การทดสอบแบ�งออกเป(น

Unit Tests : ใช่�ทดสอบการท*างานของ classes และ methods แบ�งออกเป(น - black-box testing : ทดสอบ class ว�าท*างานได�ถ3กต้�องต้ามท��ก*าหนด specification ไว�ใน CRC cards หร,อไม� - white-box texting : ทดสอบ method ในแต้�ละ class ว�าท*างานได� ถ3กต้�องต้ามท��ก*าหนดไว�ใน method specification หร,อไม� Integration Tests : ใช่�ทดสอบการท*างานร�วมกนของกล��ม classes System Tests : ใช่�ทดสอบการท*างานร�วมกนของ classes ท/งหมด Acceptance Tests : ทดสอบโดย user เพั,�อด3ว�าระบบท*างานได�ต้รงต้ามความต้�องการ ทางธุ�รก!จัท��ท*าให�ต้�องสร�างระบบข1/นมาแบ�งออกเป(น - alpha testing : ทดสอบโดยใช่�ข�อม3ลสมมต้! - beta testing : ทดสอบโดยใช่�ข�อม3ลจัร!ง

Development DocumentationThree Types of Documentation - Reference Documents ใช่�เม,�อ user ต้�องการเร�ยนร3 �ว�าจัะใช่�งาน function ใด function

หน1�ง ในระบบได�อย�างไร เช่�น แก�ไขข�อม3ลในช่�อง field หร,อเพั!�มrecord ใหม� - Procedures Manuals ใช่�อธุ!บายว�าจัะด*าเน!นงานทางธุ�รก!จัได�อย�างไร เช่�น พั!มพั#รายงานประจั*าเด,อน - Tutorials ใช่�สอนการใช่�งานส�วนประกอบหลกของระบบ

Conversion Conversion เป(นกระบวนการทางเทคน!คในการแทนท��

ระบบเด!มด�วยระบบใหม� โดยต้�องม�การวางแผนกระบวนการ หลกสามข/นต้อน ก�อนท��จัะเร!�มด*าเน!นการ

ซึ่1�งท/งสามข/นต้อนประกอบด�วย - Install Hardware - Install Software - Convert Data

ConversionConversion Style Conversion style เป(นว!ธุ�การซึ่1�ง user จัะถ3กสลบการใช่�

งานจัากระบบเก�ามายงระบบใหม� โดยม�ว!ธุ�ท��แต้กต้�างกนโดย ม3ลฐานอย3�สองว!ธุ� ค,อ

- Direct Conversion - Parallel Conversion

ConversionConversion StyleDirect Conversion ว!ธุ� direct conversion ( บางคร/งก4เร�ยกว�า cold turkey, big bang หร,อ abrupt cutover) ระบบเก�าจัะถ3กแทนท��โดย

ระบบใหม�ทนท� ว!ธุ�น�/เป(นว!ธุ�ท��เร�ยบง�ายและต้รงไปต้รงมา แต้�ก4เป(นว!ธุ�ท��

ม�ความเส��ยงส3ง เพัราะว�า อาจัจัะม�ป:ญหาต้�าง ๆ ของระบบใหม�ท��หล�ดรอดจัากการต้รวจั

สอบเก!ดข1/นได� ซึ่1�งอาจัจัะก�อให�เก!ดความเส�ยหายอย�างร�ายแรงต้�อองค#กร

ConversionConversion StylesParallel Conversion โดยว!ธุ� parallel conversion ระบบใหม�จัะถ3กใช่�งานค3�ขนานไปกบระบบ

เก�าพัร�อม ๆ กน โดย user จัะต้�องป;อนข�อม3ลท/งระบบเก�าและระบบใหม� แล�วท*าการเปร�ยบเท�ยบผลลพัธุ#ท��ได�ว�าระบบใหม�ท*างานได�ถ3กต้�องหร,อไม� หลงจัากผ�านไปช่�วระยะเวลาหน1�ง ประมาณหน1�งหร,อสองเด,อน ถ�าระบบใหม�ท*า

งานได�ถ3กต้�องสมบ3รณ# ระบบเก�าก4จัะถ3กปAดระบบและใช่�งานแต้�เพั�ยงระบบใหม�เพั�ยงระบบเด�ยว ว!ธุ�น�/ช่�วยลดความเส��ยงในการใช่�งานระบบใหม� ถ�าเก!ดป:ญหาในระบบใหม� ระบบ

ใหม�ก4จัะถ3กปAดและน*าไปแก�ไขป:ญหาท��เก!ดข1/น เม,�อแก�ป:ญหาเสร4จัแล�วจั1งน*ากลบใช่�งานแบบค3�ขนานอ�กคร/ง ข�อเส�ยของว!ธุ�น�/ก4ค,อ ม�ภาระค�าใช่�จั�ายในการท*างานถ1งสองระบบพัร�อม ๆ กนในงานเร,�องเด�ยวกน

ConversionConversion Location Conversion location ก4ค,อหน�วยงานต้�าง ๆ ขององค#กรท��จัะถ3กเปล��ยนไปใช่�

ระบบใหม� ณ เวลาหน1�งเม,�อการ conversion เก!ดข1/น บ�อยคร/งท��หน�วยงานขององค#กรต้/งอย3�ในต้�างส*านกงานกน แต้�ในกรณ�อ,�นแล�วLocation จัะหมายถ1งหน�วยงานในองค#กรท��ต้ /งอย3�ในพั,/นท�� ท��ต้�างกนในส*านกงาน

แห�งเด�ยวกน ม�ว!ธุ�การท��แต้กต้�างกนโดยม3ลฐานอย3�อย�างน�อยสามว!ธุ�ในการเปล��ยนหน�วย

งานท��ต้ /งอย3�ในพั,/นต้�าง ๆ ขององค#กรไปใช่�งานระบบใหม� ดงต้�อไปน�/ - Pilot Conversion - Phased Conversion - Simultaneous Conversion

ConversionConversion Location Pilot Conversion โดยว!ธุ� pilot conversion หน�วยงานใดหน�วยงานหน1�งหร,อกล��มงาน(workgroup) ในพั,/นท��งานขององค#กร จัะถ3กเล,อกให�ถ3ก converted เป(นอนดบแรก

โดยเป(นส�วนหน1�งของการทดสอบแบบน*าร�อง (pilot test) พั,/นท��งานท��ถ3กเล,อกจัะถ3กเปล��ยนให�ไปใช่�งานระบบใหม� ไม�ว�าจัะโดยว!ธุ� direct

หร,อ parallel ถ�าการทดสอบน*าร�องผ�านไปได�ด�วยด� ระบบก4ถ3กน*าไปต้!ดต้/งในพั,/นท��งานขององค#ท��เหล,ออย3� ข�อด�ของว!ธุ�น�/ก4ค,อเพั!�มการทดสอบอ�กระดบหน1�งก�อนท��ระบบจัะถ3กใช่�งานจัร!งท�วท/งองค#กร ข�อเส�ยก4ค,อต้�องใช่�เวลามากข1/นก�อนท��ระบบจัะถ3กใช่�งานจัร!งท�วองค#กร อ�กท/งมน

ยง หมายถ1งว�า หน�วยงานท��อย3�ในพั,/นท��งานท��ต้�างกน ก*าลงใช่�งานระบบท��แต้กต้�างกนซึ่1�ง

ท*าให�เก!ดความย��งยากในการแลกเปล��ยนข�อม3ลระหว�างหน�วยงานต้�าง ๆ

ConversionConversion Location Phased Conversion โดยว!ธุ� phased conversion ระบบจัะถ3กต้!ดต้/งต้ามล*าดบท��พั,/นท��งาน

ท��ต้�างกน พั,/นท��งานกล��มแรกจัะถ3กเปล��ยนระบบก�อน จัากน/นจั1งเป(นกล��มท��สองและกล��ม

ท��สามและต้�อไปเร,�อย ๆ จันกว�าครบท/งองค#กร ถ�าเก!ดป:ญหา ป:ญหา ต้�าง ๆ จัะถ3กต้รวจัพับก�อนท��จัะม�ผลกระทบท�วท/งองค#กร แต้�ถ�าไม�ม�

ป:ญหาระบบก4จัะถ3กต้!ดต้/งไปท�ละพั,/นท��งานไปเร,�อย ๆ ว!ธุ�น�/ม�ท/งข�อด�และข�อเส�ยเหม,อนกบว!ธุ� pilot conversion แต้�ในขณะเด�ยว

กนว!ธุ�น�/ก4ใช่�บ�คลากรเพั,�อการท*า conversion น�อยกว�าการท*าconversion ท/งองค#กรพัร�อม ๆ กน

ConversionConversion Location Simultaneous Conversion Simultaneous conversion หมายถ1งท�ก ๆ พั,/นในองค#กร ถ3กconverted พัร�อม ๆ กน ระบบจัะถ3กต้!ดต้/งและพัร�อมใช่�งานในท�ก ๆพั,/นท��งาน เม,�อถ1งเวลาท��ก*าหนดไว� user ก4จัะเร!�มใช่�ระบบใหม� ว!ธุ�น�/มกจัะใช่�กบว!ธุ�direct conversion แต้�ก4สามารถใช่�กบว!ธุ� parallel conversion ได�

เช่�นกน ข�อเส�ยค,อต้�องใช่�บ�คลากรจั*านวนมากเพั,�อด*าเน!นการconversion และฝึCกอบรม users ท�วท/งองค#กร

ConversionConversion Modules ไม�เสมอไปท��ระบบจัะถ3กต้!ดต้/งพัร�อมกนท/งระบบ ระบบอาจัจัะถ3กแบ�งออกเป(นModules ย�อย เพั,�อต้!ดต้/งก4ได� โดยเราแบ�งว!ธุ�การต้!ดต้/งส�วนต้�าง ๆ ของระบบ

ได�เป(นสองว!ธุ�ค,อ - Whole-System Conversion ต้!ดต้/งพัร�อม ๆ กนท/งระบบในเวลา

เด�ยวกน ซึ่1�งเป(นว!ธุ�ท��พับเห4นท�วไป แต้�ถ�าระบบม�ขนาดใหญ�และซึ่บซึ่�อนมาก user อาจัจัะประสบความยากล*าบากในการเร�ยนร3 �การใช่�งานท/งระบบข/นต้อนการ

conversion - Modular Conversion ค,อการเล,อกต้!ดต้/งคร/งละหน1�ง module

ซึ่1�งความยากง�ายของว!ธุ�น�/ก4ข1/นอย3�กบระดบความเก��ยวพันของ module ต้�าง ๆใน

ระบบ ข�อด�ของว!ธุ�น�/ก4ค,อช่�วยลดปร!มาณการฝึCกอบรม user เพั,�อเร!�มใช่�ระบบใหม�แต้�ข�อเส�ยก4ค,อต้�องใช่�เวลามากข1/นในการต้!ดต้/งระบบท/งระบบให�เสร4จัสมบ3รณ#

ConversionSelecting the Appropriate Conversion Strategy ม�ป:จัจัยท��ต้�องค*าน1งอย3�สามประการ ในการเล,อกกลย�ทธุ#การ conversion ท��เหมาะสมประกอบด�วย - Risk (ความเส��ยง) ระบบท��ได�รบการทดสอบมาด�ม�แนวโน�มท��จัะม�ความเส��ยงน�อย สามารถเล,อกใช่�ว!ธุ�direct conversion และว!ธุ� simultaneous conversion ได� แต้�ถ�าไม�ใช่�

ก4ต้�องใช่�ว!ธุ�อ,�นๆ ท��กล�าวมาข�างต้�นซึ่1�งสามารถช่�วยลดความเส��ยง - Cost (ค�าใช่�จั�าย) ค�าใช่�จั�ายของว!ธุ�การ conversion แต้�ละว!ธุ�ไม�เท�ากน ว!ธุ�ท��สามารถลดความเส��ยงม�ค�าใช่�จั�ายส3งกว�าว!ธุ�ท��ม�ความเส��ยงส3ง - Time (เวลา) ว!ธุ�ท��ม�ความเส��ยงส3งจัะใช่�เวลาในการ conversion น�อยกว�าว!ธุ�ท��ช่�วยลดความเส��ยง