System analysis and design เนื้อหามิดเทอม 2566/1

Midterm Guideline

• 9 ข้อ 70 คะแนน (35%)
• ถามตอบเป็น English
• วิเคราะห์, ประยุกต์ 5+3+6
• จำ 4+6+6+ศัพท์เติมตาราง 8
• เข้าใจ 5
• Context 7
• Level0 8
• Usecase, Use-case description 12
• System request, Project schedule, การคำนวนเงิน (Cash flow), ไม่มีให้คำนวน ไม่มีให้เขียนในข้อสอบ

Chapter 1

• Systems Development Life Cycle (SDLC)

  • There are 2 main approaches for systems development life cycle (SDLCs).

    1. Predictive approacha
       • Can be developed according to the plan
       • Requirements of a system or the users' needs are well understood
    2. Adaptive approach
       • flexible and adapt the project as it progresses.
       • requirements of a system or the users’ needs are not well understood.

  • There are 3 main systems development methods

    1. Structured analysis: Builds an overall plan
       • Waterfall
       • Parallel development
       • V-model
    2. Object-Oriented (O-O) Analysis: Combines data and the processes into objects
    3. Agile methods

  • System Development Technique

    Name	Meaning	Advantages	Disadvantages
    Waterfall	Analysts and users proceed sequentially from one phase to the next.	- Have requirements before developing begins and little to no changes after the profect process.	- Need to have the entire design ready before starting to code
    			- A big gap between planning and system delivery
    			- Testing being somewhat neglected (ignored) until later in the process.
    			- Overlooked in the volumes of documentation
    Parallel	Divided project into a series of subprojects that can be designed and implemented in parallel.	- Reduces the time requiredto deliver a system	- Some components may depend on others being completed first
    			- Overlooked in the volumes of documentation
    V-model	It is an extension of the waterfall model that adds an additional layer of testing and validation activities.	- Defects can be identified and addressed early	- Testing can lead to longer development
    Rapid Application development	Sequential Mini-Waterfall process	- First version is deliver fast	- Users will use intentionally incomplete system
    		- Fast feedback from users
    System prototyping	Building a prototype of the system to demonstrate its functionalities and features.	- Clarifies user requirements	- Might lead to confusion between prototype and final system
    		- Provides a tangible (จับต้องได้) representation of the system
    Throwaway prototyping	Similar to system prototyping, but the prototype is discarded after gathering requirements and insights.	- Helps in clarifying requirements and user needs	- Resources and effort spent on discarded prototype
    		- Rapid feedback and iteration

    • Waterfall

      1. Systems planning phase: Understanding why an information system should be built
         • Systems request: Describes problems or desired changes
         • Preliminary investigation: Gathering essential information to determine whether a project is feasible and worth pursuing (continue).
           • Feasibility study
      2. Systems analysis phase: Build a logical model of the new system.
         • Who will use the system, what the system will do, and where and when it will be used.
         • Requirements modeling: Investigate business processes and document
         • Deliver System requirements document
      3. Systems design phase: To create a physical model
         • How the system will operate, in terms of the hardware, software, network infrastructure, the user interface, ...
         • Deliver Application architecture
      4. Systems implementation phase: Building
         • Systems evaluation: To determine whether the system operates properly and if costs and benefits are within expectations.
         • Deliver Completely functioning and documented information system
      5. Systems support and security phase: Maintains and protects the system

    • Parallel development (Waterfall variant)

      • The project is divided into a series ofnsubprojects that can be designed and implemented in parallel.
      • Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered.

    • V-model (Waterfall variant)

      
      • Pays more explicit attention to testing.
      • Each step is tested

    • Object-Oriented Analysis

      • An object is a member of a class
      • OO development methods can use the waterfall model or the model that stresses greater iteration.

    • Rapid Application Development (RAD) (Agile methods)

      • A series of versions that are developed sequentially.
      • The first version is developed quickly by a mini-waterfall process
      • Users can provide valuable feedback

    • System prototyping (RAD Variant)

    • Throwaway prototyping (RAD Variant)

Chapter 2

• Project management

  • Organizing and directing other people to achieve a planned result within a predetermined schedule and budget.
  • Project execution management: Focus on task
  • Project control management: Focus on performance
  • 2 Approach
    • Predictive approach
      • Detailed plans, estimates, schedules, and budgets are developed at the beginning of the project.
    • Adaptive approach
      • Planning tasks are more distributed across the entire lifetime of the project.
  • 3 Project management processes
    1. Executing
       • Project schedule
       • Assigning and coordinating the work of project teams
       • Communicating with all project stakeholders
    2. Controlling
       • Determining progress and taking corrective action when necessary
       • Assessing (ประเมิณ) whether requests for scope changes are necessary
       • Maintaining an issues list
       • Resolving problems.
    3. Closing the project out
       • Smooth shutdown of the project 🎉🎉
       • Releasing team members for other assignments
       • Finalizing the budget and its expenditures
       • Reviewing or auditing the results of the project
  • Project management knowledge area
    • Project Scope Management: Defining and controlling the functions
    • Project Time Management: Building a detailed schedule of all project tasks and then monitoring the progress
    • Project Cost Management: Calculating the initial cost/benefit analysis and its later updates and monitoring
    • Project Quality Management: Establishing a comprehensive plan for ensuring quality, which includes quality-control activities
    • Project Human Resource Management: Recruiting and hiring project team members; training, motivating ):, and team building
    • Project Communications Management: Identifying all stakeholders and the key communications to each; also establishing all communications mechanisms and schedule
      • คุยกับคนลงทุน / รายงานความก้าวหน้า / ติดต่อไม่ได้ทำไง
    • Project Risk Management: Identifying and reviewing all potential risks for failure and developing plans to reduce these risks
      • เช่น Team หาย ทํายังไงต่อ!
    • Project Procurement Management: Developing requests for proposals, evaluating bids, writing contracts, and then monitoring vendor performance
      • ทำเอกสาร เขียนสัญญา ทํา Requirement
    • Project Integration Management Integrating all the other knowledge areas into one seamless whole

• Planning phase

  • Project sponsor: Person who identifies business value
    • คนที่ระบุสี่งที่ จะได้จาก Prjeet
  • Approval committee: Reviews system requests
    • คนอนุมัติ Projeet / กรรมการ
  • Business needs: ความต้องการทางธุรกิจ
    • System’s functionality (what it will do).
  • Stalseholder: ผู้มีส่วนได้ส่วนเสีย
    • Staff ในองกร / ลูกค้า / User
  • System Request: Reasons for project
    • Project sponsor: ผู้ริเริ่ม ผู้เห็นปํๆหา ฝู๋คิดวิธีแก้ปัญหา
    • Business need: Why ทําทําไม เช่น ง่ายขึ้น 1 เพิ่มยอด
    • Business requirements: functionod Requirment ทําอะไรได้บ้าง
    • Business value: Benefit จากระบบ จะได้อะไร เป็น ตัวเลข
    • Special issues or constraints: เงื่อนไข พิเศษ
      • เช่น ทําเสร็จก่อนงาน Chrismas, ทํา เสร็จก่อน . . ., ต้อง Security clearance (โบร่ทำ Oppenheimer)
  • Feasibility Analysis: ดูความเป็นไปได้
    • Technical Feasibility: Can We Build It?
      • Familiarity with technology
      • Project size
      • Compatibility with existing systems
    • Economic Feasibility: Should We Build It?
      1. Identify costs and benefits
      2. Determine cash flow
      3. Assess financial viability

         • Net present value (NPV): Inflation

         • Return on investment (ROI): Average rate of return earned on the money invested in the project.

           $$ROI = \dfrac{Total\space Benefits - Total\space Costs}{Total\space Costs}$$

         • Break even point (BEP): จุดคืนทุน หน่วยเป็นปี

    • Schedules feasibility
      • Critical path: is the sequence of tasks that determine the length of the project.
    • Resource feasibility
      • Team members, Computer resources, Physical facilities, and support staff

Chapter 3

• Requirement determination อยู่ใน Phase analysis
  • Determine: เอา Detail
  • Structuring: Modeling System Requirements
    • เช่น Tables, Diagrams, ...
• Stakeholders
  1. The users, those who actually use the system;
  2. The clients, those who pay for and own the system;
  3. The technical staff, the people who establish and maintain the computing environment of the organization.
• Functional requirements are the activities that the system must perform
• Non-functional requirements are characteristics of the system other than activities it must perform or support.
  • เช่น Availability, Modifiability, Performance, Security, Testability, ...
  • Technical requirements: Operational characteristics related to the environment, hardware, and software
    • จะรันจะต้องใช้อะไร
  • Performance requirements: measures of workload, such as throughput and response time.
  • Usability requirements: UI / Documents / Support
  • Security requirements
• Information gathering techniques
  • Traditional Methods
    • Interviews
    • Observations
    • Documents
  • Modern Methods
    • Joint application design (JAD)
      • เอา Stakeholder มาจับเข่าคุย
    • Prototyping

Chapter 4

• Use Case Diagram: Design phase

• Logical models: ออกแบบโดยไม่ขึ้น กับ Hardware / Saftware

• Use case model

  • Use case diagrams
  • Use case descriptions
  • System sequence diagrams (เรียนหลัง Midterm)
  • Activity diagrams (เรียนหลัง Midterm)

• Use case represents the activities that are performed by the users

  • ไม่มีประโยชน์ที่ ไม่มี User / น้อย เช่น Backup, Transaction, Generate report
  • Techniques for identifying use cases
    • User goal technique
      • Talk to all users to get them to describe their goals in using the system.
    • CRUD technique (ไม่ค่อยได้ใช้จริง)
    • Event decomposition technique (ไม่ค่อยได้ใช้จริง)

• Use case diagram:

  
  • Describe the high-level functions and scope of a system.
  • Identify the interactions between the system and its actors.
  • $\text{\color{red}Not how the system operates internally}$
  • Actors A role of a user that interacts with the system that you are modeling.

    • The user can be a human user, an organization, a machine, or another external system.

    • เช่น API อื่นๆ ก็ด้วย

    • Inheritance: specialized actor will inherit the behavior of the superclass and extend it in some way.

      • ส่วนที่ Super class มีก็จะใช้ได้เหมือนเดิม แต่เพิ่มส่วนพิเศษขึ้นมา
      • เช่น Student เป็น Super class สามารถลงวิชาเรียนได้, International Student เป็น Inheritance class ที่สามารถลงวิชาเรียนได้และ Security check ได้
      
  • Symbols:
    • Use cases: Functional requirement (verb)
    • Package: Subsystem
    • System boundary: To separate the use cases to a system from the actors
  • Relationships

    • «include»: จะทำ .. ต้องทำ .. มาก่อน

      • เช่น User จะสั่งของ User จะต้องดูว่าของมีไหมก่อน
      

    • «extend»: ... สามารถทำแบบนี้ก็ได้

      • เช่น จะจ่ายเงิน สามารถ จ่ายแบบเงินสด หรือ PromptPay ก็ได้
      

• Use Case Descriptions

  • Brief Description: Used for very simple use cases

  • Intermediate Description: Expands the brief description to include the internal flow of activities for the use case.

    Main Flow
    1. ...
    2. ...
    3. ...
    4. ...
    Exceptional Conditions
    3. if ...
    a. ...
    b. ...

  • Fully Developed Description

    • Use case Name

    • Scenarios: สถานการณ์

    • Triggering event: Event that initiates the use case from the event table.

      • เช่น User want to add the movie the "My Lists"

    • Brief description

    • Actor or actors

    • Related Use Cases

    • Stakeholders: Users who do not actually invoke the use case but who have an interest in results produced from the use case.

    • Preconditions: Condition ที่ต้องมีก่อนทำ Use case นี้

    • Postcondition: Condition ที่จะได้เป็นหลังจากทำ Use case นี้

    • Flow of Activities

    • Exception Conditions

      Make sure ว่าเลขใน Exception Conditions ต้องตรงกับเลข ใน Flow of Activities

Chapter 5

• Data flow diagram: แผนภาพ การไหลของข้อมูลในระบบ

  • สามารถใช้ได้ทั้งใน Analysis phase, และ design phase

  • 4 Symbols

    • Entity
    • Process
    • Data flow
    • Data stores
    

  • Source / Sink (Entity)

    • Source: Provide data to the system
    • Sink: Receive output from the system
    • Entity $\rArr$ Entity ❌
    • Entity $\rArr$ Process ✅
    • Entity $\rArr$ Data store ❌

  • Data flow

    • เป็นคำนาม!!!
    • หัวลูกศรสองฝั่งห้าม!! เพราะ Data flow มาคนละเวลา

  • Process

    • เป็นคำกริยา!!!
    • ต้องมีทั้ง Input และ Output!!

  • Data store: เป็นข้อมูลที่ระบบเก็บ เช่น Database

    • คำนาม
    • Data store $\rArr$ Entity ❌
    • Data store $\rArr$ Process ✅
    • Data store $\rArr$ Data store ❌

• Context Diagram: One process and shows the data flows to and from external entities.

  • Process Number 0 อย่าลืม!!
  • ไม่มี Data store!!

• Level 0 Diagram หรือ leveL 0 DFD

  • Show all the major high-level processes of the system
  • Only one level 0 DFD!
  • เอา Dataflow ของ Context diagram ลงมาให้ครบ!

กูม่ายวายล้า