CSE 784

Software Studio
class notes

Chapter 6

Software Development
Process Models

Jim Fawcett
copyright (c) 1994 - 2002
 Model Definitions
 Model:
A representation of the most essential features of a
physical object or process used as a pattern for
reasoning about, analyzing, or predicting behavior

 Abstract Model:
A model with no concrete instances, e.g., a meta-
model, or model of a model, used to reason about
models.

 Software Development Model:

A model of the phases, activities, products, and roles
of people involved with the development of software.

 Software Computation Model (Component

Model):
A model of the structure, behavior, and dependencies
of a software component.

– Logical Model (Process Model):

A computational model which focuses on processing to
be done and the information necessary to do it.

– Physical Model (Structural Model):

A computational model which focuses on structural and
data dependencies of a software product, including
source code which implements its design.

Chapter 6 - Process Models 2

Software Computational Models

 Computational models describe structure,

behavior, and dependencies of software
components. They enable us to reason about
and predict the behavior of software systems
and their components.

 Without computational models, large-scale

software development would be virtually
impossible. We need the abstractions provided
by computational models to understand how
these large systems are supposed to work.

 We use these models when we write require-

ments specifications and conduct design
reviews.

Chapter 6 - Process Models 3

 Computational Model Views
 A computational model represents the processing, data,
and physical structure of a software component. Each
component level - function, class, module, program,
software system - can be described in different ways:
 Logical Model - applies to all levels
– client’s view of component’s operation
– capsule summary of key features and functions
 Process Model - for modules, programs, systems
– major partitions of processing and data flow between them,
shown by DFDs, Data dictionary.
– logical and requirements model for each process captured by
Pspecs.
 Structural Model - for modules, programs, systems
– data, control, and timing dependencies on outside
environment shown by context diagram, performance
requirements.
– major partitions captured by a module diagram.
– data, processing, control, and timing dependencies between
partitions shown by structure chart, class hierarchy diagram,
state transition diagram, critical threads, performance
requirement flow-downs.
 Implementation Model - applies to all levels
– brief logical model for each component in prologue
– description of algorithms and data structures used to build
component
– list of all components in the physical software
– source code for each component

Chapter 6 - Process Models 4

 SW Product Model
 Architecture
– defines product components and allocates processing to them
– defines external product behavior
 Requirements Specification
– describes what constitutes correct operation
– it is the basis for testing and evaluation
 Product Specification
– defines an architecture for the system
– describes software design and implementation
– specifies a software build process
 Test Plan
– defines procedures for unit, integration, validation,
qualification, and regression testing
– qualification test procedures are emphasized
 Prototype Code
– verifies design for critical processing, analyzes
implementation problems as they arise
 Product Code
– Code for each component of the product, implemented as
software modules.
– test stub attached to each module, used to establish basic
software cycling and nearly correct operation
 Test Code
– test drivers for unit and qualification tests
 Test Report

Chapter 6 - Process Models 5

 Relating Computational models to
Software Product
 Architectural Model - concept document
– logical and structural model which discloses the systems
organizing principles, major processes, and critical design issues

 Requirements Model - A and B level specifications

– process model which represents what system is obligated to do
– must be complete, unambiguous, and succinct
– strictly tied to the application domain, ignores solution domain
– requirements modeling is a decomposition process

 Design Model - C level specification

– structural and implementation model shows how system works
– focused mostly on the solution domain
– design is initially a top-down decomposition followed by
recomposition, that is, construction of a solution from a series of
components

 Component Models to support Reuse

– manual pages and design notes show how each module provides
its services
– prologues provide a flow down of process obligations which
enable orderly code inspection and unit testing
– prologues state assumed preconditions and post conditions
which result from the components activities
– prologues, pseudo code, and source code show how the solution
works at the most detailed level
– each component is part of a solution to an application need,
tested independently and then integrated

Chapter 6 - Process Models 6

 Software Development Models

• A software development model is concerned with the

phases, activities, products, and roles of people
involved in the development of software.

• Production of large scale software is a complex

endeavor:
– scores of documents are produced
– code is written, not only for the application, but also to
prototype new ideas, support various hardware and
software test phases, and for managing software
builds
– many reviews are held internally with the develop-
ment team and for the customer
– enormous amounts of data are collected, used to
manage the development and keep developers and
customer apprised of the program’s status

• Models are an essential part of that process, used to

guide developers in their day-to-day activities, keep
the program focused on its principle objectives, and
promote communication through the use of stand-
ardized documentation and reviews.

Chapter 6 - Process Models 7

 SW Process Model
(Focus on Development Process)

 Requirements Analysis
– define what the system must do
– define architecture
– build a requirements model
– review requirements specifications with customer
 Design and Unit Test
– define how the system will met requirements
– define structure, e.g., modules, classes, functions
– build and test each module by populating with functions and
classes
 Integration
– integrate modules and test
– carry out performance, validation, and stress tests
 Qualification
– legal demonstration that developer’s obligations have been
met, e.g., the system meets customer’s require-ments
 Audits
– Functional Configuration Audit (FCA) showing that
contracting office and contractor have been successful
producing a working product
– Physical Configuration Audit (PCA) showing that contractor
and contracting office have supplied all purchased
components to the end user

Chapter 6 - Process Models 8

 Waterfall Development Model
 A software development process which proceeds linearly in time
through the phases:
– Specification analysis: analyzing what software must do
and writing contractual requirements documents to specify
resulting functional behavior and performance.
– Design: developing a physical structure for software by
partitioning into modules, classes, and functions, and
defining the processing necessary for each. Each module,
class, and function has a prologue which flows down
software processing requirements to that level.
– Code and unit test: writing source code for functions,
classes, and modules, and compilation with test drivers to
verify that each component satisfies the processing
requirements flowed down to it.
– Integration testing: building software execution images
which progressively combine more modules, providing
incremental capability, until the entire product has been
assembled and is functioning. When integration begins
many modules are likely to have errors since only unit
testing has been conducted.
– Qualification testing: a step by step process of verifying
that each requirement identified in the requirements
specification has been met.

Requirements
Analysis

design
code and
Unit Test
integration
test

Qualification
Test
Chapter 6 - Process Models 9
 Waterfall Development Roles

 Software Product Manager

– Responsible for software cost and schedule
– Has ultimate authority on all software
development decisions
– Depends on Architect, Test Manager, and Team
Leaders to implement his decisions.
 Software Architect
– Responsible for top-level software partitioning,
defining user interfaces
– Manages interfaces between software developed
by each team
– Is the source of knowledge on how the system
works
 Test Manager
– Responsible for Test Plan and Qualification
– Develops, with the test team, test descriptions
and procedures, usually by assigning to the
individual teams for elaboration
– Conducts the Test Readiness Review and
Qualification Test

Chapter 6 - Process Models 10

 Waterfall Development Roles

 Team Leader
– Responsible for one subsystem – may be a single
module or a family of modules.
– Responsible for production of B and C specifications
for his team’s software.
• Presents his B-specification at the SSR (see formal
reviews slide).
• Usually delegates C Specification development to his
team members.
– Reponsible, with the other team leaders, for software
integration. Integration process is usually organized
by the Software Architect or Test Manager.
– Responsible to fully support Test Manager for the
team’s part of the system, including production of Test
Descriptions, Test Procedures, and test conduct.
 Team Members
– Responsible for their assigned part of the teams C-
Specification, code, and unit test.
– Usually present at the PDR and CDR (see formal
reviews slide).
 Quality Assurance
– Responsible for continuing assessment of the software
quality.
– Reports to the Program Manager.

Chapter 6 - Process Models 11

Breaking Down and Building Up
 Software requirements analysis and preliminary design is
a process of breaking down or decomposition in the
application domain:
– application requirements are decomposed to processes and
data flows
– each process is allocated part of the requirements model
and may derive additional requirements necessary to
complete or disambiguate its process model
– a design structure is developed by associating major process
blocks with modules - to be composed of func-tions and
classes
– each stage of the decomposition needs to allocate
requirements to its component parts, otherwise there is no
basis for deciding the correctness of the design
– at the lowest component level requirements are specified as
preconditions assumed to hold for the component,
processing the component must perform on its input data,
and post conditions which the processing must guarantee.

 Detailed design and testing is a process of building up or

recomposition in the solution domain:
– function and class development builds a language into
which the applications processing is encoded
– each function and class is tested for conformance to its
process model.
– new functions and classes are added to satisfy the process
model of the module in which they are embedded
– modules are populated in order of their dependencies and
used to progressively build system capability
– this process continues until all system requirements are met
and tested.

Chapter 6 - Process Models 12

 Breaking Down, Building Up

logical behavioral model of

A-Specification
software system

organizing principles
Architectural Concept high level structure
design issues
decomposition
in application domain
logical models of
major processing
B-Specification components
with data flows

logical process models

--> logical modules
C-Specification --> functions, classes
--> physical modules
recomposition
in solution domain
physical modules
Integration & Test --> physical programs
--> physical system

logical behavioral model of

Qualification Test
software system

Chapter 6 - Process Models 13

 Waterfall Model –
Customer Reviews
 Requirements Analysis:
– Software Specification Review (SSR) presents
 Architecture
 B-Spec = DFDs + HIPOs + Data Dict + RTM
 derived requirements
 requirements and design and issues

 Design:
– Preliminary Design Review (PDR) presents
 Module structure
 Prelim C-Specs = ModCht + StrChts +
Class Structures + HIPOs
 resolution of design and requirements issues
 derived requirements, design and test issues
– Critical Design Review (CDR) presents
 C-Specs = ModCht + StrChts + Hdrs + STDs + HIPOs +
Pseudo Code
 resolution of design and test issues

 Code and Unit Test:

– informal code walkthroughs and inspections

 Integration Testing:
– Test Readiness Review (TRR) presents
 major test groups
 test procedures
 test equipment, environment

Chapter 6 - Process Models 14

 Customer Reviews (continued)

 Qualification Testing:
– formal, step-by-step, proof that system meets A and B level
specification requirements
 demonstration:
run software and observe programmed responses which verify
requirements
 test:
instrument software to develop logged data, examine off-line to verify
requirements
 analysis:
show by models, calculation, reference to past data, or other deductive
means that the implementation will satisfy requirements
 inspection:
examine source code, development files, documentation to show that
requirements have been satisfied

 Audits:
– Functional Configuration Audit (FCA)
an Audit of both contracting office and contractor by outside
agency to verify that contractual obligations have been met.
Includes specification and test report reviews.

– Physical Configuration Audit (PCA)

an Audit of both contracting office and contractor by outside
agency to verify that all the component parts purchased by
the contract are in fact the ones tested and delivered.

Chapter 6 - Process Models 15

 Waterfall Model Products
 Specification analysis:
– operational concept document (OCD)
– B level software requirements specification (SRS)
– allocated baseline
 Design:
– software test plan
– software test descriptions
– database design document (DDD)
– C level software design document (SDD)
also called a C-spec
– software development files
– computer resources integrated support document (CRISD)
– development baseline
 Code and unit test:
– test procedures
– source code
– development baseline
 Integration testing:
– software test procedures
– test readiness review
 Qualification testing:
– software test report (STR)
– software product specification (SRS, SDD, code, STR)
– version description document (VDD)
– computer system operators manual (CSOM)

Chapter 6 - Process Models 16

 Waterfall Model Summary
 The waterfall model does a good job of capturing the
essentials of a large software development process:
– activities required
– roles of specific project personnel
– products generated

 It does not do a very good job of accounting for many

realities of the development process:
– Need for constant change due to:
• requirement errors
• design errors
• Implementation errors
• performance deficits
• accommodation of changes in another part of the system
– Need to carefully control change.
– Discovery of unforeseen risks.
– Uncertainty in scheduling work that the team has not done
before, e.g., design and development using unfamiliar
technology or new platforms.

 This failing of the waterfall model has prompted the

development of several new variations on the waterfall
theme.
– Incremental Development
– Spiral model
– Design by Contract
– Extreme Programming
– Amalgams of two or more of these.

Chapter 6 - Process Models 17

Capability Maturity Model (CMM)
 Formalized, under DoD funding, by the Software
Engineering Institute, Carnegie Mellon University, it
describes software development processes in terms of five
levels:
– Level 1 - Initial
Ad hoc process, unpredictable results.
Key process areas:
• none
– Level 2 - Repeatable
Disciplined process using standard management principles.
Key Process Areas:
• requirements management
• project planning
• project tracking and oversight
• configuration management
• quality assurance
– Level 3 - Defined
Standard process applied consistently across organization.
– Level 4 - Managed
Predictable process using metrics gathered as part of the
applied process.
– Level 5 - Optimizing
Continuously improving process with a mandated process for
defect prevention.

 References:
– The Capability Maturity Model, Software Engineering Institute,
Addison Wesley, 1994
– Process Improvement for Small Organizations, Kelly & Culleton,
IEEE Computer, October 1999

Chapter 6 - Process Models 18

 Variations on the
Development Model
 Incremental Development Model
– Partitions development into modules, implementing in order of dependency,
so that as each is completed, we integrate only a small amount of newly
developed code with an existing baseline.
 Design by Contract
– Espoused by Bertrand Meyers, an authority on Object Oriented
Development and creator of the Eiffel programming language.
– Attempts to support and enforce the use of contracts between users and
suppliers of services.
 Spiral Model
– Attempts to control project risks by developing a series of prototypes with
increasing functionality, culminating in the final delivered product.
 Evolutionary Project Management, an Extension of the Spiral Model
– Plans for frequent working deliveries to the customer with progressively
more functionality.
– At the end of each cycle, devise a plan, schedule, and budget for the next
release.
– Emphasis on continuous testing.
 Extreme Programming, an Extension of Evolutionary PM
– Takes evolutionary programming to an extreme.
– Requirements are based on user “stories”, e.g., how I would use the
product.
– Customers decide when to release, but only when all tests pass.
– We work until the money is gone.
 Microsoft Development Process
– Segregate development organization into:
• Top level product managers and system architects
• Project teams – each project creates a new version or a new feature.
• Each team consists of a project manager, developers, and testers
• Project manager is responsible for the specifications, schedule, and delivery.
• Developers are responsible for reviewing and criticizing the specification,
developing product code, and fixing bugs found by the testers.
• Testers beat unmercifully on the developer’s code, hoping to find all visible and
latent bugs.

Chapter 6 - Process Models 19

Incremental Development Model
 Begins with requirements analysis and preliminary
design just like the spiral model.

As soon as modules are defined one is selected

that has no dependencies on other modules (at
least one almost always exists). This module’s
development proceeds as with the spiral model,
until unit test is completed. A regression
(summary) level test is incorporated into the
module’s source code as a test stub, and used to
verify the module’s operation.

Next a module is selected which depends at most

on the completed module. It also is subjected to
the spiral model process through integration test
with the completed module. That is, detailed
design, code and unit test, and integration test are
all completed.

This process continues until all the modules have

been integrated. The development completes by
carrying out qualification test to demonstrate that
the software meets all its contractual obligations.

Chapter 6 - Process Models 20

 Incremental Development

Requirements Analysis

Preliminary Design

Design Design --- Design

phases

Code & UT Code & UT --- Code & UT

partially tested
code
Integration Test
partially tested
correct code code
Integration Test

correct code
Integration Test

modules

Qualification Test

Chapter 6 - Process Models 21

 Design by Contract
 Design by Contract
– A development process based on built-in test.
– Uses assertion constructs to guarantee correctness
 Pre-conditions:
– Conditions which must be satisfied by the caller. These are
assumptions the service supplier makes about the caller.
These assumptions are EXPLICIT!
– Pre-conditions are checked by the REQUIRES(bool) construct.
 Post-conditions:
– Conditions the service supplier guarantees to hold after
delivery of the service, provided that the pre-conditions are
met.
– Post-conditions are checked by the ENSURE(bool) construct.
 Invariants:
– Invariants are conditions which must hold at the end of every
service invocation. They define correctness for the module’s
state.
– Invariants are checked by the CHECK_INVARIANT construct.
– Invariants are defined at the end of a class declaration with
the syntax:

INVARIANT
invariant statements, e.g.:
ASSERT(bool), IMPLIES(bool,bool), or
BASE_INVARIANT(base class)
END_INVARIANT

Chapter 6 - Process Models 22

 Spiral Model
 The Spiral Development Model, developed by Barry Boehm
of TRW, and used by that organization, and others starting
in 1986.
 Development proceeds through several prototypes,
culminating in the completed system. Each prototype is
developed according to the waterfall model, e.g. through
requirements analysis, code and unit test, integration, and
system testing.
 Its intent is to deal effectively with the uncertainties and
risks associated with a large new development.

Chapter 6 - Process Models 23

Evolutionary Project Management
 Plan for frequent deliveries of a production quality system
that runs with growing functionality.
 Goals:
– budget cost and schedule for the complete project
– divide the project into a series of small delivery cycles
– focus on short-term, clear goals with a high expectation of
meeting them
– deliver fully tested, production-quality software with the right
documentation at the end of each cycle
– solicit feedback from customer, management at the end of
every cycle
– reassess objectives at the beginning of every cycle
– estimate effort at the beginning of each cycle
– make quality objectives part of the project requirements
– conclude the project when the budgeted cost or schedule has
been consumed or the customer contracts for further work.
 Inspection process:
– All deliverable items are inspected by the Project Manager
and an inspection committee (of developers) using a walk-
through process lead by the originator.
– All defects are recorded.
– The originator removes all defects and resubmits the item for
inspection. The process repeats until the item meets or
exceeds its planned levels of quality.
 References:
– Evolutionary Project Management, Woodward, IEEE
Computer, October 1999

Chapter 6 - Process Models 24

 Extreme Programming

 Extreme Programming is a development process

designed to develop high quality software using an
incremental development process.
– Requirements are based on User Stories, something
like use cases, but developed by the customer.
– Builds in small incremental stages, with each stage
ending in a release of operational software to the
customer.
– Emphasizes a test-as-you-go process.
– Software tests are designed before the production
software, based on requirements.
– As software is built it is continually tested.
– The developer does not move on until all tests pass.
– Assumes the use of a lot of automated testing.
– No releases are made to the customer until all tests
pass.

 This process is very like the incremental

development process I require of you, but with a
more formal approach to testing.
– Extreme Programming construction tests are close to
full unit testing.

Chapter 6 - Process Models 25

 Extreme Programming
 Planning
Customers decide scope and time of releases based on estimates
provided by developers. Only functionality demanded by
customers is implemented in each iteration.
 Small Releases
The system is put into production in a few months, before the
whole is complete. New releases are made often, perhaps
monthly.
 Simple Design - At every moment the design:
– runs all tests
– communicates everything developers want to communicate
– contains no duplicate code
– has fewest possible classes and methods
 Tests - Developers write unit tests continuously.
Tests are collected and must all run correctly. Customers write
functional tests for the functionality in each release. These tests
should also always run correctly.
 Refactoring
Design of the system is evolved through transformations of the
existing design that keep all tests running.
 Pair Programming
All code is written by two people at one terminal.
 Just Rules
Being part of the Extreme team you sign up to follow the rules.
The team can change the rules at any time if there is consensus
on how the effects of change will be measured
 References:
– Embracing Change with Extreme Programming, Beck, IEEE
Computer, October 1999.

Chapter 6 - Process Models 26

 Low-Level Process Models

 The process models we have discussed so far

attempt to describe the entire development process.
– Waterfall, spiral, incremental, evolutionary

 There are other important models that address

smaller parts of the process, most notably the
Design by Contract model.

 Design by Contract addresses the detailed design

and implementation phases of development.
– Attempts to guarantee contracts between the user of
a service and the provider of the service.
– It does this by embedding assertions about pre-
conditions and post-conditions.
– A pre-condition is a condition required for the service
to function correctly and users must guarantee that it
holds, otherwise an exception is thrown.
– A post-condition is a guarantee of delivery of some
commodity in some state, provided that the pre-
condition holds. Should the post condition fail to hold
an exception is thrown.

Chapter 6 - Process Models 27

Microsoft Development Process
 Microsoft uses a process called “Synchronize and Stabilize”,
developed in the late 80’s and early 90’s.
– give designers lots of autonomy to evolve designs iteratively
– force the team to synchronize their work frequently
– periodically stabilize design changes and feature innovations
 Goal is to balance almost hacker-like flexibility and speed
with professional engineering discipline.
 Project begins with a vision of what the product is to do
(jointly developed by marketing and the development team)
 Program manager develops a rough functional specification
which the team evolves until end of the project.
 Schedule has a few stabilization points (milestones). Each
has a list of prioritized features and represents progress after
weeks of a development cycle:
– design, code, usability test, test, daily builds
 Each milestone marks either an alpha (internal) or beta
(external) release.
 Buffer time precedes each release. It is used to add new
features
 In the final milestone the user interface is frozen. The team
runs a final test, debugging, and stabilization sub-cycle and
issues a final release.
 Only when the project is complete is the functional
specification considered done.
 References:
– Software Development on Internet Time, Cusumano & Yoffie,
IEEE Computer, October 1999

Chapter 6 - Process Models 28

 Microsoft Test Process

 Testing starts with:

– private builds by the individual developers
– Buddy builds by the whole development team
 As soon as the team releases a build, testers begin
beating on build, based on:
– Known bugs
– Smart attempts to break code
 Tester’s goals are to find the source of each known
bug and find new bugs and their sources.
 They file bug reports which are assigned to the
responsible developer to fix.
 Testers run Build Variation Tests (BVTs) continuously.
– BVTs are automated, fast, but not too thorough.
 Every night testers run stress tests
 Every 10 or 15 builds the testers run Functional Test
suites which are much more thorough.
 As the product matures they run:
– Long haul tests designed to find resource leaks
– Performance tests
– Security tests

Chapter 6 - Process Models 29

 Survival Guide – Integration
Procedure

Find these steps in the class text, page 203, Table 14-1.

 Developer develops a piece of code.

 Developer unit tests the code.
 Developer steps through every line of code, including
all exception and error cases, in an interactive
debugger.
 Developer integrates this preliminary code with a
private version of the main build.
 Developer submits code for technical review.
 Developer informally turns code over to testing for test
case preparation. Code is reviewed.
 Developer fixes any problems identified during the
review. Fixes are reviewed.
 Developer integrates final code with the main build.
 Code is declared “complete” and can be checked off
the project activity list.

Chapter 6 - Process Models 30

 Survival Guide – Daily Build
Procedure

 The developer merges his code changes with the master

source files, after checking for conflicts with recent
changes made by other developers.
 He builds and tests a private release to ensure that the
newly implemented features still works as expected.
 The developer runs the current smoke test against his
private build to be sure the new code won’t break the
build.
 The developer checks his private copies of the source
code into the master source files.
 The build team generates a complete build of the
software from the master sources.
 The build team runs the smoke test to evaluate whether
the build is stable enough to be tested.
 If the build team discovers any errors that prevent the
build from being tested (the build is broken), it notifies
the developer who checked in the breaking code. That
developer fixes the problem immediately. Fixing the
build is the project’s top priority.
 Anyone who breaks the build becomes the project goat,
and is put in charge of the build process until someone
else breaks the build.

Chapter 6 - Process Models 31

 Configuration Management
 Configuration management is charged with controlling and
providing access to the thousands of documents, code
components, and project data items that are generated in a
large software development program. Its obligations are:

 Identification: Identify every version of every:

– document, e.g., specification, design , test, program memo,
contract letter, ...
– product code component
– support and test code component
– project data
 Each is identified by number, date, and author or responsible
individual. It then becomes a configur-ation item.

 Baselining: A baseline is a snapshot of the development

configuration (all the configuration items) at specific points in
the development:
– requirements baseline just before SSR
– design baseline just before PDR and again before CDR
– informal unit test baselines
– informal integration baselines
– integration test baseline just before TRR
– qualification test baseline just before FCA, PCA
 Each configuration item must be retrievable from any
baseline at any time after the baseline has been constructed.

Chapter 6 - Process Models 32

 Configuration Management
(continued)

 Access Control: is intended to insure that all changes to

a baseline are properly authorized, all builds have known
components, and no baseline becomes corrupted. Access
control depends on the type of baseline, e.g.:

– formal baselines: The baseline created before each major

review, e.g., SSR, PDR, CDR, TRR, PCA are formal and
require customer approval to change.
– informal baselines: All other baselines require inter-nal
approval for change, e.g., the Software Project Manager or
his agents, the librarian and team leaders.

 Control of the internal baseline is based on role models:

– developer may have only read access

– team leader has read and write access to the software
components being developed by his team
– librarian has read and write access to the entire internal
baseline, but uses the access as directed by team leaders and
the Software Project Manager
– Software Project Manager has complete discretion over
the internal baseline

Chapter 6 - Process Models 33

 Configuration Management
(continued)

 Association: The configuration management system

must maintain associations between each component of a
baseline for every version. The CM process must be able
to answer the questions:
– which components where used with any specific build of the
hundreds of builds prepared during develop-ment?
– which of the test data items came from any specific build?
– what requirements where identified for a specific build?
– what requirements, design, or implementation issues where
unresolved for any specific build?
– what changes in source code where made between any two
builds?
– what changes in a document where made between any two
releases?
 Build Control: The CM system must ensure that a
“packing list” of software components is constructed for
each build which identifies the specific versions used and
test results obtained.

The Software Project Manager and Customer must be

confident that the version lists and result assoc-iations are
accurate.

Chapter 6 - Process Models 34

 Configuration Management
(continued)

 CM Tools: Maintaining CM integrity requires:

– use of database management tools for all but the smallest
projects
– build control using a testbed with:
 command language batch automation
 make files
 structure libraries based on disk directories organized and access
controlled by baseline
 extensive requirements trace databases

 Independent Validation and Verification (IV&V):

 Many contracts demand an IV&V process conducted by a
third party (not customer and not developer). Its purpose
is to measure and report on:
– development process integrity
– software quality
 IV&V activities are usually carried out by product sampling
via inspections, participation in require-ments, design,
code, and test walkthroughs, and through the evaluation
of test plans and test data.

Chapter 6 - Process Models 35

 Development Model Summary

 The waterfall model defines all the major

phases, activities, and products of any
software development process. Its
unilateral movement through the phases of
development is not very realistic - there are
always cycles back to make changes and
fix errors - but it serves well to define the
basic development process.

 Some variation of the incremental model is

probably the most used process in
Software Engineering organizations that
have a disciplined development process -
not all do.

 The Spiral and Evolutionary Models have

been used on small to medium scale
programs with some success.

Chapter 6 - Process Models 36

 Development Model Summary
 Waterfall Model
– assumes single pass through requirements analysis, design, code
and unit test, and qualification.
– base on the house construction metaphor.
 assumes the foundation (requirements) must be done perfectly
 assumes that framing (design) can only begin after the foundation is complete.
 that siding and interior (code and unit test) can’t be started until the frame is
complete.
 assumes that final finish work (qualification) won’t affect any of the earlier
work.
– The one pass model makes sense for building houses when the
builder follows a standard process to construct a product just like
millions of others already in existence.
– It just does not work well for “one of a kind” systems even if there
is significant reuse of existing components.

 Incremental Model
– brings only one partially tested component into a thoroughly
tested baseline.

 Spiral Model
– more accurate than the waterfall, in that it recognizes the need for
revision as the developer’s learn more about the system. Based
on delivering a series of prototypes before a final version.

 Evolutionary and Extreme Programming

– There is a lot of current interest in these models. Successes have
been reported on small to medium sized programs.

 Design by contract
– as implemented with the Eiffel language, is being used in Europe,
but not much use in this country.

Chapter 6 - Process Models 37

 SW Process Model

 Requirements Analysis
– define what the system must do
– define architecture
– build a requirements model
– review requirements specifications with customer
 Design and Unit Test
– define how the system will met requirements
– define structure, e.g., modules, classes, functions
– build and test each module by populating with functions and
classes
 Integration
– integrate modules and test
– carry out performance, validation, and stress tests
 Qualification
– legal demonstration that developer’s obligations have been
met, e.g., the system meets customer’s require-ments
 Audits
– Functional Configuration Audit (FCA) showing that
contracting office and contractor have been successful
producing a working product
– Physical Configuration Audit (PCA) showing that contractor
and contracting office have supplied all purchased
components to the end user

Chapter 6 - Process Models 38

 SW Product Model
 Architecture
– defines product components and allocates processing to them
– defines external product behavior
 Requirements Specification
– describes what constitutes correct operation
– it is the basis for testing and evaluation
 Product Specification
– defines an architecture for the system
– describes software design and implementation
– specifies a software build process
 Test Plan
– defines procedures for unit, integration, validation,
qualification, and regression testing
– qualification test procedures are emphasized
 Prototype Code
– verifies design for critical processing, analyzes
implementation problems as they arise
 Product Code
– Code for each component of the product, implemented as
software modules.
– test stub attached to each module, used to establish basic
software cycling and nearly correct operation
 Test Code
– test drivers for unit and qualification tests
 Test Report

Chapter 6 - Process Models 39

Notable Quotes - Robert Martin

 From Robert Martin, President of Object Mentor

Inc. and former editor of the C++ Report:

– “I’ve said it before, and I’ll say it again: The best

process for developing software is the smallest
process that we can get away with using.”

– “The best a process can hope to do is install the

checkpoints and reviews needed to catch errors
and stimulate project management decisions”

 This overlooks the essential goals of:

– establishing strong channels of communication

– creating well understood allocations of
responsibility
– defining early all products needed to complete a
project.

 However, I agree with his main point.

Chapter 6 - Process Models 40

 Notable Quotes - Fred Brooks
 From Fred Brooks:
– Former Chairman of the Computer Science Department,
University of North Carolina
– Former Program Manager, IBM System/360.
– Former Program Manager, IBM OS/360.

 “One occasionally reads newspaper accounts of how two

programmers in a remodeled garage have built an
important program that surpasses the best efforts of large
teams. And every programmer is prepared to believe such
tales, for he knows that he could build any program much
faster than the 1000 statements/year reported for
industrial teams.

Why then have not all industrial programming teams been

replaced by dedicated garage duos? One must look at
what is being produced.”

 “Assuming that he has the disciplined, experienced

architects and that there are many implementers, how
shall the manager ensure that everyone hears, under-
stands, and implements the architects decisions? How can
a group of 10 architects maintain the conceptual integrity
of a system which 1000 men are building? A whole
technology for doing this was worked out for the
System/360 hardware design effort, and it is equally
applicable to software projects.”

Chapter 6 - Process Models 41