Docstoc

Software Development Lifecycle Models

Document Sample
Software Development Lifecycle Models Powered By Docstoc
					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:
  – 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
                                       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
                                          Rapid prototype
                  Spiral Model            Specification
                                          Planning
                                          Design
1. Objective setting: for                 Implementation
   each phase--identify                   Integration

   constraints, risk,
   management plan
2. Risk Assessment and
   reduction
3. Develop and Validate
4. Planning: review project
   and decide whether to
   continue further in loop.   Risk        Verify
                               Analysis    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
USDP vs. Standard Terminology (Booch, Jacobson &
                   Rumbaugh)
                              Classification of iterations
  Individual iteration
                      Inception Elaboration Construction        Transition

                        Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. … Iter.
                      iterations #1       #n #n+1         #m #m+1       #k

       Requirements

           Analysis
                                         USDP calls these
                                         “core workflows”
             Design
                                        (Classically called
     Implementation
                                            “phases”)
               Test
              USDP vs. Standard Terminology 2 of 2

                         USDP                                                              Classical
                         Terminology                                                       Terminology

                         Requirements
                                                                                              Requirements analysis
                              Analysis

                                Design                                                                        Design
                                                                                                     Implementation
                       Implementation
                                                                                                       Integration
                                   Test                                                                          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. Iter. .. Iter. Iter.    …..      Iter. Iter. …..       Iter.
                 iterations #1       #n #n+1                 #m #m+1               #k


Requirements                                      Amount of effort expended
                                                  on the requirements phase
                                                  during the first Construction
   Analysis                                       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/agileSoftwar
            eDevelopment.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
• Iterative
   – Build releasable software in short time periods
   – Iterative time frames measured in months
• Agile
   – Build releasable software in short time periods
   – Time frame in weeks
   – Time frame is strict
      Agile Contrasted with Waterfall
• 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
Agile                             Plan-driven
• Low criticality                 • High criticality
                                  • Junior developers
• Senior developers
                                  • Low requirements change
• Requirements change very        • Large number of developers
  often
                                  • Culture that demands order
• 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     • Shared understanding
   – Pair programming        – Coding Standards
   – Planning Game           – Collective code
   – Test drive                ownership
     development             – Simple design
   – Whole team              – System metaphor
• Continuous process      • Programmer welfare
   – Continuous              – Sustainable pace
     integration
   – Design improvement
   – Small releases

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:29
posted:6/17/2012
language:English
pages:47