Review of Software Process Models

1
Review of Software Process Models
CEN 4021 Class 2 01/12

• Review Class 1
• Software Process Models

2
What is Software Project Management (SPM)?

• Software project management is concerned with
  ensuring that, for a software project, the most
  appropriate process and methodologies are chosen,
  the desired internal product structure is
  attained and the external product properties are
  achieved. In addition, the project management
  constraints of schedule and resources must be
  met. Tsui 04
• (5/5 points)

3
Software Development Process

• Software development process An ordered set of
  defined activities that describe the defining of
  requirements, designing, coding, and release for
  a software artifact.
• A process may contain some subprocesses, such as
  the design subprocess within the software
  development process.

4
Software Development Process

• Software methodology A set of rules and
  principles defined to achieve a specific goal and
  to accomplish a specific task in the development
  or support of software.

5
Software Process

• S/w Specification requirements elicitation
  (func. non-func.) and analysis.
• S/w Development systems design, detailed design
  (OO design), implementation.
• S/w Validation validating system against
  requirements (testing).
• S/w Evolution meets changing customer needs and
  error correction (maintenance).

6
Software Specification

• Reqs elicitation
• Reqs analysis
• Reqs prototyping
• Reqs documentation
• Reqs review
• Reqs sign-off
• Reqs change and impact management

7
Software Development

• Design
• Architectural design
• Overall system, external subsystems
• Application-specific high-level design
• App specific subsystems
• Application-specific low-level design
• Object design
• Design analysis
• Design review
• Design change and impact management

8
Software Development

• Implementation
• Programming standards definition
• User documentation, help text, and other
  information standards definitions
• Software code acquisition and reuse management
• Program documentation
• Program and information review
• Program unit testing

9
Software Validation (or VV)

• Test planning
• Test scenario development
• Test case and test script development
• Test scenario and test case review
• Test result tracking and analysis
• Test execution, problem reporting, resolution,
  and fix-integration management

10
Software Evolution

• Software must evolve to meet the customer needs.
• Software maintenance is the process of changing a
  system after it has been delivered. Reasons for
  maintenance
• to repair faults,
• to adapt the software to a different operating
  environment, and
• to add to or modify systems functionality.
• What are the four types of maintenance activities?

11
Software Process Models

• Software Process Models
• Waterfall Model
• V-Model
• Evolutionary Model
• Boehms Spiral
• Incremental model
• Unified Development Software Process

12
Waterfall Model (Royse 1970)
Requirements Definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
13
Waterfall Model cont

• One or more documents are produced after each
  phase and signed off.
• Points to note
• Water does not flow up i.e., it is difficult to
  change artifact produced in the previous phase.
• This model should be used only when the
  requirements are well understood.
• Reflects engineering practice.
• Simple management model.

14
V-Model (Jensen Tonies 1979)
Requirements Specification
Acceptance test
System design
System and integration test
Detailed Design
Unit Test
Implementation
Horizontal lines denote The information flow
between activities at the same abstraction
level.
15
V-Model cont

• Similar to waterfall model but makes explicit the
  dependency between development and VV
  activities.
• The left half of the V represents development and
  the right half system validation.
• Note the requirements specification includes
  systems reqs. analysis, s/w reqs. elicitation,
  and reqs. analysis.

16
Evolutionary Model
Concurrent activities
Initial Version
Specification
Intermediate Versions
Outline Description
Development
Final Version
Validation
17
Evolutionary Model cont

• Idea develop initial implementation, expose it
  to user, and refine it until an adequate system
  is produced.
• Two types
• Exploratory
• Throw-away prototyping
• Adv. model used when problem is not clearly
  defined.
• Disadv. process not visible, systems are poorly
  constructed, may require special tools and
  techniques.

18
Boehms Spiral Model (Boehm 1987)
Evaluate alternatives, identify resolve risks
Design objectives, alternatives, constraints
Risk analysis
Risk analysis
Risk analysis
Prototype 3
Prototype 2
Not shown in detail
Prototype 1
Concept of operation
Requirements plan
S/w Reqs.
Detailed Design
Sys. Product Design
Development Plan
Reqs. Validation
Code
Integration Plan
Design Validation
Unit Test
Develop verify next level product
Integration Test
Acceptance Test
Plan next phase
19
Boehms Spiral Model cont

• Tries to accommodate infrequent change during
  development.
• Each round of the spiral involves
• Determine objectives
• Specify constraints
• Generate alternatives
• Identify risks
• Resolve risks
• Develop and verify next level product
• Plan

20
Incremental Development (Mills et al. 1980)
Define outline requirements
Assign requirements to increments
Design system architecture
Develop system increment
Validate increment
Integrate increment
Validate system
Final system
System incomplete
21
Incremental Development cont

• S/w specification, design and implementation is
  broken down into a series of increments which are
  developed in turn.
• Gives customers some opportunities to delay
  decisions on the detailed requirements of the
  system.
• Services are identified and a priority allocated.
• Each increment provides a subset of the systems
  functionality.

22
Incremental Development cont

• Advantages
• Customers do not have to wait for the entire
  system.
• Customers gain experience using early increments
  of the system.
• Lowers the risk of overall project failure.
• Most important system services receives the most
  testing.
• Disadvantages
• May be difficult to map meaningful functionality
  into small increments.

23
Incremental Development cont

• The incremental approach has evolved to extreme
  programming (Beck 1988).
• One of the Agile Process Models.
• Extreme programming
• Development delivery of very small increments.
• Customer involvement in the process.
• Constant code improvement.
• Egoless programming programs are regarded as
  group property!

24
Unified Software Development Process (Booch,
Jacobson and Rumbaugh, 1999)

• Similar to Boehms spiral model.
• A project consists of several cycles, each ends
  with the delivery of a product to the customer.
• Each cycle consists of four phases
• Inception
• Elaboration
• Construction
• Transition
• Each phase consists of a number of iterations.

These phases differ wildly between projects
i.e., time and deliverables.
25
Unified Software Development Process cont

• Inception ends with commitment from the project
  sponsor to go ahead.
• Elaboration ends with
• basic architecture of the system in place,
• a plan for construction agreed,
• all significant risks identified,
• major risks understood enough not to be too
  worried.
• Construction ends with a beta-release system
• Transition is the process of introducing the
  system to it users.

26
Unified Software Development Process cont

• Note that the activities Requirements, Analysis,
  Design, Implementation, and Testing participate
  in each iteration of the Unified Process.
• Activities have differing phase-specific needs
  e.g., during elaboration phase, the requirements
  and analysis activities are allocated most of the
  resources.

27
Unified Software Development Process cont
System Development
Analysis model
Process is use case driven!
specified by
Design model
realized by
Use case model
distributed by
Deployment model
All models are related through traceability
dependencies.
implemented by
Implementation model
Requirements captured as a set of use cases.
verified by
Test model