David vernon software_engineering_notes

Year 5
Software Engineering 2
(Module 514)
Academic Session 2008-2009
Semester 2
COURSE NOTES
Professor D. Vernon

Khalifa University Module 514: Software Engineering 2
2
Course Outline
Aims
To provide a working knowledge of techniques for the estimation, design, building, and quality
assurance of software projects.
Objectives
On completion of this module, it is expected that you will be able to:
1. Understand the relevance of measure and metric to software process improvement.
2. Compute FP, KLOC and other metrics.
3. Estimate the cost, effort, and duration of software projects using empirical techniques.
4. Estimate the cost, effort, and duration of software projects using the basic COCOMO Model.
5. Understand software quality assurance attributes, standards, and metrics for analysis.
6. Analyse software requirements and design solutions using both structured and object-
oriented analysis and design techniques.
7. Understand the social, ethical and professional issues in software projects.
Course Contents
Software process and project metrics: measures vs. metrics, process improvement, LOC
metrics, FP metrics, metrics for quality (correctness, maintainability, integrity, usability, defect
removal efficiency). Software project planning: resources, estimation, decomposition, COCOMO
estimation model. Project scheduling and tracking: human resources and effort, task definition,
task networks, schedules. Software quality assurance (SQA): quality attributes, software
reviews, statistical quality assurance, software quality standards, McCall’s quality factors, FURPS,
metrics for analysis, design, implementation, testing, maintenance. Object-oriented analysis,
design, and testing: OOD concepts, analysis and design issues, classes, inheritance, and
polymorphism, testing strategies, metrics. Social, ethical and professional issues: code of
ethics, copyright & security.
Recommended Textbooks
Software Engineering – A Practitioner’s Approach
Roger S. Pressman
McGraw-Hill, 5th
edition, 2001
Software Engineering
I. Sommerville,
Addison Wesley Longman, 6th
edition, 2000
Recommended References
The Mythical Man-Month : Essays on Software Engineering
P. F. Brooks
Anniversary Edition, 1995
Addison-Wesley
Software Engineering: Methods and Management Analysis
A. von Mayrhauser and V. R. Basili
Academic Press, 1990
Software Engineering Concepts
R. Fairley
McGraw-Hill, 1995

3
1. A Review of Software Engineering
Software Engineering – A Definition1
Software engineering is the branch of systems engineering concerned with the development of
large and complex software intensive systems.
It focuses on:
• the real-world goals for, services provided by, and constraints on such systems;
• the precise specification of system structure and behaviour, and the implementation of
these specifications;
• the activities required in order to develop an assurance that the specifications and real-
world goals have been met;
• the evolution of such systems over time and across system families.
It is also concerned with the:
• Processes
• Methods
• Tools
for the development of software intensive systems in an economic and timely manner.
Motivation
Consider the following statement2
“The scale of the software-dependent industry, often termed the secondary sector, extends far
beyond the conventional software sector. It is estimated that more than half of the world’s [1]
current software is “embedded” in other products, where it largely determines their functionality.
This percentage is set to increase dramatically over the next decade [2].
Software currently implements key, market-differentiating capabilities in sectors as diverse as
automobiles, air travel, consumer electronics, financial services, and mobile phones and is adding
major value in domestic appliances, house construction, medical devices, clothing and social
care.
Future competitive advantage will be based on the characteristics of products sold or services
provided. Many of those characteristics, such as functionality, timeliness, cost, availability,
reliability, interoperability, flexibility, simplicity of use or other qualities, will be largely software-
determined so that excellence in design, manufacturing or marketing will be to no avail without
appropriate software. For example, 90% of the innovation in a modern car is software-based.
Innovation, whether continuous or disruptive, will be delivered through quality software, and will
determine the success of more and more products and services.”
[1] In Germany the figure is greater than 70% (Source BMBF study 2001)
[2] “By 2010, there will be 16 billions Embedded Programmable Microcomponents (8 billions in
2003) or, in the average, 3 embedded devices per person worldwide” Artemis Technology
position paper, June 2004 ; Available at: http://www.cordis.lu/ist/artemis/background.htm
1
A. Finkelstein and J. Kramer, “Software Engineering: A Road Map” in "The Future of Software
Engineering", Anthony Finkelstein (Ed.), ACM Press 2000.
2
www.lero.ie: the Irish Software Engineering Research Centre

4
The Three Dimensions of Software Engineering
Software engineering is a rich, multi-faceted, and evolving field. It is often useful to think of it in
three dimensions, each dimension being concerned with one particular aspect.
The first dimension contains all of the tools, techniques, methods, and processes required to
develop software.
The second contains the management techniques required to organize software projects
successfully, to monitor the effectiveness of the development, and to improve the development
process.
The third addresses the way in which the non-functional attributes of the software being
developed in achieved. Non-functional attributes refer not to what the software does (its function)
but instead to the manner in which it does it (its dependability, security, composability, portability,
interoperability … these are sometimes referred to as the ‘-ilities’).

5
The Three Components of Software Engineering
There is also another way of looking at software engineering. This is sometimes referred to as
the three Ps: People, Product and Process.
People are a very important aspect of software engineering and software systems. People use
the system being developed, people design the system, people build the system, people maintain
the system, and people pay for the system. Software engineering is as much about the
organization and management of people as it is about technology.
There are typically two types of software product.
Generic products: these are stand-alone systems that are produced by a development
organization and sold in the open market to any customer who wants to buy it.
Bespoke (customized) products: these are systems that are commissioned by a specific customer
and developed specially by some contractor to meet a special need.
Most software expenditure is on generic products by most development effort is on bespoke
systems.
The trend is towards the development of bespoke systems by integrating generic components
(that must themselves be interoperable). This requires two of the non-functional properties (one
of the ‘ilities’) mentioned earlier: composability and interoperability.
The software process is a structured set of activities required to develop a
software system:
• Specification
• Design
• Validation
• Evolution
These activities vary depending on the organization and the type of system being developed.
There are several different process models and the correct model must be chosen to match the
organization and the project.
Let’s now look more deeply at the different types of software process.

6
The Basic Software Development Process
To start with, we will recall the software development process that we used when learning how to
program.
This process has a number of activities and a number of (resultant) outcomes. In the following
diagram, the activities are the arrows and the outcomes are the bubbles.
We will follow the diagram sequentially.
First we have the Problem Identification outcome. This is actually the result of a lot of
background work in the general area of the problem. Call it experience. It is an ability to look at a
domain (e.g. telecommunications or engine control) and to identify the issue that needs to be
addressed and the problem to be solved (e.g. elimination of noise or cross-talk on a
communication channel, or engine control for temperature-dependent fuel efficiency). It also
required an understanding of the theoretical issues by which we can model this problem.
This gives us our first activity: problem modelling.
Working with the end-users of our software system, we can then state clearly the requirements
of the system: what the user needs it to do (e.g. a bank may want to offer face recognition as a
security feature on it’s ATMs: the requirements will state the expected behaviour of the system).
From this, we can abstract the problem from the problem space and model it computationally:
this means we can identify the theoretical tools we need to solve the problem (statistical analysis
for the elimination of noise on the communication channel; characterization of the relationship
between fuel consumption and engineer cylinder temperature for the engine control; the
extraction of facial features from images and the statistical classification techniques used to
match these feature with faces in a database).
The result of this process of modeling and abstraction is a complete statement of the
computational model: a definition of
• the information that the system requires to solve the problem (the inputs)
• the explicit techniques used to process/analyze/transform that information (the
computational model)
• the information that will be produced (the outputs)

7
It will also identify how the information needs to be presented to the system in great detail and
how the information will be output (or presented to the user), again in great detail.
Ideally, it will also include a decomposition of the major functional blocks involved in the
processing/analysis/transformation (i.e. a modular decomposition of the computational model).
This information is collectively known as the ‘system specification’.
Once you have this specification, before proceeding you must return and see if it actually matches
what the user needs: i.e. you need to validate that the system specification satisfies the
requirement (you would be surprised how often it doesn’t). If it does, you can proceed to the next
activity: software design. If it doesn’t, then either the requirements were wrong and need to be
changed, or the specification was wrong, and needs to be changed, or, more likely, both were
wrong and need to be changed.
Software design is a process that allows you to turn your computational model into a workable
algorithm to solve the problem. Typically, it will require
• a functional decomposition of the overall system into manageable components
(at the very least: data input, data validation, data processing / analysis / transformation,
data output),
• explicit algorithms for each block (either using pseudo-code or flow-charts)
• a definition of the data-structures that will represent the input information, the output
information, and any internal information representations,
• a definition of which functional components access and/or change which data-structures.
You now have your system design. At this point you can begin coding, i.e. programming. Note
that you will never try to code the entire system in one go. You will always code up one module at
a time, and one data-structure at a time, building your system incrementally.
Similarly, you test your software incrementally, as you add more and more modules.
You will need to test for
• verification (given certain inputs, is it computing the right answer)
• validation (is it doing what we want, i.e. is it satifying the requirements)
• evaluation (how well is it doing it compared to other systems or establishes metrics).
Although not shown on the diagram, there is another process or activity called maintenance,
which is concerned with continually updating the system to allow for changes in requirements and
corrections to errors.
Finally, there is one extremely important activity that applies to all outcomes: documentation. It
is essential that every outcome is fully described and documented in great detail.

8
The Engineering Process Model3
We can see that the basic software development process is very similar to the standard
engineering process model:
• Specification - set out the requirements and constraints on the system
• Design - Produce a paper model of the system
• Manufacture - build the system
• Test - check the system meets the required specifications
• Install - deliver the system to the customer and ensure it is operational
• Maintain - repair faults in the system as they are discovered
Generic Software Process Models
There are many different software process models. Here are just four (we will cover one
additional one – the spiral model – in more depth shortly).
• The waterfall model
Separate and distinct phases of specification and development; (more below)
• Evolutionary development
Specification and development are interleaved (more below)
• Formal transformation
A mathematical system model is formally transformed to an implementation
• Reuse-based development
The system is assembled from existing components
The Waterfall Model
The waterfall model has separate and distinct phases of specification and development. These
are:
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
Each one follows the other sequentially and doesn’t begin until the previous one is finished. The
drawback of the waterfall model is the difficulty of accommodating change after the process is
underway (e.g. what happens if you find a flaw in the design after you have started
implementation?).
3
Please refer also to Chapter 1 of ‘Software Engineering’, I. Sommerville.
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance

9
The Evolutionary Development Model
There are two types of evolutionary development:
1. Exploratory prototyping
The objective is to work with customers and to evolve a final system from an initial outline
specification (i.e. build and adapt the system incrementally). Here, you should start with
well-understood requirements
2. Throw-away prototyping
In this case, the objective is to understand (find out) the system requirements. The idea is
that you quickly build a prototype and see if it suits the client’s needs. If it does, you
continue with development; if, as is more likely, it doesn’t, you throw it away and start
again with a better idea of what is needed. Here, you normally start with poorly
understood requirements
There are problems with both of these approaches.
First, there is a lack of process visibility (we say more about this in a moment, just note here that it
means that it is difficult to assess the real progress through documented analysis).
Second, the resultant systems are often poorly structured.
Third, special skills (e.g. in languages for rapid prototyping) may be required
Typically, this approach is useful in the following situations:
• For small or medium-size interactive systems
• For parts of large systems (e.g. the user interface)
• For short-lifetime systems
Validation
Final
version
Development
Intermediate
versions
Specification
Initial
version
Outline
description
Concurrent
activities

10
Risk Management
One of the principal tasks of a manager is to minimise risk of failure associated with each activity.
The 'risk' inherent in an activity is a measure of the uncertainty of the outcome of that activity.
High-risk activities (usually but not always) cause schedule and cost overruns.
Risk is related to the amount and quality of available information. The less information, the higher
the risk.
Different process models have different levels of risk:
Waterfall
• High risk for new systems because of specification and design problems
• Low risk for well-understood developments using familiar technology
Prototyping (Evolutionary)
• Low risk for new applications because specification and program stay in step
• High risk because of lack of process visibility
Transformational
• High risk because of need for advanced technology and staff skills.
Hybrid Process Models
Large systems are usually made up of several sub-systems and the same process model does
not have to be used for all subsystems: you can (and should) choose the process model which is
best suited to the type of sub-system you are developing.
For example, you might use the prototyping/evolutionary model for high-risk specifications and the
waterfall model for well-understood developments.
The Spiral Model of the Software Process
This was developed by B. Boehm and it tries to explicitly deal with the risk associated with each
activity in the software development process.
There are four phases in each revolution around the spiral; each revolution is concerned with just
one activity in the software development process.
1. Objective setting
Specific objectives for the project phase are identified
2. Risk assessment and reduction
Key risks are identified, analysed and information is sought to reduce these risks
3. Development and validation
An appropriate model is chosen for the next phase of development.
4. Planning
The project is reviewed and plans drawn up for the next round of the spiral

11
The following is a template for the various activities in a single revolution around the spiral
(remember, these activities are concerned with minimizing the risk associated with this particular
part of the software development process in question):
• Objectives
• Constraints
• Alternatives
• Risks
• Risk resolution
• Results
• Plans
• Commitment
Here’s how these activities might be used for software development task to improve software
quality:
• Objectives
o Significantly improve software quality
• Constraints
o Within a three-year timescale
o No large-scale capital investment
o No radical change to company standards
• Alternatives
o Reuse existing certified software
o Introduce formal specification and verification
o Invest in testing and validation tools
• Risks
o No cost effective quality improvement possible
o Quality improvements may increase costs excessively
o New methods might cause existing staff to leave
Risk
analysis
Risk
analysis
Risk
analysis
Risk
analysis Proto-
type 1
Prototype 2
Prototype 3
Opera-
tional
protoype
Concept of
Operation
Simulations, models, benchmarks
S/W
requirements
Requirement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integration
testAcceptance
testService Develop, verify
next-level product
Evaluate alternatives
identify, resolve risks
Determine objectives
alternatives and
constraints
Plan next phase
Integration
and test plan
Development
plan
Requirements plan
Life-cycle plan
REVIEW

12
• Risk resolution
o Literature survey
o Pilot project
o Survey of potential reusable components
o Assessment of available tool support
o Staff training and motivation seminars
• Results
o Experience of formal methods is limited - very hard to quantify improvements
o Limited tool support available for company standard development system.
o Reusable components available but little reuse tool support
• Plans
o Explore reuse option in more detail
o Develop prototype reuse support tools
o Explore component certification scheme
• Commitment
o Fund further 18-month study phase
Note that the spiral model is a hybrid model: you can use whatever conventional model you want
with it:
• If you are using the waterfall model (for well-understood systems), then each phase of the
waterfall will probably correspond to one revolution
• If you are using the evolutionary model (for uncertain systems, such as user interfaces),
then each phase may correspond to a distinct evolutionary iteration or prototype.
The spiral model has many advantages:
• Focuses attention on reuse options
• Focuses attention on early error elimination
• Puts quality objectives up front
• Integrates development and maintenance
• Provides a framework for hardware/software development
But it also has a few problems:
• Contractual development often specifies process model and deliverables in advance
• Requires risk assessment expertise
• Needs refinement for general use

13
Process Visibility
Software systems are intangible – you can’t see and feel them like you can with a manufactured
product like cars, keyboards, cameras – so managers need documents to assess progress.
However, this may cause problems
• Timing of progress deliverables may not match the time needed to complete an activity
• The need to produce documents constrains process iteration
• The time taken to review and approve documents is significant
The waterfall model is still the most widely used deliverable-based model. Each phase in the
process must be completed before the next phase begins and this provides a natural breakpoint
to create and check the appropriate documentation.
The following are some of the documents that might be produced using the waterfall process
model:
Finally, let’s review the visibility associated with each process model:
Activity Output documents
Requirements analysis Feasibility study, Outline requirements
Requirements definition Requirements document
System specification Functional specification, Acceptance test plan
Draft user manual
Architectural design Architectural specification, System test plan
Interface design Interface specification, Integration test plan
Detailed design Design specification, Unit test plan
Coding Program code
Unit testing Unit test report
Module testing Module test report
Integration testing Integration test report, Final user manual
System testing System test report
Acceptance testing Final system plus documentation
Process model Process visibility
Waterfall model Good visibility, each activity produces some
deliverable
Evolutionary
development
Poor visibility, uneconomic to produce
documents during rapid iteration
Formal
transformations
Goodvisibility, documents must be produced
from each phase for the process to continue
Reuse-oriented
development
Moderate visibility, it may be artificial to
produce documents describing reuse and
reusable components.
Spiral model Good visibility, each segment and each ring
of the spiral should produce some document.

14
‘Software Engineering is Not Enough’
Software engineering courses and textbooks tend to emphasize the management aspects and
process aspects of software development (there is not one single program listing in the textbook4
for this course).
While software engineering is certainly important, it is not everything.
The following points, taken from a recent article in IEEE Software5
, make the argument.
Software Development Is More Than Methodology (or Process, or Estimation, or Project
Management)
‘Software development is a fundamentally technical problem for which management solutions can
be only partially effective.’
‘Software development … is the hardest and least understood part of the software engineering life
cycle. Coding is immensely difficult without a good design but still very difficult with one.
Maintaining code is next to impossible without good documentation and formidable with it.’
‘There is no magic method that guarantees a well-engineered product.’
Programming is Hard
‘Programming remains monstrously complicated for the vast majority of applications.’
‘The only programs that are simple and clear are the ones you write yourself. When you have
written a program in its entirety, you have forced yourself to understand every aspect of the
problem and the solution.’
Documentation is Essential
‘There is rarely such a thing as too much documentation … the only hope for understanding
programs is good documentation of control structure blocks and detailed descriptions of the
purpose and use of data structures.’
‘Documentation – often exceeding the source code in size – is a requirement, not an option.’
You Must Validate Data
‘Good developers understand that they cannot trust user inputs. Each time an input enters the
system it must be validated to prevent failure or corruption of internal data.’
‘Developers quickly learn that every program has two parts: the code that performs the desired
function and the code that handles failure [and validation]’
‘You must painstakingly validate each parameter of each call, often meaning a lot of If statements
and calls to validation routines.’
‘Constraints on data and computation usually take the form of wrappers – access routines (or
methods) that prevent bad data from being stored or used and ensure that all programs modify
data through a single, common interface.’
4
R. Pressman, Software Engineering: A Practitioner’s Approach, McGraw-Hill, New York 1997.
5
J. A. Whittaker and S. Atkin, “Software Engineering Is Not Enough”, IEEE Software, July/August 2002, pp.
108-115.

15
Failure is Inevitable – You Need To Handle It
‘Exception handlers … raising exceptions is not the same thing as programming constraints.
Constraints actually prevent failure. Exceptions, on the other hand, let the failure occur and then
trap it. The trapped failure can then be handled by a special routine that the developer provides.’
‘Failure recovery is often difficult.’
Before you can even begin, you must be an expert in both the problem domain and the
solution domain
‘Before design, developers must pursue two activities: familiarizing themselves with the problems
they are to solve (we’ll call this problem-domain expertise) and studying the tools they will use to
solve them (we’ll call this solution-domain expertise). Expertise in both domains is crucial for
project success.’
‘Learning the problem domain means more than simply talking to users and gathering
requirements.’
‘The solution domain … consists of the tools that a team of developers and testers employ to
build the software product … editors, compilers, linkers, and debuggers, … make-utilities, runtime
libraries, development environments, version-control managers, and … the operating system.’
‘Developers must be masters of their programming language and their OS; methodology alone is
useless.’

16
2. Software Process and Project Metrics6
Measurement
Measurement is fundamental to any engineering discipline.
Software metrics is a term used to describe a range of measurements for software.
Measurement is applied to:
The software process to improve it
A software project to assist in
♦ Estimation
♦ Quality control
♦ Productivity assessement
♦ Project control
A software product to assess its quality
Terminology: Measures, Metrics, and Indicators
Measure: something that provides a quantitative indication of the extent, amount, dimensions,
capacity, or size of some attribute of a product or process. For example, the number of errors
uncovered in a single review is a measure.
Metric: a quantitative measure of the degree to which a system, component, or process
possesses a given attribute. For example, the number of errors uncovered per review is a metric.
Metrics relate measures.
Indicator: a metric or combination of metrics that provides some insight into the software
process, project, or product.
Metrics in the Process and Project Domains
The effectiveness of a software engineering process is measured indirectly:
♦ We derive a set of metrics based on the outcomes that result from the process
♦ We derive process metrics by measuring characteristics of specific software engineering
tasks
Examples of outcomes include:
♦ Measures of errors uncovered before the release of the software;
♦ Defects delivered to and reported by end users;
♦ Human effort expended
♦ Calendar time expended
♦ Conformance to the planned schedule
Examples of characteristics include:
♦ Time spent on umbrella activities (e.g. software quality assurance, configuration
management, measurement.)
6
Please refer also the Chapter 4 of ‘Software Engineering – A Practitioner’s Approach’, R. S. Pressman.

17
Software process metrics should be used carefully:
♦ Use common sense and organizational sensitivity when interpreting them
♦ Provide regular feedback to individuals and teams who have worked to collect the measures
and metrics
♦ Don’t use metric to appraise (judge) individuals
♦ Never use metrics to threaten individuals or teams
♦ Metric data that flag problem areas should not be considered ‘negative’ – they are simply an
indicator of potential process improvement
Software Measurement
There are two types of measurements:
1. Direct measures
♦ direct process measures include cost and effort
♦ direct product measures include lines of code (LOC), execution speed, memory size, defects
per unit time
2. Indirect measures
♦ Indirect product measures include functionality, quality, complexity, efficiency, reliability,
maintainability.
Size-oriented Metrics
♦ Errors per KLOC
♦ Defects per KLOC
♦ $ per KLOC
♦ pages of documentation per KLOC
♦ errors per person-month
♦ LOC per person-month
♦ $ per page of documentation
Size-oriented metrics are not universally accepted as the best way to measure the process of
software development. For example LOC are language dependent and can penalize shorter well-
designed programming styles; they don’t easily accommodate non-procedural languages.

18
Function-Oriented Metrics
Since functionality cannot be measured directly, it must be derived indirectly using other direct
measures. The function point metric is the most common function-oriented metric.
Function points are computed as follows.
Step 1. Complete the following table.
Weighting Factor
Measurement Parameter Count Simple Average Complex
Number of user inputs × 3 4 6 =
Number of user outputs × 4 5 7 =
Number of user inquiries × 3 4 6 =
Number of files × 7 10 15 =
Number of external interfaces × 5 7 10 =
User input a distinct application-oriented data to the software
User output a distinct application-oriented output such as error messages, menu, etc
User inquiry an on-line input that results in the generation of some immediate software
response in the form on an on-line output
File a logically-distinct respository of information
External interface a machine readable interface such as port, disk, tape, CD
Step 2. Compute the complexity adjustment values by answering the following questions
and rating each factor (Fi) on a scale of 0 to 5:
F1 Does the system require reliable backup and recovery?
F2 Are data communications required?
F3 Are there distributed processing functions?
F4 Is performance critical?
F5 Will the system run in an existing, heavily utilized operational environment?
F6 Does the system require on-line data entry?
F7 Does the on-line data entry require the input transaction to be built over multiple
operations?
F8 Are the master files updated online?
F9 Are the inputs, outputs, files, or inquiries complex?
F10 Is the internal processing complex?
F11 Is the code designed to be reusable?
F12 Are conversion and installation included in the design?
F13 Is the system designed for multiple installations in different organizations?
F14 Is the application designed to facilitate change and ease of use by the user?
Note:
0 No influence
1 Incidental
2 Moderate
3 Average
4 Significant
5 Essential

19
Step 3. Compute the function point value from the following equation:
( )∑×+×= iFtotalcountFP 01.065.0_
Once function points have been calculated, they are used to normalize measures of software
productivity, quality, and other attributes:
♦ Errors per FP
♦ Defects per FP
♦ $ per FP
♦ page of documentation per FP
♦ FP per person-month
Extended Function Point Metrics
The function point metric was originally designed to be applied to business information systems
applications which typically focus on information processing and transaction processing. It is not
quite as useful for engineering applications because they emphasize function and control rather
than data transactions.
Extended function point metrics overcome this by including a new software characteristic called
algorithms (a bounded computation problem that is included within a specific computer program).
More sophisticated extended function point metrics, such as 3-D function points, have also been
developed.
3D Function Point Metric
The key idea with the 3D Function Point metric is to extend the standard FP to include not only
the complexity of the data processing but also the functional (algorithmic) complexity. The
software system is characterized in three dimensions:
1. The data dimension. This is evaluated in much the same way as the normal FP. In this
case, you count the number of internal data-structures, external data sources, user
inputs, user outputs, and user inquiries, each being assigned a complexity attribute of
low, average, or high.
2. The functional dimension. This is evaluated by identifying all distinct information
transformations in the system (or module).
Transformations imply a change in the semantic content of the data, not simply a
movement of data from one place to another.
Specifically, a transformation is a series of processing steps that are governed by a set of
semantic constraints (Pressman calls them semantic statements – they could equally be
called semantic predicates). For example, a search algorithm (i.e. a transformation taking
a list as input and producing an position locator as output) would have several processing
steps that probe elements in the list and then move to a different location; the semantic
constraint is that the element being probed should be identical to the key being sought.
Transformations may have many processing steps and many semantic constraints.
Depending on the number of steps and constraints we characterize the complexity of
each transformation as low, average, or high, according to the following table.

20
Semantic Constraints (Statements / Predicates)
1-5 6-10 >10
1-10 Low Low Average
11-20 Low Average High
Processing
Steps
>20 Average High High
3. The control dimension. This is measured by counting the number of transitions between
states. For this, you need a state transition diagram for the system or module being
analysed. For example, the following state transition diagram has 6 state transitions.
Finally, you compute the 3D FP index by completing the following table:
Complexity Weighting
Measurement Element Count Simple Average High Sub-
Total
Internal data structures × 7 10 15 =
External data × 5 7 10 =
Number of user inputs × 3 4 6 =
Number of user outputs × 4 5 7 =
Number of user inquiries × 3 4 6 =
Transformations × 7 10 15 =
Transitions × 1 1 1 =
The 3D Function Point index is equal to the sum of the sub-totals.

21
Reconciling Difference Metrics Approaches
The relationship between lines of code and function points depends on the programming
language used to implement the software. The following table provides a rough indication of the
number of lines of code required to build one function point in various languages.
Programming Language LOC/FP (average)
Assembly language 320
C 128
Cobol 105
Fortran 105
Pascal 90
Ada 70
OO languages 30
4GLs 20
Code generators 15
Spreadsheets 6
Graphical languages (icons) 4

22
Metrics for Software Quality
The quality of a system or product depends on
♦ The requirements that describe the problem;
♦ The analysis and design that models the solution;
♦ The code that leads to an executable program;
♦ The tests that exercise the software to uncover errors.
A good software engineering uses measurement to assess the quality of all four components. To
accomplish this real-time quality assessment, the engineer must use technical measures to
evaluate quality in an objective (rather than a subjective) way. Chapters 18 and 23 of Pressman
cover these technical measures where metrics are presented for the analysis model, specification
quality, design model, source code, testing, and maintenance, with variants for object-oriented
systems.
Project managers must also assess quality as the project progresses.
♦ Typically he will collect and assimilate into project-level results the individual measures and
metric generated by software engineers.
♦ The main focus at project level is on errors and defects.
DRE (Defect Removal Efficiency) is an error-based quality metric which can be used for both
process and project quality assurance
DRE = E / (E + D)
where
E = the number of errors found before delivery of the software to the end user
D = the number of defects found after delivery.
The ideal value of DRE is 1.
The DRE metric can also be used to assess quality within a project to assess a team’s ability to
find errors before they are passed to the next framework activity. In this case, we redefine it as
follows
)/( 1++= iiii EEEDRE
where
iE = the number of errors found during software engineering activity i
1+iE = the number of errors found during software engineering activity i+1 that are traceable
to errors that were not discovered in software engineering activity i.
We will return to metrics for software quality later in the course (please refer also the Chapter 4 of
‘Software Engineering – A Practitioner’s Approach’, R. S. Pressman).

23
3. Software Project Planning – Resources, Estimation, Decomposition,
and the COCOMO Estimation Model7
The software project management process begins with a set of activities collectively called project
planning. The first of these activities is estimation. Best-case and worst-case scenarios should
be considered so that the project can be bounded.
The software project planner must estimate several things before a project begins:
♦ How long it will take
♦ How much effort will be required
♦ How many people will be involved
♦ The hardware resources required
♦ The software resource required
♦ The risk involved
A good project manager is someone with
♦ The ability to know what will go wrong before it actually does
♦ The courage to estimate when the future is unclear and uncertain
Issues that affect the uncertainty in project planning include:
♦ Project complexity (e.g. real-time signal processing vs. analysis of examination marks)
♦ Project size (as size increases, the interdependency between its component grows rapidly)
♦ Structural uncertainty (the completeness and finality of the requirements).
The software planner should demand completeness of function, performance, and interface
definitions (all contained in the system specification).
Software Scope
Scope addresses:
♦ Function – the actions and information transformations performed by the system
♦ Performance – processing and response time requirements
♦ Constraints – limits placed on the software by, e.g., external hardware or memory restrictions
♦ Interfaces – interations with the user and other systems
♦ Reliability – quantitative requirements for functional performance (mean time between
failures, acceptable error rates, etc.)
Scope can only be established by detailed discussions and reviews with the client. To get the
process started, some basic questions must the addressed:
♦ Who is behind the request for this work?
♦ Who will use the solution?
♦ What will be the economic benefit of a successful solution?
♦ Is there another source for the solution?
♦ How would you (the client) characterize a ‘good’ output that would be generated by a
successful solution?
♦ What problems will this solution address?
7

24
♦ Can you show me or describe to me the environment in which the solution will be used?
♦ Are there any special performance issues or constraints that will affect the way the solution is
approached?
♦ Are you the right person to answer these questions?
♦ Are your answers official?
♦ Are my questions relevant to the problem you have?
♦ Am I asking too many questions?
♦ Is there anyone else who can provide additional information?
♦ Is there anything else that I should be asking you?
These questions will break the ice and prepare for more problem-specific and project-specific
meetings.
The bottom line is that you need to identify completely the data, function, and behaviour of the
system, its constraints, and its performance requirements.
In order to do this properly, you will inevitably have to engage in a process of decomposition, sub-
dividing the overall system into functional sub-units.

25
Resources
Software Project Planning also requires the estimation of resources:
• Environmental Resources: Development (hardware and software) tools
• Reusable software component (i.e. pre-existing reusable software)
• People (human resources)
Each resource is specified by four characteristics
1. Description of the resource
2. Statement of availability
3. Time at which the resource will be required
4. Duration for which the resource will be required
Human Resources
Need to identify:
• the skill sets (e.g. databases, CGI, java, OO)
• the development effort (see later for techniques for estimating effort)
Reusable Software Resources
• Off-the-shelf components – can be acquired in house or from a third party and which can
be used directly in the project
• Full-experience components – existing specification, designs, code, test data developed
in house in previous projects but may require some modification; members of the project
team have full experience in the area represented by these components
• Partial-experience components – as above but require substantial modification;
members of the project team have partial experience in these areas
• New components – software that must be built by the team specifically for this project.
Environmental Resources
This refers to the software engineering environment. Note that this refers to more than the
development tools such as compilers, linkers, libraries, development computers. It also refers to
the final target machine and any associated hardware (e.g. a navigation system for a ship will
require access to the ship during final tests).

26
Software Project Estimation
Software is the most expensive part of a computer-based system
A large cost over-run may mean the difference between profit and loss (and bankruptcy).
Software cost and effort estimation is not an exact science but we can do much better than
guesstimates by using systematic methods (to be described below).
Generally, we use one or both of two approaches:
1. Decomposition Techniques
2. Empirical Estimation Techniques
Decomposition Techniques for Estimation
The first step in estimation is to predict the size of the project. Typically, this will be done using
either LOC (the direct approach) or FP (the indirect approach). Then we use historical data (on
similar types of projects) about the relationship between LOC or FP and time or effort to predict
the estimate of time or effort for this project.
If we choose to use the LOC approach, then we will have to decompose the project quite
considerably into as many component as possible and estimate the LOC for each component.
The size s is then the sum of the LOC of each component.
If we choose to use the FP approach, we don’t have to decompose quite so much.
In both cases, we make three estimates of size:
sopt an optimistic estimate
sm the most likely estimate
spess an optimistic estimate
and combine them to get a three-point or expected value EV
EV = (sopt + 4sm + spess)/6
EV is the value that is used in the final estimate of effort or time.

27
LOC Example
Consider the following project to develop a Computer Aided Design (CAD) application for
mechanical components.
• The software is to run on an engineering workstation
• It must interface with computer graphics peripherals (mouse, digitizer, colour display,
laser printer)
• It is to accept 2-D and 3-D geometric data from an engineer
• The engineer will interact with and control the CAD system through a graphic user
interface
• All geometric data and other supporting information will be maintained in a CAD
database
• Design analysis modules will be develop to produce the required output which will be
displayed on a number of graphics devices.
After some further requirements analysis and specification, the following major software functions
are identified:
User interface and control facilities (UICF)
2D geometric analysis (2DGA)
3D geometric analysis (3DGA)
Database management (DBM)
Computer graphics display functions (CGDF)
Peripheral control (PC)
Design analysis modules (DAM)
Function Optimistic LOC Most Likely LOC Pessimistic LOC Estimated LOC
UICF 2000 2300 3000 2367
2DGA 4000 5400 6500 5350
3DGA 5500 6600 9000 6817
DBM 3300 3500 6000 3883
CGDF 4250 4900 5500 4892
PC 2000 2150 2950 2258
DAM 6900 8400 10000 8417
Estimate LOC 33983
Historical data indicates that the organizational average productivity for systems of this type is
630 LOC/per-month and the cost per LOC is $13.
Thus, the LOC estimate for this project is
• 33983 / 620 = 55 person months
• 33983 * 13 = $441700

28
FP Example
Measurement Parameter Optimistic Likely Pess. Est.
Count
Weight FP-count
Number of user inputs 20 24 30 24 4 97
number of user outputs 12 15 22 16 5 78
number of user inquiries 16 22 28 22 4 88
number of files 4 4 5 4 10 42
number of external interfaces 2 2 3 2 7 15
Count 321
Factor Value
Backup and recovery 4
Data communications 2
Distributed processing 0
Performance critical 4
Existing operating
environment
3
On-line data entry 4
Input transactions over multiple screens 5
Master file updated on-line 3
Information domain values complex 5
Internal processing complex 5
Code designed for reuse 4
Conversion/installation in design 3
Multiple installations 5
Application designed for change 5
Estimated number of FP is
Count total * (0.65 + 0.01 * Σ Fi) = 372
Historical data indicates that the organizational average productivity for systems of this type is 6.5
FP/per-month and the cost per FP is $1230.
Thus, the FP estimate for this project is
• 372 / 6.5 = 58 person months
• 372 * 1230 = $45700

29
Empirical Estimation Models
The general form of empirical estimation models is:
C
evBAE )(×+=
Where A, B, and C are empirically derived constants. E is effort in person months and ev is the
estimation variable (either LOC or FP).
Here are some of the many model proposed in the software engineering literature:
91.0
)(2.5 KLOCE ×=
16.1
)(73.05.5 KLOCE ×+=
05.1
)(2.3 KLOCE ×=
047.1
)(288.5 KLOCE ×=
FPE ×+−= 0545.039.13
FPE ×+= 12.157.585
Note: for any given value of LOC or FP, they all give a different answer! Thus, all estimation
models need to be calibrated for local needs.
The COCOMO Model
COCOMO stands for COnstructive COst MOdel.
There are three COCOMO models:
Model 1: The Basic COCOMO model which computes software development effort
and cost as a function of program size expressed in LOC.
Model 2: The Intermediate COCOMO model which computes software development
effort and cost as a function of program size and a sset of cost drivers that
include subjective assessments of product, hardware, personnel, and
project attributes.
Model 3: The Advanced COCOMO model which incorporates all the characteristics
of the intermediate version with an assessment of all the cost drivers’
impact on each step (analysis, design, etc.) of the software engineering
process.

30
Basic COCOMO Model
bb
b KLOCaE =
bd
b EcD =
Where:
E is the effort applied in person-months
D is the development time in chronological months
KLOC is the estimated number of delivered lines of code for the project (expressed in
thousands).
ab, bb, cb, db are given in the following table.
Software Project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Note that there are three different types of project:
1. Organic: relatively small simple software projects in which small teams with good application
experience work to a set of less than rigid requirements.
2. Semi-detached: an intermediate sized project in which teams with mixed experience work to
meet a mix of rigid and less than rigid requirements.
3. Embedded: a software project that must be developed within a set of tight hardware,
software, and operational constraints.
For example, the basic COCOMO model the CAD system would yield an estimate of effort as
follows:
952.334.24.2 05.105.1
=×=×= KLOCE person-months
3.12955.25.2 35.035.0
=×=×= ED months

31
Intermediate COCOMO Model
EAFKLOCaE ib
i ×=
Where:
E is the effort applied in person-months
EAF is an effort adjustment factor
KLOC is the estimated number of delivered lines of code for the project (expressed in
thousands).
ai, bi, are given in the following table.
Software Project ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
The EAF typically has values in the range 0.9 to 1.4 and is computed on the basis of 15 cost
driver attributes. There are four categories of attributes:
1. Product attributes
2. Hardware attributes
3. Personnel attributes
4. Project attributes
Each of the 15 attributes are rated on a scale of 1-6 and these are then use to compute an EAF
based on published tables of values.

32
The Software Equation
The software equation is a multivariable model that assumes a specific distribution of effort over
the life of a software development project. The model is based on productivity data from over
4000 software engineering projects.
43
3
tP
LOCB
E
×
=
Where:
E is the effort applied in person-years (NB not person-months)
t is the project duration in years (NB not months)
B is a special skills factor that increases slowly as the need for integration, testing, quality
assurance, documentation, and management skills grows. Typical values are:
5-15 KLOC (small projects) B = 0.16
> 70KLOC B = 0.39
P is a productivity parameter that reflects:
• Overall process maturity and management practices
• Extent to which good software engineering practices are used
• Level of programming languages used
• State of the software environment
• Skills and experience of the software teams
• Complexity of the application
Typical values are:
Real-time embedded software P=2000
Telecommunication and system software P=10,000
Scientific software P=12,000
Business systems applications P=28,000
Note that the software equation has two independent variables: LOC and t.

33
4. Project Scheduling and Tracking: Human Resources and Effort, Task
Definition, Task Networks, Schedules 8
Project Scheduling
Software development projects are very often delivered late. Why? There are several possible
reasons:
• Unrealistic deadline
• Changing customer requirements (without rescheduling)
• Underestimate of amount of effort required
• Unforeseen risks
• Unforeseen technical difficulties
• Unforeseen human difficulties
• Poor communication between project staff
• Failure by project management to monitor and correct for delays
’How do software projects fall behind? One day at a time”
Fred Brooks, author of The Mythical Man-Month
Note: aggressive (i.e. unrealistic) deadlines are a fact of life in the software business.
The project manager must:
• Define all the project tasks,
• Identify the ones that are critical (i.e. on the critical path
9
),
• Allocate effort and responsibility
• Track progress
The project schedule will evolve: it will start as a macroscopic schedule and become
progressively more detailed as the project proceeds.
Basic principles of software project scheduling
Compartmentalization: Decompose the product and the process into a set of
manageable activities/tasks.
Interdependency: Determine the interdependency between each component task (this
then determines how tasks are ordered and what tasks can be undertaken in parallel).
Time Allocation: Allocate an estimate of effort to each task. Allocate a start date and an
end date.
Effort Validation: make sure the amount of allocated effort does not exceed the
available effort (globally and at any point in time).
Defined Responsibilities: Assign each task to a specific member of the team.
Defined Outcomes: Define the outcome (output) for each task – code, documentation,
presentation, reports, etc. These are often referred to as deliverables.
Defined Milestones: Set milestones (checkpoints when a group of tasks is complete and
the collective outcomes have been reviewed for quality).
8
9
Critical Path: the chain of tasks that must be completed on schedule if the project as a whole is to be
completed on schedule. Consequently, the critical path determines the duration of the project.

34
The Relationship between People and Effort
There is a common myth: “if we fall behind schedule, we can always add more staff and catch up
later in the project”. Unfortunately, adding people late in the project often causes the schedule to
slip further (new people have to learn, current people have to instruct them, and while they are
doing so no work gets done. In addition, the communication overhead and complexity increases.)
Fred Brooks, author of the Mythical Man-Month (1975) put it thus:
“Adding man-power to a late software project makes it later”.
In essence, the relationship between the number of people working on a project and the
productivity is not linear.
Recall the software equation:
43
3
tP
LOCB
E
×
=
Consider a small telecommunications project requiring an estimated 10000 lines of code. In this
case, P = 10000 (telecommunications and systems software) and B = 0.16.
If the time available for the project is 6 months, then the estimated effort is approximately equal to
2.5 person-years or a team of at least 5 people.
On the other hand, if the time available for the project is extended to 9 months, then the estimated
effort is approximately equal to 0.5 person-years, i.e. a one-person team. Even if this estimate is
debatable, it does show the highly non-linear relationship between the time available, the number
of people to be deployed, and the effort required.
Distribution of Effort
Once we have an estimate of the total effort required for a project, we then need to distribute it
across each component task.
A common rule-of-thumb (i.e. guideline) is to distribute the effort 40%-20%-40%:
40% for specification, analysis, and design
20% for implementation
40% for testing.
Note that it is often recommended that the specification, analysis, and design phase account for
more than 40%.
Defining a Task Set for the Software Project
A task set is a collection of software engineering work tasks, milestones, and deliverables
(outcomes) that must be accomplished to complete a project. Task sets are designed to
accommodate different type of project:
1. Concept development projects (explore new business application or technology)
2. New application development projects (usually the result of a client request)
3. Application enhancement projects (major modification of existing systems, typically
providing extended functionality)
4. Application maintenance projects (correct, adapt, extend existing software in a way that is
not immediately obvious to the user).
5. Reengineering projects (rebuilding a legacy system)

35
You also need to decide on the degree of rigor with which the software development process will
be applied. There are four different levels of rigor:
1. Casual (all process framework activities but umbrella tasks and documentation
minimized).
2. Structured (all process framework activities, with significant software quality assurance)
3. Strict (all process framework activities; all umbrella activities, robust documentation)
4. Quick Reaction (apply the process framework but only focus on those task absolutely
necessary to attain a good quality outcome).
Adaptation criteria are used to determine the recommended degree of rigor to apply. There are
11 adaptation criteria:
1. Size of the project
2. Number of potential users
3. Mission criticality
4. Application longevity
5. Stability of requirements
6. Ease of customer-developer communication
7. Maturity of application technology
8. Performance constraints
9. Embedded/non-embedded characteristics
10. Project staffing
11. Re-engineering factors
Each criterion is assigned a grade (1-5): 1 is a project in which a small set of process tasks need
to be applied and the overall methodological and documentation requirements are minimal. 5 is a
project all process tasks have to be applied in full with strong requirements for methodology and
documentation.
To select the appropriate task set for a project, complete the following table
Adaptation Criteria Entry Point MultiplierGrade Weight
Concept New Dev Enhanc. Maint. Reeng. X
Size of the project 1.2 0 1 1 1 1
Number of potential users 1.1 0 1 1 1 1
Mission criticality 1.1 0 1 1 1 1
Application longevity 0.9 0 1 1 0 0
Stability of requirements 1.2 0 1 1 1 1
Ease of customer-developer
communication
0.9 1 1 1 1 1
Maturity of application technology 0.9 1 1 0 0 1
Performance constraints 0.8 0 1 1 0 1
Embedded/non-embedded
characteristics
1.2 1 1 1 0 1
Project staffing 1.0 1 1 1 1 1
Reengineering factors 1.2 0 0 0 0 1
Average Score (TSS – Task Set Selector)
TSS Value Degree of Rigor
TSS < 1.2 Casual
1.0 < TSS < 3.0 Structured
TSS > 2.4 Strict
Note the overlap in value ranges: this is not an exact science! Use your judgment.

36
Selecting Software Engineering Tasks
In order to develop a project schedule, a task set must be distributed on the project time line.
The task set will vary according to the type of project and the degree of rigor. Depending on the
project time, you will choose an appropriate process model (e.g. waterfall, evolutionary, spiral).
This process is forms the basis for a macroscopic schedule for a project.
Once this is complete, you must then proceed to refine each of the major tasks, breaking them
into smaller composite tasks (remember: each sub-task also needs to have input and outcomes
specified). This process of task decomposition is exactly the same one as we use when
performing a function decomposition of the product during the specification phase of the software
life-cycle, i.e. you should aim to identify clear, distinct, modular, independent tasks with well-
defined inputs (typically the result of other tasks) and well-defined outputs (typically feeding into
other tasks).
Note well that this process of task identification and decomposition will be greatly aided if you
have a developed a rigorous and complete system specification (including all the supporting data,
functional, and process models: entity relationship diagrams, functional decomposition diagrams
[equivalently, the software architecture], data-flow diagrams, state-transition diagrams, etc.). If
these haven’t yet been created, then the schedule must be revisited and revised when they have.
Creating a Task Network
Once this is complete, the next step is to create a task network. This is a graphic representation
of the task flow for a project and it makes explicit the dependencies, concurrency, and ordering of
component tasks. In addition, it allows the project manager to identify the critical path: the tasks
that must be completed on schedule in order to avoid any delay in the overall project schedule.
I.1
Concept
scoping
I.3a
Tech. Risk
Assessment
I.3b
Tech. Risk
Assessment
I.3c
Tech. Risk
Assessment
Three I.3 tasks are
applied in parallel to
3 different concept
functions
Three I.3 tasks are
applied in parallel to
3 different concept
functions
I.4
Proof of
Concept
I.5a
Concept
Implement.
I.5b
Concept
Implement.
I.5c
Concept
Implement.
I.2
Concept
planning
I.6
Customer
Reaction
Integrate
a, b, c

37
Create the Project Schedule
The final step is to create the project schedule (remembering always that it is a dynamic living
entity that must be monitored, amended, revised, and validated),
All of the information for the schedule now exists at this point: the identity and purpose of each
task, the relative sequencing of each task, the estimates of effort and time for each task.
Typically, you will use a standard tool to effect this schedule for you. One such approach is the
Program evaluation and review technique (PERT). A PERT chart represents each task/subtask
as a box containing its identity, duration, effort, start date, and end date (among other things). It
displays not only project timings but also the relationships among tasks (by arrows joining the
tasks). It identifies the tasks to be completed before others can begin and it identifies the critical
path, i.e. the sequence of tasks with the longest completion time. The critical path is important as
it defines the absolute minimum time needed to complete the project. Note that the critical path
can change as task start-dates and durations are changed.
Another standared tool is the timeline chart or GANTT chart. This represents tasks by horizontal
bars and lines are used to show the dependencies.
I.1.1 Identify need and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
I.1.2 Define desired output/control/input (OCI)
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnostics
Scope other WP functions
Document OCI
FTR: Review OCI with customer
Revise OCI as required;
Milestone; OCI defined
I.1.3 Define the functionality/behavior
Define keyboard functions
Define voice input functions
Decribe modes of interaction
Decribe spell/grammar check
Decribe other WP functions
FTR: Review OCI definition with customer
Revise as required
Milestone: OCI defintition complete
I.1.4 Isolate software elements
Milestone: Software elements defined
I.1.5 Research availability of existing software
Reseach text editiong components
Research voice input components
Research file management components
Research Spell/Grammar check components
Milestone: Reusable components identified
I.1.6 Define technical feasibility
Evaluate voice input
Evaluate grammar checking
Milestone: Technical feasibility assessed
I.1.7 Make quick estimate of size
I.1.8 Create a Scope Definition
Review scope document with customer
Revise document as required
Milestone: Scope document complete
week 1 week 2 week 3 week 4Work tasks week 5

38
5. Software quality assurance (SQA): quality attributes, software
reviews, statistical quality assurance, software quality standards 10
Software Quality Assurance
Software Quality Assurance (SQA) is an activity that is applied throughout the software process.
SQA encompasses:
• A quality management approach
• Effective engineering technology (methods and tools)
• Formal technical reviews
• Multi-layered testing strategy
• Control of software documentations
• Procedures for assuring compliance with software development standards
• Measurement and reporting mechanisms
Quality control is the central issue in quality assurance: the use of inspections, reviews, and tests
(used throughout the development cycle) to ensure that each work product (module, function,
document) meets its requirements. Quality control implies a feedback loop to correct and improve
the process that lead to the work product; we measure, assess, and correct through feedback.
Later in the course, we will look in detail at measures and metrics specifically developed for
distinct stages in the software process.
Quality assurance consists of the auditing and reporting functions of management. The goal of
quality assurance is to provide management with the data necessary to be informed about
product quality.
A definition of software quality:
Conformance to explicitly stated functional and performance requirements, explicitly
documented development standards, and implicit characteristics that are expected of all
professionally developed software.
Some important points:
• Software requirements are the foundation from which quality is measured – lack of
conformance to requirements is lack of quality.
• Specified standards define a set of development criteria that guide the manner in which
software is engineered.
• There is always a set of implicit requirements (the non-functional attributes, such as
dependability, etc.).
Typically, there will be two main groups involved in SQA:
1. The software engineering team; quality is achieved by applying appropriate measures
and metrics, conducting formal technical reviews, and performing well-planned software
testing.
2. The SQA group. This group serves as the in-house customer representative; their goal is
to assist the engineering team by performing independent quality audits.
10

39
Software Reviews
Software reviews are used to ‘filter out’ errors at various stages of the development process.
There are many types of reviews, including informal discussions, customer presentations, and
formal technical reviews FTR (sometimes referred to as a walkthrough). It is a software quality
assurance activity that is performed by software engineers.
The objectives of the FTR are:
• To uncover errors in function, logic, or implementation for any representation of the
software;
• To verify that the software under review meets its requirements;
• To ensure that the software has been represented according to pre-defined standards
• To achieve software that is developed in a uniform manner;
• To make projects more manageable.
Every review meeting should adhere to the following guidelines:
• Between three and five people should be involved (typically, the producer of the work, the
project leader, the review leader, two or three reviewers, and a review recorder.
• Attendees should prepare in advance (but not spend more than 2 hours of work per
person)
• Duration of the review should be less than 2 hours
A FTR should focus on one (small) part of the overall project.
At the end of the review, all attendees must decide whether to
• Accept the work projects without further modification;
• Reject the work product due to severe errors (there will have to be another review once
the errors are corrected).
• Accept the work provisionally (minor errors have been encountered and no new review is
required once they are corrected).
The FTR team then signs off on this decision. In all cases, the review meeting must be fully
documented. Typically, two documents will be produced:
1. Review Issues List (issues raised; action items)
2. Review Summary (1 page: what was reviewed, who reviewed it, what were the findings
and conclusions).
Some guidelines for FTRs
• Review the product, not the producer
• Set an agenda and maintain it
• Limit debate and rebuttal
• Identify problem areas, but don’t attempt to solve every problem noted
• Take written notes
• Limit the number of participants and insist on advance preparation
• Develop a checklist for each work product that is likely to be reviewed
• Allocate resources and time schedule for FTRs
• Conduct meaningful training for all reviewers
• Review your early reviews

40
Statistical Quality Assurance
The goal of statistical quality assurance is to try to assess quality in a quantitative manner.
• Information about software defects is collected and categorized
• Each defect is traced to its underlying cause (e.g non-conformance to specification,
design error, violation of standards, poor communication with customer).
• Use the Pareto principle (80% of the defects can be traced to 20% of all possible causes):
identify the critical 20%.
• Fix the problems in the 20%
Clearly, this is a feedback process.
The following is a list of typical sources of errors and defects.
• Incomplete or erroneous specification (IES)
• Misinterpretation of customer communication (MCC)
• Intentional deviation from specification (IDS)
• Violation of programming standards (VPS)
• Error in data representation (EDR)
• Inconsistent module interface (IMI)
• Error in design logic (EDL)
• Incomplete or erroneous testing (IET)
• Inaccurate or incomplete documentation (IID)
• Error in programming language translation of design (PLT)
• Ambiguous or inconsistent human-computer interface (HCI)
• Miscellaneous (MIS)
The goal is to build a table of data detailing the number and percentage of defects that can be
traced to each of these sources and then focus on the sources giving the largest percentage of
defects:
Total Serious Moderate Minor
Number % Number % Number % Number %
IES
MCC
IDS
VPS
EDR
IMI
EDL
IET
IID
PLT
HCI
MIS

41
In addition, one can compute the error index (EI) as follows:
∑ ×= PSPIiEI i )(
Where i is the number of the current phase in the software process (requirements, specification,
… ), PS is the size of the product (e.g. in kLOC), and PIi is the phase index (a weighted metric of
the number of serious, moderate, and minor errors uncovered at phase i):
)/()/()/( iitiimiisi ETwEMwESwPI ++=
Ei is the total number of errors uncovered during phase i of the software process
Si is the number of serious errors
Mi is the number of moderate errors
Ti is the number of minor errors
Ws = 10, typically
Wm = 3, typically
Wt = 1, typically
Note that the error index weights errors that occur later in the software process more heavily.
The key message here in using the Pareto Principal and SQA is:
‘Spend your time focusing on things that really matter, but first be sure you understand what really
matters’.
The Quality System
Software development organizations should have a quality system (or quality management
system) addressing the following tasks:
• Auditing of projects to ensure that quality controls are being adhered to;
• Staff development of personnel in the SQA area
• Negotiation of resources to allow staff in the SQA area to do their job properly
• Providing input into the improvement of development activities
• Development of standards, procedures, guidelines
• Production of reports for top-level management
• Review and improvement of the quality system
Details procedures for accomplishing these tasks will be set out in a Quality Manual. Often, these
procedures will follow international standards such as ISO 9001.
The quality manual is then used to create a quality plan for each distinct project.

42
The ISO 9001 Quality Standard
The ISO 9001 is an international standard that has been adopted by more than 130 countries.
It is becoming increasingly important as a way by which clients can judge (or be assured of) the
competence of a software developer.
One of the problems with ISO 9001 is that it is not industry-specific – it can be used by any type of
industry.
For the software industry, the relevant standard are:
• ISO 9001 Quality Systems – Model for Quality Assurance in Design, Development,
Production, Installation, and Servicing.
This is a standard which describes the quality system used to support the development of
a product which involves design.
• ISO 9000-3 Guidelines for the Application of ISO 9001 to the Development, Supply, and
Maintenance of Software.
This is a specific document which interprets ISO 9001 for the software developer.
• ISO 9004-2. Quality Management and Quality System Elements – Part 2.
This document provides guidelines for the servicing of software facilities such as user
support.
The requirement of the standard are grouped under 20 headings:
1. Management responsibility
2. Quality system
3. Contract review
4. Design control
5. Document control
6. Purchasing
7. Purchase supplied product
8. Product identification and traceability
9. Process control
10. Inspection and testing
11. Inspection, measuring and test equipment
12. Inspection and test status
13. Control of non-conforming product
14. Corrective action
15. Handling, storage, packaging and delivery
16. Quality records
17. Internal quality audits
18. Training
19. Servicing
20. Statistical techniques
An excerpt from ISO 9001
4.11 Inspection, measuring and test equipment
The supplier shall control, calibrate, and maintain inspection, measuring, and test equipment,
whether owned by the supplier, on loan, or provided by the purchaser, to demonstrate the
conformance of product to the specified requirements. Equipment shall be used in a manner
which ensures that measurement uncertainty is known and is consistent with the required
measurement capability.

43
Note the generality of this statement: it could apply to the developer of any product.
Consequently, it can be hard to interpret in a specific (software) domain. It is very common for
companies to invest in the services of an external consultant to help then achieve ISO 9001
certification (and other quality-oriented models such as CMM – the Software Engineering Institute
Capability Maturity Model). See www.q-labs.com for an example of the offerings of a typical
international consulting firm.

44
6. McCall’s Quality Factors, FURPS, and Technical Metrics for Analysis,
Design, Implementation, Testing, and Maintenance11
Introduction
So far in this course, we have been concerned with metrics that are applied at the process and
project level. We now shift our focus to measures that can be used to assess the quality of the
software as it is being developed to allow the software engineer to assess, control, and improve
his development process.
We will begin by introducing two software quality checklists that explicitly highlight the factors that
influence quality and their relationships to software quality metrics.
Recall the issues associated with quality identified in the previous section:
• Software requirements are the foundation from which quality is measured – lack of
conformance to requirements is lack of quality.
• Specified standards define a set of development criteria that guide the manner in which
software is engineered; if they are not followed, low quality software will probably be
produced.
• There is always a set of implicit requirements (the non-functional attributes, such as
dependability, etc.); if these are not addressed, low quality software will probably be
produced.
McCall’s Quality Factors
McCall and his colleagues proposed a categorization of factors that affect software quality. These
software quality factors focus on three important aspects of a software product:
• Its operational characteristics (product operation)
• Its ability to undergo change (product revision)
• Its adaptability to new environments (product transition)
The software quality factors are:
• Product Operation
o Correctness
o Reliability
o Efficiency
o Integrity (security)
o Usability
• Product Revision
o Maintainability
o Flexibility
o Testability
• Product transition
o Portability
o Reusability
o Interoperatibility
It is very difficult (and often impossible) to develop direct measures of these quality factors.
McCall proposes the combination of several metrics to provide these measures.
11

45
The metrics he proposes are:
1. Auditability (ease with which conformance with standards can be checked)
2. Accuracy (precision of computations)
3. Communication commonality (use of standard interfaces and protocols)
4. Completeness (w.r.t. requirements)
5. Conciseness (compact code)
6. Consistency (uniformity of design and documentation)
7. Data commonality (use of standard data structures and types)
8. Error tolerance (cf graceful degradation)
9. Execution efficiency (run-time performance)
10. Expandability (cf reuse)
11. Generality (number of potential applications)
12. Hardware independence
13. Instrumentation (degree to which the program monitors its own operation and identifies
errors, cf autonomic computing)
14. Modularity (functional independence of program components)
15. Operability (ease of use)
16. Security
17. Self-documentation (usefulness/clarity of source code and internal documentation)
18. Simplicity (ease of understanding of source code / algorithms)
19. Software system independence (decoupling from operating system and libraries esp.
DLLs)
20. Traceability (ability to trace a design, representation, or code to initial requirements)
21. Training (ease of learning by new users)
Each metric is simply graded on a scale of 0 (low) to 10 (high).
The measure for the software quality factors is then computed as a weighted sum of each metric:
iiq mcF ×= ∑
where qF is the software quality factor, ic are weighting factors, im are the metrics that affect the
quality factor. The weighting factors are determined by local organizational considerations.

46
The metrics that are used for each software quality factor are identified from a checklist:
Software Quality Factors
Software Quality Metric
Correctness
Reliability
Efficiency
Integrity
Maintainability
Flexibility
Testability
Portablity
Reusability
Interoperability
usability
Auditability x x
Accuracy x x
Communication commonality
Completeness x
Conciseness x x x
Consistency x x x x
Data commonality x
Error tolerance x
Execution efficiency x
Expandability x
Generality x x x x
Hardware independence x x
Instrumentation x x x
Modularity x x x x x x x
Operability x x
Security x
Self-documentation x x x x x
Simplicity x x x x
Software system independence x x
Traceability x
Training x
FURPS
Hewlett-Packard developed a set of software quality factors with the acronym FURPS.
They define the following five major factors:
1. Functionality
2. Usability
3. Reliability
4. Performance
5. Supportability
Each is assessed by evaluating a set of metrics, in much the same way as McCall’s Quality
factors.

47
Technical Metrics for Analysis, Design, Implementation, Testing, and Maintenance
Metrics for the Analysis Model
These metrics examine the analysis model with the intent of predicting the size of the resultant
system. One of the most common size metrics is the Function Point (FP) metric.
The following metrics can be used to assess the quality of the requirements.
Specificity metric (lack of ambiguity)
rui nnQ /1 =
uin is the number of requirements for which all reviewers had identical interpretations
nffr nnn +=
rn is the total number of requirements
fn is the number of functional requirements
nfn is the number of non-functional requirements
Completeness of functional requirements
)/(2 siu nnnQ ×=
un is the number of unique function requirements
in is the number of inputs
sn is the number of states
Metrics for the Design Model
Structural Complexity of a module i
)()( 2
ifiS out=
)(ifout is fan-out of module i (i.e. the number of modules that are called by module i)
Data Complexity of a module i
]1)(/[)()( += ifiviD out
)(iv is the number of input and output variables that are passed to and from module i
System Complexity of a module i
)()()( iDiSiC +=
)(iv is the number of input and output variables that are passed to and from module i

48
Morphology Metrics (based on program architecture / functional decomposition graph)
• size = n + a
n is the number of nodes in the tree (number of modules)
a is the number of arcs (lines of control)
• depth = longest path from root to a leaf node
• width = maximum number of nodes at any one level
• arc-to-node ratio, r = a/n, provides a simple indication of the coupling of the
architecture
Cohesion Metrics (require knowledge of the detailed design of a module)
Recall: cohesion is the degree to which a module performs a distinct task or function
(without the need to interact with other modules in the program).
First, we need to define five concepts:
Data slice: a backward walk through a module looking for data values
that affect the module location at which the walk began.
Data tokens D(i) : the variables in a module i
Glue tokens G(i): the set of data tokens that lie on more than one data slice
Superglue tokens S(i): the data tokens that are common to every data slice in a
module
Stickiness: the stickiness of a glue token is directly proportional to the
number of data slices that it binds.
Strong Functional Cohesion: SFC(i) = S(i) / D(i)
A module with no superglue tokens (i.e. no tokens that are common to all data
slices) has zero strong functional cohesion – there are no data tokens that
contribute to all outputs.
As the ratio of superglue tokens to the total number of tokens in a module
increases towards a maximum value of 1, the functional cohesiveness of the
module also increases.
Weak Functional Cohesion: WFC(i) =G(i) / D(i)
A module with no glue tokens (i.e. no tokens that are common to more than one
data slices) has zero weak functional cohesion – there are no data tokens that
contribute to more than one output.
Cohesion metrics take on values in the range 0 to 1.
What is the cohesion of a module that produces only one output?

49
Coupling Metrics (also require knowledge of the detailed design of a module)
Recall: coupling is the degree of interconnection among modules (and the
interconnection of a module to global data).
There are (at least) four types of coupling:
1. Data coupling – exchange of data between modules via parameters
2. Control flow coupling – exchange of control flags via parameters (this allows
one module to influence the logic or flow of control of another module)
3. Global coupling – sharing of global data structures
4. Environmental coupling – the number of modules to which a given module is
connected.
Let:
di = number of input data parameters
ci = number of input control parameters
do = number of output data parameters
co = number of output control parameters
gd = number of global variables used as data
gc = number of global variables used as control
w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)
Define a module coupling indicator mc
mc = k / M
M = di + do + a ci + b co + gd + c gc + w + r
where k = 1, a = b = c = 2
These constants may be adjusted to suit local organizational conditions.
The higher the value of mc, the lower the overall coupling.
For example, if a module has a single input data parameter and a single output data
parameter, and if it access no global data, and is called by a single module, then
mc = 1 / (1 + 1 + 0 + 0 + 0 + 0 + 0 + 1) = 0.33
This is the highest value of a module coupling indicator (why?)
In order to have the coupling metric move upward as the degree of coupling
increases, we can define a revised coupling metric C as:
C = 1 - mc
In this case, the degree of coupling increases non-linearly between a minimum value
of 0.66 to a maximum value that approaches 1.0.

50
Complexity Metrics (also require knowledge of the detailed design of a module)
The most widely used complexity metric is the cyclomatic complexity, sometimes
referred to as the McCabe metric (after its developer, Thomas McCabe).
Cyclomatic complexity defines the number of independent paths in the basis set of a
program.
An independent path is any path through the program that introduces at least one
new set of processing statements or a new condition.
A basis set is a set of independent paths which span (i.e. include) every statement in
the program.
If we represent a program as a flow graph (i.e. a graph with statements represented
as nodes and flow of control represented as edges; areas bounded by edges and
nodes are called regions, with the area outside the graph counting as one region)
then an independent path must move along at least one edge that has not been
traversed in any of the other independent paths.
We can define cyclomatic complexity in two (equivalent) ways:
• The cyclomatic complexity V(G) of a flow graph G is defined as:
V(G) = E – N + 2
Where E is the number of flow graph edges and N is the number of flow
graph nodes.
• The cyclomatic complexity V(G) of a flow graph G is defined as:
V(G) = p + 1
Where P is the number of predicate nodes contained in the flow graph G.
A predicate node is a node that contains a condition and is characterized by
two or more edges emanating from it.
Sequence If-Else While do Case

51
For example, the cyclomatic complexity of the above program is 4:
4 = 12 – 10 + 2
4 = 3 + 1
3
4
// Sample Code
1 While records remain
2 read record
3 if record field 1 == 0
4 process record
store in buffer
increment counter
else
5 if record field 2 == 0
6 reset counter
else
7 process record
store in file
8 endif
9 endif
10 End while
5
7
1
6
8
9
100
2

52
Interface Design Metrics
Graphic user interfaces, GUIs, require the placement of widgets (buttons, dialogue
boxes, scroll bars, etc) on a screen. The layout appropriateness metric, LA, is one
way of assessing the effectiveness of the interface (or, more specifically, the spatial
organization of the GUI; effectiveness is best measured by user feedback).
Define the cost C of performing a series of actions with a given layout as the sum of
the frequency of transition between a pair of widgets times the cost of that transition
(e.g. the distance a cursor must travel to accomplish the transition). The summation
is effected for all transitions required for a particular task.
C = Σ (f(k) / m(k))
where
f(k) is the frequency of a transition k
m(k) is the cost of a transition k
The summation is made for all k, i.e. all transitions.
The LA metric is then defined as follows:
LA = 100 x Co / Ci
where
Co is the cost of the optimal layout
Ci is the cost of the current layout
To compute the optimal layout for a GUI, the screen is divided into a grid, with each
square representing a possible position for a widget. If there are N positions in the
grid and K widgets, then the number of possible layouts is [ N! / K! x (N-K)! ] x K!
This is the number of possible combinations of K widgets in N spaces times the
number of permutations of widgets.
If N is large, you will need to use a non-exhaustive approach to finding the optimal
layout (e.g. tree search or dynamic programming).
LA is used to assess different proposed GUI layouts and the sensitivity of a particular
layout to changes in task descriptions (i.e. changes in the sequence or frequency of
transitions).

53
Metrics for Source Code
Halstead’s theory of software science defines a number of metrics for source code.
Define the following measures.
n1 be the number of distinct operators that appear in a given program (including the language
constructs such as for, while, do, case, … ).
n2 be the number of distinct operands that appear in a given program
N1 be the total number of occurrences of operators in a given program
N2 be the total number of occurrences of operands in a given program
Program length metric
N = n1 log2 n1 + n2 log2 n2
Program volume metric
V = N log2 ( n1 + n2 )
Halstead defines a volume ratio L as the ratio of volume of the most compact form of a given
program to the volume of the actual program:
L = 2 / n1 x n2 / N2
Metrics for Testing
Much has been written about software metrics for testing. However, most of this material focuses
on the testing process, rather than characteristics (quality) of the tests themselves.
In general, testers must rely on analysis, design, and code metrics to guide them in the design
and execution of test cases.
FP metrics can be used as a predictor of overall testing effort, especially when combined with
past experience in required testing.
The cyclomatic complexity metric defines the effort required for basis path (white box) testing; it
also helps identify the functions or modules that should be targeted for particularly rigorous
testing.
Metrics for Maintenance
IEEE Standard 982.1-1988 suggests a software maturity index (SMI) that provides an indication
of the stability of a software product based on changes that occur for each release of the product.
SMI = [ MT - (Fa + Fc + Fd )] / MT
where
MT = the number of modules in the current release
Fa = the number of modules in the current release that have been changed
Fa = the number of modules in the current release that have been added
Fa = the number of modules from the preceding release that were deleted in the current release.

54
7. OO classes, inheritance, and polymorphism 12
Object-oriented technologies (sometimes referred to as just object technologies) involve more that
just object-oriented programming (using OO languages such as C++, Eiffel, Smalltalk). Object
technologies also include the analysis, design, and testing phases of the development life-cycle.
It is extremely difficult to define all the necessary classes for a major system or product in a single
iteration. Consequently, OO systems tend to evolve over time so an evolutionary process model,
such as the spiral model, is probably the best paradigm for OO software engineering.
What is an object-oriented approach? There are many definitions of OO.
One definition is that it is the exploitation of class objects, with private data members and
associated access functions (cf. concept of an abstract data type). This is a good start and
introduces some key concepts:
Class A class is a ‘template’ for the specification of a particular collection of
entities (e.g. a widget in a Graphic User Interface).
More formally, ‘a class is an OO concept that encapsulates the data and
procedural abstractions that are required to describe the content and
behaviour of some real-world entity’.
Attributes Each class will have specific attributes associated with it (e.g. the
position and size of the widget).
These attributes are queried using associated access functions (e.g.
set_position)
Object An object is a specific instance (or instantiation) of a class (e.g. a
button or an input dialogue box).
12
Customer
Communication
Planning
Construction & Release
Customer
Evaluation
Engineering,
Risk Analysis look-up
classes
in library
extract
classes
if available
engineer
classes
if unavailable
construct
nth iteration
of system
put new
classes
in library
OO analysis
OO design
OO programming
OO testing
identify
candidate
classes

55
Data Members The object will have data members representing the class attributes
(e.g. int x, y;)
Access function The values of these data members are accessed using the access
functions (e.g. set_position(x, y);)
These access functions are called methods (or services).
Since the methods tend to manipulate a limited number of attributes (i.e.
data members) a given class tends to be cohesive.
Since communication occurs only through methods, a given class tends
to be decoupled from other objects.
Encapsulation The object (and class) encapsulates the data members (attributes),
methods (access functions) in one logical entity.
Data Hiding Furthermore, it allows the implementation of the data members to be
hidden (why? Because the only way of getting access to them – of seeing
them – is through the methods.) This is called data hiding.
Abstraction This separation, though data hiding, of physical implementation from
logical access is called abstraction.
Messages Objects communicate with each other by sending messages (this just
means that a method from one class calls a method from another method
and information is passed as arguments).
So far, so good. All this sounds very familiar and no different to what was covered in abstract
data-types in the course on Algorithms and Data-Structures. However, there is a stronger
meaning associated with OO. Ellis and Stroustrup, for example, define OO as follows:
‘The use of derived classes and virtual functions is often called object-oriented
programming’
The implication of this statement is that OO also includes two further concepts of inheritance and
polymorphism.
A complete treatment of these concepts would require specific reference to an OO programming
language and its constructs. However, a simple definition is still required.
Inheritance We can define a new class as a sub-class of an existing class (e.g.
button is a sub-class of the widget class; a toggle button is a sub-class of
the button class).
Each sub-class inherits (has by default) the data members and methods
of the parent class (the parent class is sometimes called a super-class).
For example, both the button and toggle button classes (and objects)
have set_position() methods and (private) position data members x and
y.
A sub-class is sometimes called a derived class.
The C++ programming language allows multiple inheritance, i.e. a sub-
class can be derived from two or more super-classes and therefore
inherit the attributes and methods from both. Multiple inheritance is a
somewhat controversial capability as it can cause significant problems for
managing the class hierarchy.

56
Polymorphism If the super-class is designed appropriately, it is possible to re-define the
meaning of some of the super-class methods to suit the particular needs
of the derived class. For example, the widget super-class might have a
draw() method. Clearly, we need a different type of drawing for buttons
and for input boxes.
However, we would like to use the one generic method draw() for both
types of derived classes (i.e. for buttons and for input boxes).
OO programming languages allow us to do this. This is called
polymorphism (literally: multiple structure) – the ability to define and
choose the required method depending on the type of the derived class
(or object) without changing the name of the method. Thus, the draw()
method has many structures, one for each derived class.
Two views of a class / object
A Class Hierarchy
class name
attributes:
operations:
attributes:
operations
chairtable desk
"chable"
instances of chair
furniture (superclass)
subclasses of the
furniture superclass

57
Message Passing Between Objects
sender object
attributes:
operations:
receiver object
attributes:
operations:
message: [receiver, operation, parameters]
message:
[sender, return value(s)]

58
8. Object-oriented analysis, design, and testing: OOD concepts,
analysis and design issues 13
Object-Oriented Analysis (OOA)
In order to build an analysis model, five basic principles are applied:
1. The information domain is modeled
2. Module function is described
3. Model behaviour is represented
4. Models are partitioned (decomposed)
5. Early models represent the essence of the problem; later models provide implementation
details.
The goal of OOA is to define all classes (their relationships and behaviour) that are relevant to the
problem to be solved. We do this by:
• Eliciting user requirements
• Identifying classes (defining attributes and methods)
• Specifying class hierarchies
• Identifying object-to-object relationships
• Modelling object behaviour
These steps are reapplied iteratively until the model is complete.
There are many OOA methods. For exampe:
The Booch Method
• Identify Classes and objects
• Identify the semantics of classes and objects
• Identify relationships among classes and objects
• Conduct a series of refinements
• Implement classes and objects
The Coad and Yourdon Method
• Identify objects
• Define a generalization-specification structure (gen-spec)
• Define a whole-part structure
• Identify subjects (subsystem components)
• Define attributes
• Define services
The Jacobson Method (OOSE)
• Relies heavily of use case modeling (how the user (person or devide) interacts with the
product or system
The Rambaugh Method (Object Modelling Technique OMT)
• Scope the problem
• Build an object model
• Develop a dynamic model
• Construct a functional model
13
Please refer also the Chapters 19-21 of ‘Software Engineering – A Practitioner’s Approach’, R. S.
Pressman.

59
There are seven generic steps in OOA:
1. Obtain customer requirements
(identify scenarios or use cases; build a requirements model)
2. Select classes and objects using basic requirements
3. Identify attributes and operations for each object
4. Define structures and hierarchies that organize classes
5. Build an object-relationship model
6. Build an object-behaviour model
7. Review the OO analysis model against use cases / scenarios
We will look at each of these in turn.
Requirements Gathering and Use Cases
Use cases are a set of scenarios each of which identifies a thread of usage of the system to be
constructed. They can be constructed by first identifying the actors: the people or devices that
use the system (anything that communicates with the system). Note that an actor is not
equivalent to a user: an actor reflects a particular role (a user may have many different roles, e.g.
in configuration, normal, test, maintenance modes).
Once the actors have been identified, on can then develop the use case, typically by answer the
following questions:
• What are the main tasks or functions that are performed by the actor?
• What system information will the actor require, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
Class-Responsibility-Collaborator (CRC) Modelling
CRC modeling provides a simple means for identifying and organizing the classes that are
relevant to a system.
Responsibilities are the attributes and operations that are relevant for the class (‘a responsibility is
anything a class knows or does’).
Collaborators are those classes required to provide a class with the information needed to
complete a responsibility (a collaboration implies either a request for information or a request for
some action).
Guidelines for Identifying Classes
We said earlier that ‘a class is an OO concept that encapsulates the data and procedural
abstractions that are required to describe the content and behaviour of some real-world entity’.
We can classify different types of entity and this will help identify the associated classes:
Device classes: these model external entities such as sensors, motors, and key-boards.
Property classes: these represent some important property of the problem environment (e.g.
credit rating)
Interaction classes: these model interactions what occur among other objects (e.g. purchase of
a commodity).

60
In addition, objects/classes can be categorized by a set of characteristics:
Tangibility does the class respresent a real device/physical object or does it represent
abstract information?
Inclusiveness is the class atomic (it does not include other classes) or is it an aggregate (it
includes at least one nested object)?
Sequentiality is the class concurrent (i.e. it has its own thread of control) or sequential (it is
controlled by outside resources)?
Persistence is the class transient (i.e. is it created and removed during program operation);
temporary (it is created during program operation and removed once the program
terminates) or permanent (it is stored in, e.g., a database)?
Integrity is the class corruptible (i.e. it does not protect its resources from outside
influence) or it is guarded (i.e. the class enforces controls on access to its
resources)?
For each class, we complete a CRC ‘index card’ noting these class types and characteristics, and
listing all the collaborators and attributes for the class.
Guidelines for assigning responsibilities to classes
• System intelligence should be evenly distributed.
• Each responsibility should be stated as generally as possible.
• Information and the behavior that is related to it should reside within the same class.
• Information about one thing should be localized with a single class, not distributed across
multiple classes.
• Responsibilities should be shared among related classes, when appropriate.
class name:
class type: (e.g., device, property, role, event, ...)
class characterisitics: (e.g., tangible, atomic, concurrent, ...)
responsibilities: collaborators:

61
Reviewing the CRC Model
• All participants in the review (of the CRC model) are given a subset of the CRC model
index cards.
• All use-case scenarios (and corresponding use-case diagrams) should be organized into
categories.
• The review leader reads the use-case deliberately. As the review leader comes to a
named object, she passes the token to the person holding the corresponding class index
card.
• When the token is passed, the holder of the class card is asked to describe the
responsibilities noted on the card. The group determines whether one (or more) of the
responsibilities satisfies the use-case requirement.
• If the responsibilities and collaborations noted on the index cards cannot accommodate
the use-case, modifications are made to the cards.

62
Defining Structures and Hierarchies
The next step is to organize the classes identified in the CRC phase into hierarchies.
There are two types of hierarchy:
1. Generalization-Specialization (Gen-Spec) structure
2. Composite-Aggregate (Whole-Part) structure
The Gen-Spec structure can be represented by the following type of diagram:
The relationship between classes in a Gen-Spec hierarchy can be viewed as a ‘Is A’ relation. For
example, an entry sensor ‘Is A’ sensor. This indicates a relationship by inheritance (entry sensor
is a sub-class of sensor and inherits the base class methods and members).
The Composite-Aggregate structure can be represented by the following type of diagram
The relationship between classes in a Composite-Aggregate hierarchy can be viewed as a
‘Has A’ relation. For example, a control panel ‘Has A’ key-pad. This indicates a relationship by
nesting (key-pad is a component class of control panel).
Note that there are alternative styles of diagrams for both types of diagram.

63
Defining Subjects and Subsystems
Once the class hierarchies have been identified, we then try to group them into subsystems or
subjects. A subject / subsystem is a subset of classes that collaborate among themselves to
accomplish a set of cohesive responsibilities.
A subsystem / subject implements one or more contracts with its outside collaborators. A contract
is a specific list of requests that collaborators can make of the subsystems.

64
The Object-Relationship Model
The next step is to define those collaborator classes that help in achieving each responsibility.
This establishes a connection between classes. A relationship exists between any two classes
that are connected.
There are many different (but equivalent) graphical notations for representing the object-
relationship model. All are the same as the entity-relationship diagrams that are used in modeling
database systems and they depict the existence of a relationship (line) and the cardinality of the
relationship (1:1, 1:n, n:n, etc).
In the following notation, the direction of the relation is also shown and the cardinality is show at
both ends of the relationship line. A cardinality of zero implies a partial participation.
The object-relationship model makes explicit the message paths between classes.

65
The Object-Behaviour Model
The object-behaviour model indicates how an OO system will respond to external events or
stimuli.
To create the model, you should perform the following steps:
1. Evaluate all use-cases to fully understand the sequence of interaction within the system.
2. Identify events that drive the interaction sequence and understand how these events relate to
specific objects.
3. Create an event trace for each use-case.
4. Build a state transition diagram for the system.
5. Review the object-behavior model to verify accuracy and consistency.
In general, an event occurs whenever an OO system and an actor exchange information. Note
that an event is Boolean: an event is not the information that has been exchanged; it is the fact
that information has been exchanged.
An actor should be identified for each event; the information that is exchanged should be noted
and any conditions or constraints should be indicated.
Some events have an explicit impact on the flow of control of the use case, other have no direct
impact on the flow of control.
For OO systems, two different characterizations of state must be considered.
• The state of each object as the system performs its function.
• The state of the system as observed from outside as the system performs its function.
The state of an object can be both passive and active:
• The passive state is the current status of all an object’s attributes.
• The active state is the current status of the object as it undergoes a continuing
transformation or process.
An event (i.e. a trigger) must occur to force an object to make a transition from one active state to
another.

66
One component of an object-behaviour model is a simple representation of the active states for
each object and the events (triggers) that cause changes between active states.
A partial active state transition diagram for the object control panel
The second type of behavioural representation for OOA considers a state representation for the
overall product or system. This representation is an event trace model that indicates how events
cause transitions from object to object and a state-transition diagram that depicts the processing
behaviour of each object. An event trace is actually a shorthand version of the use case.
A partial event trace

67
Once a complete event trace has been developed, all of the events that cause transitions
between system objects can be collated into a set of input events and output events (from an
object). This can be represented using an event flow diagram.
A partial event flow diagram
Homeowne
r
Control
Panel
System
Selects stay/away
Enters password
Ready for next action
Ready for activation/deactivation
Beep sounded
Sensors activated/eactivated
Red light on
System
ready
Initiates beep
Activate/deactivate sensors
Red light on request

68
Object-Oriented design (OOD)
‘Designing object-oriented software is hard, and designing reusable object-oriented software is
even harder … a reusable and flexible design is difficult if not impossible to get “right” the first
time’. OOD is a part of an iterative cycle of analysis and design, several iterations of which may
be required before one proceeds to the OOP stage.
There are many OOD approaches, almost all of which are the direct adjuncts of OOA approaches
(e.g. the Booch method, the Coad and Yourdon Method, the Jacobson method, the Rambaugh
method). The following gives just an overview of the issues that are common to all approaches.
OOD is a critical process in the transition from OOA model to OO implementation (OO
programming) because it requires you to set out the details of all aspects of the OOA model that
will be needed when you come to write the code. At the same time, it allows you to validate the
OOA model.
Thus, the main goal in OOD is to make the OOA models less abstract by filling in all the details,
but without going as far as writing the OO code. This will require you to state exactly:
• how the attributes (data members) will be represented;
• the algorithms and calling sequences required to effect the methods;
• the protocols for effecting the messaging between the objects;
• the control mechanism by which the system behaviour will be achieved (i.e. task
management and HCI management).
In essence, developing the design based on the analysis model, we are focusing on the
algorithmic, representation, and interface issues; on how the system will be implemented, rather
than on what will be implemented. When we write the OO code, we then realize that design
using a specific language.
There are several level to an OO design. These are often represented in a pyramidal manner
(just as in the case of the design of imperative programs).
classesclasses
attributesattributes
m ethodsm ethods
relationshipsrelationships
behaviorbehavior
Analysis M odelAnalysis M odel
objectsobjects
data structuresdata structures
algorithm salgorithm s
m essagingm essaging
controlcontrol
Design M odelDesign M odel
responsibilities
design
message
design
class and object
design
subsystem
design

69
And we can visualize the mapping of the OOA models to the OOD, as follows:
The software engineering will follow some standard steps in the design process:
• Partition the analysis model into sub-systems
• Identify concurrency that is dictated by the problem
• Allocate subsystems to processors and tasks
• Choose a basic strategy for implementing data management
• Identify global resources and the control mechanism required to access them.
• Design an appropriate control mechanism for the system
• Consider how boundary conditions should be handled.
• Review and consider trade-offs.
Typically, there will be (at least) four different types of subsystem:
1. Problem domain subsystems: subsystems responsible for implementing customer/client
requirements directly.
2. Human interaction subsystems: the subsystems that implement the user-interface
(incorporating reusable GUI class libraries).
3. Task management subsystems: the subsystems that are responsible for controlling and
coordinating concurrent tasks.
4. Data management subsystems: the subsystem(s) that is responsible for the storage and
retrieval of objects.
Note that, when two subsystems communicate with one another, they can establish a
client/server link or a peer-to-peer link.
In a client/server link, each of the subsystems takes on one of the roles implied by the client and
server. Service flows from server to client in only one direction. In a peer-to-peer link, services
may flow in either direction.
Object-
relationship
model
Object-Behavior
Model
CRC
Index Cards
Attributes, operations,
collaborators
THE ANALYSIS MODEL
responsibilities
design
message
design
Class and object
design
subsystem
design
THE DESIGN MODEL
Use cases

70
When designing a subsystem, the following guidelines may be useful:
• The subsystem should have a well-defined interface through which all communication
with the rest of the system occurs.
• With the exception of a small number of “communication classes,” the classes within a
subsystem should collaborate only with other classes within the subsystem.
• The number of subsystems should be kept small.
• A subsystem can be partitioned internally to help reduce complexity.
In addition to designing the organization of (sets of) classes and objects, we also have to design
individual objects and classes. Typically, the design will incorporate two distinct aspects: a
protocol description and an implementation description.
A protocol description establishes the interface of an object by defining each message that the
object can receive and the related operation that the object performs.
An implementation description shows implementation details for each operation implied by a
message that is passed to an object. This will include:
1. information about the object's private part
2. internal details about the data structures that describe the object’s attributes
3. procedural details that describe operations
requestclient
subsystem
contract
contract contract
request
request
server
subsystem
peer
subsystem
peer
subsystem

71
9. OO testing strategies, metrics 14
Object-Oriented Testing (OOT)
Recall that the goal of testing is to find the greatest number of errors (i.e. the focus should be to
try to break the system, not just demonstrate that it produces the right answer in certain
circumstances).
However, we need to broaden our view of testing in OO to include not only conventional testing of
code/programs but the review of OO analysis and design models. Why? Because the same
semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis,
design, and code level. Therefore, a problem in the definition of class attributes that is uncovered
during analysis will circumvent side effects that might occur if the problem were not discovered
until design or code (or even the next iteration of analysis).
Thus, in OOT
• we begin by evaluating the correctness and consistency of the OOA and OOD models;
• we recognize that the testing strategy changes
o the concept of the ‘unit’ broadens due to encapsulation
o integration focuses on classes and their execution across a ‘thread’ or in the
context of a usage scenario
o validation uses conventional black box methods
• test case design draws on conventional methods (black-box testing and white-box
testing) but also encompasses special features
Testing the CRC Model
1. Revisit the CRC model and the object-relationship model.
2. Inspect the description of each CRC index card to determine if a delegated
responsibility is part of the collaborator’s definition.
3. Invert the connection to ensure that each collaborator that is asked for service is
receiving requests from a reasonable source.
4. Using the inverted connections examined in step 3, determine whether other
classes might be required or whether responsibilities are properly grouped among
the classes.
5. Determine whether widely requested responsibilities might be combined into a
single responsibility.
Steps 1 to 5 are applied iteratively to each class and through each evolution of the OOA model.
14
Please refer also the Chapters 19, 22-23 of ‘Software Engineering – A Practitioner’s Approach’, R. S.
Pressman.

72
OOT Strategy
OO brings particular complexities to the testing process. In particular, encapsulation and
inheritance make testing more complicated.
In the case of encapsulation, the data members are effectively hidden and the test strategy needs
to exercise both the access methods and the hidden data-structures.
In the case of inheritance (and polymorphism), the invocation of a given method depends on the
context (i.e. the derived class for which that method is called). Consequently, you need to have a
new set of tests for every new context (i.e. every new derived class). Multiple inheritance makes
the situation even more complicated.
In conventional testing, we begin by unit testing and then proceed, incrementally, to test larger
and larger sub-systems (i.e. integration testing). This approach has to be adapted for OO:
• class testing is the equivalent of unit testing:
1. operations within the class are tested
2. the state behavior of the class is examined (very often, the state of an object is
persistent).
• integration testing requires three different strategies:
1. thread-based testing—integrates the set of classes required to respond to one
input or event (incremental integration may not be possible).
2. use-based testing—integrates the set of classes required to respond to one use
case
3. cluster testing—integrates the set of classes required to demonstrate one
collaboration
OO Test Case Design
• Each test case should be uniquely identified and should be explicitly associated with the
class to be tested,
• The purpose of the test should be stated,
• A list of testing steps should be developed for each test and should contain:
1. a list of specified states for the object that is to be tested
2. a list of messages and operations that will be exercised as a consequence of the
test
3. a list of exceptions that may occur as the object is tested
4. a list of external conditions (i.e., changes in the environment external to the
software that must exist in order to properly conduct the test)
5. supplementary information that will aid in understanding or implementing the test.

73
OO Test Methods
Random testing
• Identify operations applicable to a class
• Define constraints on their use
• Identify a series of random but valid test sequences (a valid operation sequence for that
class/object, i.e. a sequence of messages or method invocations for that class)
Partition Testing
• Partition testing reduces the number of test cases required to test a class in much the
same way as equivalence partitioning for conventional software (i.e. input and output are
categorized, and test cases are designed to exercise each category)
• State-based partitioning
o categorize and test operations based on their ability to change the state of a class
• Attribute-based partitioning
o categorize and test operations based on the attributes that they use
• Category-based partitioning
o categorize and test operations based on the generic function each performs
Inter-Class Testing
• For each client class, use the list of class operators to generate a series of random test
sequences. The operators will send messages to other server classes.
• For each message that is generated, determine the collaborator class and the
corresponding operator in the server object.
• For each operator in the server object (that has been invoked by messages sent from the
client object), determine the messages that it transmits.
• For each of the messages, determine the next level of operators that are invoked and
incorporate these into the test sequence

74
Project Metrics
Since the achievement of re-use is such an important part of the OO strategy, LOC estimates of
project size make little sense.
FP estimates can be used effectively because the required information domain counts are readily
available.
There are a number of other OO-specific metrics. These include the following.
Number of scenario scripts. A scenario script is a detailed sequence of steps that
describe the interaction between the user and the application. Each script is organized
into triplets of the form {initiator, action, participant}
Initiator is the object that requests some service
Action is the result of the request
Participant is the server object that satisfies the request
Number of key classes. Key classes are highly-independent components (objects).
Number of support classes. Support classes are required to implement the system, but
are not immediately related to the problem domain (e.g. GUI classes, database access
classes, communication classes).
Average number of support classes per key class.
Number of subsystems. A subsystem is an aggregation of classes that support a
function that is visible to the end user of a system.
Project Estimation
Although normal estimation techniques do apply for OO approaches, the historical database of
OO projects is relatively small and so the empirical formulae may not be as accurate as you might
wish them to be. Consequently, it may be useful to estimate project effort and cost using an OO-
specific technique in addition to the normal approach (the more estimates you have, the better).
One OO-specific approach estimates effort as follows:
E = w * (k + s)
E is the estimated project effort.
W is the average number of person-days per class (typically, 15-20 person-days).
k is the number of key classes (estimated from the analysis phase)
s is the number of support classes (estimated as m * k, where m is a multiplier identified from the
following table:
Interface Type m
No GUI 2.0
Text-based user interface 2.25
GUI 2.5
Complex GUI 3.0

75
Technical Metrics
Technical metrics are needed that highlight the special features of OO:
• Localization (data cohesion)
• Encapsulation
• Information Hiding
• Inheritance
• Abstraction
Design Metrics
The CK (Chidamber and Kemerer) Metric Suite
Weighted Methods per Class (WMC)
WMC = Σ ci
where
ci is the normalized complexity measure for method i (using, e.g. cyclomatic
complexity measure)
Note that it is not straightforward to decide on the number of methods in a class (consider
those defined in the derived class vs those defined in base class)
A low value of WMC implies a good design (cf. reusability, testability).
Depth of the Inheritance Tree (DIT)
DIT is the maximum length from the base class(root) to the derived classes (leaf nodes)
A large DIT indicates leads to greater design complexity (but significant reuse).
Number of Children (NOC)
NOC is the number of derived classes for a given class.
A lager value for NOC implies increased reuse, but also increased effort to test and
possible diluted abstraction in the parent class.
Coupling between Object Classes (CBO)
CBO is the number of collaborators for a class.
‘As CBO increases, it is likely that the reusability of a class will decrease’.
Response Set for a Class (RFC)
RFC is the set of methods that can potentially be executed in response to a message
received by an object of that class.
As RFC increases, the effort required for testing increases.

76
Lack of Cohesion in Methods (LCOM)
LCOM is the number of methods that access one or more of the same attributes.
In general, high values for LCOM imply that the class might be better designed by
breaking it into two ore more separate classes.
The Lorenz and Kidd Metrics
Class Size (CS)
The overall class size can be determined by the total number of operations (both inherited
and locally defined) that are encapsulated within the class and by the number of attributes
(inherited and locally defined).
Large values of CS may indicate that the class has too much responsibility.
Number of Operations Overridden by a subclass (NOO)
If NOO is large, the designer may have violated the abstraction implied by base class
(note that this does not apply to pure virtual functions and abstract classes in C++).
Number of Operations Added by a Subclass (NOA)
As NOA increases, the subclass drifts away from the abstraction implied by the
superclass.
In general, as the depth of the class hierarchy increases, the value for NOA at lower
levels in the hierarchy should go down.
Specialization Index (SI)
SI = (NOO x level) / Mtotal
where
level is the level in the hierarchy at which the class resides
Mtotal is the total number of methods for that class.
The higher the value of SI, the more likely that the class hierarchy has classes that do not
conform to the superclass abstraction.
Average Operation Size (OS)
Either LOC or the number of messages sent by the operation (method) can be used to
measure OS.
Operation Complexity (OC)
Any complexity measure can be used; OC should be as low as possible (to maximize
cohesion of responsibility).
Average Number of Parameters per Operation (NP)
In general, NP should be kept as low as possible.

77
Test Metrics
Encapsulation
Lack of Cohesion in Methods (LCOM)
(see above)
Percent Public and Protected (PAP)
The percentage ratio of public (and protected) attributes to private attributes; high values
indicate likelihood of side effects among classes.
Public Access to Data Members (PAD)
The number of classes (or methods) that can access another class’s attributes. High
values indicate the potential for side effects.
Inheritance
Number of Root Classes (NOR)
The number of class hierarchies. Testing effort rises with NOR.
Fan In (FIN)
For OO, fan-in is an indication of multiple inheritance (the fan in is the number of base
classes from which a sub-class is derived).
Number of Children (NOC) and Depth of Inheritance Tree (DIT)
See above.

78
10. Social, ethical, and professional issues: code of ethics, copyright, &
security
Code of Ethics
“A code of ethics functions like a technical standard, only it’s a standard of behaviour”
Joseph Herkert, former president of the IEEE Society on the Social Implications of Technology.
IEEE Code of Ethics
(Taken from: http://www.ieee.org/about/whatis/code.html)
We, the members of the IEEE, in recognition of the importance of our technologies in affecting the
quality of life throughout the world, and in accepting a personal obligation to our profession, its
members and the communities we serve, do hereby commit ourselves to the highest ethical and
professional conduct and agree:
1. to accept responsibility in making engineering decisions consistent with the safety, health
and welfare of the public, and to disclose promptly factors that might endanger the public
or the environment;
2. to avoid real or perceived conflicts of interest whenever possible, and to disclose them to
affected parties when they do exist;
3. to be honest and realistic in stating claims or estimates based on available data;
4. to reject bribery in all its forms;
5. to improve the understanding of technology, its appropriate application, and potential
consequences;
6. to maintain and improve our technical competence and to undertake technological tasks
for others only if qualified by training or experience, or after full disclosure of pertinent
limitations;
7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct
errors, and to credit properly the contributions of others;
8. to treat fairly all persons regardless of such factors as race, religion, gender, disability,
age, or national origin;
9. to avoid injuring others, their property, reputation, or employment by false or malicious
action;
10. to assist colleagues and co-workers in their professional development and to support
them in following this code of ethics.
Approved by the IEEE Board of Directors
August 1990

79
Software Engineering Code of Ethics and Professional Practice
(IEEE Computer Society and Association for Computer Machinery code of ethics for software
engineers: http://computer.org/certification/ethics.htm)
"The time is right to get serious about this. As software becomes increasingly dominant in the IT
industry, and, indeed, in everything else, there is an obvious need for a professional-level
recognition. Far too much is placed on particular credentials for specific products or applications
without regard to the bigger picture. The result is poorly engineered software projects."
(Version 5.2) as recommended by the IEEE-CS/ACM Joint Task Force on Software Engineering
Ethics and Professional Practices and Jointly approved by the ACM and the IEEE-CS as the
standard for teaching and practicing software engineering.
Short Version
PREAMBLE
The short version of the code summarizes aspirations at a high level of the abstraction; the
clauses that are included in the full version give examples and details of how these aspirations
change the way we act as software engineering professionals. Without the aspirations, the details
can become legalistic and tedious; without the details, the aspirations can become high sounding
but empty; together, the aspirations and the details form a cohesive code.
Software engineers shall commit themselves to making the analysis, specification, design,
development, testing and maintenance of software a beneficial and respected profession. In
accordance with their commitment to the health, safety and welfare of the public, software
engineers shall adhere to the following Eight Principles:
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote
an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.

80
SOFTWARE ENGINEERING CODE OF ETHICS AND PROFESSIONAL PRACTICE
IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices
Full Version
PREAMBLE
Computers have a central and growing role in commerce, industry, government, medicine,
education, entertainment and society at large. Software engineers are those who contribute by
direct participation or by teaching, to the analysis, specification, design, development,
certification, maintenance and testing of software systems. Because of their roles in developing
software systems, software engineers have significant opportunities to do good or cause harm, to
enable others to do good or cause harm, or to influence others to do good or cause harm. To
ensure, as much as possible, that their efforts will be used for good, software engineers must
commit themselves to making software engineering a beneficial and respected profession. In
accordance with that commitment, software engineers shall adhere to the following Code of
Ethics and Professional Practice.
The Code contains eight Principles related to the behavior of and decisions made by professional
software engineers, including practitioners, educators, managers, supervisors and policy makers,
as well as trainees and students of the profession. The Principles identify the ethically responsible
relationships in which individuals, groups, and organizations participate and the primary
obligations within these relationships. The Clauses of each Principle are illustrations of some of
the obligations included in these relationships. These obligations are founded in the software
engineer s humanity, in special care owed to people affected by the work
of software engineers, and the unique elements of the practice of software engineering. The Code
prescribes these as obligations of anyone claiming to be or aspiring to be a software engineer.
It is not intended that the individual parts of the Code be used in isolation to justify errors of
omission or commission. The list of Principles and Clauses is not exhaustive. The Clauses should
not be read as separating the acceptable from the unacceptable in professional conduct in all
practical situations. The Code is not a simple ethical algorithm that generates ethical decisions. In
some situations standards may be in tension with each other or with standards from other
sources. These situations require the software engineer to use ethical judgment to act in a
manner which is most consistent with the spirit of the Code of Ethics and Professional Practice,
given the circumstances.
Ethical tensions can best be addressed by thoughtful consideration of fundamental principles,
rather than blind reliance on detailed regulations. These Principles should influence software
engineers to consider broadly who is affected by their work; to examine if they and their
colleagues are treating other human beings with due respect; to consider how the public, if
reasonably well informed, would view their decisions; to analyze how the least empowered will be
affected by their decisions; and to consider whether their acts would be judged worthy of the ideal
professional working as a software engineer. In all these judgments concern for the health, safety
and welfare of the public is primary; that is, the Public Interest is central to this Code.
The dynamic and demanding context of software engineering requires a code that is adaptable
and relevant to new situations as they occur. However, even in this generality, the Code provides
support for software engineers and managers of software engineers who need to take positive
action in a specific case by documenting the ethical stance of the profession. The Code provides
an ethical foundation to which individuals within teams and the team as a whole can appeal. The
Code helps to define those actions that are ethically improper to request of a software engineer or
teams of software engineers.

81
The Code is not simply for adjudicating the nature of questionable acts; it also has an important
educational function. As this Code expresses the consensus of the profession on ethical issues, it
is a means to educate both the public and aspiring professionals about the ethical obligations of
all software engineers.
PRINCIPLES
Principle 1 PUBLIC
Software engineers shall act consistently with the public interest. In particular, software engineers
shall, as appropriate:
1.01. Accept full responsibility for their own work.
1.02. Moderate the interests of the software engineer, the employer, the client and the users with
the public good.
1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications,
passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the
environment. The ultimate effect of the work should be to the public good.
1.04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the
public, or the environment, that they reasonably believe to be associated with software or
related documents.
1.05. Cooperate in efforts to address matters of grave public concern caused by software, its
installation, maintenance, support or documentation.
1.06. Be fair and avoid deception in all statements, particularly public ones, concerning software
or related documents, methods and tools.
1.07. Consider issues of physical disabilities, allocation of resources, economic disadvantage and
other factors that can diminish access to the benefits of software.
1.08. Be encouraged to volunteer professional skills to good causes and contribute to public
education concerning the discipline.
Principle 2 CLIENT AND EMPLOYER
Software engineers shall act in a manner that is in the best interests of their client and employer,
consistent with the public interest. In particular, software engineers shall, as appropriate:
2.01. Provide service in their areas of competence, being honest and forthright about any
limitations of their experience and education.
2.02. Not knowingly use software that is obtained or retained either illegally or unethically.
2.03. Use the property of a client or employer only in ways properly authorized, and with the
client's or employer's knowledge and consent.
2.04. Ensure that any document upon which they rely has been approved, when required, by
someone authorized to approve it.

82
2.05. Keep private any confidential information gained in their professional work, where such
confidentiality is consistent with the public interest and consistent with the law.
2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in
their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property
law, or otherwise to be problematic.
2.07. Identify, document, and report significant issues of social concern, of which they are aware,
in software or related documents, to the employer or the client.
2.08. Accept no outside work detrimental to the work they perform for their primary employer.
2.09. Promote no interest adverse to their employer or client, unless a higher ethical concern is
being compromised; in that case, inform the employer or another appropriate authority of
the ethical concern.
Principle 3 PRODUCT
Software engineers shall ensure that their products and related modifications meet the highest
professional standards possible. In particular, software engineers shall, as appropriate:
3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant
tradeoffs are clear to and accepted by the employer and the client, and are available for
consideration by the user and the public.
3.02. Ensure proper and achievable goals and objectives for any project on which they work or
propose.
3.03. Identify, define and address ethical, economic, cultural, legal and environmental issues
related to work projects.
3.04. Ensure that they are qualified for any project on which they work or propose to work by an
appropriate combination of education and training, and experience.
3.05. Ensure an appropriate method is used for any project on which they work or propose to
work.
3.06. Work to follow professional standards, when available, that are most appropriate for the task
at hand, departing from these only when ethically or technically justified.
3.07. Strive to fully understand the specifications for software on which they work.
3.08. Ensure that specifications for software on which they work have been well documented,
satisfy the users requirements and have the appropriate approvals.
3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes
on any project on which they work or propose to work and provide an uncertainty
assessment of these estimates.
3.10. Ensure adequate testing, debugging, and review of software and related documents on
which they work.
3.11. Ensure adequate documentation, including significant problems discovered and solutions
adopted, for any project on which they work.

83
3.12. Work to develop software and related documents that respect the privacy of those who will
be affected by that software.
3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in
ways properly authorized.
3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.
3.15 Treat all forms of software maintenance with the same professionalism as new development.
Principle 4 JUDGMENT
Software engineers shall maintain integrity and independence in their professional judgment. In
particular, software engineers shall, as appropriate:
4.01. Temper all technical judgments by the need to support and maintain human values.
4.02 Only endorse documents either prepared under their supervision or within their areas of
competence and with which they are in agreement.
4.03. Maintain professional objectivity with respect to any software or related documents they are
asked to evaluate.
4.04. Not engage in deceptive financial practices such as bribery, double billing, or other improper
financial practices.
4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably be
avoided or escaped.
4.06. Refuse to participate, as members or advisors, in a private, governmental or professional
body concerned with software related issues, in which they, their employers or their clients
have undisclosed potential conflicts of interest.
Principle 5 MANAGEMENT
Software engineering managers and leaders shall subscribe to and promote an ethical approach
to the management of software development and maintenance. In particular, those managing or
leading software engineers shall, as appropriate:
5.01 Ensure good management for any project on which they work, including effective procedures
for promotion of quality and reduction of risk.
5.02. Ensure that software engineers are informed of standards before being held to them.
5.03. Ensure that software engineers know the employer's policies and procedures for protecting
passwords, files and information that is confidential to the employer or confidential to
others.
5.04. Assign work only after taking into account appropriate contributions of education and
experience tempered with a desire to further that education and experience.

84
5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes
on any project on which they work or propose to work, and provide an uncertainty
assessment of these estimates.
5.06. Attract potential software engineers only by full and accurate description of the conditions of
employment.
5.07. Offer fair and just remuneration.
5.08. Not unjustly prevent someone from taking a position for which that person is suitably
qualified.
5.09. Ensure that there is a fair agreement concerning ownership of any software, processes,
research, writing, or other intellectual property to which a software engineer has
contributed.
5.10. Provide for due process in hearing charges of violation of an employer's policy or of this
Code.
5.11. Not ask a software engineer to do anything inconsistent with this Code.
5.12. Not punish anyone for expressing ethical concerns about a project.
Principle 6 PROFESSION
Software engineers shall advance the integrity and reputation of the profession consistent with the
public interest. In particular, software engineers shall, as appropriate:
6.01. Help develop an organizational environment favorable to acting ethically.
6.02. Promote public knowledge of software engineering.
6.03. Extend software engineering knowledge by appropriate participation in professional
organizations, meetings and publications.
6.04. Support, as members of a profession, other software engineers striving to follow this Code.
6.05. Not promote their own interest at the expense of the profession, client or employer.
6.06. Obey all laws governing their work, unless, in exceptional circumstances, such compliance
is inconsistent with the public interest.
6.07. Be accurate in stating the characteristics of software on which they work, avoiding not only
false claims but also claims that might reasonably be supposed to be speculative, vacuous,
deceptive, misleading, or doubtful.
6.08. Take responsibility for detecting, correcting, and reporting errors in software and associated
documents on which they work.
6.09. Ensure that clients, employers, and supervisors know of the software engineer's
commitment to this Code of ethics, and the subsequent ramifications of such commitment.
6.10. Avoid associations with businesses and organizations which are in conflict with this code.

85
6.11. Recognize that violations of this Code are inconsistent with being a professional software
engineer.
6.12. Express concerns to the people involved when significant violations of this Code are
detected unless this is impossible, counter-productive, or dangerous.
6.13. Report significant violations of this Code to appropriate authorities when it is clear that
consultation with people involved in these significant violations is impossible, counter-
productive or dangerous.
Principle 7 COLLEAGUES
Software engineers shall be fair to and supportive of their colleagues. In particular, software
engineers shall, as appropriate:
7.01. Encourage colleagues to adhere to this Code.
7.02. Assist colleagues in professional development.
7.03. Credit fully the work of others and refrain from taking undue credit.
7.04. Review the work of others in an objective, candid, and properly- documented way.
7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.
7.06. Assist colleagues in being fully aware of current standard work practices including policies
and procedures for protecting passwords, files and other confidential information, and
security measures in general.
7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the
client or public interest may compel software engineers, in good faith, to question the
competence of a colleague.
7.08. In situations outside of their own areas of competence, call upon the opinions of other
professionals who have competence in that area.
Principle 8 SELF
Software engineers shall participate in lifelong learning regarding the practice of their profession
and shall promote an ethical approach to the practice of the profession. In particular, software
engineers shall continually endeavor to:
8.01. Further their knowledge of developments in the analysis, specification, design,
development, maintenance and testing of software and related documents, together with
the management of the development process.
8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost
and within a reasonable time.
8.03. Improve their ability to produce accurate, informative, and well-written documentation.

86
8.04. Improve their understanding of the software and related documents on which they work and
of the environment in which they will be used.
8.05. Improve their knowledge of relevant standards and the law governing the software and
related documents on which they work.
8.06 Improve their knowledge of this Code, its interpretation, and its application to their work.
8.07 Not give unfair treatment to anyone because of any irrelevant prejudices.
8.08. Not influence others to undertake any action that involves a breach of this Code.
8.09. Recognize that personal violations of this Code are inconsistent with being a professional
software engineer.
This Code was developed by the IEEE-CS/ACM joint task force on Software Engineering Ethics
and Professional Practices (SEEPP):
Executive Committee: Donald Gotterbarn (Chair),
Keith Miller and Simon Rogerson;
Members: Steve Barber, Peter Barnes, Ilene Burnstein, Michael Davis, Amr El-Kadi, N. Ben
Fairweather, Milton Fulghum, N. Jayaram, Tom Jewett, Mark Kanko, Ernie Kallman, Duncan
Langford, Joyce Currie Little, Ed Mechler, Manuel J. Norman, Douglas Phillips, Peter Ron
Prinzivalli, Patrick Sullivan, John Weckert, Vivian Weil, S. Weisband and Laurie Honour Werth.
This Code may be published without permission as long as it is not changed in any way and it
carries the copyright notice.
Copyright © 1999 by the Institute for Electrical and Electronics Engineers, Inc. and the
Association for Computing Machinery, Inc..

87
Case studies from the Online Ethics Center for Engineering and Science, Case Western
Reserve University
(taken from http://www.onlineethics.org).
Infants Under Pressure
Sam Wilson, an experienced engineer was employed by MedTech, a company that made medical
equipment. An important line of products were respirators, used in hospitals. A colleague of Sam
asked him to check out one of these respirators, one designed for infant use. He soon determined
that a relief valve intended to protect against overpressure being applied to the infant's lungs was
incorrectly placed, so that, under certain circumstances, the infant could experience dangerously
high pressure. Correcting the error would not be difficult, since all that was needed was to
reposition the relief valve. In similar circumstances in the past, Sam had seen such problems
handled with dispatch. He called the matter to the attention of the appropriate manager and
assumed that it would be taken care of.
A month or so later (Sam was not directly involved with this particular device) he learned that
nothing had been done. Hundreds of these devices were already in use, and Sam was concerned
about the increasing likelihood of a tragic event. He went back to the manager and urged him to
take appropriate action. When the manager fended him off, Sam said that if prompt measures
were not taken to correct the problem he would have to report it to the cognizant regulatory
agency. The response of MedTech was to fire Sam. Apparently the then current president of
MedTech did not have the same attitude toward product quality that had been prevalent in the
past.
At about the same time, the respirator problem was identified by a physician who had
encountered one in hospital practice. Sam brought suit against MedTech for wrongful discharge,
claiming that his actions in calling attention to the problem were mandated by the code of ethics
that binds professional engineers. Sam is a licensed PE.
Various management changes have since occurred and the legal process is slowly moving along.
Using Other People's Software
Jim Warren was a senior software systems expert, hired by NewSoft, a start-up company, to help
in the development of a new product. He soon learned that the product was based on proprietary
software for which NewSoft did not have a license. Jim assumed that this was some sort of
mistake and spoke to the company president about the matter. He was assured that the situation
would be rectified. But time passed and nothing happened except that Jim found other instances
of the same practice. Repeated efforts to get NewSoft to legalize its operations failed and Jim,
after threatening to notify the victimized companies, was discharged.
Law enforcement officials were brought into the picture and lawyers on all sides began
negotiating. At this date it is not clear whether criminal charges will be filed. There appears to be a
strong possibility of some sort of out-of-court settlement among the companies involved. It is not
clear how this will ultimately affect Jim Warren.
Not Lighting Up
Will Morgan, a licensed electrical engineer, worked for a state university on construction and
renovation projects. His immediate manager was an architect, and next in the chain of command
was an administrator, John Tight, a man with no technical background. Tight, without talking to
the engineers, often produced estimates on project costs that he passed on to higher university
officials. In those cases, not infrequent, where it became evident that actual costs were going to
exceed his estimates, he would pressure the engineers to cut corners.
One such occasion involved the renovation of a warehouse to convert some storage space into
office space. Among the specifications detailed by Morgan was the installation of emergency exit
lights. These were mandated by the building code. As part of his effort to bring the actual costs
closer to his unrealistic estimate, Tight insisted that the specification for emergency lights be
deleted.

88
Will strongly objected on obvious grounds. When he refused to yield, Tight brought charges
against him, claiming that he was a disruptive influence. Although his immediate superior, the
architect, did not support these charges, he did not fight for Morgan, who was ultimately
dismissed by the university. Morgan is now suing for wrongful discharge.
Making Good Wafers Look Bad
Don Fisher, an electrical engineer, worked for Dicers, a company that purchased wafers for
microprocessor chips from another company and then diced, packaged, and sold them. Don was
assigned the task of testing these wafers. After a while, he was instructed by his manager to alter
the testing process in such a manner that the quality of the purchased wafers was made to seem
lower than it really was, which had the effect of the lowering the price paid. Don objected to this
practice and refused to go along. Eventually, he was discharged .
Air Bags
SafeComp is a company that, among other things, designs and makes sensing devices for
automobile air bags. Bob Baines was hired to work in the quality control department. About six
weeks after starting work, he was asked to sign off on a design that he felt very uncertain about.
He checked with people involved in the design and found the situation, at best, ambiguous.
Bob told his manager that he would not feel right about signing off, and, since he was relatively
inexperienced with SafeComp's procedures, asked that he not be required to do this. His
manager kept applying pressure. Eventually, Bob decided that he wished neither to violate his
principles by doing something that he thought was wrong, nor to become involved in a battle in
which his career would certainly be major casualty. He quietly resigned. (For a little more
information on this case, see [3]).
Flight is also Risky
Ralph Sims had worked for the US Government for many years as an engineer, rising to a fairly
high managerial position. On retirement, he accepted an executive position with SuperCom, a
company producing electronic equipment for the military.
Shortly after coming on board, Ralph was informed by a subordinate that, for a long time, a key
test on an important product was not being made in the manner specified by the contract. This
had been going on for several years and the subordinate felt very uncomfortable about it. Ralph,
who had considerable expertise in the technology involved, looked into the matter carefully. It
turned out that, in his previous career, he had acquired some knowledge about the specified test.
He found that, a shorter, and hence less costly, test had indeed been substituted for the required
one. But, after some study, he concluded that SuperCom's test was actually as effective as the
specified test. Nevertheless, by this unauthorized substitution, SuperCom was violating the
contract and exposing itself both to criminal and to civil prosecution. He took his findings to upper
management and urged them to apply to the contracting agency for a contract change authorizing
the simpler test. Ralph felt confident that such a change would be accepted.
But his arguments were not accepted and SuperCom continued on their previous course. Ralph
did not see why he should get into an unpleasant battle with the SuperCom's leaders over this,
since there were no safety issues and even the quality of the product was not actually at stake.
Nevertheless, he did not wish to be involved in a dishonest and probably illegal operation.
Therefore, he chose the course of quietly resigning, without turning in the company.
About three years later, a SuperCom employee reported the deception to the government, and a
criminal investigation was launched. When he resigned, Ralph had signed a non-disclosure
agreement as a condition for receiving some severance pay. Nevertheless, when called upon by
the prosecutor's office to give information about the situation, he cooperated fully.
To his dismay, when the indictments came down, he was one of the people charged with
complicity in the fraud. This necessitated his hiring an attorney and undergoing both the expenses
and anguish of being a defendant in a criminal case. Fortunately for him, after many months, a

89
new prosecutor was assigned to the case. Shortly afterward, the charges against Ralph were
dropped. But, meanwhile, the affair had cost him tens of thousands of dollars in out-of-pocket
expenses, not to mention lost time and anxiety.
Some Remarks
Although the IEEE Ethics Hotline was listed in the IEEE Institute and occasionally mentioned in
that publication, my impression is that only a small percentage of IEEE members were aware of
its existence. Therefore, I suspect that the cases that came to us represent only a small fraction of
what is out there. I feel that providing engineers facing ethics related problems with advice from
experienced people as well as a sympathetic ear is clearly very useful. But, it should also be
evident from the samples provided above, that engineering societies could do a lot more to help.
Aside from the obvious value of providing some financial aid, there is also the possibility of low
key intervention at the early stages. For example, such intervention in the ICU case and in the air
bag case might have had very beneficial effects for all concerned, including not only the
engineers and the general public, but also the employers. The mere presence in such cases of a
large organization expressing an interest in the engineer's situation and contentions changes the
entire picture. It makes it far more difficult for an employer to casually brush off an engineer
expressing serious professional concerns. We have seen evidence of this in the past and, in a
few recent cases, not mentioned here. An interesting aspect of some of these cases, fully
consistent with other such cases previously on record, is the blatant irrationality displayed by
some managers. What combination of ignorance, arrogance, stupidity, and greed produced the
self-destructive behavior of management in the respirator case?
Acknowledgment:
Listing names of people who are part of an important enterprise is analogous to making up a list
of people to invite to a wedding. A very short list omits significant contributors, and a longer list
makes omissions more painful. Nevertheless, here is a short list of key figures in the drive to
develop and energize ethics support in the IEEE, with apologies to others not mentioned:
Walt Elden, Ray Larsen, Joe Wujek, Mal Benjamin, Joe Herkert.
References
Stephen H. Unger, What Happened to Ethics Support?, Letter, IEEE Institute, December, 1999,
p. 15.
Stephen H. Unger, in Spring 1999 issue of IEEE Technology and Society magazine.
Stephen H. Unger, Reality check: ethics and air bags, IEEE Institute, August, 1998, p. 2.

David vernon software_engineering_notes

More Related Content

What's hot (19)

Viewers also liked (7)

Similar to David vernon software_engineering_notes (20)

Recently uploaded (20)

David vernon software_engineering_notes