1. Chapter 1: Introduction to Systems Analysis and Design

2. The Role of Systems Analysis and Design
Systems analysis and design is a step-by-step process for developing high-quality information systems.
An information system combines information technology, people, and data to support business requirements.

3. Information system components
A system is a set of related components that produces specific results.
Every system requires input data. In an information system, data consists of basic facts that are the system’s raw material.
Information is data that has been transformed into output that is valuable to users.
An information system has five key components: hardware, software, data, processes, and people

4. The systems development life cycle
The systems development life cycle (SDLC) is a common methodology for systems development in many organizations.

5. The systems development life cycle
Systems Planning and Selection
Identify the need for a new or enhanced system.
Investigate (tìm hiểu) the system and determine the proposed system’s scope.
Produce a specific plan for the proposed project
Systems Analysis
Determine the requirements of the system
Study the requirements and structure them according to their interrelationships, eliminating any redundancies

6. The systems development life cycle
Systems Design: Convert the description of the recommended solution into logical and then physical system specifications
Logical design concentrates on the business aspects of the system.
Physical design convert the logical design into physical, or technical, specifications, specify the programming languages, database systems and file structures will be used for the data

7. The systems development life cycle
Systems Implementation and Operation
Implementation: coding, testing, and installation.
Operation: programmers make the changes that users ask for and modify the system to reflect changing business conditions.

8. Systems development tools
Modeling
Modeling produces a graphical representation of a concept or process that systems developers can analyze, test, and modify
Prototyping
Prototyping tests system concepts and provides an opportunity to examine input, output, and user interfaces before final decisions are made.
A prototype is an early working version of an information system.

9. Systems development tools
Computer-Aided Systems Engineering (CASE) Tools
CASE tools provide an overall framework for systems development and support a wide variety of design methodologies, including structured analysis and object- oriented analysis.

10. Systems development models
Waterfall model
The Rational Unified Process

11. Waterfall model
In a waterfall model, each phase must be completed fully before the next phase can begin.
This type of model is basically used for the for the project which is small and there are no uncertain requirements.

12. Waterfall model Advantages of waterfall model
This model is simple and easy to understand and use.
It is easy to manage due to the rigidity of the model.
In this model phases are processed and completed one at a time. Phases do not overlap.
Waterfall model works well for smaller projects where requirements are very well understood.

13. Waterfall model Disadvantages of waterfall model
It is very difficult to go back.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing.

14. Rational Unified Process
Stands for "Rational Unified Process." RUP is a software development process from Rational, a division of IBM.
RUP is a method of managing OO Software Development
RUP divides the development process into four distinct phases that each involve business modeling, analysis and design, implementation, testing, and deployment.

15. Rational Unified Process

16. The Development Phases in RUP
Inception Phase
Elaboration Phase
Construction Phase
Transition Phase

17. Inception Phase
Overriding goal is obtaining buy-in from all interested parties
Initial requirements capture
Cost Benefit Analysis
Initial Risk Analysis
Project scope definition
Defining a candidate architecture
Development of a prototype

18. Elaboration Phase Requirements Analysis and Capture Use Case Analysis
Use Case (80% written and reviewed by end of phase)
Use Case Model (80% done)
Scenarios
Sequence and Collaboration Diagrams
Class, Activity, Component, State Diagrams

19. Elaboration Phase
Glossary (so users and developers can speak common vocabulary)
Domain Model
To understand the problem: the system’s requirements as they exist within the context of the problem domain
Risk Assessment Plan revised
Architecture Document

20. Construction Phase Focus is on implementation of the design:
Cumulative increase in functionality
Greater depth of implementation
Implement all details.
Analysis continues, but focus on design and coding

21. Transition Phase Transfer of the system to the user community
It includes manufacturing, shipping, installation, training, technical support and maintenance
Control is moved to maintenance team
Software updates
Integration with existing systems

22. Core workflows
During each of these phases the RUP defines 6 core process work flows
Business modeling:
The vision and scope of the business is captured.
The business use-cases, workflows and business objects are identified
Requirements modeling
Mapping of the business use cases and objects onto system use cases and objects.
Scoping of the requirements.
Development of the requirements Specification including functional and non-functional requirements.

23. Core workflows
Analysis and Design: Here the high-level architecture and design is developed and verified to ensure that
The architecture can accommodate the requirements
The architecture and design can grow with increasing number of concurrent users and higher transaction volumes.
Implementation
The lower-level design of the system.
The actual construction of the system in terms of components, subsystems and classes.
The development of low-level unit tests.

24. Core workflows
Testing: Unit testing done for individual objects the testing workflow tests
the objects interact correctly,
the integration of higher level components and subsystems
the requirements have been implemented correctly,
any failures are fed beck to the development team and that the system is not deployed with any defects.

25. Core workflows Deployment Producing external releases of the software.
Packaging the software.
Distributing the software.
Installing the software.
Providing training and assistance to users.
Beta testing.
Migration of existing software or data.
Initiating the process of formal acceptance.

26. Systems development methods
Structured analysis
Agile methods
Object-oriented analysis (O-O)

27. Structured Analysis
Structured analysis is a traditional systems development technique that is time-tested and easy to understand.
Represents the system in terms of data and the processes that act upon that data.
Modeling tools: Data flow diagrams (DFDs)

28. Agile methods
Build a series of prototypes and constantly adjusting them to user requirements.
Emphasize continuous feedback, and each incremental step is affected by what was learned in the prior steps.
Use a spiral model

29. Agile methods
EXPLORATION (thăm dò): environment, asserting your conviction that the problem can and should be approached with agile development, assemble the team, and assess team member skills
PLANNING. may only take a few days to accomplish. In this stage you and your customers agree on a date anywhere from two months to half a year from the current date to deliver solutions to their most pressing business problems (you will be addressing the smallest, most valuable set of stories). If your exploration activities were sufficient, this stage should be very short.
ITERATIONS TO THE FIRST RELEASE. iterations to the first release. Typically these are iterations (cycles of testing, feedback, and change) of about three weeks in duration.
One goal is to run customer-written functional tests at the end of each iteration. During the iterations stage you should also question whether the schedule needs to be altered or whether you are tackling too many stories
PRODUCTIONIZING.the feedback cycle speeds up so that rather than receiving feedback for an iteration every three weeks, software revisions are being turned around in one week
MAINTENANCE. Once the system has been released, it needs to be kept running smoothly. New features may be added, riskier customer suggestions may be considered

30. Object-oriented analysis and design
Object-oriented (O-O) analysis and design is an approach that is used to develop the systems that must change rapidly in response to dynamic business environments.
Use the industry standard for modeling object- oriented systems, called the unified modeling language (UML), to break down a system into a use case model.

31. Object-oriented analysis and design

32. Object-oriented analysis and design
The object-oriented modeling approach provides several benefits:
The ability to tackle more challenging problem domains
Improved communication among users, analysts, designers, and programmers
Reusability of analysis, design, and programming results
Increased consistency among the models developed during object-oriented analysis, design, and programming

33. Object-oriented analysis and design
Design review
Object Modeling Technique
Object-Oriented Analysis
Object-Oriented Design
Three models
Object model
Dynamic model
Functional model
Four phases

34. Design - Review Design transforms requirements into Also develops
an architecture diagram
subsystems, modules and their relationships
a detailed design
a specification of the abstract interface, data structures, and algorithms of each module
Also develops
a review plan for ensuring the design meets the requirements
a test plan for ensuring the implementation meets the design

35. Object-Oriented Software Development
Object-Oriented Methodology
Development approach used to build complex systems using the concepts of object, class, polymorphism, and inheritance with a view towards reusability
Encourages software engineers to think of the problem in terms of the application domain early and apply a consistent approach throughout the entire life-cycle

36. Object-Oriented Software Development
Object-Oriented Analysis and Design
Analysis models the “real-world” requirements, independent of the implementation environment
Design applies object-oriented concepts to develop and communicate the architecture and details of how to meet requirements

37. Object-Oriented Analysis
Object-Oriented Analysis is the “requirements phase” of Object-Oriented Software Development
think of it as an alternative semi-formal technique
Semi-formal technique
class modeling
dynamic modeling
functional modeling
These steps focus on
data
actions
and their relationships
Reuses familiar tools
E-R diagrams
Finite State Machines
Data flow diagrams
Steps and diagrams
are typically performed in parallel after initial class definition
must be kept in synch

38. Object-Oriented Analysis
Builds a real-world model from requirements
client interviews
domain knowledge
real-world experience
Model is more precise and concise than the informal problem definition
The model addresses three aspects of objects
class structure and relationships
sequencing of interactions and events
data transformations and computations