Systems Analysis and Design with UML

PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 6th Edition
Copyright © 2020 John Wiley & Sons, Inc. All rights reserved.
Chapter 1:
Introduction to Systems
Analysis and Design

Learning Objectives
 What is Systems Analysis and Design? Why build systems?
 Objectives and goals of systems development. Why projects
fail.
 How applications are built. Basics of programming
 How programming is managed. The systems development
life cycle (SDLC)
 Identify the four phases
 Analyst/Team roles & skill sets
 Problems with traditional SDLC
 Object-oriented systems analysis & design
 The agile systems development approaches
 Scrum
 XP
 Lean and Kanban
 The Agile Manifesto
 The Unified Modeling Language (UML)
2

Systems Analysis and Design
 Software Engineering Body of Knowledge (SWEBOK) defines
software engineering (SE) as ‘the application of a systematic,
disciplined, quantifiable approach to the development, operation,
and maintenance of software; that is, the application of engineering
to software’ (Bourque, 2014)
 Information systems development (ISD) is defined as “The
integrated social and technical practices of conceptualizing and
realizing information technology-based systems, and managing the
associated changes and implications to accomplish specific goals
in organizational contexts” (Hassan and Mathiassen, 2018)
 ISD is also known as Systems Analysis and Design because the
process of ISD takes the shape of analyzing the system and
designing it.
3

Why Build Systems?
 Solve a business problem
 Capture a business opportunity
 “Because my boss asked me to”
4

The F-35 fighter jet includes a $400,000
augmented reality helmet
Solve the pilot’s problem: You can look down below you or around you and
see “through” the metal of the plane onto the earth and horizon below and in
front of you. It will point out high value targets at a distance and in close
range.

9-6
“Lockheed Is Using These Augmented
Reality Glasses to Build Fighter Jets”
Solve the mechanic’s problem
Augmented reality glasses and educational software provide real-
time visuals during the plane's assembly

Quiz
 Google
 What problem did Google solve?
 What makes Google’s search engine different from other earlier
search engines?
 What other businesses did Google spawn from Search?
 Netflix
 What opportunities did Netflix capture by building its online
streaming service?
 What did Netflix online streaming service change?
 What is common between Netflix’s system and Amazon’s
business model?
7

Introduction
 Project Failures
 1985 Software design flaws in Therac-25 machine lead to radiation overdoses
and killed 3 patients
 The DOD/government discards 70% of their software code, costing billions
 1994 Denver Airport lost $1.1 million/day for more than 3 months because
software problems in the baggage handling system
 2000 Standish Group Study
 Only 28% of system development projects successful
 72% of projects cancelled, completed late, over budget, and/or limited in
functionality
 2010 Standish Group Study – 63% failure
 2013 – Obama Insurance Marketplace
 2018 – Uber’s self-driving test car kills a pedestrian. The system did not read
the woman pushing a bicycle crossing the street as a pedestrian
8

Why Do Projects Fail?
 Incomplete or changing requirements
 Lack of customer involvement
 Lack of executive support
 Developer/technology incompetence
 Lack of resources
 Unrealistic expectations
 Poor integration between Dev and Ops (Development and
Production environments)
9

The manager vs. the techie
 Many managers recognize the need to change but don’t fully
understand the opportunities or how to employ the
technology effectively
 Many technical people understand the details of various
technologies but don’t have the management background or
authority to provide consistent, integrated solutions.
 A business problem is not the same as a technical problem.
Which one of these is a business problem (select all)?
 How much inventory to order for next week?
 Which item needs to be promoted?
 Our subscription renewal rate is declining
 Physicians are having problems accessing email from patients
10

Communication gaps between
developers and customers (users)
How the
customer
imagined
it
How the
customer
described
it
How the
analysts
designed
it
How the
programmers
built it
The final
product
11

The Systems Analyst: Skills
 Agents of change
 Identify ways to improve the organization
 Motivate & train others
 Skills needed:
 Technical: must understand the technology
 Business: must know the business processes
 Analytical: must be able to solve problems
 Communications: technical & non-technical audiences
 Interpersonal: leadership, management and collaboration
skills
 Ethics: deal fairly and protect confidential information
12

The Systems Analyst: Roles
 Business Analyst
 Focuses on the business issues
 Systems Analyst
 Focuses on the IS issues
 Infrastructure Analyst
 Focuses on the technical issues
 Change Management Analyst
 Focuses on the people and management issues
 Project Manager
 Ensures that the project is completed on time and within budget
13

© 2019 Cengage. All rights reserved.
How are applications built? Coding
• Computer programming or coding encompasses a broad set of activities that
include planning, coding, testing, and documenting
• The set of rules that specify the sequence of keywords, parameters, and
punctuation in a program instruction is referred to as syntax
• Watch coding video: https://www.youtube.com/watch?v=nKIu9yen5nc

Programming Basics

Compilers and Interpreters

Systems Active Learning Exercise (SALE) #1
Introduction to Programming
 Read the Active Learning Exercise#1 instructions on Canvas. Take
notes. DO NOT TAKE THE QUIZ UNTIL YOU’RE READY
 Install VS Code and write the bank account program. As you write
the code, respond to the questions by noting down your answers.
 Discuss your answers with your learning partner. Resolve any
issues.
 Pay attention to all the questions by responding with as much
detail as possible. Responses that are too brief may be penalized.
 Submit the answers to the Active Learning Exercise#1 on Canvas
as a team.
18

The Need for a Formal Process: The Systems
Development Life Cycle (SDLC)
Planning
Analysis
Design
Implementation
19

The SDLC Process
 The process consists of four phases
 Each phase consists of a series of steps
 Each phase is documented (deliverables)
 Phases are executed sequentially,
incrementally, iteratively or in some other
pattern
20

Questions to be Answered
 Planning phase
 Why should we build this system?
 What value does it provide?
 How long will it take to build?
 Analysis phase
 Who will use it?
 What should the system do for us?
 Where & when will it be used?
 Design phase
 How should we build it?
21

SDLC: The Planning Phase
Project Initiation
 Develop/receive a system
request
 Conduct a feasibility analysis
Project Management
 Develop the work plan
 Staff the project
 Monitor & control the project
22

SDLC: The Analysis Phase
1. Develop an analysis
strategy
 Model the current system
 Formulate the new system
2. Gather the requirements
 Develop a system concept
 Create a business model to
represent:
 Business data
 Business processes
3. Develop a system proposal
23

SDLC: The Design Phase
1. Develop a design strategy
2. Design architecture and
interfaces
3. Develop databases and
file specifications
4. Develop the program
design to specify:
 What programs to write
 What each program will do
24

SDLC: The Implementation
Phase
1. Construct the system
 Build it (write the
programming code)
 Test it
2. Install (deploy) system
 Train the users
3. Support the system
(maintenance)
25

SDLC: Methodologies
 Methodology: a formalized approach to
implementing the SDLC
 Categories
 Process oriented
 Data centered
 Object-oriented
 Structured
 Rapid action development
 Agile development
26

Classes of Methodologies
 Structured Development
 Waterfall Development
 Parallel Development
 Rapid Application Development
 Phased
 Prototyping
 Agile Development
 Scrum
 eXtreme Programming XP)
 Crystal methods
 Lean development
 Adaptive Software Development
 Dynamic Systems Development Methodology (DSDM)
 DevOps (not strictly a methodology)
27

Which Methodology to Use?
28

Classic Waterfall Model
29

Quiz: Disadvantage of the
Waterfall Methodology
 Think about three disadvantages of the Waterfall SDLC
Methodology
30

Early solution: Prototyping
31

What is Agile Development?
 Traditional approaches assume:
 We can anticipate the complete set of requirements
 Strive to drive variation out of processes
 Strive to force people and processes to the plan
 In real-life:
 Changes are inevitable
 Even clients do not know what they want
 External business environment causes change and variations – out of anyone’s control
 Agile development is about how to better handle inevitable changes throughout the life
cycle.
 Change is part of innovation
 Innovation is part of business
 Therefore, systems must be able to handle change
 Reduce the cost of rework while maintaining quality
 Conforming to plan no longer the primary goal – instead, satisfying customers at the
time of delivery, not at project initiation, takes precedence.
32

Agile’s Focus on People
 It’s the people who handles the change
 Individual competency – everyone is good at
something (find that talent)
 Capable team members will perform well in any
process, but poor processes and bad politics can kill
a project
 Leverage the interplay between talent, skill and
knowledge – capitalize on each individual and
team’s unique strengths
 Work jointly to improve the knowledge and skills of
individuals
 Learn the difference between communication and
collaboration
 Communication is the sending and receiving of
information.
 Collaboration is actively working together to
deliver a work product or make a decision
33

AGILE MANIFESTO
 Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.
 Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
 Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference to
the shorter timescale.
 Businesspeople and developers must work together
daily throughout the project.
 Build projects around motivated individuals. Give
them the environment and support they need and
trust them to get the job done.
 The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
 Working software is the primary measure of
progress.
 Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
 Continuous attention to technical excellence and
good design enhances agility.
 Simplicity--the art of maximizing the amount of
work not done--is essential.
 The best architectures, requirements, and designs
emerge from self-organizing teams.
 At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
34

History of Scrum
 Rugby metaphor how Japanese cut down product development time,
maintained or enhanced quality and built more innovative products (Fuji
copier, Canon copier, Honda)
 Built-in instability – challenging goals
 Self-organizing project team
 Autonomy – set own direction and tasks
 Self-transcendence – set goals and elevate
 Overlapping development phases -- intensive interaction
 Multilearning – within the group and across different functions and tasks
 Subtle control – establish checkpoints
 Transfer learning – document and institutionalize
35
Takeuchi and
Nonaka
(1986)

Scrum Team Roles
 Product Owner (Voice of the customer)
 Responsible for maximizing the value (return on investment) of the application. Makes the
commitment that product will be delivered
 In constant communication with customer, identifies product features, makes decisions based on
business changes
 Meets with team everyday to make sure they understand how the backlog and goals are changing
 Prioritize product features (deciding which one goes to the top of the backlog list) for the next
Sprint
 Continue to reprioritize and refine the list
 Scrum Master (“Servant leader”-serve the team, cannot be product owner, not project
manager)
 Commands respect of team members, manages team conflicts, develops the team
 Guides product owner, team enabler, ensures team can get on with real work
 Ensures development team has all the tools and resources they need
 Makes sure everyone follows Scrum practices, can be disruptive if need arises
 Team members (members in charge of creating the product)
 Skilled in their craft, fulfills its promises
 Consist of cross-functional members and includes all expertise necessary (programmers, UI
designer, testers)
 Self-organizing, each decide to commit
36

Scrum Concepts
 Product Backlog
 A prioritized list of what’s required ranked in order of value to the customer or business, with the
highest value at the top. It evolves over the lifetime of the project and items are continuously added,
removed or reprioritized
 The Sprint
 Cycles or iterations of work which are typically 1-4 weeks long. Sprints are fixed and end on a
specific date whether the work is completed or not; it is never extended (time-boxed)
 Sprint Planning
 Takes place at the beginning of every Sprint where the product backlog is reviewed, goals and
context are discussed and items from the Product Backlog are committed to be completed by the
end of the Sprint
 Daily Scrum
 Meeting which takes place every day for just 15 minutes in which everyone attends and the
outcome of which may result in replanning (what did you do? What will you do? Any problems?)
 Sprint review
 A meeting where the Scrum team and the stakeholders inspects what was done, discuss and decide
what to do next. Following the Spring Review, the team gets together for a Spring Retrospective
and agree on changes to try
 Release
 The product of every Sprint is working code that meets the standards of satisfaction
37

Sprint Retrospective
38

Scrum Artifacts (Deliverables)
 User Story
 Produced by product owner -- Quick and simple description of a specific way
that a user will use the system
 A story could be a use case (with user requirements and system requirements)
or just a paragraph that can fit into a 3X5 index card
 Include “conditions of satisfaction” on the back that gauges if the goals are
completed
 Product Backlog
 Produced by product owner’s – agenda that is clearly visible and accessible
 Includes functional and non-functional requirements
 Constantly changing due to external pressures and business demands
 Sprint Backlog
 Estimation of the size of the feature produced from a story using story points
(relative rating 1-5) based on effort (e.g., man hours), complexity, risk, etc.
 Prioritized list of tasks to work on based on the product backlog
 Produced by team members to be completed with the timebox
 Relatively stable in order to allow team members to complete in time
 Sprint burndown chart
 Visual representation of progress to track product development effort
remaining in a Sprint
39
Burndown chart

Sprint Burndown Chart
40

Scrum Steps
 Planning
 Solicit user stories
 Develop backlog list – define release date and functionality, select for immediate
development along with estimate of schedule and cost. Includes conceptualization
and analysis
 Develop feasibility report, assess risk and develop mitigation plan
 Design how backlog items will be implemented (refine system architecture and
complete high-level design)
 Develop sprint backlog and list of tasks
41

Scrum Steps …(cont’d)
 Perform Sprint
 Meet with teams to review release plans (distribute, review and adjust standards of satisfaction with
which the product will conform)
 Analysis and design of each packet (product component or objects that must be changed to implement
backlog item in a new release)
 Develop new release functionality
 Test each packet and document changes
 Close each packet and create executable versions and how they implement backlog requirements
 Hold daily scrum to present work and review progress, raise and resolve issues, add Sprint backlog items
 Review risk and appropriate responses, consolidate results from meeting into affected packets, including
new properties
 Hold Sprint Review
 Hold meeting with team, product management and possibly customers, sales, marketing and others
 Review features assigned to the team and include changes to implement Product Backlog items
 Introduce new backlog items based on required changes
 Set time for next review based on progress
 Closure
 Managers ensure that time, competition, requirements, costs and quality concur for the new release to
occur, declare the release ”closed”
 Prepare developed product for general release
 Complete integration, system test, user documentation, training materials and marketing materials.
42

Scrum workflow
43

Agile in the form of Scrum
44
Principles behind the agile manifesto
Scrum in 10 minutes
Introduction to Scrum in 5 min

From Waterfall to Extreme
Programming
45

12 Principles of XP
 1. Planning game – Customers decide scope
and timing of releases. Only implement
functionality demanded by stories
 2. Small releases – daily to monthly releases
feeding into the system that is put into
production in months (instead of years)
 3. Metaphor – instead of buzzwords, use
metaphors that can be used to create a
unified story and shared vision that people
can easily understand (e.g. system works like
a bakery)
 4. Simple design –say everything once and
only once, no duplicate code, fewest classes
and methods
 5. Test – write unit tests minute by minute,
automate it so it’s capable of accepting
change
 6. Refactoring - After adding a feature, the
developers ask if they can make the code
simpler. Restructure the system without
changing its behavior to remove duplication,
improve communication, simplify, or add
flexibility.
 7. Pair programming – the first (coder)
thinks about the best way to implement the
method, the second thinks strategically
about the approach and how to simplify
 8. Continuous integration – added into
current system and must pass tests or are
discarded
 9. On-site customer -- available full-time to
answer the questions, resolve disputes and
set small-scale priorities
 10. 40-hour weeks -- No one can work a
second consecutive week of overtime.
Ensures everyone is fresh, creative.
Frequent overtime is a sign of deeper
problems.
 11. Open workspace – Pair programmers
work in the center surrounded by cubicles
 12. Just rules – everyone agrees on how to
run the shop
46

XP Flow
 Development cycle – customer picks the next release by choosing
the most valuable features (stories) from all possible stories and
picks the next iteration based on cost and speed
 Programmers turn the stories into smaller grained tasks and test
cases which they accept responsibility for.
 Stories are use cases that can fit into an index card, must be
business-oriented, testable and estimable
 Release – items are stories that are priced, and budget is calculated
by measuring team’s output of estimated stories delivered per unit
time
 Iteration – put into production stories, programmers implement
tasks, integrate its code and test with current system. At the end, all
unit tests and functional tests run
47

Agile Approaches
48
Source: Learning
Agile by Stellman
and Greene 2015

DevOps
 Emerged as a result of dissatisfaction concerning poor deployment
of applications/products to the customer (too slow and error prone)
 Development had to wait for operations (production), operations
blame development for throwing code over the wall
 DevOps is a philosophy that integrates developers and operations
teams to think more alike (shared culture), improve collaboration,
automate workflows and measure application performance to
enable continuous and rapid deployment of small chunks of
software
 Introduction to DevOps
49

Copyright © 2020 John Wiley & Sons, Inc. All rights reserved. 50
Models and Modeling
 How do we define requirements? After collecting
information, create models
 Model– a representation of some aspect of the system
being built
 Types of Models
 Textual model– something written down, described
 Graphical models– diagram, schematic
 Mathematical models– formulas, statistics, algorithms
 Unified Modeling Language (UML)
 Standard graphical modeling symbols/terminology used for
information systems

Reasons for Modeling
 Learning from the modeling process
 Reducing complexity by abstraction
 Remembering all the details
 Communicating with other development team members
 Communicating with a variety of users and stakeholders
 Documenting what was done for future
maintenance/enhancement

Traditional Software Modeling
Methods
 Program flowchart
 Data Flow Diagram
(DFD)
52

Bank Account Program
Flowchart – Page 1
53

Bank Account Program
Flowchart - Page 2
54

Unified Modeling Language
 Provides a common vocabulary of object-oriented
terms and diagramming techniques rich enough to
model any systems development project from
analysis through implementation
 Version 2.5 has 15 diagrams in 2 major groups:
 Structure diagrams
 Behavior diagrams
55

Some Analysis and Design Models

UML Structure Diagrams
 Represent the data and static relationships in an
information system
 Class
 Object
 Package
 Deployment
 Component
 Composite structure
57

UML Behavior Diagrams
 Depict the dynamic relationships among the
instances or objects that represent the business
information system
– Activity
– Sequence
– Communication
– Interaction overview
– Timing
– Behavior state machine
– Protocol state machine,
– Use-case diagrams
58

UML Activity
Diagram
• The activity diagram can be used to
describe procedural logic (in a
program), business process, and
workflow.
• In many ways, they play a role similar
to flowcharts, but the principal
difference between them and
flowchart notation is that they support
parallel behavior.
• For procedural logic we will use only
a portion of the symbols that does not
include modeling parallel activities
59
Initial node
Activity
Decision
Final node
Transition
(connector)

Sample activity diagram portion
60

Do this!
 Work together to draw a program flowchart for the original
Bank Account program. Share the work with your learning
partner. Paste the completed diagram into a Word document
for submission to Active Learning Activity#1. This exercise
should help students learn how to:
 combine separate diagrams into one diagram
 Copy Visio diagrams into a Word document.
 Work together in your learning pair to modify the Bank
Account program to add new print balance, withdrawal and
deposit functions.
61

A paradigm shift: Why use
object-oriented methods?
 To understand why object-oriented methods are popular today, we need
to understand the differences between un-structured/structured
programming and object-oriented programming
 Both un-structured programming methods and object-oriented
programming can build the same system (e.g. bank account)
 What is the first step in improving the original bank account program?
Use structured programming (add some structure)
 Use functions
 Create new functions for withdrawals and deposits
 How can we extend the functions of the bank account system?
 Create new accounts, e.g. savings account
 Savings account will need new functions – calculate interest
 We can reuse existing code by applying object-oriented programming
 Create the account object that already contain withdrawal and deposit
”methods”
62

Object-Oriented
Systems Analysis & Design
 Attempts to balance data and process
 Utilizes the Unified Modeling Language (UML) and the
Unified Process
 Characteristics of OOAD:
 Use-case Driven
 Architecture Centric
 Iterative and Incremental
63

Characteristics of Object-
Oriented Systems
 Classes & Objects
 Object (instance): instantiation of a class
 Attributes: information that describes the class
 State: describes its values and relationships at a point in
time
 Methods & Messages
 Methods: the behavior of a class
 Messages: information sent to an object to trigger a
method (procedure call)
64

Oriented Systems (cont.)
 Encapsulation & information hiding
 Encapsulation: combination of process & data
 Information hiding: functionality is hidden
 Inheritance
 General classes are created (superclasses)
 Subclasses can inherit data and methods from a superclass
65

Oriented Systems (cont.)
 Polymorphism & dynamic binding
 Polymorphism: the same message can have different meanings
 Dynamic binding: type of object is not determined until run-
time
 Contrast with static binding
66

Quiz on Object Orientation
 Describe how each of the following could be implemented in
the bank account program:
 Encapsulation – demonstrate how a variable is hidden
 Instantiation – demonstrate how an object is created
 Inheritance – demonstrate how a class is inherited
 Methods and messages – demonstrate how a function (method)
is called
 Polymorphism
67

Object-Oriented Systems
Analysis & Design
 Use-case driven
 Use-cases define the behavior of a system
 Each use-case focuses on one business process
 Architecture centric
 Functional (external) view: focuses on the user’s perspective
 Static (structural) view: focuses on attributes, methods, classes
& relationships
 Dynamic (behavioral) view: focuses on messages between
classes and resulting behaviors
68

Object-Oriented Systems
Analysis & Design (cont.)
 Iterative & incremental
 Undergoes continuous testing & refinement
 The analyst understands the system better over time
 Benefits of OOSAD
 Break a complex system into smaller, more manageable
modules
 Work on modules individually
69

Systems Analysis and Design with UML

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Systems Analysis and Design with UML

Similar to Systems Analysis and Design with UML (20)

Recently uploaded

Recently uploaded (20)

Systems Analysis and Design with UML

Editor's Notes