Docstoc

Software Engineering - A Layered Technology

Document Sample
Software Engineering  - A Layered Technology Powered By Docstoc
					A Layered Technology
   Software Engineering
   Software Engineering

          tools
        methods
      process model
     a “quality” focus




                          1
A Common Process Framework

 Common process framework
   Framework activities
     work tasks
     work products
     milestones & deliverables
     QA checkpoints
   Umbrella Activities

                                 2
         Umbrella Activities
Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management


                                       3
           The Process Model:
              Adaptability
the framework activities will always be
 applied on every project ... BUT
the tasks (and degree of rigor) for each
 activity will vary based on:

  the type of project (an “entry point” to the model)
  characteristics of the project
  common sense judgment; concurrence of the
   project team

                                                         4
Linear Models




                5
               Waterfall Model                      SSR - System Software Review
                                                    PDR - Preliminary Design Review
                                                    CDR - Critical Design Review
                                                    TRR - Test Rediness Review
                                                    FCA - Functional Configuration Audit
                                                    PCA - Physical Configuration Audit
  Software                                          ORR - Operational Rediness Review
Requirements
  Analysis
                  Software
      SRS          Design
                              Code and Unit
                        SDS      Testing
                                                 Software
                                                Integration
                                       STP       and Test
                                                                             Software
                                                       SIP                  Acceptance
                                                                               Test


SSR               PDR           CDR           TRR          FCA                CRR
                                                           PCA
                                                                                           6
         Waterfall - DOD Model                                 NASA Model)
                                                                  Hardware
                                      Hardware
                                                                Implementation

System
Design                                                 Operational
           Software
         Requirements                                   Timelines
   PP      Analysis     Preliminary
                         Software
               SRS        Design           Detailed
                                           Software
                              PDD           Design
                                                       Code and Unit
                                                 SDS      Testing
                                                                         Software
                                                                        Integration
                                                              STP        and Test
                                                                                       Software
                                                                               SIP    Acceptance
                                                                                         Test


SDR        SSR            PDR              CDR                            TRR            FCA
                                                                                         PCA
                                                                                                   7
  Rapid Application Development Model
            Rapid Throwaway Prototype Model

  Software
Requirements
  Analysis
                 Build
      SRS      Prototype

                    PDD      Software
                              Design
                                      Code and Unit
                                  SDS    Testing       Software
                                                      Integration
                                               STP
                                                       and Test      Software
                                                          SIP       Acceptance
                                                                       Test

  SSR            PR           PDR         CDR         TRR    FCA      CRR
                                                             PCA                 8
                RAD Characteristics
   High speed adaptation of the linear model
   Based on Component-based construction
   Has incremental flavor
   Not well- suited where precision is required,
    e.g. high risk systems not easily modularized systems
 Have rigid performance requirements
    1. Model the Information Flow
    2. Refine the flows into Data elements
    3. Model the data transformations
    4. Generate the code 4GLs, component reuse, CASE
    5. Test and integration                                 9
     Reuse and Automated Development
     Models/Component Assembly Model
  Software
Requirements
  Analysis
                   Software
     SRS            Design
                               Code and Unit
                 SDS              Testing          Software
                                                  Integration
                               STP                 and Test         Software
                                                                   Acceptance
                                                      SIP             Test

  SSR               PDR           CDR          TRR          FCA      CRR
                                                            PCA

           Identify Reusable Components
   Informal Specification     Formal Specifications         Code
                                                                                10
Component Based Development


Architecture for Software Reuse
Based on Object Orientation
Classes are stored in a library
When requirements are received,the
 first stop is the library


                                      11
          Linear Model Characteristics

Documentation driven model
 systematic and requires rigor.
 Inflexible partitioning of project into distinct stages
 difficult to respond to changes in customer requirements
   Model appropriate when requirements are well-understood.
 Programmers HATE to create documentation.
 Users HATE to read documentation.
 If users read, they rarely understand documentation.
 Programmers don't understand other programmers documentations.
 Standards for documentation not clear although UML ordained.
                                                                   12
Iterative Models




Prototyping
                   13
         Evolutionary (Prototype) Model
               ONLY A PART OF THE FULL SYSTEM
  Software
Requirements
  Analysis
                   Build
      SRS        Prototype
                             Software
                      PDD     Design
                                        Code and Unit
                                           Testing       Software
                                 SDS                    Integration
                                                         and Test      Software
                                               STP                    Acceptance
                                                          SIP            Test

  SSR             PR          PDR          CDR          TRR     FCA     CRR
                                                                PCA
               Series of Implementations of each PART                              14
 Evolutionary/Prototype Model
Issues
  Process is not visible--Lack of process visibility
  Systems are often poorly structured—Change tends to
   corrupt the structures
  Special tools and techniques may be required—Special
   skills (e.g. in languages for rapid prototyping) may
   be required
Applicability
  For small or medium-size interactive systems
  For parts of large systems (e.g. the user interface)
  For short-lifetime systems



                                                          15
              Iterative Models
                                                team #3
                      team #2                          b u s in e s s
                                                       m o d e l in g


 team #1              b u s in e s s                                         d a t a
                      m o d e lin g                                     m   o d e l in g


                                                                                             p r o c e s s

business                                  d a ta
                                                                                            m o d e l in g


modeling                               m o d e lin g                                                         a p p l i c a tio n
                                                                                                             g e n e r a t io n


                                                                                                                                     te s tin g
                                                                                                                                          &
                                                                                                                                    tu rn o v e r
                                                            p ro cess
             data                                          m o d e lin g
           modeling
                                                                                           a p p lic a t io n
                                                                                           g e n e ra tio n
                               process
                              modeling                                                                                              te s tin g
                                                                                                                                         &
                                                                                                                                   tu r n o v e r

                                                  application
                                                  generation

                                                                                                       testing
                                                                                                           &
                                                                                                      turnover

                               60 - 90 days


                                RAD
                                                                                                                                                    16
                      The Incremental Model
  S steminform tion
   y    /      a             increment 1
     engineering

analysis       design       code            test      delivery of
                                                     1st increment


   increment 2 analysis            design          code        test       delivery of
                                                                         2nd increment


                        increment 3nalysis
                                  a                   design          code        test           delivery of
                                                                                                3rd increment


                                       increment 4 analysis              design          code         test

                                                                                                          delivery of
                                                                                                         4th incremen


                                                                             calendar time
                                                                                                                17
            Incremental Development Model

            ONLY A PART OF THE FULL SYSTEM
  Software
Requirements
  Analysis
                 Software
      SRS         Design
                             Code and Unit
                                Testing        Software
                       SDS
                                              Integration
                                     STP       and Test         Software
                                                   SIP         Acceptance
                                                                  Test


  SSR             PDR           CDR          TRR         FCA     CRR
                                                         PCA

            Can Determine a PART at any phase.                              18
Characteristics of Incremental Model

Same Requirements, specification, maintenance,and
 requirement phases as in Waterfall
The systems is partitioned into builds where each
 build is independently designed and scheduled
 "incrementally“ The 1st build gives some
 "production"functionality Subsequent builds add
 functionality
User perspective
Get some results quickly
Reduces new system "culture shock"
                                                     19
Characteristics of Incremental Model

Costs easily prorated over the development cycle
It employs the systems approach
Changes are easier to implement (e.g.design of later
 builds may not start until some phases are complete
 and all their changes well known).
Problems - May degenerate into "Build and Fix“
May result in builds that cannot integrate with one
 another


                                                        20
Spiral Model

                       Risk
Planning               Analysis
                       Prototyping




                Simulation

   Client       Operational Prototype
   Evaluation   Verification for Next Level
   and Input
                Developing                    21
An Evolutionary (Spiral) Model
                   l
                  Panning               i        i
                                       Rsk Analyss
                                              Prototyping
  Customer
Communication


                                                 n
                                                E gineering


         t
     Cus omer
      v
     E aluation                 t           e e
                            Cons ruction & R leas
   And                       Simulation/ Operational
   input                     Prototype/Verification for
                             the Next
                             Level/Development
                                                              22
         CleanRoom Approach

Specification
                Incremental
                Development
                  Planning    Specification
                               and Design
                                 Usage
                                 Design
                                              Statistical
                                               Testing
                                                            Certification



                                                                            23
                              V Model
                              Validate requirements               OPERATION
       REQUIREMENTS                                             & MAINTENANCE
         ANALYSIS

                                                           ACCEPTANCE
                                                             TESTING
                SYSTEM
                DESIGN
                                                      SYSTEM
                              Verify design           TESTING


                   PROGRAM                UNIT & INTE-
                    DESIGN               GRATION TESTING




                             CODING
[Pfleeger 98]
                                                                            24
  Operational Specification Model

                                         [Pfleeger 98]
          Execute and
           Revise




 OPERATIONAL          TRANSFORMED
 SPECIFICATION        SPECIFICATION          TEST
(problem-oriented)    (implementation-
                        oriented)
                                                DELIVERED
                                                 SYSTEM
    SYSTEM
  REQUIREMENTS
(sometimes informal
  or incomplete)
                                                            25
   Still Other Process Models


Concurrent process model—recognizes
 that different part of the project will be
 at different places in the process
Formal methods—the process to apply
 when a mathematical specification is to
 be developed




                                              26
     Formal Method Characteristics
Formal Methods Model Specifications produce proofs
                      Required rigorous notation
                      Enhances accuracy
                      Reduces flexibility

Some Formal Methods Petri Nets, Zed, Hoare Logic,
                     CSP, Weakest Preconditions

Formal Methods Abstraction
 Add formality to reduce ambiguity Use graphical
 representations Describe the possible system states,
 transitions, and triggers
                                                        27
      Capability Maturity Model
Organizations are not born using a mature process
 model.
Most organizations use NO known process model
Watts Humphrey wrote a book to lay out a plan for
 improving the process model within organizations.
 His book “Managing the Software Process” and
 other research has greatly improved the software
 engineering process.
The SEI Developed a capability maturity model
 which proposes a model for maturing an
 organizations process model.

                                                     28
      Capability Maturity Model


Five Process Maturity Levels
 Level 0:   Chaos
 Level 1:   Initial
 Level 2:   Repeatable
 Level 3:   Defined
 Level 4:   Managed
 Level 5:   Optimizing

                                  29
        Level 1: Initial


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


                                30
      Level 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



                                      31
Process Maturing to Level 2


Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and
 oversight
Software project planning
Requirement management
                                 32
          Level 3: Defined
The software process for both
 management and engineering activities
 is documented, standardized, and
 integrated into an organization-wide
 software process. All projects use a
 documented and approved version of
 the organization’s process for
 developing and maintaining software.
This level includes all characteristics
 defined for level 2.


                                           33
    Process Maturing Level 3
Peer Reviews
Inter-group coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus


                                   34
         Level 4: Managed
Detailed measures of the software
 process and product quality are
 collected. Both the software process
 and products are quantitatively
 understood and controlled using
 detailed measures.
This level includes all characteristics
 defined for level 3.



                                           35
   Process Maturing Level 4

Software quality management
Quantitative process
 management




                               36
       Level 5: Optimizing

Continuous process improvement
 is enables by quantitative
 feedback from the process and
 from testing innovative ideas and
 technologies
This level includes all
 characteristics defined for level 5.


                                        37
   Process Maturing Level 5

Process change management
Technology change management
Defect prevention




                                38
                CMM Issues
focuses on project management rather than
 product development.
ignores the use of technologies such as rapid
 prototyping.
does not incorporate risk analysis as a key
 process area
does not define its domain of applicability



                                                 39

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:206
posted:5/26/2012
language:English
pages:39
Description: Software Engineering - A Layered Technology