Software Development Lifecycle Models Fall 2010

Question: We know that we have to do some things in order to get a software product completed: gather requirements Design Implement Test … How do you order these activities so that you are most productive?

One view Requirements Elicitation Requirements analysis Requirements specification Prototyping Architectural design Detailed design Implementation Unit testing Integration testing System testing Delivery Maintenance

What is a lifecycle model?

Some Models Code and fix Waterfall Prototyping RAD Incremental/evolutionary Reusable components Automated synthesis Spiral XP

0. Code and Fix (aka “cowboy”) Repeat write code fix it Until code is good enough or resources exhausted

1. Waterfall (traditional) First systematic approach, best studied. Winston Royce Some aerospace and government agencies mandate some form of this model. Must be adapted to a particular situation or organization.  

Waterfall Requirements Elicitation Requirements analysis Requirements specification Prototyping Architectural design Detailed design Implementation Unit testing Integration testing System testing Delivery Maintenance

Waterfall Phases Feasibility Specify Requirements Design Implement Test Deliver Maintain

Maintain (evolution?) Corrective: (fix bugs) 12% = “emergency fixes” 9% = routine debugging Adaptive: (secondary changes) 17% = change data formats 6% = hardware changes Perfective (improve) 5% = improvements in documentation 4% = improvements in efficiency   42% = change user requirements Preventive (form of Perfective)

2. Rapid Prototypes Gomaa and Scott (early 80s) Prototypes are throwaway. Build prototype, User feedback drives correction of requirements Toss the prototype Build system in traditional way

3. RAD Rapid application development: Used for short development cycle based on components and 4GLs. Used for Modeling: business, data, and process Application generation Testing/installation

3. RAD Difficult to scale to large projects. Works best when system can be modularized and is well understood (eg business apps) Does not work well when technical risks are high, system cannot be modularized, or interfaces to other systems are an issue.

4. Incremental/Evolutionary Recognized as desirable by government Incremental: design is totally laid out first Functionality is provided in stages Evolutionary: prototype evolves into final version  Goal: get feedback earlier in process repeat give user something evaluate/measure adjust design and objectives

Update Test documentation Incremental Development Iteration No. 1 2 3 867 868 Update SPMP1 Test whole Integrate Update Test documentation Test units Update source code Implement Design Update SDD2 Analyze requirements Update SRS3 1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5. Reusable software: build it from parts, this is the goal of the Ada project. need to have parts, specs for parts, and tools for accessing them. there are several methods of automating the lookup of parts specify as pre and post conditions

6. Automated Synthesis Transformations: KIDS, SPECWARE, HATS Start with a formal specification (mathematical) successively refine this (formally) until code may entail theorem proving may entail computer assisted software engineering environment Pre and post conditions First order specifications, etc

6. Automated Synthesis Programmer can no longer fix the code directly. Code is not result of coding, but of transforming. Change the specs and the code changes. Also correct by construction, proofs as programs

7. Spiral Barry Boehm (see IEEE Computer, vol 21, no 5, may 1988, pp61-72.) meta-model 4 stages in each cycle identify objectives and alternatives evaluate alternatives, identify risk, deal with risks develop, verify, prototype, use any model evaluate and plan next cycle  starts with hypothesis that something can be improved ends with product

Spiral Model Rapid prototype Specification Planning Design Implementation Integration Objective setting: for each phase--identify constraints, risk, management plan Risk Assessment and reduction Develop and Validate Planning: review project and decide whether to continue further in loop. Risk Analysis Verify Test

Spiral Model Focus on eliminating errors early Look at level of effort Accommodates growth and change (evolution) Restrictions In-house development (not contracted) Good for large-scale systems Requires training in risk analysis and resolution

Driving Forces waterfall: documentation driven evolutionary: increment driven transformational: specification driven spiral: risk driven

Classification of iterations (Classically called “phases”) USDP vs. Standard Terminology (Booch, Jacobson & Rumbaugh) Classification of iterations Individual iteration Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. ….. … Requirements Analysis USDP calls these “core workflows” (Classically called “phases”) Design Implementation Test

Requirements analysis USDP vs. Standard Terminology 2 of 2 USDP Terminology Classical Terminology Requirements Analysis Requirements analysis Design Implementation Test Design Implementation Integration Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Unified Process Matrix Jacobson et al: USDP Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. ….. ….. Requirements Analysis Amount of effort expended on the requirements phase during the first Construction iteration Design Implementation Test

Agile (1) moving quickly and lightly; (2) mentally quick; "an agile mind"; (3) Refers to the speed of operations within an organization and speed in responding to customers (reduced cycle times).

Agile Methods Agile is an iterative and incremental (evolutionary) approach to software development which [sic] is performed in a highly collaborative manner with "just enough" ceremony that produces high quality software which meets the changing needs of its stakeholders. http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

Values of Agile Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Outline of Agile Methods Minimize risk by developing software in short cycles Iterations typically last one to four weeks An iteration like a miniature software project includes planning, requirements analysis, design, coding, testing, and documentation. At the end of each iteration, the team re-evaluates project priorities

Communications Emphasize real time communication face-to-face rather than written documents All team members are co-located Programmers, testers, techwriters managers "customers" who define the product

Software Working software is the primary measure of progress Very little written documentation relative to other methods Criticism of agile methods: undisciplined May or may not be true

History Evolved in the mid 1990s Reaction against "heavyweight" methods such as waterfall Waterfall regimented and micromanaged Bureaucratic, slow Contradicts way SEs actually perform effective work Agile is a return to practices seen early in software development Is this good? Bad? 2001 meeting at Snowbird adopted name “agile” over “lightweight”

History Extreme Programming (XP) Not first, but most popular Established in 1966 by Kent Beck Tried to save the Chrysler C3 project (but didn’t) 1999 Elements of Extreme Programming

Different Agile Methods Created prior to 2000 Scrum Crystal Clear (1986) XP (1996) Adaptive Software Development Feature Driven Development DSDM (1885)

Some of the principles behind the Agile Manifesto Customer satisfaction by rapid (two weeks?), continuous delivery of useful software Working software is the principal measure of progress. Late changes in requirements are welcomed. Daily, face-to-face conversation is the best form of communication. Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design. Simplicity Self-organizing teams Regular adaptation to changing circumstances

Adaptive vs Predictive Methods Adaptive methods focus on adapting quickly to changing realities difficulty describing exactly what will happen in the future The further away a date is, the more vague an adaptive method will be. Team can report what tasks will be complete next week Team can report what features will be worked on next month Team cannot predict what features will be in the release 6 months out Predictive methods focus on planning the future in detail difficulty changing direction A predictive team can report exactly what features and tasks are planned for the entire length of the development process. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently.

Agile Contrasted with Iterative Build releasable software in short time periods Iterative time frames measured in months Agile Time frame in weeks Time frame is strict

Agile Contrasted with Waterfall Most predictive of methods: sequence of steps is highly planned Document driven: progress is based on delivery of documents after each stage Lengthy testing and integration phase at end of project Delivers fully implemented software at the end of the project Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration Agile Least predictive methods Feature driven: progress based on delivery of features Testing is part of feature development: no significant integration problems Delivers fully developed features (but small subset of them) each development cycle

Agile Contrasted with Cowboy "cowboy coding“ Cowboy coding is the absence of a defined method: team members do whatever they feel is right Success depends on heroics Agile Agile may be confused with cowboy Agile teams follow defined (and often very disciplined and rigorous) processes

Suitability of Agile Methods Organization must support negotiation People must be trusted Requires higher competence Organizations must live with the decisions developers make Organizations must support rapid communication Suitable for projects with small teams, with fewer than 20 to 40 people.

Agile vs Plan-driven Plan-driven Agile High criticality Junior developers Low requirements change Large number of developers Culture that demands order Agile Low criticality Senior developers Requirements change very often Small number of developers Culture that thrives on chaos

Some of the well-known agile software development methods: Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear and Other Crystal Methodologies Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean software development Agile Unified Process (AUP)

XP The main aim of XP is to reduce the cost of change.

XP Extreme Programming Explained describes Extreme Programming as being: An attempt to reconcile humanity and productivity A mechanism for social change A path to improvement A style of development A software development discipline

Five Values of XP Communication Simplicity Feedback Courage Respect

Activities Coding Testing Listening Designing

12 XP Practices Fine scale feedback Pair programming Planning Game Test drive development Whole team Continuous process Continuous integration Design improvement Small releases Shared understanding Coding Standards Collective code ownership Simple design System metaphor Programmer welfare Sustainable pace