1. Approaches to Systems Development
Chapter 10

2. Outline Introduction Ch 10 - Approaches to System Development
Systems Analyst
Ch 10 - Approaches to System Development
SDLC
Predictive vs Adaptive Approaches
Agile Methodologies
RUP XP
Scrum

3. Systems Analyst

4. 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)

5. …more of a business problem solver than a technical programmer
Systems Analyst
…more of a business problem solver than a technical programmer
Knowledge & Skills
Technical
DB, Programming, Computers Hardware, Networking, 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

6. Development Projects & the SDLC

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

8. SDLC: Systems Development Life Cycle
Provides overall framework for managing systems development process
All projects use some variation of SDLC
Phase
Project Initiation
Planning
Analysis
Design
Implementation
Deployment
Core Process
1. Identify the problem/need & obtain approval
2. Plan & monitor the project
3. Discover & understand the details
4. Design the system components
5. Build, test, and integrate system components
6. Complete system tests and deploy solution
Ch 11
Ch 11
Ch 2-5
Ch 6, 8-9,12-13
Ch 13
Ch 14

9. 2 Approaches to the SDLC Assumptions Assumptions Predictive SDLC
Adaptive SDLC
Waterfall Model
Modified Waterfall
Spiral Model
Incremental Development
Assumptions
can be planned in advance
system can be developed according to the plan
Assumptions
Iterative
Must be flexible & adapt

10. Predictive Approaches
Waterfall
Support
Deployment
Planning
Analysis
Design
Implementation
Project Initiation
One phase begins when another completes; Specifications are frozen
Problems
System requirements “locked in”
Limited user involvement
Too much focus on milestone deadlines
Modified Waterfall
Overlapping phases
Can go backwards
Support
Deployment
Planning
Analysis
Design
Implementation
Project Initiation

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

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

13. Methodology
A comprehensive guideline to follow for completing every SDLC activity
Abstraction used
to separate out
aspect
Methodology
Models
Techniques
Tools
Software to
create models
or other project
components
Guidelines
or instructions

14. Agile Methodologies

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

16. Agile Methodologies
These are complete adaptive development methodologies that incorporate Agile principles:
Rational Unified Process (RUP)
Extreme Programming
Scrum
They are iterative, incremental, and agile

17. Rational Unified Process (RUP)
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
4 Phases
9 Disciplines
Inception
Elaboration
Construction
Transition
A&D of Core
Reqs -Use Cases
Coding
Solve Tech, Perf,
Reliability concerns
Scope & Prelim est.
User acceptance testing,
Deploying
Each phase can consist of one or more iterations.

18. Extreme Programming (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
4 Core Values
Open & frequent
Keep it simple
From Client, users, developers
Courage to do it right; re-do if necessary

19. XP - 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. XP Project Approach Project Release # Iteration # User Stories5
Iteration2 2
Release2 3 4
Iteration3 1

21. final release is deployed!
XP Project Approach
Project
Release #
Iteration #
User Stories
Project1
Release1
Iteration1 5
Iteration2 2
Release2 3 4
Iteration3 1
Outer layer – 1x per PROJECT
Create all user stories
Create system metaphor
Create all acceptance tests
Plan all releases
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!
Inner Layer – 1x per ITERATION
Code & unit test each user story
Integration testing of user stories
Project ends when the
final release is deployed!

22. Scrum
Scrum
An iterative and incremental agile SW development methodology
frequent releases in short development cycles: 2-week sprints
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
Development 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
Main Concepts:
Product Backlog - Prioritized list of user requirements
Development Team has complete control over organization & work processes

23. 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 – 2 weeks, 4 weeks

24. Scrum - Meetings Sprint Planning - 8 hours before the Sprint
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 beginning of day
Purpose: Daily status update between the development team: Yesterday, Today, Barriers
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

25. XP vs Scrum XP Scrum Work Units Rate of Change
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)
No additions allowed once sprint has started but can remove a feature
Order of Features within an iteration
Features prioritized by the customer
Must work on features in order!
Features prioritized by the Product Owner
Dev Team determines the sequence (but typically works on priority)
SW Engineering Practices
12 Principles: test-driven development, pair programming, etc.
No engineering practices prescribed
But it can be combined w/XP practices