Development Lifecycle Models

Document Sample
Development Lifecycle Models Powered By Docstoc
					CSC 4900: Advanced Software

            Fall 2009
            Dr. Chuck Lillie
                     Course Outline
             Goals:
               –   Comprehend quality software development methodologies.
               –   Apply software engineering principles.
               –   Construct a quality software product.
             Objectives:
               –   By the end of this course the student should be able to:
                       Recognize and define five major software development lifecycle models.
                       Evaluate a Statement of Work (SOW) and determine project requirements.
                       Create a Work Breakdown Structure (WBS) for a software project.
                       Develop a software requirements analysis document.
                       Design and document a software project.
                       Write and execute a software test plan.
                       Implement a programming project using an established software development
             Evaluation
                       Weekly Progress Reports   20%
                       Programming Project       40%
                       Team Evaluation           20%
Chart 2
                       Final Exam                20%
                   Course Outline

             Two Parts
              –   Software Development Process
                      Problem Definition
                      Requirements Analysis
                      Development Lifecycle
                      Program Management
              –   Major Programming Project
                      Each Team will Select Project
                      Project Definition and Planning
                      Implementation
                         –   Status Reports
                      Testing
                      Project Presentation
Chart 3
                   Major Programming Project

             Weekly Progress Reports
              –   Every Wednesday
              –   Different Team Member
             Statement of Work*
             Requirements Specification*
             Work Breakdown Structure (WBS)*
             Technical Specification Documents (Design Document)*
             Development Schedule and Plan*
             Test Plan*
             Test Report*
             Code                        * This document will have a
             User’s Manual*              peer review report attached
Chart 4
                   Past Projects

             Budget Planning and Reporting System
              –   Move spreadsheets to web
              –   Allow update function across all divisions
              –   Propagate updates to composite worksheet
             Use web to inform out of state students of how to get from
              point a to point b
              –   Include foreign language capability
             Web-based multimedia presentation of entertainment
              content for children ages 4-8
             Electronic Grade Book for Primary & Secondary School
             Web-based product to manage sale of merchandise
              –   Track inventory
              –   Determine when to reorder
             Web-based recipe system
             Electronic Message Board
Chart 5
                   Suggested Project: iPod Touch

             Write an application for the iPod Touch
              –   Second life application
              –   Other suggestions
             What is needed
              –   Access to Apple desktop computer
                      Needed for iPod development environment
                      Old Main Room 237 and other locations on campus
                         –   Not in Oxendine
              –   Knowledge of iPod interfaces (APIs)
              –   Knowledge of Second Life interfaces (APIs)
              –   Can Second Life be accessed from iPod?
                      On-going projects for last two or three years
Chart 6
                   iPod Touch Background

             Background:
              –   Link to the Apple iPhone Development page:
                  Register to be a iPhone developer
             Download the SDK
             Read the following documents:
             Getting started doucments
              –   Getting started with iPhone
              –   Getting started with tools
              –   Getting started with data management

Chart 7
                   Major Decision Point: August 31, 2009

             What is needed to write an interface of Second Life to
              –   How long will it take?
              –   What are the resources required?
                      Person hours
                      Tools
                      Knowledge
              –   What can be accomplished in one semester? Two semesters?
                      Can this be structured as a phased approace or incremental
                       development project?
                         –   What are the phases or increments?

             Any other projects that could support Mass

Chart 8
                   Why do Software Engineering

             Microsoft Word 1.0 (WinWord)
             Directive to team
              –   Develop best word processor ever
              –   Within 12 months
             Problems
              –   Unachievable goals
              –   Project size of WinWord takes at best 460 days
                      The highest estimate for WinWord was 395 days
                      Actually took 5 years and 660 man-months
              –   High turnover
                      Four managers in five years
              –   Took 12 months in stabilization vice 3 months
Chart 9
           Lecture 1

Chart 10
                  General Development Strategy

              Select/Customize a Process
              Create Best Possible Schedule
              Avoid Classic Mistake
              Understand Development Fundamentals
              Identify and Mange Risk Factors
              Follow Schedule Oriented Practices

Chart 11
                  Software Development
                  Fundamentals – Three Areas

              Management
              Technical
              Quality-Assurance

Chart 12
                  Management Fundamentals

              Planning
              Estimation and Scheduling
              Tracking
              Measurement

Chart 13
                  Technical Fundamentals

              Requirements Management
              Design
              Construction
              Software Configuration Management

Chart 14
                    Quality-Assurance Fundamentals

              Identify Error-Prone Modules
              Design and Conduct Testing
              Technical Reviews
               –   Walkthroughs
               –   Code Reading
               –   Inspections

Chart 15
               Software Development Activities

            Problem Definition
            Requirements Analysis
            Implementation Planning
            High-level Design (or Architecture)
            Detailed Design
            Coding and Unit Testing (Debugging)
            Integration and System Testing
            Deployment and Maintenance
            Documentation, Verification, Management
Chart 16
                    Problem Definition

              A clear statement of the problem
              Defines problem without any reference to solution
              Should be in user’s language
               –   Not in technical terms
              This is typically in Statement of Work (SOW)

                        Failure to define problem may cause
                          you to solve the wrong problem
Chart 17
                   Requirements Analysis

              This is the what is to be solved
              Helps ensure that the user rather than the
               programmer drives system’s functionality
              Helps avoid arguments
              Minimizes changes to the system after
               development begins
              Change is inevitable
               –   Set up change-control procedure
               –   Use development approaches that accommodate

           Specifying requirements adequately is a key to project success
Chart 18
                     Implementation Planning

              Defines how the product will be implemented
              Establishes development schedule
              Identifies resources required
               –   Labor hours and people
               –   Other direct costs
              Estimated budget
              Create Work Breakdown Structure (WBS)
                   This is the roadmap that will be used throughout
                   the development process. Without a roadmap you
                   don’t know where you are going and you won’t
                   know that you arrived.
Chart 19
                     High-level Design
                     (or Architecture)

              This is how to solve the problem
               –   (recall that requirements is the what is to be solved)
              Defines the overall organization of the system in
               terms of high-level components and interactions
              All design levels are documented in specification
               documents that keep track of design decisions

                   High-level and detail-level are usually not separated

Chart 20
                    Detailed Design

              Components are decomposed into lower level
              Precisely defined interactions
              Interfaces are defined
              Constraints are identified

               The purpose of the design phase is to specify a particular
               software system that will meet the stated requirements

Chart 21
                   High Level Design for a Compile

              Source code

                            Parser           Semantic                        Symbol
                                            parse tree

                               Intermediate Code
                                                                          Semantic Analyzer
                                            intermediate representation

                                            intermediate representation

                                Assembly Code                             Type checking
           Assembly code

Chart 22
                   Coding and Unit Testing

              Produces the actual code that will be delivered to
               the customer
              Typically develop modules that are independently

               Results in an implemented and tested collection of modules

Chart 23
                   Integration and System Testing

              All the modules that have been developed and
               tested individually are put together – integrated –
               and are tested as a whole system
              Integrated and tested progressively (on larger
               sets of modules)
              Some coding may be necessary to complete the

                   The final stage is “actual” use or alpha testing.

Chart 24
                    Deployment and Maintenance
              Deployment: defines the physical run-time architecture of
               the system
               –   Set proper system parameters
               –   Install applications
              Maintenance: long-term development
               –   60% of total cost of software is maintenance
               –   Cost of maintenance:
                       40% to changes in user’s requirements
                       17% to changes in data formats
                       12% to emergency fixes
                       9% to routine debugging
                       6% to hardware changes
                       5% to improvements in documentation
                       4% to improvements in efficiency
                       7% to other sources

Chart 25
                    Documentation, Verification,
              Common to all the other activities
              Documentation
               –   Main result of any activity – each activity products at least one
              Verification and Validation
               –   Verification: Assessment of the internal correctness of process
               –   Validation: how the product responds to needs of customer
               –   Performed as quality control as reviews, walk-througs, and
               –   Discovery and removal of errors as early as possible
              Management
               –   Budget, schedule, resources

Chart 26
           Lecture 2

Chart 27

              Requirements Analysis   2/7/2007
              Architectural Design    2/21/2007
              Detailed Design         2/21/2007
              Implementation          4/11/2007
              Testing                 4/20/2007
              Demo                    4/23/2007
              Delivery                4/27/2007

Chart 28
                  Development Lifecycle Models

              Waterfall (Pure Waterfall)
              Spiral (Spiral)
              Evolutionary (Evolutionary Prototype)
              Incremental (Staged Delivery)
              Commercial-off-the-shelf (COTS) Integration
              Rehost/port
              Reengineering
              Automated Application Generation (AAG)
              Maintenance
Chart 29
                  Development Lifecycle Models
                  -- Features

          Requirements are defined first
          Multiple internal development cycles
          Multiple customer deliveries
          Functional content primary driver
          Process primary driver

Chart 30
                   Development Lifecycle Models
                   – Selection Criteria
          Does the system have a precedent (I.E., Have similar
           systems been built before)?
          Is the technology understood and stable?
          Are the requirements understood and stable?
          Are suitable COTS products available and ready to be
           used in end products?
          Is this a large or complex project or product?
          Is the project fully funded at startup?
          Is the project cost or schedule constrained and
           requirements cannot be reduced?
          Is there a need for engineering subprojects driven by risk
           identification and mitigation?
          Is the existing system’s maintenance cost too high/is her
           a need to facilitate future system enhancements?
Chart 31

              Description
               –   An orderly sequence of steps from the initial software
                   concept through system testing
               –   A review at the end of each phase
               –   Document driven
               –   Phases are discontinuous

Chart 32
              Advantages
               –   Helps minimize planning overhead
               –   Works well for projects that are well understood buy
               –   Works well when quality requirements dominate cost
                   and schedule
               –   Works well if you have a technically weak staff
              Disadvantages
               –   Have to fully specify requirements at beginning of
               –   Waterfall model isn’t flexible
               –   Generates few visible signs of progress until the very
Chart 33
               –   Excessive amount of documentation
                   Waterfall Model




                                                                   And Testing

                                                                                 System Testing

Chart 34

              Description
               –   A metamodel that can accommodate any
                   process development model
               –   A particular model is chosen based on level of
               –   Spiral model is cyclic
               –   Four stages
                     Objectives identified
                     Alternatives evaluated and risk areas identified
                     Develop and verify next level of product
                     Review and plan for next iteration

Chart 35

Chart 36

              Advantages
               –   Requirements not well understood
               –   Risks not known
               –   As costs increase risks decrease
               –   Provides management insight
              Disadvantages
               –   Difficult to use for contracted software
                       Don’t know the outcome at beginning of project
                       Only as good at mitigating risk as engineers are at identifying

Chart 37

              Description
               –   Develop system concept as you move through the
               –   Develop prototypes including real requirements
                   analysis, real design, and real maintainable code
              Advantages
               –   Manage changing requirements
               –   Unsure of optimal architecture or algorithms
               –   Produces steady, visible signs of progress
              Disadvantages
               –   Don’t know time required to complete project
               –   Can become an excuse to do code-and-fix
Chart 38

                   Design and        Refine
           Initial                    Refine
                   implement           Refine
                                     prototype until
                                         Refine        Complete
           concept                    prototype until
                                       prototype until
                   initial prototype acceptable until and release
                                         acceptable    prototype

Chart 39

              Description
               –   Also known as Staged Delivery
               –   Deliver software in successive stages throughout the
              Advantages
               –   Put useful functionality into hands of customer early
               –   Provides tangible signs of progress
              Disadvantages
               –   Won’t work without careful planning
               –   Determining stage dependencies

Chart 40




                      Stage 1: Detailed design,. Code, debug, test, and delivery

                      Stage 2: Detailed design,. Code, debug, test, and delivery

Chart 41
                      Stage n: Detailed design,. Code, debug, test, and delivery
                  Commercial-off-the-shelf (COTS)

              Description
              Advantages
              Disadvantages

Chart 42

              Description
              Advantages
              Disadvantages

Chart 43

              Description
              Advantages
              Disadvantages

Chart 44
                    Automated Application
                    Generation (AAG)

              Description
              Advantages
              Disadvantages

Chart 45

              Description
              Advantages
              Disadvantages

Chart 46
           Lecture 3

Chart 47

              Size Estimation
              Effort Estimation
              Schedule Estimation

                 Most projects overshoot their estimated
                 schedules by anywhere from 25% to 100%

                 Without an accurate schedule estimate, there is
                 no foundation for effective planning

Chart 48
              Constructing software is like constructing a house: you
               can’t tell exactly how much it is going to cost until you
               know exactly what “it” is.
              As with building a house, you can either build your dream
               house – expense be hanged – or you can build to a
               budget, you have to be very flexible about the product
              Whether you build to a budget or not, software
               development is a process of gradual refinement, so some
               imprecision is unavoidable. Unlike building a home, in
               software the only way to refine the product concept and
               thereby the estimate is to actually build the software.
              Estimates can be refined over the course of a project.
               Promise your customer that you will provide more refined
               estimates at each stage.
Chart 49
                    Estimation Process

              Estimate the size of the product (number of lines
               of code or function points)
               –   First need to estimate the size of the program to be
              Estimate the effort (man-months)
               –   Need accurate size estimates and historical data on
                   past projects
              Estimate the schedule (calendar months)
               –   With size and effort estimates, schedule is easy
               –   Selling the schedule is HARD
              Provide estimates in ranges and periodically
               refine the ranges to provide increasing precision
Chart 50
               as the project progresses
                   Size Estimation

              Use an algorithmic approach, such as function
               points, that estimates program size from program
              Use size-estimation software that estimates
               program size from your description of program
               features (screens, dialogs, files, database tables,
              Estimate each major piece of the new system as
               a percentage of the size of a similar piece of an
               old system. Add the pieces to get the total size.
                  Size estimation should be in terms of lines-of-code
Chart 51
                   Estimation Tips

              Avoid off-the-cuff estimates
              Allow time for the estimate, and plan it
              Use data from previous projects
              Use developer-based estimates
              Estimate by walk-through
              Estimate by categories
              Estimate at a low level of detail
              Don’t omit common tasks
              Use software estimation tools
              Use several different estimation techniques, and compare
               the results
              Change estimation practices as the project progresses
Chart 52
                  Effort Estimation

              Use estimation software to create an effort
               estimate directly from the size estimate
              Use organization's historical data to determine
               how much effort previous projects of the
               estimated size have taken
              Use an algorithmic approach such as Barry
               Boehm’s COCOMO model or Putnam and Myer’s
               lifecycle model to convert a lines-of-code
               estimate into an effort estimate
                  Effort estimates should be in terms of man-months
Chart 53
                    Schedule Estimation

              Size estimate: 65,000 lines of code
               –   One programmer can produce 1000 lines of code in one month
               –   65,000/1000 = 65 man-months
              Can get schedule estimate from effort estimate with the
               following equation
               Schedule in months = 3.0 * man-months1/3
              Example
               –   65 man-months to build project
               –   12 months = 3*651/3 -- (651/3 = 4.0207)
              65 man-months / 12 months = 5 or 6 team members

               One of the common problems with schedule estimates is
               that they are usually done so crudely that people pad them
               to give themselves a margin of error.
Chart 54
           Lecture 4

           Risk Management

Chart 55
                    Risk Management

                                               Risk Identification

                             Risk Assessment   Risk Analysis

                                               Risk Prioritization

           Risk Management

                                                Risk Management Planning

                             Risk Control       Risk Resolution

                                                Risk Monitoring

Chart 56
                    Risk Identification

              Most Common Schedule Risks
               –   Feature creep
               –   Requirements or development gold-plating
               –   Shortchanged quality
               –   Overly optimistic schedules
               –   Inadequate design
               –   Silver-bullet syndrome
               –   Research oriented development
               –   Weak personnel
               –   Contractor failure
               –   Friction between developers and customers
Chart 57
                    Risk Analysis

              Risk identified
               –   Probability of loss (%)
               –   Size of loss (weeks or dollars or …)
               –   Risk exposure (weeks or dollars or …)

Chart 58
                  Risk Prioritization

              Helps to identify the most important risks
              Plan mitigation
              Assign resources as needed

Chart 59
                    Risk Control

              Risk management planning
              Risk resolution
               –   Avoid the risk
               –   Transfer the risk from one part of a system to another
               –   Buy information about the risk
               –   Estimate the root cause of the risk
               –   Assume the risk
               –   Publicize the risk
               –   Control the risk
              Risk monitoring

Chart 60
                   Steps in risk management

         Risk assessment Risk identification  Assumption analysis
                                              Decision driver analysis
                                                System dynamics
                                                Performance models
                                                Cost models
                          Risk analysis         Network analysis
                                                Decision analysis
     Risk management                            Quality risk factor analysis
                          Risk prioritization Risk exposure
                                              Compound risk reduction
                                                 Buying information
                                                 Risk avoidance
                          Risk reduction         Risk transfer
                                                 Risk reduction leverage
                                                 Development process
             Risk control Risk management planning Risk element planning
                                                    Risk plan integration
                                                Risk mitigation
                          Risk resolution       Risk monitoring and reporting
Chart 61
                                                Risk reassessment
           Example of risk exposure calculation

Chart 62
           Lecture 5

            Classic Mistakes

Chart 63
                  Classic Mistakes

              People related mistakes
              Process related mistakes
              Product related mistakes
              Technology related mistakes

Chart 64
                   Classic Mistakes
                   People Related Mistakes

              Undermined motivation
              Weak personnel
              Uncontrolled problem personnel
              Heroics
              Adding people to late project
              Noisy, crowded offices
              Friction between developers and customers
              Unrealistic expectations
              Lack of effective project sponsorship
              Lack of stakeholder buy-in
              Politics placed over substance
              Wishful thinking
Chart 65
                   Classic Mistakes
                   Process Related Mistakes

              Overly optimistic schedules
              Insufficient risk management
              Contractor failure
              Insufficient planning
              Abandonment of planning under pressure
              Wasted time during the fuzzy front end
              Shortchanged upstream activities
              Inadequate design
              Shortchanged quality assurance
              Insufficient management controls
              Premature or overly frequent convergence
              Omitting necessary task from estimates
              Planning to catch up later
              Code-like-hell programming
Chart 66
                  Classic Mistakes
                  Product Related Mistakes

              Requirements gold-platting
              Feature creep
              Developer gold-platting
              Push-me, pull-me negotiation
              Research-oriented development

Chart 67
                  Classic Mistakes
                  Technology Related Mistakes

              Silver-bullet syndrome
              Overestimated savings from new tools or
              Switching tools in the middle of a project
              Lack of automated source code control

Chart 68
           Lecture 6

              Best Practices

Chart 69
                        Best Practices

              Change Board
               –   Group that controls changes to software
               –   Efficacy
                       Potential reduction from nominal schedule:   Fair
                       Improvement in progress visibility:          Fair
                       Effect on schedule risk:                     Decreased Risk
                       Chance of first-time success:                Very Good
               –   Major Risk
                       Approving to few or too many changes

Chart 70
                        Best Practices

              Daily Build and Smoke Test
               –   Product is built every day (compiled, linked, and
                   combined into an executable program) – the product is
                   then tested to see if it “smokes”
               –   Efficacy
                       Potential reduction from nominal schedule:     Good
                       Improvement in progress visibility:            Good
                       Effect on schedule risk:                       Decreased Risk
                       Chance of first-time success:                  Very Good
               –   Major Risk
                       Pressure to release interim versions of a product too frequently

Chart 71
                        Best Practices

              Designing for Change
               –   Identifying likely changes, developing a change plan,
                   and hiding design decisions so that changes do not
                   ripple through a program.
               –   Efficacy
                       Potential reduction from nominal schedule:   Fair
                       Improvement in progress visibility:          None
                       Effect on schedule risk:                     Decreased Risk
                       Chance of first-time success:                Good
                       Chance of long-term success:                 Excellent
               –   Major Risk
                       Overeliance on the use of programming languages to solve
                        design problems rather than on change-oriented design

Chart 72
                        Best Practices

              Evolutionary Delivery
               –   Deliver selected portions of the software earlier than
                   would otherwise be possible.
               –   Efficacy
                       Potential reduction from nominal schedule:    Good
                       Improvement in progress visibility:           Excellent
                       Effect on schedule risk:                      Decreased Risk
                       Chance of first-time success:                 Very Good
                       Chance of long-term success:                  Excellent
               –   Major Risk
                       Feature creep, diminished project control, unrealistic schedule
                        and budget expectations, inefficient use of development time by
Chart 73
                        Best Practices

              Evolutionary Prototyping
               –   System developed in increments so that it can readily
                   be modified in response to end-user and customer
               –   Efficacy
                       Potential reduction from nominal schedule:     Excellent
                       Improvement in progress visibility:            Excellent
                       Effect on schedule risk:                       Increased Risk
                       Chance of first-time success:                  Very Good
                       Chance of long-term success:                   Excellent
               –   Major Risk
                       Unrealistic schedule and budget expectations, inefficient use of
                        prototyping time, unrealistic performance expectations, poor
                        design, poor maintainability

Chart 74
                     Best Practices

          Goal Setting
           –   Use goals to motivate software developers
                                (Shorten schedule, decrease risk, maximum visibility)
           –   Efficacy
                   Potential reduction from nominal schedule: (Very Good, None, None)
                   Improvement in progress visibility: (None, Good, Excellent)
                   Effect on schedule risk: (Increased Risk, Decreased Risk, Decreased
                   Chance of first-time success:       (Good, Good, Good)
                   Chance of long-term success:        (Very Good, Very Good, Very Good)
           –   Major Risk
                   Significant loss of motivation if goals are changed

Chart 75
                        Best Practices

              Inspections
               –   Formal technical review
               –   Efficacy
                       Potential reduction from nominal schedule:   Very Good
                       Improvement in progress visibility:          Fair
                       Effect on schedule risk:                     Decreased Risk
                       Chance of first-time success:                Good
                       Chance of long-term success:                 Excellent
               –   Major Risk
                       None

Chart 76
                        Best Practices

              Joint Application Development (JAD)
               –   Requirements-definition and user-interfaced design
                   methodology in which end-users, executives, and
                   developers attend intense off-site meetings to work out
                   a system’s details.
               –   Efficacy
                       Potential reduction from nominal schedule:   Good
                       Improvement in progress visibility:          Fair
                       Effect on schedule risk:                     Decreased Risk
                       Chance of first-time success:                Good
                       Chance of long-term success:                 Excellent
               –   Major Risk
                       Unrealistic productivity expectations following the JAD
                        sessions, premature, inaccurate estimates of remaining work
                        following JAD sessions
Chart 77
           Backup Slides

Chart 78
                          Waterfall Model
                                                      Software          Software
                                                    Requirements        Detailed     Software
                                                      Analysis           Design     Integration
              Needs                                      Software            Software          Software
             Analysis                                   Architectural         Coding          Qualification
                                                          Design            And Testing         Testing

                        System                                                     Software
                      Requirements                                                  Item n

                                                                             Component Integration
                                                                                                               & Release
                                       System                                  & Qualification
                                                                                    Item n

                                                      Hardware                          Hardware
                                                     Component          Hardware       Qualification
                                                    Requirements         Design          Testing

                                                             Hardware          Fabrication/Purchase
                                                             Make/Buy             And Assembly
Chart 79
           Effective Practices

                                              Ineffective Practices
                 Effective Practices

           Schedule-     Set of Practices
           Oriented      You Use on Any
           Practices     Particular Project

Chart 80
           Scheduled Oriented Practices


Chart 81
                      Course Outline
          Chapters 1, 2, 4                            Chapter 3
            –   Software development strategy            –   Classical mistakes
            –   Software development                   Chapter 6
                fundamentals                             – Core issues
          Chapter 7                                     – Time versus quality
            –   Lifecycle planning                     Chapters 10, 11, 12, 13
                    Waterfall, spiral, prototype
                                                         –  Customer oriented development
          Chapters 8, 9                                 –  Motivation
            –   Estimation                               –  Teamwork
            –   Scheduling                               –  Team structure
          Chapter 5                                   Best Practices
            –   Risk management                        Project
          Project                                       – Project reports
            –   SOW, requirements analysis,              – Test results
                WBS, technical specifications,           – Working demonstration
                test plan
                                                         – User’s manual
          Midterm Exam
                                                       Final Exam
            –   Chapters 1, 2, 4, 5, 7, 8, 9
                                                         – Comprehensive
Chart 82

Shared By: