Approaches to
Systems Development
Chapter 10
Outline
Introduction
 Systems Analyst
Ch 10 - Approaches to System Development
 SDLC
− Predictive vs Adaptive Approaches
 Agile Methodologies
2
Systems Analyst
3
Systems Analyst
Organizational role most responsible for
the analysis & design of information systems.
 Translates a _________ __________ into an
___________ ___________ ___________ .
 Job Titles
− vary by organization; read the job description
• Systems Analyst
• Business Analyst (client-facing)
4
Systems Analyst
…more of a business problem solver
than a technical programmer
Knowledge & Skills
• DB, Programming, Computers Hardware, Networking,
TECHNICAL
Operating systems, and utilities, Communication &
collaboration technology
• SDLC techniques
BUSINESS
• Organizational knowledge, Management techniques,
Functional work processes
PEOPLE
• Communication skills, Interpersonal Skills
• Roles: Negotiator, Teacher, Mentor, Collaborator, Manager
5
Development Projects
& the SDLC
6
Information System Development Project
 What is it?
− It's a planned undertaking
− Has fixed beginning and end
− Produces desired result or product
 It can differ in…
− Features
− Size
− Cost
− Resources
7
SDLC: SYSTEMS DEVELOPMENT LIFE CYCLE
 Provides overall framework for managing systems development
process
 All projects use some variation of SDLC
Phase
Core Process
Project Initiation
1. Identify the problem/need & obtain approval
Ch 11
Planning
2. Plan & monitor the project
Ch 11
Analysis
3. Discover & understand the details
Ch 2-5
Design
4. Design the system components
Ch 6, 8-9,12-13
Implementation
5. Build, test, and integrate system components
Ch 13
Deployment
6. Complete system tests and deploy solution
Ch 14
8
2 Approaches to the SDLC
Predictive SDLC
Adaptive SDLC
•
Waterfall Model
•
Spiral Model
•
Modified Waterfall
•
Incremental Development
Assumptions
• can be planned in
advance
• system can be
developed
according to the
plan
Assumptions
• Iterative
• Must be
flexible &
adapt
9
Predictive Approaches
Project
Initiation
Waterfall

Planning
One phase begins when another completes;
Specifications are frozen
Problems

System requirements “locked in”

Limited user involvement

Too much focus on milestone deadlines
Analysis
Design
Implementati
on
Deploymen
t
Support
Modified Waterfall


Overlapping phases
Can go backwards
Project
Initiation
Planning
Analysis
Design
Implementation
Deployment
Support
10
Adaptive Approaches
Spiral Model
 An iterative approach
 Spiral until project completion
− Then, deployed!
 Project Management:
− managed differently than a waterfall approach
Note: An iteration contains the complete SDLC
11
Adaptive Approaches
Incremental Development
 Also, an iterative approach
 BUT…System is built in small increments; it is "grown"
• As an iteration is completed it is integrated to the whole
• Partially deployed in steps
 Advantage
− some functionality gets
into the user's hands
much earlier
12
Methodology
A comprehensive guideline to follow for completing
every SDLC activity
Abstraction used
to separate out
aspect
Models
Methodology
Software to
create models
or other project
components
Tools
Techniques
Guidelines
or instructions
13
Agile Methodologies
14
Agile Philosophy
A guiding philosophy and set of guidelines for :
 developing information systems
in an unknown, rapidly changing environment
− complements Adaptive SDLCs & Methodologies
− makes sure developers are fast to respond to changes
“Manifesto for Agile Development”  agilemanifesto.org
−Value responding to change over following a plan
−Value individuals and interactions over processes and tools
−Value working software over comprehensive documentation
−Value customer collaboration over contract negotiation
Agile Methodologies
These are complete adaptive development
methodologies that incorporate Agile principles:
 Unified Process
 Extreme Programming
 Scrum
 They are iterative, incremental, and agile
16
Unified Process (UP)
Unified Process (UP)
 An object-oriented systems development methodology
 Invented by 3 Amigos:
− Grady Booch, James Rumbaugh, & Ivar Jacobson
• Rational Software, which is now owned by IBM
• Also, invented UML
17
Unified Process (UP)
4 Phases
9 Disciplines
Incepti
on
Elaboration
Scope & A&D of Core
Prelim Reqs
est.
-Use Cases
Construction
Coding
Solve Tech, Perf,
Reliability
concerns
Transiti
on
User acceptance
testing,
Deploying
Each phase can consist of one or more iterations.
18
Extreme Programming (XP)
XP
 An iterative and incremental agile SW development
methodology
− With frequent releases in short development cycles: 2-week iterations
− Main Concepts:
• 4 Core Values
• 12 Software Engineering Practices
• extends these “to the extreme”
• Emphasizes
Software quality
Keep it simple
4 Core Values
Open & frequent
From Client,
users,
developers
Courage to do it right;
re-do if necessary
19
XP's 12 Software Engineering Practices
 Planning – quick rough plan; develop user stories; heavily involve users
 Testing – "user story" tests written before coding; can be re-run anytime
 Test-Driven Development & Automated Testing
 Pair Programming – one writes (driver), one inspects (navigator), trade turns
 Simple Designs – few classes & methods, no duplicate code
 Refactoring – improving code quality without changing what it does
 Owning Code Collectively – allows anyone to improve code
 Continuous integration – unit-tested code is integrated daily
 On-site customer – customer must commit to the project
 System metaphor –have an easily-understood vision in laymen's terms – e.g. assembly line
 Small Releases – small & frequent deployment
 40-Hour Work Week – don’t overload the developers
 Coding standards – follow standards
20
Scrum
 Scrum
 An iterative and incremental agile SW development methodology
− frequent releases in short development cycles: 2-week sprints
− Main Concepts:
• Team has complete control over organization & work processes
• Product Backlog - Prioritized list of user requirements
Organization
• Product Owner - client stakeholder who controls the Product Backlog
• Scrum Master - Scrum project manager
• a facilitator, removes impediments, resolves issues
• However, the Scrum Team does the schedule
• Scrum Team - 5 to 9 developers, testers, architects, designers, etc.
• Small self-organizing teams; have all the skills necessary
• They ultimately decide what goes in a Sprint
• Can have more than 1 team in larger projects
21
Scrum Sprint
Sprint - A time-controlled mini-project to implement part of the system
•
Scope is frozen (but can be reduced)
• Time period is kept constant
Task Board
Product
Backlog
ToDo
Done
Sprint
Backlog
50
Sprint
Planning
Meeting
Product
Owner
WIP
7
Scrum master
Scrum team
Incremental
Software
Product
2 to 4-wk.
Sprint
Sprint
Sprint
Review Retrospective
(“Demo”)
Daily Scrum
(“Stand-up”)
22
Scrum Meetings
Time: assumptions are for a 1-month sprint
 Sprint Planning - 8 hours before the Sprint
 Purpose: Creating the Sprint Backlog
− Part I: Product Owner presents the desired set of User Stories & the acceptance criteria for each story.
− Part II: Dev Team takes each story & breaks them into tasks; creates time estimates per task;
finalizes the user stories they can commit to.
• Dev Team gets to say if there are details lacking in the user stories & cannot commit to certain stories
− Attended by: Scrum Master, Development Team, Product Owner
 Daily Scrum (“Stand-Up”) - 15 mins @ beginning of day
 Purpose: Daily status update between the development team: Yesterday, Today, Barriers
− Attended by: Scrum Master, Development Team, Product Owner
 Sprint Review (“Demo”) – 4 hours at the end of the Sprint
 Purpose: a demo to inspect & adapt the product; additions to product backlog may be
identified.
− Attended by: Scrum Master, Development Team, Product Owner PLUS: stakeholders, management and
developers from other teams
 Sprint Retrospective - 3-hours at the end of the Sprint
 Purpose: process improvement - lessons learned, successes and failure
− Attended by: Scrum Master, Development Team
23
XP vs Scrum
XP
Scrum
Work Units

Iteration = 2 weeks

Sprints = 2 to 4 weeks
Rate of Change

Can add a feature of equal size
(for an unstarted feature within
an iteration)

Order of
Features within
an iteration

Features prioritized by the
customer
Must work on features in order!

No additions allowed
once sprint has started
but can remove a
feature
Features prioritized by
the Scrum product
owner

SW Engineering  12 Principles: test-driven
Practices
development, pair programming,
etc.

Team determines the
sequence (but typically
works on priority)

No engineering practices
prescribed

But it can be combined
w/XP practices
24
Review these slides
with the textbook
25
XP Project Approach
26
Project
Iteration #
User
Stories
Iteration1
5
Iteration2
2
Iteration1
3
 Create all acceptance tests
Iteration2
4
 Plan all releases
Iteration3
1
XP Project Approach
Release #
Project1
Release1
 Outer layer – 1x per PROJECT
Release2
 Create all user stories
 Create system metaphor
 Loop thru each RELEASE (Middle Layer)
 Middle Layer – 1x per RELEASE
 Plan all iterations
 Loop thru each ITERATION (Inner Layer)
 Acceptance testing of the Release
 Deploy the Release!
Project ends when the
final release is deployed!
 Inner Layer – 1x per ITERATION
 Code & unit test each user story
 Integration testing of user stories
27