Chapter 2 Software Development Process Models

1
Chapter 2 Software Development Process Models
2
Table of Contents

• 2.1 Introduction to Software Processes
• 2.2 Software Development Process Models
• 2.2.1 Waterfall Model
• 2.2.2 Incremental Model
• 2.2.3 Prototyping Model
• 2.2.4 Spiral Model
• 2.2.5 Fourth-Generation Techniques (4GT)
• 2.2.6 Rational Unified Process (RUP) Model
• 2.3 Comparison of Software Development Process
  Models
• Exercises

3
2.1 Introduction to Software Processes
4
Software Processes

• Software activities are tasks in a project to
  develop a software system.
• A software process is a structured set of
  software activities in a project.
• A linear sequence of activities analysis,
  design, coding, testing, training, maintenance
• A software activity might be a software process,
  too.

5
Software Activities

• Requirement acquisition
• Requirement analysis
• Requirement specification
• System analysis
• System design

6
Software Activities (contd)

• Detailed design
• Coding
• Testing
• Maintenance

7
Requirement Acquisition

• problem statements
• to describe the problem to be solved and
  providing a conceptual overview of the proposed
  system

8
Requirement Analysis

• A process of discovering, refinement, modeling
  and specification.
• Principles represent information domain of a
  problem
• Modeling (graphical textual description)
• modeling methods SA, OOA, JSD, DSSD, SADT
• model component information, function, behavior
• Artifact
• Requirement specification.
• capturing functionality, behavior, and structure

9
Design

• The problem is decomposed into modules
• The interface between modules must be specified
• Define architecture
• Artifact design model
• Data design data abstraction, data structure,
  data modeling
  
• Procedural design iteration , conditional,
  sequence
• Architectural design program structure, software
  architecture

10
Implementation

• Individual module programming
• pseudo-code ? computer programs
• The goals
• the development of well-documented programs
• reliable, easy to read, flexible, correct
  programs
• Integration of modules
• Artifact executable programs

11
Testing

• Test the system from requirement engineering to
  implementation
• Verification and Validation (VV)
• Artifact testing report

12
Maintenance

• Maintain user satisfaction
• Repair errors, requirements changed or extended
• Changes are inevitable in both the system
  environment and user requirements.
• Maintenance Evolution

13
Maintenance (contd)

• 4 kinds of maintenance activities
• Corrective
• Adaptive
• Perfective
• Preventive

Cost
14
2.2 Software Development Process Models
15
Software Development Process Models

• Also Software Life Cycle Models
• Waterfall model
• Incremental model
• Prototyping
• Spiral model
• Fourth-generation techniques (4GT)
• Rational Unify process (RUP) model

16
Waterfall Model

• The waterfall model is defined with a sequence
  of activities.
• An activity starts after the previous activity is
  fully completed.
• This model is documentation-centric.

17
Waterfall Model (contd)
18
Waterfall Model (contd)

• This model implicitly requires a corresponding
  verification with each activity.
• This model is best applied to projects whose
  requirements and implementation are well
  understood.
• However, it is difficult to define all
  requirements at the beginning of a project.
• This model does not address the adaptation to
  changes.

19
Waterfall Model (contd)

• A working version of the system is not seen until
  late in the projects life cycle.
• Real projects are rarely sequential.
• This model is frequently for software implemented
  with functional decomposition.

20
Incremental Model

• The incremental model uses the waterfall model to
  develop software systems through incremental
  releases that provide improved versions of a
  system at regular intervals.
• User requirements are prioritized and the highest
  priority requirements are included in early
  increments.

21
Incremental Model (contd)
Cycle 3
Cycle 2
Cycle 1
the highest priority requirements
lower priority requirements
the lowest priority requirements
version 1
version 2
version 3
22
Incremental Model (contd)

• This model can produce a working version of the
  system earlier in the projects life cycle.
• This model can reduce the risk of the project.
• Early increments can help elicit requirements for
  later increments.

23
Prototyping Model

• The prototyping model rapidly builds prototypes
  that provide a reduced functionality or a limited
  performance version of the system.
• The model gives more emphasis on the requirement
  activity of a project.
• Prototypes can be used to clarify requirements
  rapidly.

24
Prototyping Model (contd)
25
Prototyping Model (contd)

• The roles of prototyping
• as the means to acquire and validate users
  requirements.
• as scaled-down version of the final operational
  system.
• as the means to validate solution specifications.
• as a solution specification for design and
  implementation
• Benefits
• improve communication
• reduce risk
• most feasible way to validate specification
• for maintenance as well.

26
Prototyping Model (contd)

• Strategies
• Throwaway prototyping
• The objective is to understand the user
  requirements.
• Starts with poorly understood requirements
• implement only aspects poorly understood
• Evolutionary prototyping
• The objective is to work with customers and to
  evolve a final system from the prototype.
• Should start with well-understood requirements
• more likely to implement aspects better
  understood

27
Spiral Model

• The spiral model combines the features of the
  previous three models and adds risk assessment as
  a new feature.
• Risks are explicitly assessed and resolved
  throughout the process.

28
Spiral Model (contd)
Progress through steps
Cumulative cost
Evaluate alternatives identify, resolve risks
Determine objectives, alternative, constraints
Risk analysis
Risk analysis
Risk analysis
Risk analy -sis
Operational Prototype
Prototype
Prototype
Prototype
Commitment partition
1
2
3
Simulations, models, benchmarks
Requirements plan life-cycle plan
Review
Software requirement
Detailed design
Software product design
Requirement validation
Development plan
Plan next phases
Code
Unit test
Design validation and verification
Integration and test plan
Integration and test
Acceptance test
Service
Develop, verify next-level product
29
Steps in Spiral Model

• 4 steps in a cycle (loop)
• Objectives identify specific objectives and
  devise alternative approaches
• Risk assessment assess risks based on
  alternatives, resolve risks, and decide which
  process model to use.
• Development and validation develop the system
• Planning review the system and plan the next
  phase
• Each cycle represents a phase in this model.

30
4GT

• Use diagrams or some specific languages as input
  to describe the characteristics and behavior of
  the software.
• The input is called 4th-generation language (4GL)
  
• With the input, automatically generate source
  code.
• The techniques used are called 4th-generation
  Techniques (4GT).

31
4GT (contd)
32
RUP Model

• The Rational Unified Process (RUP) model is
• Use-case driven
• Drive the design, implementation, and validation
  of the system
• Use case model is for requirement analysis.
• Architecture-centric
• An architecture describes the entire system that
  is divided into parts and their interactions.
• The architecture can be used to decide which
  parts need to be developed and which parts can be
  built by reusing the existing software components.

33
RUP (contd)

• Iterative and incremental
• See the figure.
• The model repeats over a series of cycles.
• A cycle consists of 4 phases inception,
  elaboration, construction, transition. Each phase
  has iterations.
• Incremental Incrementally add something new,
  such as functions, components and subsystems, to
  the system.
• Design and documentation use UML.

34
RUP (contd)
35
RUP (contd)

• Inception Specify the most critical use cases
  and build a outline architecture.
• Elaboration Specify most of the use cases and
  build a system architecture.
• Construction Build the system.
• Transition Move into beta release, train
  customer personnel, provide help-line assistance.

36
2.3 Comparison of Software Development Process
Models
37
Waterfall Model

• Waterfall model problems
• traceability/different languages in different
  phases
• Process is too linear
• requirement acquisition and validation
• maintainability difficult due to the use of
  functional decomposition
• assume fully elaborated documentation at the
  early stage of the life cycle.
• reusability top-down design
• communication

38
Waterfall Model (contd)

• based on functional decomposition
• Strongly dependent on detailed functional
  breakdown
• not consider evolutionary changes.
• not encourage reusability

39
Prototyping Model

• Prototyping (partial implementation )
• Benefits
• improve communication
• reduce risk
• communication between developments
• determine a proposed designs unknown properties
• address requirement acquisition and validation
  limitation
• provide a basis for assessing the feasibility and
  performance of alternative designs
• most feasible way to validate specification.
• for maintenance as well

40
Prototyping Model (contd)

• Limitation
• quick and direct approach without considering
  issues such as quality and maintainability.

41
Languages Used in Different Phases

• Prototyping language both specification and
  design
• Specification language abstract of system
  functionality
• Design language abstract of system structure
• Programming language optimization

42
Languages Used in Different Phases (contd)
containing quantifies
supporting formal reasoning
detail algorithm and data structure
verify correctness and completeness of design or
implementation
executable
low priority
prototyping lang.
no
yes
no
must
yes
interconnections during architecture and module
design
specification language
not necessary
no
not
Design language
no
programming language
efficient
43
Waterfall Model
E
Functionality
inappropriateness
D
shortfall
B
C
lateness
slop adaptability
original reqt.
longevity
A
Time
t0
t1
t2
t3
t4
t5
O (t0) original reqt. A ( at t1) an
operational product, not satisfying the old to
needs because poor understanding of
needs. A - B undergo a series of
enhancements. B - D the cost of enhancements
increase, to build a new system. stop at t4.
cycle repeat itself
waterfall model
44
Throwaway Prototyping and Spiral Model
before understanding of the users need gt
increase in functionality
Functionality
t0
t1
t2
t4
Time
45
Evolutionary Prototyping
46
Reusable Software versus Conventional
conventional approach
47
Exercises

• Do you think complexityand changeis the
  problems of software development? Why?
• Comparison of different software engineering
  paradigms
• waterfall, prototyping, spiral, OOLC, 4GL
• prototype both specification and design
• program optimization

48
Exercises (contd)

• Issues in using different kinds of language in
  waterfall model
• different phases need different kinds of
  languages
• transformation between languages at different
  phases.
• main features of each language
• specification, design, prototype, program
• specification abstract of system functionality
• design abstract of system structure
• prototype both specification and design
• program optimization