Approaches to Systems Development Chapter 10

Outline Ch 10 - Approaches to System Development SDLC Predictive vs Adaptive Approaches Agile Methodologies RUP XP Scrum

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

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

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

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

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

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

Agile Methodologies

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: Rational Unified Process (RUP) Extreme Programming Scrum They are iterative, incremental, and agile

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.

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

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

XP Project Approach Project Release # Iteration # User Stories 5 Iteration2 2 Release2 3 4 Iteration3 1

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!

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

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

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 mins @ 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

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