Overview
SOFTWARE
ENGINEERING
Overview
© The McGraw-Hill Companies, 2005
Slide 1.1
Typical Classical Phases

Requirements phase
Explore the concept
Elicit the client’s requirements

Analysis (specification) phase
Analyze the client’s requirements
Draw up the specification document
Draw up the software project management plan
“What the product is supposed to do”
© The McGraw-Hill Companies, 2005
Slide 1.2
Typical Classical Phases (contd)

Design phase
Architectural design, followed by
Detailed design
“How the product does it”

Implementation phase
Coding
Unit testing
Integration
Acceptance testing
© The McGraw-Hill Companies, 2005
Slide 1.3
Typical Classical Phases (contd)

Postdelivery maintenance
Corrective maintenance
Perfective maintenance
Adaptive maintenance

Retirement
© The McGraw-Hill Companies, 2005
Slide 1.4
No separate documentation phase
Slide 1.5

Documentation activities must be performed in
parallel with all other development and
maintenance activities

There is no separate documentation phase
© The McGraw-Hill Companies, 2005
Strengths of the Object-Oriented Paradigm
Slide 1.6

With information hiding, postdelivery maintenance
is safer
The chances of a regression fault are reduced

Development is easier
Objects generally have physical counterparts
This simplifies modeling (a key aspect of the objectoriented paradigm)
© The McGraw-Hill Companies, 2005
Strengths of the Object-Oriented Paradigm (contd)
Slide 1.7

Well-designed objects are independent units
Everything that relates to the real-world object being
modeled is in the object — encapsulation
Communication is by sending messages
This independence is enhanced by responsibility-driven
design (see later)
© The McGraw-Hill Companies, 2005
Strengths of the Object-Oriented Paradigm (contd)
Slide 1.8

A classical product conceptually consists of a
single unit (although it is implemented as a set of
modules)
The object-oriented paradigm reduces complexity
because the product generally consists of independent
units

The object-oriented paradigm promotes reuse
Objects are independent entities
© The McGraw-Hill Companies, 2005
Classical Phases vs Object-Oriented Workflows
Slide 1.9
Figure 1.8

There is no correspondence between phases and
workflows
© The McGraw-Hill Companies, 2005
In More Detail
Slide 1.10
Figure 1.9

Objects enter here
© The McGraw-Hill Companies, 2005
Object-Oriented Paradigm

Slide 1.11
Modules (objects) are introduced as early as the
object-oriented analysis workflow
This ensures a smooth transition from the analysis
workflow to the design workflow

The objects are then coded during the
implementation workflow
Again, the transition is smooth
© The McGraw-Hill Companies, 2005
The Object-Oriented Paradigm in PerspectiveSlide 1.12

The object-oriented paradigm has to be used
correctly
All paradigms are easy to misuse

When used correctly, the object-oriented paradigm
can solve some (but not all) of the problems of the
classical paradigm
© The McGraw-Hill Companies, 2005
Moving Target Problem
Slide 1.13

A change in the requirements while the software
product is being developed

Even if the reasons for the change are good, the
software product can be adversely impacted
Dependencies will be induced

Any change made to a software product can
potentially cause a regression fault
A fault in an apparently unrelated part of the software
© The McGraw-Hill Companies, 2005
Moving Target Problem (contd)

Slide 1.14
If there are too many changes
The entire product may have to be redesigned and
reimplemented

Change is inevitable

There is no solution to the moving target problem
© The McGraw-Hill Companies, 2005
Iteration and Incrementation
Slide 1.15

In real life, the operations of the analysis phase
are spread out over the life cycle

The basic software development process is
iterative
Each successive version is intended to be closer to its
target than its predecessor
© The McGraw-Hill Companies, 2005
Miller’s Law
Slide 1.16

At any one time, we can concentrate on only
approximately seven chunks (units of information)

To handle larger amounts of information, use
stepwise refinement
Concentrate on the aspects that are currently the most
important
Postpone aspects that are currently less critical
Every aspect is eventually handled, but in order of
current importance

This is an incremental process
© The McGraw-Hill Companies, 2005
Other Life-Cycle Models

Slide 1.17
The following life-cycle models are presented and
compared:
Code-and-fix life-cycle model
Waterfall life-cycle model
Rapid prototyping life-cycle model
Extreme programming and agile processes
Synchronize-and-stabilize life-cycle model
Spiral life-cycle model
© The McGraw-Hill Companies, 2005
Code-and-Fix Model

No design

No
specifications
Slide 1.18
 Maintenance
nightmare

The easiest way
to develop
software

The most
expensive way
Figure 2.7
© The McGraw-Hill Companies, 2005
Waterfall Model
© The McGraw-Hill Companies, 2005
Slide 1.19
Figure 2.8
Rapid Prototyping Model

Linear model

“Rapid”
© The McGraw-Hill Companies, 2005
Slide 1.20
Figure 2.9
Extreme Programming

Somewhat controversial new approach

Stories (features client wants)
 Estimate duration and cost of each story
 Select stories for next build
 Each build is divided into tasks
 Test cases for a task are drawn up first

Pair programming

Continuous integration of tasks
© The McGraw-Hill Companies, 2005
Slide 1.21
Unusual Features of XP
Slide 1.22

The computers are put in the center of a large
room lined with cubicles

A client representative is always present

Software professionals cannot work overtime for 2
successive weeks

No specialization
© The McGraw-Hill Companies, 2005
Synchronize-and Stabilize Model
Slide 1.23

Microsoft’s life-cycle model

Requirements analysis — interview potential
customers

Draw up specifications

Divide project into 3 or 4 builds

Each build is carried out by small teams working in
parallel
© The McGraw-Hill Companies, 2005
Synchronize-and Stabilize Model (contd)
Slide 1.24

At the end of the day — synchronize (test and debug)

At the end of the build — stabilize (freeze the build)

Components always work together
 Get early insights into the operation of the product
© The McGraw-Hill Companies, 2005
Spiral Model

Slide 1.25
Simplified form
Rapid prototyping
model plus risk
analysis preceding
each phase

If all risks cannot be
mitigated, the project
is immediately
terminated
Figure 2.10
© The McGraw-Hill Companies, 2005
Analysis of the Spiral Model

Slide 1.26
Strengths
It is easy to judge how much to test
No distinction is made between development and
maintenance

Weaknesses
For large-scale software only
For internal (in-house) software only
© The McGraw-Hill Companies, 2005
Comparison of Life-Cycle Models

Different life-cycle models have been presented
Each with its own strengths and weaknesses

Criteria for deciding on a model include:
The organization
Its management
The skills of the employees
The nature of the product

Slide 1.27
Best suggestion
“Mix-and-match” life-cycle model
© The McGraw-Hill Companies, 2005
The Unified Process

Slide 1.28
The Unified Process is not a series of steps for
constructing a software product
No such single “one size fits all” methodology could
exist
There is a wide variety of different types of software

The Unified Process is an adaptable methodology
It has to be modified for the specific software product to
be developed

UML is graphical
A picture is worth a thousand words
© The McGraw-Hill Companies, 2005
The Unified Process (contd)
Slide 1.29

UML diagrams enable software engineers to
communicate quickly and accurately

The Unified Process is a modeling technique
A model is a set of UML diagrams that represent various
aspects of the software product we want to develop

UML stands for unified modeling language
UML is the tool that we use to represent (model) the
target software product
© The McGraw-Hill Companies, 2005
The Requirements Workflow

Slide 1.30
The aim of the requirements workflow
To determine the client’s needs

First, gain an understanding of the application
domain (or domain, for short)
That is, the specific business environment in which the
software product is to operate

Second, build a business model
Use UML to describe the client’s business processes
If at any time the client does not feel that the cost is
justified, development terminates immediately
© The McGraw-Hill Companies, 2005
The Analysis Workflow

Slide 1.31
The aim of the analysis workflow
To analyze and refine the requirements

Why not do this during the requirements workflow?
The requirements artifacts must be totally
comprehensible by the client

The artifacts of the requirements workflow must
therefore be expressed in a natural (human)
language
All natural languages are imprecise
© The McGraw-Hill Companies, 2005
The Analysis Workflow (contd)

Slide 1.32
Example from a manufacturing information
system:
“A part record and a plant record are read from the
database. If it contains the letter A directly followed by
the letter Q, then calculate the cost of transporting that
part to that plant”

To what does it refer?
The part record?
The plant record?
Or the database?
© The McGraw-Hill Companies, 2005
The Analysis Workflow (contd)

Slide 1.33
Two separate workflows are needed
The requirements artifacts must be expressed in the
language of the client
The analysis artifacts must be precise, and complete
enough for the designers
© The McGraw-Hill Companies, 2005
The Specification Document (contd)

Slide 1.34
Specification document (“specifications”)
Constitutes a contract
It must not have imprecise phrases like “optimal,” or
“98 percent complete”

Having complete and correct specifications is
essential for
Testing, and
Maintenance

The specification document must not have
Contradictions
Omissions
Incompleteness
© The McGraw-Hill Companies, 2005
Software Project Management Plan
Slide 1.35

Once the client has signed off the specifications,
detailed planning and estimating begins

We draw up the software project management
plan, including
Cost estimate
Duration estimate
Deliverables
Milestones
Budget

This is the earliest possible time for the SPMP
© The McGraw-Hill Companies, 2005
The Design Workflow

Slide 1.36
The aim of the design workflow is to refine the
analysis workflow until the material is in a form
that can be implemented by the programmers
Many nonfunctional requirements need to be finalized at
this time, including




Choice of programming language
Reuse issues
Portability issues
Retain design decisions
For when a dead-end is reached, and
To prevent the maintenance team reinventing the wheel
© The McGraw-Hill Companies, 2005
Classical Design

Architectural design
Decompose the product into modules

Detailed design
Design each module:


Data structures
Algorithms
© The McGraw-Hill Companies, 2005
Slide 1.37
Object-Oriented Design

Slide 1.38
Classes are extracted during the object-oriented
analysis workflow, and
Designed during the design workflow

Accordingly
Classical architectural design corresponds to part of the
object-oriented analysis workflow
Classical detailed design corresponds to part of the
object-oriented design workflow
© The McGraw-Hill Companies, 2005
The Implementation Workflow

Slide 1.39
The aim of the implementation workflow is to
implement the target software product in the
selected implementation language
A large software product is partitioned into subsystems
The subsystems consist of components or code
artifacts
© The McGraw-Hill Companies, 2005
The Test Workflow

Slide 1.40
The test workflow is the responsibility of
Every developer and maintainer, and
The quality assurance group

Traceability of artifacts is an important requirement
for successful testing
© The McGraw-Hill Companies, 2005
Requirements Artifacts

Slide 1.41
Every item in the analysis artifacts must be
traceable to an item in the requirements artifacts
Similarly for the design and implementation artifacts
© The McGraw-Hill Companies, 2005
Analysis Artifacts

Slide 1.42
The analysis artifacts should be checked by
means of a review
Representatives of the client and analysis team must be
present

The SPMP must be similarly checked
Pay special attention to the cost and duration estimates
© The McGraw-Hill Companies, 2005
Design Artifacts

Design reviews are essential
A client representative is not usually present
© The McGraw-Hill Companies, 2005
Slide 1.43
Implementation Artifacts

Slide 1.44
Each component is tested as soon as it has been
implemented
Unit testing

At the end of each iteration, the completed
components are combined and tested
Integration testing

When the product appears to be complete, it is
tested as a whole
Product testing

Once the completed product has been installed on
the client’s computer, the client tests it
Acceptance testing
© The McGraw-Hill Companies, 2005
Implementation Artifacts (contd)

Slide 1.45
COTS software is released for testing by
prospective clients
Alpha release
Beta release

There are advantages and disadvantages to being
an alpha or beta release site
© The McGraw-Hill Companies, 2005
Postdelivery Maintenance

Slide 1.46
Postdelivery maintenance is an essential component of
software development
 More money is spent on postdelivery maintenance than on all other
activities combined

Problems can be caused by
 Lack of documentation of all kinds

Two types of testing are needed
 Testing the changes made during postdelivery maintenance
 Regression testing

All previous test cases (and their expected outcomes) need
to be retained
© The McGraw-Hill Companies, 2005
Retirement

Slide 1.47
Software is can be unmaintainable because
A drastic change in design has occurred
The product must be implemented on a totally new
hardware/operating system
Documentation is missing or inaccurate
Hardware is to be changed—it may be cheaper to
rewrite the software from scratch than to modify it

These are instances of maintenance (rewriting of
existing software)

It occurs when the client organization no longer
needs the functionality provided by the product
© The McGraw-Hill Companies, 2005
The Phases of the Unified Process

Slide 1.48
The increments are identified as phases
© The McGraw-Hill Companies, 2005
Figure 3.1
The Phases of the Unified Process (contd)
Slide 1.49

The four increments are labeled
Inception phase
Elaboration phase
Construction phase
Transition phase

The phases of the Unified Process are the
increments
© The McGraw-Hill Companies, 2005
The Phases of the Unified Process (contd)
Slide 1.50

In theory, there could be any number of
increments
In practice, development seems to consist of four
increments

Every step performed in the Unified Process falls
into
One of the five core workflows and also
One of the four phases

Why does each step have to be considered twice?
© The McGraw-Hill Companies, 2005
The Phases of the Unified Process (contd)
Slide 1.51

Workflow
Technical context of a step

Phase
Business context of a step
© The McGraw-Hill Companies, 2005
The Inception Phase

Slide 1.52
The aim of the inception phase is to determine
whether the proposed software product is
economically viable
1. Gain an understanding of the domain
2. Build the business model
3. Delimit the scope of the proposed project
Focus on the subset of the business model that is covered
by the proposed software product
4. Begin to make the initial business case
© The McGraw-Hill Companies, 2005
Elaboration Phase

Slide 1.53
The aim of the elaboration phase is to refine the
initial requirements
Refine the architecture
Monitor the risks and refine their priorities
Refine the business case
Produce the project management plan

The major activities of the elaboration phase are
refinements or elaborations of the previous phase
© The McGraw-Hill Companies, 2005
The Tasks of the Elaboration Phase

Slide 1.54
The tasks of the elaboration phase correspond to:
All but completing the requirements workflow
Performing virtually the entire analysis workflow
Starting the design of the architecture
© The McGraw-Hill Companies, 2005
The Elaboration Phase: Documentation
Slide 1.55

The deliverables of the elaboration phase include:
The completed domain model
The completed business model
The completed requirements artifacts
The completed analysis artifacts
An updated version of the architecture
An updated list of risks
The project management plan (for the rest of the
project)
The completed business case
© The McGraw-Hill Companies, 2005
Construction Phase

The aim of the construction phase is to produce
the first operational-quality version of the software
product
This is sometimes called the beta release

Slide 1.56
The emphasis in this phase is on
Implementation, and
Testing



Unit testing of modules
Integration testing of subsystems
Product testing of the overall system
© The McGraw-Hill Companies, 2005
The Construction Phase: Documentation
Slide 1.57

The deliverables of the construction phase
include:
The initial user manual and other manuals, as
appropriate
All the artifacts (beta release versions)
The completed architecture
The updated risk list
The project management plan (for the remainder of the
project)
If necessary, the updated business case
© The McGraw-Hill Companies, 2005
The Transition Phase

Slide 1.58
The aim of the transition phase is to ensure that
the client’s requirements have indeed been met
Faults in the software product are corrected
All the manuals are completed
Attempts are made to discover any previously
unidentified risks

This phase is driven by feedback from the site(s)
at which the beta release has been installed
© The McGraw-Hill Companies, 2005
The Transition Phase: Documentation

Slide 1.59
The deliverables of the transition phase include:
All the artifacts (final versions)
The completed manuals
© The McGraw-Hill Companies, 2005
The Transition Phase: Documentation

Slide 1.60
The deliverables of the transition phase include:
All the artifacts (final versions)
The completed manuals
© The McGraw-Hill Companies, 2005
Programming Team Organization

Slide 1.61
Example:
Sheila and Harry code two modules, m1 and m2, say

What can go wrong
Both Sheila and Harry may code m1, and ignore m2
Sheila may code m1, Harry may code m2. When m1
calls m2 it passes 4 parameters; but m2 requires 5
parameters
Or, the order of parameters in m1 and m2 may be
different
Or, the order may be same, but the data types may be
slightly different
© The McGraw-Hill Companies, 2005
Programming Team Organization (contd)
Slide 1.62

This has nothing whatsoever to do with technical
competency
Team organization is a managerial issue
© The McGraw-Hill Companies, 2005
Communications Problems

Slide 1.63
Example
There are three channels of communication between
the three programmers working on a project. The
deadline is rapidly approaching but the code is not
nearly complete

“Obvious” solution:
Add a fourth
programmer
to the team
© The McGraw-Hill Companies, 2005
Figure 4.1
Communications Problems (contd)

Slide 1.64
But other three have to explain in detail
What has been accomplished
What is still incomplete

Brooks’s Law
Adding additional programming personnel to a team
when a product is late has the effect of making the
product even later
© The McGraw-Hill Companies, 2005
Team Organization

Slide 1.65
Teams are used throughout the software
production process
But especially during implementation
Here, the discussion is presented within the context of
programming teams

Two extreme approaches to team organization
Democratic teams (Weinberg, 1971)
Chief programmer teams (Brooks, 1971; Baker, 1972)
© The McGraw-Hill Companies, 2005
Democratic Team Approach
Slide 1.66

Basic underlying concept — egoless programming

Programmers can be highly attached to their code
They even name their modules after themselves
They see their modules as extension of themselves
© The McGraw-Hill Companies, 2005
Democratic Team Approach (contd)

Slide 1.67
If a programmer sees a module as an extension
of his/her ego, he/she is not going to try to find
all the errors in “his”/“her” code
If there is an error, it is termed a bug 
The fault could have been prevented if the code had
been better guarded against the “bug”
“Shoo-Bug” aerosol spray
© The McGraw-Hill Companies, 2005
Democratic Team Approach (contd)

Proposed Solution

Egoless programming
Slide 1.68
Restructure the social environment
Restructure programmers’ values
Encourage team members to find faults in code
A fault must be considered a normal and accepted event
The team as whole will develop an ethos, a group identity
Modules will “belong” to the team as whole
A group of up to 10 egoless programmers constitutes a
democratic team
© The McGraw-Hill Companies, 2005
Difficulties with Democratic Team Approach
Slide 1.69

Management may have difficulty
Democratic teams are difficult to introduce into an
undemocratic environment
© The McGraw-Hill Companies, 2005
Strengths of Democratic Team Approach
Slide 1.70

Democratic teams are enormously productive

They work best when the problem is difficult

They function well in a research environment

Problem:
Democratic teams have to spring up spontaneously
© The McGraw-Hill Companies, 2005
Classical Chief Programmer Team
Slide 1.71
Figure 4.3

Six programmers, but now only 5 lines of
communication
© The McGraw-Hill Companies, 2005
Classical Chief Programmer Team (contd)
Slide 1.72

The basic idea behind the concept
Analogy: chief surgeon directing an operation, assisted
by





Other surgeons
Anesthesiologists
Nurses
Other experts, such as cardiologists, nephrologists
Two key aspects
Specialization
Hierarchy
© The McGraw-Hill Companies, 2005
Classical Chief Programmer Team (contd)
Slide 1.73

Chief programmer
Successful manager and highly skilled programmer
Does the architectural design
Allocates coding among the team members
Writes the critical (or complex) sections of the code
Handles all the interfacing issues
Reviews the work of the other team members
Is personally responsible for every line of code
© The McGraw-Hill Companies, 2005
Classical Chief Programmer Team (contd)
Slide 1.74

Back-up programmer
Necessary only because the chief programmer is human
The back-up programmer must be in every way as
competent as the chief programmer, and
Must know as much about the project as the chief
programmer
Does black-box test case planning and other tasks that
are independent of the design process
© The McGraw-Hill Companies, 2005
Classical Chief Programmer Team (contd)
Slide 1.75

Programmers
Do nothing but program
All other aspects are handled by the programming
secretary
© The McGraw-Hill Companies, 2005
Impracticality of Classical CPT
Slide 1.76

The chief programmer must be a highly skilled
programmer and a successful manager

There is a shortage of highly skilled programmers

There is a shortage of successful managers

The qualities needed to be a highly skilled
programmer are unlikely to be found in a
successful manager, and vice versa
© The McGraw-Hill Companies, 2005
Impracticality of Classical CPT (contd)
Slide 1.77

The back-up programmer must be as good as the
chief programmer
But he/she must take a back seat (and a lower salary)
waiting for something to happen to the chief
programmer
Top programmers, top managers will not do that

The programming secretary does nothing but
paperwork all day
Software professionals hate paperwork

Classical CPT is impractical
© The McGraw-Hill Companies, 2005
Beyond CP and Democratic Teams

Slide 1.78
We need ways to organize teams that
Make use of the strengths of democratic teams and
chief programmer teams, and
Can handle teams of 20 (or 120) programmers

A strength of democratic teams
A positive attitude to finding faults

Use CPT in conjunction with code walkthroughs or
inspections
© The McGraw-Hill Companies, 2005
Beyond CP and Democratic Teams (contd)
Slide 1.79

Potential pitfall

The chief programmer is personally responsible
for every line of code
He/she must therefore be present at reviews

The chief programmer is also the team manager
He/she must therefore not be present at reviews!
© The McGraw-Hill Companies, 2005
Beyond CP and Democratic Teams (contd)
Slide 1.80
Figure 4.4

Solution
Reduce the managerial role of the chief programmer
© The McGraw-Hill Companies, 2005
Beyond CP and Democratic Teams (contd)
Slide 1.81

It is easier to find a team leader than a chief
programmer

Each employee is responsible to exactly one
manager—lines of responsibility are clearly
delineated

The team leader is responsible for only technical
management
© The McGraw-Hill Companies, 2005
Beyond CP and Democratic Teams (contd)
Slide 1.82

Budgetary and legal issues, and performance
appraisal are not handled by the team leader

The team leader participates in reviews — the
team manager is not permitted to do so

The team manager participates in regular team
meetings to appraise the technical skills of the
team members
© The McGraw-Hill Companies, 2005
Larger Projects
Slide 1.83
Figure 4.5

The nontechnical side is similar
For even larger products, add additional layers
© The McGraw-Hill Companies, 2005
Beyond CP and Democratic Teams (contd)
Slide 1.84
Figure 4.6

Decentralize the decision-making process, where
appropriate
Useful where the democratic team is good
© The McGraw-Hill Companies, 2005
Synchronize-and-Stabilize Teams

Used by Microsoft

Products consist of 3 or 4 sequential builds

Small parallel teams
3 to 8 developers
3 to 8 testers (work one-to-one with developers)
The team is given the overall task specification
They may design the task as they wish
© The McGraw-Hill Companies, 2005
Slide 1.85
Synchronize-and-Stabilize Teams (contd)
Slide 1.86

Why this does not degenerate into hacker-induced
chaos?
Daily synchronization step
Individual components always work together

Rules
Programmers must adhere to the time for entering the
code into the database for that day’s synchronization

Analogy
Letting children do what they like all day…
… but with a 9 P.M. bedtime
© The McGraw-Hill Companies, 2005
Extreme Programming Teams

Slide 1.87
Feature of XP
All code is written by two programmers sharing a
computer
“Pair programming”
© The McGraw-Hill Companies, 2005
Strengths of Pair Programming

Slide 1.88
Programmers should not test their own code
One programmer draws up the test cases, the other
tests the code

If one programmer leaves, the other is sufficiently
knowledgeable to continue working with another
pair programmer

An inexperienced programmer can learn from his
or her more experienced team member
© The McGraw-Hill Companies, 2005
Strengths of Pair Programming
Slide 1.89

Test cases are drawn up by one member of the
team, tested by the other

Knowledge is not all lost if one programmer leaves

An inexperienced programmer can learn from an
experienced colleague

Centralized computers promote egoless
programming
© The McGraw-Hill Companies, 2005
Stepwise Refinement

Slide 1.90
A basic principle underlying many software
engineering techniques
“Postpone decisions as to details as late as possible to
be able to concentrate on the important issues”

Miller’s law (1956)
A human being can concentrate on 7 ± 2 items at a time
© The McGraw-Hill Companies, 2005
Appraisal of Stepwise Refinement

Slide 1.91
A basic principle used in
Every workflow
Every representation

The power of stepwise refinement
The software engineer can concentrate on the relevant
aspects

Warning
Miller’s Law is a fundamental restriction on the mental
powers of human beings
© The McGraw-Hill Companies, 2005
Cost–Benefit Analysis

Compare costs and future benefits
 Estimate costs
 Estimate benefits
 State all assumptions explicitly

Example: Computerizing KCEC
© The McGraw-Hill Companies, 2005
Slide 1.92
Cost–Benefit Analysis (contd)

Tangible costs/benefits are easy to measure

Make assumptions to estimate intangible
costs/benefits
Slide 1.93
Improving the assumptions will improve the estimates
© The McGraw-Hill Companies, 2005
Software Metrics
Slide 1.94

To detect problems early, it is essential to measure

Examples:
LOC per month
Defects per 1000 lines of code
© The McGraw-Hill Companies, 2005
The Five Basic Metrics

Size
In lines of code, or better

Cost
In dollars

Duration
In months

Effort
In person months

Quality
Number of faults detected
© The McGraw-Hill Companies, 2005
Slide 1.95
Software Versions

Slide 1.96
During maintenance, at all times there are at
least two versions of the product:
The old version, and
The new version

There are two types of versions: revisions and
variations
© The McGraw-Hill Companies, 2005
Revisions

Slide 1.97
Revision
A version to fix a fault in the artifact
We cannot throw away an incorrect version



The new version may be no better
Some sites may not install the new version
Perfective and adaptive maintenance also result in
revisions
© The McGraw-Hill Companies, 2005
Variations
Slide 1.98
A variation is a version for a different operating
system–hardware
 Variations are designed to coexist in parallel

Figure 5.11
© The McGraw-Hill Companies, 2005
Testing

Slide 1.99
There are two basic types of testing
Execution-based testing
Non-execution-based testing

“V & V”
Verification

Determine if the workflow was completed correctly
Validation

Determine if the product as a whole satisfies its requirements
© The McGraw-Hill Companies, 2005
Software Quality
Slide 1.100

Not “excellence”

The extent to which software satisfies its
specifications

Every software professional is responsible for
ensuring that his or her work is correct
Quality must be built in from the beginning
© The McGraw-Hill Companies, 2005
Software Quality Assurance

Slide 1.101
The members of the SQA group must ensure that
the developers are doing high-quality work
At the end of each workflow
When the product is complete

In addition, quality assurance must be applied to
The process itself

Example: Standards
© The McGraw-Hill Companies, 2005
Managerial Independence

Slide 1.102
There must be managerial independence between
The development group
The SQA group

Neither group should have power over the other

More senior management must decide whether to
Deliver the product on time but with faults, or
Test further and deliver the product late

The decision must take into account the interests
of the client and the development organization
© The McGraw-Hill Companies, 2005
Non-Execution-Based Testing

Underlying principles
We should not review our own work
Group synergy
© The McGraw-Hill Companies, 2005
Slide 1.103
Walkthroughs
Slide 1.104

A walkthrough team consists of from four to six
members

It includes representatives of
The team responsible for the current workflow
The team responsible for the next workflow
The SQA group

The walkthrough is preceded by preparation
Lists of items


Items not understood
Items that appear to be incorrect
© The McGraw-Hill Companies, 2005
Managing Walkthroughs
Slide 1.105

The walkthrough team is chaired by the SQA
representative

In a walkthrough we detect faults, not correct them
A correction produced by a committee is likely to be of
low quality
The cost of a committee correction is too high
Not all items flagged are actually incorrect
A walkthrough should not last longer than 2 hours
There is no time to correct faults as well
© The McGraw-Hill Companies, 2005
Managing Walkthroughs (contd)
Slide 1.106

A walkthrough must be document-driven, rather
than participant-driven

Verbalization leads to fault finding

A walkthrough should never be used for
performance appraisal
© The McGraw-Hill Companies, 2005
Inspections

An inspection has five formal steps
Overview
Preparation, aided by statistics of fault types
Inspection
Rework
Follow-up
© The McGraw-Hill Companies, 2005
Slide 1.107
Inspections (contd)

Slide 1.108
An inspection team has four members
Moderator
A member of the team performing the current workflow
A member of the team performing the next workflow
A member of the SQA group

Special roles are played by the
Moderator
Reader
Recorder
© The McGraw-Hill Companies, 2005
Fault Statistics

Faults are recorded by severity
Example:


Major or minor
Faults are recorded by fault type
Examples of design faults:


Not all specification items have been addressed
Actual and formal arguments do not correspond
© The McGraw-Hill Companies, 2005
Slide 1.109
Fault Statistics (contd)
Slide 1.110

For a given workflow, we compare current fault
rates with those of previous products

We take action if there are a disproportionate
number of faults in an artifact
Redesigning from scratch is a good alternative

We carry forward fault statistics to the next
workflow
We may not detect all faults of a particular type in the
current inspection
© The McGraw-Hill Companies, 2005
Comparison of Inspections and WalkthroughsSlide 1.111

Inspection
Two-step, informal process



Preparation
Analysis
Walkthrough
Five-step, formal process





Overview
Preparation
Inspection
Rework
Follow-up
© The McGraw-Hill Companies, 2005
Metrics for Inspections
Slide 1.112

Inspection rate (e.g., design pages inspected per
hour)

Fault density (e.g., faults per KLOC inspected)

Fault detection rate (e.g., faults detected per hour)

Fault detection efficiency (e.g., number of major,
minor faults detected per hour)
© The McGraw-Hill Companies, 2005
Execution-based Testing: What Should Be Tested?
Slide 1.113

We need to test correctness and also
Utility: The extent to which the product meets the user’s
needs

Examples:
– Ease of use
– Useful functions
– Cost effectiveness
Reliability: A measure of the frequency and criticality of
failure



Mean time between failures
Mean time to repair
Time (and cost) to repair the results of a failure
© The McGraw-Hill Companies, 2005
Execution-based Testing: What Should Be Tested?
Slide 1.114
Robustness : Is a function of



The range of operating conditions
The possibility of unacceptable results with valid input
The effect of invalid input
Performance



The extent to which space and time constraints are met
Real-time software is characterized by hard real-time
constraints
If data are lost because the system is too slow
– There is no way to recover those data
© The McGraw-Hill Companies, 2005
Who Should Perform Execution-Based Testing?
Slide 1.115

Programming is constructive

Testing is destructive
A successful test finds a fault

So, programmers should not test their own code
artifacts
© The McGraw-Hill Companies, 2005
Who Should Perform Execution-Based Testing? (contd)
Slide 1.116

Solution:
The programmer does informal testing
The SQA group then does systematic testing
The programmer debugs the module

All test cases must be
Planned beforehand, including the expected output, and
Retained afterwards
© The McGraw-Hill Companies, 2005
When Testing Stops

Only when the product has been irrevocably
discarded
© The McGraw-Hill Companies, 2005
Slide 1.117
Reuse Concepts
Slide 1.118

Reuse is the use of components of one product to
facilitate the development of a different product
with different functionality

Opportunistic (accidental) reuse
First, the product is built
Then, parts are put into the part database for reuse

Systematic (deliberate) reuse
First, reusable parts are constructed
Then, products are built using these parts
© The McGraw-Hill Companies, 2005
Why Reuse?

Slide 1.119
To get products to the market faster
There is no need to design, implement, test, and
document a reused component

On average, only 15% of new code serves an
original purpose
In principle, 85% could be standardized and reused
In practice, reuse rates of no more than 40% are
achieved

Why do so few organizations employ reuse?
© The McGraw-Hill Companies, 2005
Impediments to Reuse
Slide 1.120
Not invented here (NIH) syndrome
 Concerns about faults in potentially reusable
routines
 Cost of reuse

The cost of making an item reusable
The cost of reusing the item
The cost of defining and implementing a reuse process
Legal issues (contract software only)
 Lack of source code for COTS components

© The McGraw-Hill Companies, 2005
Portability

Slide 1.121
Product P:
Compiled by compiler C1, then runs on machine M1
under operating system O1

Need product P', functionally equivalent to P:
Compiled by compiler C2, then runs on machine M2
under operating system O2

P is portable if it is cheaper to convert P into P'
than to write P' from scratch
© The McGraw-Hill Companies, 2005
Why Portability? (contd)

Slide 1.122
On the contrary, portability is essential
Good software lasts 15 years or more
Hardware is changed every 4 years

Upwardly compatible hardware works
But it may not be cost effective

Portability can lead to increased profits
Multiple copy software
Documentation (especially manuals) must also be
portable
© The McGraw-Hill Companies, 2005
Planning and Estimating
Slide 1.123

Before starting to build software, it is essential to
plan the entire development effort in detail

Planning continues during development and then
postdelivery maintenance
Initial planning is not enough
Planning must proceed throughout the project
The earliest possible time that detailed planning can take
place is after the specifications are complete
© The McGraw-Hill Companies, 2005
Planning and the Software Process
Slide 1.124
Figure 9.1

The accuracy of estimation increases as the
process proceeds
© The McGraw-Hill Companies, 2005
Estimating Duration and Cost

Accurate duration estimation is critical

Accurate cost estimation is critical
Internal, external costs

There are too many variables for accurate
estimate of cost or duration
© The McGraw-Hill Companies, 2005
Slide 1.125
Metrics for the Size of a Product
Lines of code (LOC, KDSI, KLOC)
 FFP
 Function Points
 COCOMO

© The McGraw-Hill Companies, 2005
Slide 1.126
Lines of Code (LOC)

Slide 1.127
Alternate metric
Thousand delivered source instructions (KDSI)

Source code is only a small part of the total
software effort

Different languages lead to different lengths of
code

LOC is not defined for nonprocedural languages
(like LISP)
© The McGraw-Hill Companies, 2005
Lines of Code (contd)

Slide 1.128
It is not clear how to count lines of code
Executable lines of code?
Data definitions?
Comments?
JCL statements?
Changed/deleted lines?

Not everything written is delivered to the client

A report, screen, or GUI generator can generate
thousands of lines of code in minutes
© The McGraw-Hill Companies, 2005
Lines of Code (contd)
Slide 1.129

LOC is accurately known only when the product
finished

Estimation based on LOC is therefore doubly
dangerous
To start the estimation process, LOC in the finished
product must be estimated
The LOC estimate is then used to estimate the cost of
the product — an uncertain input to an uncertain cost
estimator
© The McGraw-Hill Companies, 2005
Metrics for the Size of a Product (contd)
Slide 1.130

Metrics based on measurable quantities that can
be determined early in the software life cycle
FFP
Function points
© The McGraw-Hill Companies, 2005
FFP Metric

For cost estimation of medium-scale data
processing products

The three basic structural elements of data
processing products
Files
Flows
Processes
© The McGraw-Hill Companies, 2005
Slide 1.131
FFP Metric (contd)

Slide 1.132
Given the number of files (Fi), flows (Fl), and
processes (Pr)
The size (S), cost (C) are given by

S
=
Fi + Fl + Pr
C
=
bS
The constant b (efficiency or productivity) varies
from organization to organization
© The McGraw-Hill Companies, 2005
Techniques of Cost Estimation
Expert judgment by analogy
 Bottom-up approach
 Algorithmic cost estimation models

© The McGraw-Hill Companies, 2005
Slide 1.133
Expert Judgment by Analogy

Slide 1.134
Experts compare the target product to completed
products
Guesses can lead to hopelessly incorrect cost
estimates
Experts may recollect completed products inaccurately
Human experts have biases
However, the results of estimation by a broad group of
experts may be accurate

The Delphi technique is sometimes needed to
achieve consensus
© The McGraw-Hill Companies, 2005
Bottom-up Approach

Slide 1.135
Break the product into smaller components
The smaller components may be no easier to estimate
However, there are process-level costs

When using the object-oriented paradigm
The independence of the classes assists here
However, the interactions among the classes
complicate the estimation process
© The McGraw-Hill Companies, 2005
Algorithmic Cost Estimation Models

Slide 1.136
A metric is used as an input to a model to compute
cost, duration
An algorithmic model is unbiased, and therefore
superior to expert opinion
However, estimates are only as good as the underlying
assumptions

Examples
SLIM Model
Price S Model
COnstructive COst MOdel (COCOMO)
© The McGraw-Hill Companies, 2005
Tracking Duration and Cost Estimates

Whatever estimation method used, careful
tracking is vital
© The McGraw-Hill Companies, 2005
Slide 1.137
Components of a Software Project Management PlanSlide 1.138

The work to be done

The resources with which to do it

The money to pay for it
© The McGraw-Hill Companies, 2005
Resources

Slide 1.139
Resources needed for software development:
People
Hardware
Support software
© The McGraw-Hill Companies, 2005
Work Categories

Project function
Work carried on throughout the project
Examples:



Project management
Quality control
Activity
Work that relates to a specific phase
A major unit of work,
With precise beginning and ending dates,
That consumes resources, and
Results in work products like the budget, design,
schedules, source code, or users’ manual
© The McGraw-Hill Companies, 2005
Slide 1.140
Work Categories (contd)

Slide 1.141
Task
An activity comprises a set of tasks (the smallest unit of
work subject to management accountability)
© The McGraw-Hill Companies, 2005
Completion of Work Products
Slide 1.142

Milestone: The date on which the work product is
to be completed

It must first pass reviews performed by
Fellow team members
Management
The client

Once the work product has been reviewed and
agreed upon, it becomes a baseline
© The McGraw-Hill Companies, 2005
Planning Testing
Slide 1.143

The SPMP must explicitly state what testing is to
be done

Traceability is essential

All black box test cases must be drawn up as soon
as possible after the specifications are complete
© The McGraw-Hill Companies, 2005
Training Requirements
Slide 1.144

“We don’t need to worry about training until the
product is finished, and then we can train the user”

Training is generally needed by the members of
the development group, starting with training in
software planning

A new software development method necessitates
training for every member of the group
© The McGraw-Hill Companies, 2005
Training Requirements (contd)
Slide 1.145

Introduction of hardware or software tools of any
sort necessitates training

Programmers may need training in the operating
system and/or implementation language

Documentation preparation training may be
needed

Computer operators require training
© The McGraw-Hill Companies, 2005
Requirements Phase: Determining What the Client Needs
Slide 1.146

Misconception
 We must determine what the client wants

We must determine what the client needs

It is hard for a systems analyst to visualize a software
product and its functionality
 The problem is far worse for the client

A skilled systems analyst is needed to elicit the appropriate
information from the client

The client is the only source of this information
© The McGraw-Hill Companies, 2005
Requirements Phase: Determining What the Client Needs
Slide 1.147

The solution:
Obtain initial information from the client
Use this initial information as input to the Unified
Process
Follow the steps of the Unified Process to determine the
client’s real needs
© The McGraw-Hill Companies, 2005
Overview of the Requirements Workflow
Slide 1.148

First, gain an understanding of the application
domain (or domain, for short)
The specific environment in which the target product is to
operate

Second, build a business model
Model the client’s business processes

Third, use the business model to determine the
client’s requirements

Iterate the above steps
© The McGraw-Hill Companies, 2005
Definitions

Slide 1.149
Discovering the client’s requirements
Requirements elicitation (or requirements capture)
Methods include interviews and surveys

Refining and extending the initial requirements
Requirements analysis
© The McGraw-Hill Companies, 2005
Interviewing
Slide 1.150

The requirements team meet with the client and
users to extract all relevant information

There are two types of questions
Close-ended questions require a specific answer
Open-ended questions are asked to encourage the
person being interviewed to speak out

There are two types of interviews
In a structured interview, specific preplanned questions
are asked, frequently close-ended
In an unstructured interview, questions are posed in
response to the answers received, frequently openended
© The McGraw-Hill Companies, 2005
Interviewing (contd)

Slide 1.151
Interviewing is not easy
An interview that is too unstructured will not yield much
relevant information
The interviewer must be fully familiar with the
application domain
The interviewer must remain open-minded at all times

After the interview, the interviewer must prepare a
written report
It is strongly advisable to give a copy of the report to the
person who was interviewed
© The McGraw-Hill Companies, 2005
Other Techniques
Slide 1.152

Interviewing is the primary technique

A questionnaire is useful when the opinions of hundreds of
individuals need to be determined

Examination of business forms shows how the client
currently does business

Direct observation of the employees while they perform
their duties can be useful
 Videotape cameras are a modern version of this technique
 But, it can take a long time to analyze the tapes
 Employees may view the cameras as an unwarranted invasion of
privacy
© The McGraw-Hill Companies, 2005
Initial Requirements
Slide 1.153

The initial requirements are based on the initial
business model

Then they are refined

The requirements are dynamic — there are
frequent changes
Maintain a list of likely requirements, together with use
cases of requirements approved by the client
© The McGraw-Hill Companies, 2005
Initial Requirements (contd)
Slide 1.154

There are two categories of requirements

A functional requirement specifies an action that
the software product must be able to perform
Often expressed in terms of inputs and outputs

A nonfunctional requirement specifies properties of
the software product itself, such as
Platform constraints
Reliability
© The McGraw-Hill Companies, 2005
Initial Requirements (contd)
Slide 1.155

Functional requirements are handled as part of the
requirements and analysis workflows

Some nonfunctional requirements have to wait
until the design workflow
The detailed information for some nonfunctional
requirements is not available until the requirements and
analysis workflows have been completed
© The McGraw-Hill Companies, 2005
Challenges of the Requirements Phase
Slide 1.156

Employees of the client organization often feel
threatened by computerization

The requirements team members must be able to
negotiate
The client’s needs may have to be scaled down

Key employees of the client organization may not
have the time for essential in-depth discussions

Flexibility and objectivity are essential
© The McGraw-Hill Companies, 2005
The Specification Document Must Be

Slide 1.157
Informal enough for the client
The client is generally not a computer specialist

Formal enough for the developers
It is the sole source of information for drawing up the
design

These two requirements are mutually contradictory

The specification document is a contract between
the client and the developers
© The McGraw-Hill Companies, 2005
Specification Document (contd)

Slide 1.158
Acceptance criteria
It is vital to spell out a series of tests

If the product passes the tests, it is deemed have
satisfied its specifications
© The McGraw-Hill Companies, 2005
Informal Specifications (contd)

Slide 1.159
Conclusion
Natural language is not a good way to specify a product
© The McGraw-Hill Companies, 2005
Entity-Relationship Modeling

Slide 1.160
Semi-formal technique
Widely used for specifying databases
Example
Figure 11.10
© The McGraw-Hill Companies, 2005
Entity-Relationship Diagrams (contd)

Many-to-many relationship
Figure 11.11
© The McGraw-Hill Companies, 2005
Slide 1.161
Comparison of Classical Analysis TechniquesSlide 1.162

Formal methods are
Powerful, but
Difficult to learn and use

Informal methods have
Little power, but are
Easy to learn and use

There is therefore a trade-off
 Ease of use versus power
© The McGraw-Hill Companies, 2005
Which Analysis Technique Should Be Used?
Slide 1.163

It depends on the
Project
Development team
Management team
Myriad other factors
© The McGraw-Hill Companies, 2005
Challenges of Classical Analysis

Slide 1.164
A specification document must be
Informal enough for the client; but
Formal enough for the development team

Analysis (“what”) should not cross the boundary
into design (“how”)
© The McGraw-Hill Companies, 2005
The Analysis Workflow

Slide 1.165
The analysis workflow has two aims
Obtain a deeper understanding of the requirements
Describe them in a way that will result in a maintainable
design and implementation

There are three types of classes:
Entity classes
Boundary classes
Control classes
© The McGraw-Hill Companies, 2005
The Analysis Workflow (contd)

Slide 1.166
Entity class
Models long-lived information
Examples:

Account Class
 Painting Class

Boundary class
Models the interaction between the product and the
environment
A boundary class is generally associated with input or
output
Examples:

Purchases Report Class
 Sales Report Class
© The McGraw-Hill Companies, 2005
The Analysis Workflow (contd)

Control class
Models complex computations and algorithms
Examples:

Compute Masterpiece Price Class
 Compute Masterwork Price Class
 Compute Other Painting Price Class
© The McGraw-Hill Companies, 2005
Slide 1.167
Challenges of the Object-Oriented Analysis Workflow
Slide 1.168

Do not cross the boundary into object-oriented design

Do not allocate methods to classes yet
 Reallocating methods to classes during stepwise refinement is
wasted effort
© The McGraw-Hill Companies, 2005
Data and Actions

Two aspects of a product
Actions that operate on data
Data on which actions operate

The two basic ways of designing a product
Operation-oriented design
Data-oriented design

Third way
Hybrid methods
For example, object-oriented design
© The McGraw-Hill Companies, 2005
Slide 1.169
Object-Oriented Design (OOD)

Slide 1.170
Aim
Design the product in terms of the classes extracted
during OOA

OOD consists of two steps:

Step 1.
Complete the class diagram
Determine the formats of the attributes
Assign each method, either to a class or to a client that
sends a message to an object of that class

Step 2.
Perform the detailed design
© The McGraw-Hill Companies, 2005
The Design Workflow

Slide 1.171
Summary of the design workflow:
The analysis workflow artifacts are iterated and
integrated until the programmers can utilize them

Decisions to be made include:
Implementation language
Reuse
Portability
© The McGraw-Hill Companies, 2005
The Design Workflow (contd)
Slide 1.172

The idea of decomposing a large workflow into
independent smaller workflows (packages) is
carried forward to the design workflow

The objective is to break up the upcoming
implementation workflow into manageable pieces
Subsystems
© The McGraw-Hill Companies, 2005
The Design Workflow (contd)

Slide 1.173
Why the product is broken into subsystems:
It is easier to implement a number of smaller
subsystems than one large system
If the subsystems are independent, they can be
implemented by programming teams working in parallel

The software product as a whole can then be delivered sooner
© The McGraw-Hill Companies, 2005
The Design Workflow (contd)

The architecture of a software product includes
The various components
How they fit together
The allocation of components to subsystems

Slide 1.174
The task of designing the architecture is
specialized
It is performed by a software architect
© The McGraw-Hill Companies, 2005
The Design Workflow (contd)

Slide 1.175
The architect needs to make trade-offs
Every software product must satisfy its functional
requirements (the use cases)
It also must satisfy its nonfunctional requirements,
including

Portability, reliability, robustness, maintainability, and security
It must do all these things within budget and time
constraints

The architect must assist the client by laying out
the trade-offs
© The McGraw-Hill Companies, 2005
The Design Workflow (contd)

It is usually impossible to satisfy all the
requirements, functional and nonfunctional, within
the cost and time constraints
Some sort of compromises have to be made

Slide 1.176
The client has to
Relax some of the requirements;
Increase the budget; and/or
Move the delivery deadline
© The McGraw-Hill Companies, 2005
The Design Workflow (contd)

Slide 1.177
The architecture of a software product is critical
The requirements workflow can be fixed during the
analysis workflow
The analysis workflow can be fixed during the design
workflow
The design workflow can be fixed during the
implementation workflow

But there is no way to recover from a suboptimal
architecture
The architecture must immediately be redesigned
© The McGraw-Hill Companies, 2005
Challenges of the Design Phase

The design team should not do too much
The detailed design should not become code

The design team should not do too little
It is essential for the design team to produce a
complete detailed design
© The McGraw-Hill Companies, 2005
Slide 1.178
Challenges of the Design Phase (contd)
Slide 1.179

We need to “grow” great designers

Potential great designers must be
Identified,
Provided with a formal education,
Apprenticed to great designers, and
Allowed to interact with other designers

There must be specific career path for these
designers, with appropriate rewards
© The McGraw-Hill Companies, 2005
Implementation

Slide 1.180
Real-life products are generally too large to be
implemented by a single programmer
© The McGraw-Hill Companies, 2005
Choice of Programming Language (contd)
Slide 1.181

The language is usually specified in the contract

But what if the contract specifies that
The product is to be implemented in the “most suitable”
programming language

What language should be chosen?
© The McGraw-Hill Companies, 2005
Choice of Programming Language (contd)
Slide 1.182

Example
QQQ Corporation has been writing COBOL programs
for over 25 years
Over 200 software staff, all with COBOL expertise
What is “the most suitable” programming language?

Obviously COBOL
© The McGraw-Hill Companies, 2005
Choice of Programming Language (contd)
Slide 1.183

What happens when new language (C++, say) is
introduced
C++ professionals must be hired
Existing COBOL professionals must be retrained
Future products are written in C++
Existing COBOL products must be maintained
There are two classes of programmers


COBOL maintainers (despised)
C++ developers (paid more)
Expensive software, and the hardware to run it, are
needed
100s of person-years of expertise with COBOL are
wasted
© The McGraw-Hill Companies, 2005
Choice of Programming Language (contd)
Slide 1.184

The only possible conclusion
COBOL is the “most suitable” programming language

And yet, the “most suitable” language for the latest
project may be C++

How to choose a programming language
Cost–benefit analysis
Compute costs and benefits of all relevant languages
© The McGraw-Hill Companies, 2005
Good Programming Practice

Slide 1.185
Use of consistent and meaningful variable names
“Meaningful” to future maintenance programmers
“Consistent” to aid future maintenance programmers
© The McGraw-Hill Companies, 2005
Use of Consistent and Meaningful Variable Names Slide 1.186

A code artifact includes the variable names
freqAverage, frequencyMaximum, minFr, frqncyTotl

A maintenance programmer has to know if freq,
frequency, fr, frqncy all refer to the same thing
If so, use the identical word, preferably frequency,
perhaps freq or frqncy,but not fr
If not, use a different word (e.g., rate) for a different
quantity
© The McGraw-Hill Companies, 2005
Consistent and Meaningful Variable Names
Slide 1.187

We can use frequencyAverage,

We can also use averageFrequency,
frequencyMyaximum,
frequencyMinimum, frequencyTotal
maximumFrequency, minimumFrequency, totalFrequency

But all four names must come from the same set
© The McGraw-Hill Companies, 2005
The Issue of Self-Documenting Code

Self-documenting code is exceedingly rare

The key issue: Can the code artifact be
understood easily and unambiguously by
The SQA team
Maintenance programmers
All others who have to read the code
© The McGraw-Hill Companies, 2005
Slide 1.188
Self-Documenting Code Example

Slide 1.189
Example:
Code artifact contains the variable
xCoordinateOfPositionOfRobotArm
This is abbreviated to xCoord
This is fine, because the entire module deals with the
movement of the robot arm
But does the maintenance programmer know this?
© The McGraw-Hill Companies, 2005
Prologue Comments

Slide 1.190
Minimal prologue comments for a code artifact
Figure 14.1
© The McGraw-Hill Companies, 2005
Code Reuse
Slide 1.191

Code reuse is the most common form of reuse

However, artifacts from all workflows can be
reused
© The McGraw-Hill Companies, 2005
Integration

Slide 1.192
The approach up to now:
Implementation followed by integration

This is a poor approach

Better:
Combine implementation and integration methodically
© The McGraw-Hill Companies, 2005
Top-down Integration
Slide 1.193

If code artifact mAbove sends a message to artifact
mBelow, then mAbove is implemented and integrated
before mBelow

One possible top-down ordering is
 a,b,c,d,e,f,g,
h,i,j,k,l,m
Figure 14.6 (again)
© The McGraw-Hill Companies, 2005
Top-down Integration (contd)

Slide 1.194
Advantage 1: Fault isolation
A previously successful test case fails when mNew is
added to what has been tested so far


The fault must lie in mNew or the interface(s) between mNew and
the rest of the product
Advantage 2: Stubs are not wasted
Each stub is expanded into the corresponding complete
artifact at the appropriate step

Advantage 3: Major design flaws show up early
© The McGraw-Hill Companies, 2005
Bottom-up Integration
Slide 1.195

If code artifact mAbove calls code artifact mBelow, then
mBelow is implemented and integrated before mAbove

One possible bottom-up ordering is
l,m,h,i,j,k,e,
f,g,b,c,d,a
Figure 14.6 (again)
© The McGraw-Hill Companies, 2005
Bottom-up Integration (contd)

Slide 1.196
Advantage 1
Operational artifacts are thoroughly tested

Advantage 2
Operational artifacts are tested with drivers, not by fault
shielding, defensively programmed artifacts

Advantage 3
Fault isolation
© The McGraw-Hill Companies, 2005
Sandwich Integration

Logic artifacts are
integrated top-down

Operational artifacts
are integrated
bottom-up

Finally, the
interfaces between
the two groups are
tested
© The McGraw-Hill Companies, 2005
Slide 1.197
Figure 14.7
Sandwich Integration (contd)

Advantage 1
Major design faults are caught early

Advantage 2
Operational artifacts are thoroughly tested
They may be reused with confidence

Advantage 3
There is fault isolation at all times
© The McGraw-Hill Companies, 2005
Slide 1.198
The Implementation Workflow
Slide 1.199

The aim of the implementation workflow is to
implement the target software product

A large product is partitioned into subsystems
Implemented in parallel by coding teams

Subsystems consist of components or code
artifacts
© The McGraw-Hill Companies, 2005
The Implementation Workflow (contd)
Slide 1.200

Once the programmer has implemented an
artifact, he or she unit tests it

Then the module is passed on to the SQA group
for further testing
This testing is part of the test workflow
© The McGraw-Hill Companies, 2005
Unit-testing Techniques
Slide 1.201

Neither exhaustive testing to specifications nor
exhaustive testing to code is feasible

The art of testing:
Select a small, manageable set of test cases to
Maximize the chances of detecting a fault, while
Minimizing the chances of wasting a test case

Every test case must detect a previously
undetected fault
© The McGraw-Hill Companies, 2005
Black-Box and Glass-Box Unit-testing Techniques
Slide 1.202

We need a method that will highlight as many
faults as possible
First black-box test cases (testing to specifications)
Then glass-box methods (testing to code)
© The McGraw-Hill Companies, 2005
Challenges of the Implementation Workflow Slide 1.203

Management issues are paramount here
Appropriate CASE tools
Test case planning
Communicating changes to all personnel
Deciding when to stop testing
© The McGraw-Hill Companies, 2005
Postdelivery Maintenance

Slide 1.204
Postdelivery maintenance
Any change to any component of the product (including
documentation) after it has passed the acceptance test

This is a short chapter
But the whole book is essentially on postdelivery
maintenance

In this chapter we explain how to ensure that
maintainability is not compromised during
postdelivery maintenance
© The McGraw-Hill Companies, 2005
Why Postdelivery Maintenance Is Necessary
Slide 1.205

Corrective maintenance
To correct residual faults

Analysis, design, implementation, documentation, or any other
type of faults
© The McGraw-Hill Companies, 2005
Why Postdelivery Maint. Is Necessary (contd)
Slide 1.206

Perfective maintenance
Client requests changes to improve product
effectiveness



Add additional functionality
Make product run faster
Improve maintainability
© The McGraw-Hill Companies, 2005
Why Postdelivery Maint. Is Necessary (contd)
Slide 1.207

Adaptive maintenance
Responses to changes in the environment in which
the product operates



The product is ported to a new compiler, operating system,
and/or hardware
A change to the tax code
9-digit ZIP codes
© The McGraw-Hill Companies, 2005
What Is Required of Postdelivery Maintenance Programmers?
Slide 1.208

At least 67 percent of the total cost of a product
accrues during postdelivery maintenance

Maintenance is a major income source

Nevertheless, even today many organizations
assign maintenance to
Unsupervised beginners, and
Less competent programmers
© The McGraw-Hill Companies, 2005
What is Required of Postd. Maint. Prog. (contd)?
Slide 1.209

Postdelivery maintenance is one of the most
difficult aspects of software production because
Postdelivery maintenance incorporates aspects of all
other workflows
© The McGraw-Hill Companies, 2005
Corrective Maintenance

Slide 1.210
What tools does the maintenance programmer
have to find the fault?
The defect report filed by user
The source code
And often nothing else
© The McGraw-Hill Companies, 2005
Corrective Maintenance (contd)?

Slide 1.211
A maintenance programmer must therefore have
superb debugging skills
The fault could lie anywhere within the product
The original cause of the fault might lie in the by now
non-existent specifications or design documents

Suppose that the maintenance programmer has
located the fault

Problem:
How to fix it without introducing a regression fault
© The McGraw-Hill Companies, 2005
Corrective Maintenance (contd)

Slide 1.212
How to minimize regression faults
Consult the detailed documentation for the product as a
whole
Consult the detailed documentation for each individual
module

What usually happens
There is no documentation at all, or
The documentation is incomplete, or
The documentation is faulty
© The McGraw-Hill Companies, 2005
Corrective Maintenance (contd)
Slide 1.213

The programmer must deduce from the source
code itself all the information needed to avoid
introducing a regression fault

The programmer now changes the source code
© The McGraw-Hill Companies, 2005
The Programmer Now Must

Slide 1.214
Test that the modification works correctly
Using specially constructed test cases

Check for regression faults
Using stored test data

Add the specially constructed test cases to the
stored test data for future regression testing

Document all changes
© The McGraw-Hill Companies, 2005
Corrective Maintenance (contd)

Major skills are required for corrective
maintenance
Superb diagnostic skills
Superb testing skills
Superb documentation skills
© The McGraw-Hill Companies, 2005
Slide 1.215
Adaptive and Perfective Maintenance

Slide 1.216
The maintenance programmer must go through
the
Requirements
Specifications
Design
Implementation and integration
workflows, using the existing product as a starting
point
© The McGraw-Hill Companies, 2005
Adaptive and Perfective Maintenance (contd)
Slide 1.217

When programs are developed
Specifications are produced by analysis experts
Designs are produced by design experts
Code is produced by programming experts

But a maintenance programmer must be expert in
all three areas, and also in
Testing, and
Documentation
© The McGraw-Hill Companies, 2005
Conclusion

Slide 1.218
No form of maintenance
Is a task for an unsupervised beginner, or
Should be done by a less skilled computer professional
© The McGraw-Hill Companies, 2005
The Rewards of Maintenance

Slide 1.219
Maintenance is a thankless task in every way
Maintainers deal with dissatisfied users
If the user were happy, the product would not need
maintenance
The user’s problems are often caused by the individuals
who developed the product, not the maintainer
The code itself may be badly written
Postdelivery maintenance is despised by many software
developers
Unless good maintenance service is provided, the client
will take future development business elsewhere
Post delivery maintenance is the most challenging
aspect of software production — and most thankless
© The McGraw-Hill Companies, 2005
The Rewards of Maintenance (contd)

How can this situation be changed?

Managers must assign maintenance to their
best programmers, and

Pay them accordingly
© The McGraw-Hill Companies, 2005
Slide 1.220
Reverse Engineering

Slide 1.221
When the only documentation for postdelivery
maintenance is the code itself
Start with the code
Recreate the design
Recreate the specifications (extremely hard)
CASE tools can help (flowcharters, other visual aids)
© The McGraw-Hill Companies, 2005
Reverse Engineering (contd)

Slide 1.222
Reengineering
Reverse engineering, followed by forward engineering
Lower to higher to lower levels of abstraction

Restructuring
Improving the product without changing its functionality
Examples:


Structuring code
Improving maintainability
© The McGraw-Hill Companies, 2005
Reverse Engineering (contd)

Slide 1.223
What if we have only the executable code?
Treat the product as a black box
Deduce the specifications from the behavior of the
current product
© The McGraw-Hill Companies, 2005
Challenges of Postdelivery Maintenance
Slide 1.224

The hardest challenge to solve
Maintenance is harder than development, but
Developers tend to look down maintainers, and
Are frequently paid more
© The McGraw-Hill Companies, 2005