process Software Development Process by huangyuarong

VIEWS: 18 PAGES: 59

									      Software Development Process: Life
      Cycle Models


                                 Aditya P. Mathur

                                    Department of Computer Science
                                    Purdue University, West Lafayette




                                    Last Update: Tuesday August 19, 2003


Aug 19, 2003   BITSC461/IS341 Software Engineering
       Objectives

      What is a process?

      What is Software Development Process (SDP) ?

      How is SDP organized (life cycle models)?

      How is process maturity measured?

      What are the benefits of a “good” process ?


Aug 19, 2003         BITSC461/IS341 Software Engineering   2
       Process
               Input             Output
                       Step




                                 Output
               Input                      Input                Output
                       Step 1                      Step 2


                                           Input

                                                            Sequential or linear process



Aug 19, 2003                  BITSC461/IS341 Software Engineering                          3
       Concurrent Process

                                  Output
               Input                       Input                Output
                       Step 1                       Step 3

                                            Input
                       Step 2
                                     Output
               Input


                                                             Parallel or concurrent process



Aug 19, 2003                    BITSC461/IS341 Software Engineering                           4
       Iterative Process

                                  Output
               Input                       Input                Output
                       Step 1                       Step 3

                                            Input
                       Step 2
                                     Output
               Input


                                                                      Iterative process


Aug 19, 2003                    BITSC461/IS341 Software Engineering                       5
       Features of a process
         One or more steps.

         Each step is well defined.

         Input and output of each step is well defined and
          observable.
         Start and end of a step can be identified.




Aug 19, 2003           BITSC461/IS341 Software Engineering    6
       Process model: Linear
         An arrangement of process steps.


                                Output
               Input                     Input              Output
                       Step 1                    Step 2


                 Linear model            Input




Aug 19, 2003              BITSC461/IS341 Software Engineering        7
       Process model: Concurrent


                                                       Concurrent
                                Output
               Input                     Input                Output
                       Step 1                     Step 3

                                          Input
                       Step 2
                                   Output
               Input




Aug 19, 2003            BITSC461/IS341 Software Engineering            8
       Process model: Iterative


               Input        Output Input                Output
                       Step 1                  Step 3
                                       Input
                       Step 2
                                Output
               Input

                                                  Iterative




Aug 19, 2003            BITSC461/IS341 Software Engineering      9
       Software Development Process
         Steps correspond to one or more tasks related to software
          development.
         Tasks:

      o   Requirements gathering             o   Integration
      o   Requirements analysis              o   Test
      o   Design                             o   Delivery
      o   Coding                             o   Maintenance
                                             o   Training

         Software life cycle: Software Life Cycle consists of all phases
          from its inception until its retirement. These are: Inception,
          elaboration, construction, transition.
Aug 19, 2003              BITSC461/IS341 Software Engineering               10
         Models of Software Life Cycle
        Build and fix
        Waterfall (classic)
        Rapid prototyping
        Incremental
        Spiral
        Unified




Aug 19, 2003              BITSC461/IS341 Software Engineering   11
          Build and fix model [1]
Idea or client request

                  Build first version


                            Modify until client satisfied



                                        Operations mode

   Development
                                                            Retirement
           Maintenance


   Aug 19, 2003                    BITSC461/IS341 Software Engineering   12
       Build and fix model [2]

      Product is constructed without specifications.

      There is no explicit design. However, a design will
       likely evolve in the mind of the developer.


      The approach might work for small programming
       projects [TA 162/252].




Aug 19, 2003          BITSC461/IS341 Software Engineering    13
       Build and fix model [3]

     Cost of fixing an error increases as one moves away
      from the phase in which the error was injected.

     There is a good chance that many errors will be found
      in the operations phase thereby leading to high cost of
      maintenance.

     Rarely used in commercial projects.



Aug 19, 2003         BITSC461/IS341 Software Engineering        14
          Waterfall model [1]
Requirements phase

                  Specification phase


                           Design phase

                                                                          Retirement
 Verification done at              Implementation phase
 the end of each
 phase.
                                                          Integration phase
      Development

                  Maintenance                                          Operations mode
   Aug 19, 2003                  BITSC461/IS341 Software Engineering                   15
       Waterfall model [2]

    Popular in the 70’s.

    Requirements are determined and verified with the
     client and members of the SQA group.

    Project management plan is drawn, cost and duration
     estimated, and checked with the client and the SQA
     group
    Then the design (i.e. “How is the product going to do
     what it is supposed to do.”) begins and the project
     proceeds as in the figure.
Aug 19, 2003         BITSC461/IS341 Software Engineering     16
       Waterfall model [3]

   Each phase terminates only when the documents are
    complete and approved by the SQA group.

   Notice the feedback loop between the Design phase
    and the Specifications phase.


   Maintenance begins when the client reports an error
    after having accepted the product. It could also begin
    due to a change in requirements after the client has
    accepted the product.
Aug 19, 2003         BITSC461/IS341 Software Engineering     17
       Waterfall model: Advantages

    Disciplined approach


    Careful checking by the Software Quality Assurance
     Group at the end of each phase.


    Testing in each phase.


    Documentation available at the end of each phase.

Aug 19, 2003        BITSC461/IS341 Software Engineering   18
       Waterfall model: Disdvantages

    Documents do not always convey the entire picture.


    Specification documents are detailed and difficult to
     read/understand for the client.


    Feedback from one phase to another might be too late
     and hence expensive.



Aug 19, 2003         BITSC461/IS341 Software Engineering     19
       Rapid prototyping model

    A working model of the product is developed (quickly,
     1-3 months). Serves to elicit requirements.

    Client interacts with the prototype; specifications are
     developed.

    Subsequent phases, design, coding etc., follow.
     Feedback loops less likely and fewer.

               Should the prototype be discardded or refined ?

Aug 19, 2003           BITSC461/IS341 Software Engineering       20
          Incremental model [1]
Requirements phase

                  Specification phase


                           Architectural Design

                                                                         Retirement
 Verification done at              For each build:
 the end of each                   Detailed design, coding,
 phase.                            Integration, test, delivery.
      Development

                  Maintenance                                          Operations mode
   Aug 19, 2003                  BITSC461/IS341 Software Engineering                  21
       Incremental model [2]

   Product architecture is designed. It serves as the main
    driver of the development process.
   Features are prioritised and increments defined.
   Product is designed, implemented, and integrated as a
    series of incremental builds.
   A build contains code from various modules to provide
    the desired functionality.

   A new build integrates code from previous build and
    new code.
Aug 19, 2003        BITSC461/IS341 Software Engineering       22
       Incremental model [3]

   Client can begin using the first build.

   Facilitates early adoption by the client.

   Client pays in increments; financial benefit.

   Design of the initial architecture is a difficult step. Poor
    architecture may lead to lots of changes in builds.

                 Should we construct builds in parallel?
Aug 19, 2003          BITSC461/IS341 Software Engineering          23
       Unified Development Process [1]

   Key features: Iterative development; OO analysis and
    design.
   Development organized as a series of short iterations
   Each iteration produces a working, executable,
    product that might not be a deliverable.
   No rush to code. Aslso, not a long drwan design
    process.
   Lots of visual modeling aids. Unified Modeling
    Language (UML) used.
Aug 19, 2003         BITSC461/IS341 Software Engineering    24
       Unified Development Process [2]

   Early iterations seek feedback from the customer. Risk
    and value to customer is managed through early
    feedback.

   Customer is engaged continuously in evaluation and
    requirements gathering.

   Architecture is built during early iterations.




Aug 19, 2003          BITSC461/IS341 Software Engineering    25
     Unified Development Process [3]




Aug 19, 2003   BITSC461/IS341 Software Engineering   26
       The Unified Process
        Why a Process?
              Software projects are large, complex,
               sophisticated
              time to market is key
              many facets involved in getting to the end
        Common process should
              integrate the many facets
              provide guidance to the order of activities
              specify what artifacts need to be developed
              offer criteria for monitoring and measuring a
               project
Aug 19, 2003             BITSC461/IS341 Software Engineering   27
       The Unified Process
          Component based - meaning the software system is built as a
           set of software components interconnected via interfaces
          Uses the Unified Modeling Language (UML)
          Use case driven
                                                   This is what makes
          Architecture-centric                    the Unified process
          Iterative and incremental               Unique



        Component: A physical and replaceable part of a system that conforms to
        and provides realization of a set of interfaces.
        Interface: A collection of operations that are used to specify a service of a
        class or a component

Aug 19, 2003                BITSC461/IS341 Software Engineering                         28
       The Unified Process
                                       Software
               User’s                                          Software
                                      Development
          requirements                                         System
                                         Process




Aug 19, 2003             BITSC461/IS341 Software Engineering              29
       The Unified Process
          Use Case driven
                  A use case is a piece of functionality in the
                   system that gives a user a result of value
          Use cases capture functional
           requirements
          Use case answers the question: What is
           the system supposed to do for the user?



Aug 19, 2003                BITSC461/IS341 Software Engineering    30
       The Unified Process
          Architecture centric
                  similar to architecture for building a house
          Embodies the most significant static and dynamic
           aspects of the system
          Influenced by platform, OS, DBMS etc.
          Primarily serves the realization of use cases




Aug 19, 2003                    BITSC461/IS341 Software Engineering   31
       The Unified Process
          Iterative and Incremental
                  commercial projects continue many months
                   and years
                  to be most effective - break the project into
                   iterations
          Every iteration - identify use cases,create
           a design, implement the design
          Every iteration is a complete development
           process



Aug 19, 2003                    BITSC461/IS341 Software Engineering   32
       The Unified Process
          Look at the whole process
                  Life cycle
                  Artifacts
                  Workflows
                  Phases
                  Iterations




Aug 19, 2003                    BITSC461/IS341 Software Engineering   33
       The Life of the Unified Process
          Unified process repeats over a
           series of cycles
          Each cycle concludes with a
           product release
          Each cycle consists of four phases:
                  inception
                  elaboration
                  construction
                  transition


Aug 19, 2003                BITSC461/IS341 Software Engineering   34
       The Life of the Unified Process
                                                                  Time

        Inception             Elaboration Construction                          Transition

      Iteration   Iteration   Iteration   Iteration   Iteration   Iteration   Iteration   Iteration
          1                    1                          1                         1




                                  Release 1
               A cycle with its phases and its iterations
Aug 19, 2003                    BITSC461/IS341 Software Engineering                                   35
       Life Cycle Models: Summary [1]

   Build and fix: Acceptable for short programs that do
    not require maintenance.

   Waterfall: Disciplined approach, document driven;
    delivered product may not meet client needs.

   Rapid prototyping: Ensures that delivered product
    meets client needs; might become a build-and-fix
    model.
   Incremental: Maximizes early return on investment;
    requires open architecture; may degenerate into build-
    and-fix.
Aug 19, 2003         BITSC461/IS341 Software Engineering     36
       Life Cycle Models: Summary [2]

   Spiral: Risk driven, incorporates features of the above
    models; useful for very large projects

   UDP: Iterative, supports OO analysis and design; may
    degenerate into code-a-bit-test-a-bit.




Aug 19, 2003         BITSC461/IS341 Software Engineering      37
       Objectives

     Why do software projects fail/succeed?

     How is process maturity measured ? Key Process
      Areas?

     How to do requirements analysis? What are UML, use
      cases, domain model, actors ?




Aug 19, 2003         BITSC461/IS341 Software Engineering   38
          Standish Report [1995]


Company categorization by revenue:

          Large company: >$500M

          Medium company: $200-500M

          Small comp;any: $100-200M

Sample size: 365 respondants, 8380 applications.



 Aug 19, 2003            BITSC461/IS341 Software Engineering   39
       Standish Report: Project categorization: Success/failure


   Resolution Type 1: On time, on budget, all features.
                                                              16.2%


   Resolution Type 2: Completed, over time, over budget, fewer
    features.                                                52.7%


   Resolution Type 3: Cancelled during the development cycle.
                                                              31.1%




Aug 19, 2003            BITSC461/IS341 Software Engineering           40
         Standish Report: Failure Statistics

   Success rate: Large companies: 9%
        Medium: 16.2%
        Small: 28%

   Resolution type 2: Large: 61.5%
        Medium: 46.7%
        Small: 50.4%

   Resolution type 3: Medium: 37.1%,
        Large: 29.5%
        Small: 21.6%



Aug 19, 2003             BITSC461/IS341 Software Engineering   41
       Standish Report: Cost Overruns

         Cost Overruns             % of Responses
         Under 20%                 15.5%

         21 - 50%                   31.5%

          51 - 100%                29.6%

         101 - 200%                10.2%

         201 - 400%                 8.8%

         Over 400%                  4.4%

Aug 19, 2003             BITSC461/IS341 Software Engineering   42
       Standish Report: Time Overruns

         Time Overruns % of Responses
         Under 20%              13.9%

         21 - 50%               18.3%

         51 - 100%              20.0%

         101 - 200%             35.5%

         201 - 400%             11.2%

          Over 400%              1.1%

Aug 19, 2003          BITSC461/IS341 Software Engineering   43
      Standish Report: Success Profile [1]

Project Success Factors                     % of Responses

1. User Involvement                                            5.9%

2. Executive Management Support                                13.9%

3. Clear Statement of Requirements                     13.0%

4. Proper Planning                                             9.6%

5. Realistic Expectations                                      8.2%


Aug 19, 2003          BITSC461/IS341 Software Engineering              44
       Standish Report: Success Profile [2]

Project Success Factors                       % of Responses
6. Smaller Project Milestones                           7.7%

7. Competent Staff                                              7.2%

8. Ownership                                                    5.3%

9. Clear Vision & Objectives                                    2.9%

10. Hard-Working, Focused Staff                                 2.4%

11. Other                                                       13.9%

 Aug 19, 2003             BITSC461/IS341 Software Engineering           45
      Standish Report: Failure stories

   California DMV:          Started 1987.
                            Project cancelled: 1993.
                            Cost:$45M

   American airlines:       1994
                            Settled lawsuit with
                            Hilton/Marriott/Budget-rent-a car
                            CONFIRM car rental project failed




Aug 19, 2003            BITSC461/IS341 Software Engineering     46
        Standish Report: Success Potential

Success Criteria           Points       DMV       CON         HYATT   ITAMARATI


1. User Involvement        19           NO ( 0) NO ( 0) YES (19)                 YES

2. Management Support      16           NO ( 0) YES (16) YES (16)     YES (16)

3. Clear Requirements      15           NO ( 0) NO ( 0) YES (15)      NO ( 0)

5. Realistic Expectations 10            YES (10) YES (10) YES (10)    YES (10)


10. Hard-Working Staff     3            NO ( 0) YES ( 3) YES ( 3)     YES ( 3)
TOTAL                      100          10        29         100      85
  Aug 19, 2003                 BITSC461/IS341 Software Engineering               47
       Capability Maturity Model (CMM)


Process maturity is a measure of the discipline used by an
organization during the development of a software product.


CMM assists in determining how mature a process is.


Purpose:
To assess and help improve process in software development
organizations.


Aug 19, 2003         BITSC461/IS341 Software Engineering     48
       Capability Maturity Model (CMM)


Capability maturity levels:

          Level 1:    Initial               Worst
          Level 2:    Repeatable
          Level 3:    Defined
          Level 4:    Managed
          Level 5:    Optimizing            Best




Aug 19, 2003          BITSC461/IS341 Software Engineering   49
       CMM Levels [1]

      Initial

      The software process is characterized as ad hoc, and
      occasionally even as chaotic. Few processed are
      defined, and success depends on individual effort.



                 Lacks: Reasonable process.


Aug 19, 2003          BITSC461/IS341 Software Engineering    50
       CMM Levels [2]

    Repeatable

    Basic project management processes are established to track
    cost, schedule and functionality. the necessary process
    discipline is in place to repeat earlier successes on projects
    with similar applications.

                    Lacks: Complete process.



Aug 19, 2003           BITSC461/IS341 Software Engineering           51
       CMM Levels [3]
    Defined

    The software process for both management and engineering
    activities is documented, standardized and integrated into a
    standard software process for the organization.
    All projects use an approved, tailored version of the
    organization's standard software process for developing and
    maintaining software.

                 Lacks: Predictable outcomes.


Aug 19, 2003          BITSC461/IS341 Software Engineering          52
       CMM Levels [4]


    Managed

    Detailed measures of the software process and product
    quality are collected. Both the software process and products
    are quantitatively understood and controlled.

               Lacks: Mechanism for process improvement.


Aug 19, 2003            BITSC461/IS341 Software Engineering         53
       CMM Levels [4]


    Optimized

    Continuous process improvement is enabled by quantitative
    feedback from the process and from piloting innovative ideas
    and technologies.




Aug 19, 2003          BITSC461/IS341 Software Engineering          54
       Key Process Areas [1]
               Optimizing
                     Defect prevention
                     Technology change management
                     Process change management



                             Managed:
                                        Quantitative process management
                                        Software quality management




Aug 19, 2003                BITSC461/IS341 Software Engineering           55
       Key Process Areas [2]
         Defined
               Organization process focus
               Training programs
               Integrated software management
               Peer reviews


                   Repeatable
                             Requirements management
                             Software project planning
                             Software quality assurance
                             Software configuration management


Aug 19, 2003           BITSC461/IS341 Software Engineering       56
       Maturity and product quality [1]
               Results from 34 Motorola Government Electronics
               Division (GED) projects
               -------------------- - ----------------------------------------        - -------
                       e
               CMM L vel # Projects       Relative              Faults/MEA   SL      Relative
                                              r
                                          Decease in                                        ct
                                                                                     Produ ivity
                                             r
                                          Du ation
               -------------------- - ----------------------------------------        - -------

               1              3              1                             --        --
               2              9              3.2                           890       1.0
               3              5              2.7                           411       0.8
               4              8              5.0                           205       2.3
               5              9               7.8                           126      2.8
               --------------------     - ----------------------------------------    - -------
               MEASL: Million Equivalent Assembler Source Lines

Aug 19, 2003                          BITSC461/IS341 Software Engineering                          57
       Maturity and product quality [2]

               Raytheon:

               Equipment Division moved from Level 1 to Level 3. This
               resulted in a productivity gain of 2.0 and a $7.70 return on
               every dollar invested.




Aug 19, 2003                   BITSC461/IS341 Software Engineering            58
       CMM Documents ?
         http://www.sei.cmu.edu/cmm/cmms/cmms.html




Aug 19, 2003         BITSC461/IS341 Software Engineering   59

								
To top