Management of Software

Projects

Management of software development

Cost (and its estimation):
Scope:
Time:
Risk:
Quality:

Project Management Process

A process is a series of actions directed toward a

particular result.
Project management can be viewed as a number of
interlinked processes.
The project management process groups include:
Initiating processes
Planning processes
Executing processes
Monitoring and controlling processes
Closing processes
2

Level of Activity and Overlap of

Process Groups Over Time

What is Cost and Project Cost

Management?

Cost is a resource sacrificed or foregone to

achieve a specific objective, or something given
up in exchange.
Costs are usually measured in monetary units,
such as dollars.
Project cost management includes the
processes required to ensure that the project is
completed within an approved budget.
4

Project Cost Management Processes

Cost estimating: Developing an approximation

or estimate of the costs of the resources needed
to complete a project.
Cost budgeting: Allocating the overall cost
estimate to individual work items to establish a
baseline for measuring performance.
Cost control: Controlling changes to the project
budget.
5

Basic Principles of Cost

Management

Tangible costs or benefits are those costs or benefits

that an organization can easily measure in dollars.
Intangible costs or benefits are costs or benefits that
are difficult to measure in monetary terms.
Direct costs are costs that can be directly related to
producing the products and services of the project.
Indirect costs are costs that are not directly related to
the products or services of the project, but are indirectly
related to performing the project.
Sunk cost is money that has been spent in the past;
when deciding what projects to invest in or continue, you
should not include sunk costs.
6

Typical Problems with IT

Cost Estimates

Developing an estimate for a large software

project is a complex task that requires a significant
amount of effort.
People who develop estimates often do not have
much experience.
Human beings are biased toward underestimation.

Management might ask for an estimate, but really

desire a bid to win a major contract or get internal
funding.
7

Cost Control

Project cost control includes:

Monitoring cost performance.

Ensuring that only appropriate project changes are
included in a revised cost baseline.
Informing project stakeholders of authorized changes to
the project that will affect costs.

Many organizations around the globe have

problems with cost control.
8

Earned Value Management

(EVM)

EVM is a project performance measurement

technique that integrates scope, time, and cost
data.
Given a baseline (original plan plus approved
changes), you can determine how well the project
is meeting its goals.
You must enter actual information periodically to
use EVM.
More and more organizations around the world
are using EVM to help control project costs.
9

Earned Value Management Terms

The planned value (PV), formerly called the budgeted cost of work
scheduled (BCWS), also called the budget, is that portion of the
approved total cost estimate planned to be spent on an activity
during a given period.
Actual cost (AC), formerly called actual cost of work performed
(ACWP), is the total of direct and indirect costs incurred in
accomplishing work on an activity during a given period.
The earned value (EV), formerly called the budgeted cost of work
performed (BCWP), is an estimate of the value of the physical work
actually completed.
EV is based on the original planned costs for the project or activity
and the rate at which the team is completing work on the project or
activity to date.
10

Rate of Performance

Rate of performance (RP) is the ratio

of actual work completed to the
percentage of work planned to have
been completed at any given time during
the life of the project or activity.

11

Earned Value Formulas

12

Productivity measures

Predicting the resources required for a

software development process
Size related measures based on some output
from the software process. This may be lines
of delivered source code, object code
instructions, etc.
Function-related measures based on an
estimate of the functionality of the delivered
software. Function-points are the best known
of this type of measure
13

Function points

Based on a combination of program

characteristics

external inputs and outputs

user interactions
external interfaces
files used by the system

A weight is associated with each of these

The function point count is computed by
multiplying each raw count by the weight and
summing all values
14

Function points

Function point count modified by complexity of

the project
FPs can be used to estimate LOC depending on
the average number of LOC per FP for a given
language

LOC = AVC * number of function points

AVC is a language-dependent factor varying from 200300 for assembly language to 2-40 for a 4GL

FPs are very subjective. They depend on the

estimator.

Automatic function-point counting is impossible

15

Object points

Object points are an alternative function-related

measure to function points when 4Gls or similar
languages are used for development
Object points are NOT the same as object classes
The number of object points in a program is a
weighted estimate of

The number of separate screens that are displayed

The number of reports that are produced by the system
The number of 3GL modules that must be developed to
supplement the 4GL code
16

Object point estimation

Object points are easier to estimate from a

specification than function points as they
are simply concerned with screens, reports
and 3GL modules
They can therefore be estimated at an
early point in the development process. At
this stage, it is very difficult to estimate
the number of lines of code in a system
17

Productivity estimates

Real-time embedded systems, 40-160

LOC/P-month
Systems programs , 150-400 LOC/P-month
Commercial applications, 200-800
LOC/P-month
In object points, productivity has been
measured between 4 and 50 object
points/month depending on tool support and
developer capability
18

Factors affecting productivity

Fa ctor
Application domain
ex perience
Process qualit y
Project size
Technology sup port
Working en viro nmen t

Des cripti on
Knowledge of t he application domain is essent ial for
effect ive soft ware develo pment. Engin eers wh oalready
un derstand a domain are
lik ely to be th e most
product ive.
The dev elopment p ro cess used can h av e a significant
effect on product ivity. This is co vered in Ch apt er 31.
The larger a p roject , th e more time required for t eam
co mmunicat ions. Less t ime is available for
develo pmen t so indiv idual product ivity is reduced.
Go od support technology such as CASE t ools,
support ive co nfigurat io n management syst ems, et c.
can imp ro ve productivity .
As discussed in Chapt er 2 8, a quiet work in g
en viro nmen t with p rivat e wo rk areas co nt ributes to
impro ved product iv it y.
19

Quality and productivity

All metrics based on volume/unit time are

flawed because they do not take quality into
account
Productivity may generally be increased at the
cost of quality
It is not clear how productivity/quality metrics
are related
If change is constant then an approach based on
counting lines of code is not meaningful
20

Estimation techniques

There is no simple way to make an accurate

estimate of the effort required to develop a
software system

Initial estimates are based on inadequate

information in a user requirements definition
The software may run on unfamiliar computers or
use new technology
The people in the project may be unknown

Project cost estimates may be self-fulfilling

The estimate defines the budget and the product

is adjusted to meet the budget
21

Cost Estimation Tools and

Techniques

Basic tools and techniques for cost estimates:

Analogous or top-down estimates: Use the actual cost of a
previous, similar project as the basis for estimating the cost of the
current project.
Bottom-up estimates: Involve estimating individual work items or
activities and summing them to get a project total.
Parametric modeling: Uses project characteristics (parameters) in
a mathematical model to estimate project costs.
Computerized tools: Tools, such as spreadsheets and project
management software, that can make working with different cost
estimates and cost estimation tools easier.

22

Top-down and bottom-up

estimation

Any of these approaches may be used top-down

or bottom-up
Top-down

Start at the system level and assess the overall system

functionality and how this is delivered through subsystems

Bottom-up

Start at the component level and estimate the effort

required for each component. Add these efforts to
reach a final estimate
23

Top-down estimation

Usable without knowledge of the system

architecture and the components that might
be part of the system
Takes into account costs such as integration,
configuration management and
documentation
Can underestimate the cost of solving difficult
low-level technical problems
24

Bottom-up estimation

Usable when the architecture of the

system is known and components
identified
Accurate method if the system has been
designed in detail
May underestimate costs of system
level activities such as integration and
documentation
25

Experience-based estimates

Estimating is primarily experience-based

However, new methods and technologies may
make estimating based on experience inaccurate

Object oriented rather than function-oriented

development
Client-server systems rather than mainframe systems
Off the shelf components
Component-based software engineering
CASE tools and program generators
26

Managing Scope:
Preliminary Scope Statements

A scope statement is a document used to develop and

confirm a common understanding of the project scope.
It is an important tool for preventing scope creep:

The tendency for project scope to keep getting bigger.

A good practice is to develop a preliminary or initial scope

statement during project initiation and a more detailed
scope statement as the project progresses.
27

Contents of a Preliminary Scope

Statement

Project objectives
Product or service
requirements and
characteristics
Project boundaries
Deliverables
Product acceptance
criteria
Project assumptions and
constraints
Organizational structure
for the project

Initial list of defined risks

Summary of schedule
milestones
Rough order of magnitude
cost estimate
Configuration
management
requirements
Description of approval
requirements

28

Monitoring and Controlling

Project Work

Changes are inevitable on most projects, so its

important to develop and follow a process to
monitor and control changes.
Monitoring project work includes collecting,
measuring, and disseminating performance
information.
Two important outputs of monitoring and
controlling project work include recommended
corrective and preventive actions.
29

Integrated Change Control

Three main objectives are:

Influence the factors that create changes to ensure

that changes are beneficial.

Determine that a change has occurred.

Manage actual changes as they occur.

A baseline is the approved project management

plan plus approved changes.
30

Change Control on Information

Technology Projects

Former view: The project team should strive to

do exactly what was planned on time and within
budget.
Problem: Stakeholders rarely agreed beforehand
on the project scope, and time and cost estimates
were inaccurate.
Modern view: Project management is a process
of constant communication and negotiation.
Solution: Changes are often beneficial, and the
project team should plan for them.
31

Change Control System

A formal, documented process that

describes when and how official project
documents and work may be changed.

Describes who is authorized to make

changes and how to make them.

32

Change Control Boards (CCBs)

A formal group of people responsible for

approving or rejecting changes on a project.
CCBs provide guidelines for preparing change
requests, evaluate change requests, and
manage the implementation of approved
changes.
CCBs include stakeholders from the entire
organization.
33

Managing time:Conflict Intensity

Over the Life of a Project
0.40

Conflict Intensity

0.35
0.30
Schedules

0.25

Average
Total Conflict

0.20

Priorities
Manpower
Technical opinions
Procedures

0.15

Cost
Personality conflicts

0.10
0.05
0.00
Project
Formation

Early Phases

Middle Phases

End Phases

34

Project Time Management

Processes

Activity definition: Identifying the specific activities that the

project team members and stakeholders must perform to produce
the project deliverables.
Activity sequencing: Identifying and documenting the relationships
between project activities.
Activity resource estimating: Estimating how many resources a
project team should use to perform project activities.
Activity duration estimating: Estimating the number of work
periods that are needed to complete individual activities.
Schedule development: Analyzing activity sequences, activity
resource estimates, and activity duration estimates to create the
project schedule.
Schedule control: Controlling and managing changes to the project
schedule.
35

Activity Definition

An activity or task is an element of work normally found on the

WBS that has an expected duration, a cost, and resource
requirements.
Project schedules grow out of the basic documents that initiate a
project.
The project charter includes start and end dates and budget
information.
The scope statement and WBS help define what will be done.
Activity definition involves developing a more detailed WBS and
supporting explanations to understand all the work to be done, so
you can develop realistic cost and duration estimates.

36

Activity Lists and Attributes

An activity list is a tabulation of activities to be included

on a project schedule. The list should include:

The activity name

An activity identifier or number

A brief description of the activity

Activity attributes provide more information about each

activity, such as predecessors, successors, logical
relationships, leads and lags, resource requirements,
constraints, imposed dates, and assumptions related to the
activity.
37

Milestones

A milestone is a significant event that normally

has no duration.
It often takes several activities and a lot of work
to complete a milestone.
Milestones are useful tools for setting schedule
goals and monitoring progress.
Examples include completion and customer signoff on key documents and completion of specific
products.
38

Activity Sequencing

Involves reviewing activities and determining

dependencies.
A dependency or relationship relates to the
sequencing of project activities or tasks.
You must determine dependencies in order to
use critical path analysis.

39

Three Types of Dependencies

Mandatory dependencies: Inherent in the

nature of the work being performed on a project;
sometimes referred to as hard logic.
Discretionary dependencies: Defined by the
project team; sometimes referred to as soft logic
and should be used with care because they may
limit later scheduling options.
External dependencies: Involve relationships
between project and non-project activities.
40

Network Diagrams

Network diagrams are the preferred technique for

showing activity sequencing.
A network diagram is a schematic display of the
logical relationships among, or sequencing of,
project activities.
Two main formats are the arrow and precedence
diagramming methods.
41

Sample Activity-on-Arrow (AOA)

Network Diagram for Project X

42

Arrow Diagramming Method

(ADM)

Also called activity-on-arrow (AOA) network

diagram.
Activities are represented by arrows.
Nodes or circles are the starting and ending
points of activities.

Can only show finish-to-start dependencies.

43

Process for Creating AOA

Diagrams
1.

2.

3.

4.

Find all of the activities that start at node 1. Draw their finish nodes
and draw arrows between node 1 and those finish nodes. Put the
activity letter or name and duration estimate on the associated
arrow.
Continuing drawing the network diagram, working from left to right.
Look for bursts and merges. A burst occurs when a single node is
followed by two or more activities. A merge occurs when two or
more nodes precede a single node.
Continue drawing the project network diagram until all activities
that have dependencies are included in the diagram.
As a rule of thumb, all arrowheads should face toward the right,
and no arrows should cross in an AOA network diagram.
44

Precedence Diagramming Method

(PDM)

Activities are represented by boxes.

Arrows show relationships between activities.

More popular than ADM method and used by

project management software.
Better at showing different types of
dependencies.
45

Task Dependency Types

46

Activity Resource Estimating

Before estimating activity durations, you must

have a good idea of the quantity and type of
resources that will be assigned to each activity.
Consider important issues in estimating resources:

How difficult will it be to complete specific activities on

this project?
What is the organizations history in doing similar
activities?
Are the required resources available?
47

Three-Point Estimates

Instead of providing activity estimates as a

discrete number, such as four weeks, its often
helpful to create a three-point estimate:

An estimate that includes an optimistic, most likely, and

pessimistic estimate, such as three weeks for the
optimistic, four weeks for the most likely, and five
weeks for the pessimistic estimate.

Three-point estimates are needed for PERT

estimates and Monte Carlo simulations.
48

Gantt Charts

Gantt charts provide a standard format for

displaying project schedule information by listing
project activities and their corresponding start
and finish dates in a calendar format.
Symbols include:

Black diamonds: Milestones

Thick black bars: Summary tasks

Lighter horizontal bars: Durations of tasks

Arrows: Dependencies between tasks

49

Gantt Chart for Project X

Note: In Project 2003 darker bars are red to represent critical tasks.
50

Gantt Chart for Software Launch Project

51

Adding Milestones to Gantt

Charts

Many people like to focus on meeting

milestones, especially for large projects.
Milestones emphasize important events or
accomplishments in projects.
You typically create milestone by entering
tasks that have a zero duration, or you can
mark any task as a milestone.
52

Sample Tracking Gantt Chart

53

Project Risk Management

Processes

Risk management planning: Deciding how to

approach and plan the risk management activities
for the project.
Risk identification: Determining which risks are
likely to affect a project and documenting the
characteristics of each.
Qualitative risk analysis: Prioritizing risks based
on their probability and impact of occurrence.
54

Project Risk Management

Processes (contd)

Quantitative risk analysis: Numerically estimating the

effects of risks on project objectives.
Risk response planning: Taking steps to enhance
opportunities and reduce threats to meeting project
objectives.
Risk monitoring and control: Monitoring identified and
residual risks, identifying new risks, carrying out risk
response plans, and evaluating the effectiveness of risk
strategies throughout the life of the project.
55

Risk Management Planning

The main output of risk management planning is a

risk management plana plan that documents
the procedures for managing risk throughout a
project.
The project team should review project
documents and understand the organizations and
the sponsors approaches to risk.

The level of detail will vary with the needs of the

project.
56

Topics Addressed in a Risk

Management Plan

Methodology

Roles and responsibilities

Budget and schedule

Risk categories

Risk probability and impact

Risk documentation
57

Contingency and Fallback

Plans, Contingency Reserves

Contingency plans are predefined actions that the

project team will take if an identified risk event
occurs.
Fallback plans are developed for risks that have a
high impact on meeting project objectives, and are
put into effect if attempts to reduce the risk are not
effective.
Contingency reserves or allowances are
provisions held by the project sponsor or organization
to reduce the risk of cost or schedule overruns to an
acceptable level.
58

Common Sources of Risk in Information

Technology Projects

Several studies show that IT projects share

some common sources of risk.
The Standish Group developed an IT
success potential scoring sheet based on
potential risks.
Other broad categories of risk help identify
potential risks.
59

Information Technology Success

Potential Scoring Sheet
Success Criterion

Relative Importance

User Involvement

19

Executive Management support

16

Clear Statement of Requirements

15

Proper Planning

11

Realistic Expectations

10

Smaller Project Milestones

Competent Staff

Ownership

Clear Visions and Objectives

Hard-Working, Focused Staff

Total

100
60

Potential Negative Risk Conditions

Associated With Each Knowledge Area
Knowledge Area

Risk Conditions

Integration

Inadequate planning; poor resource allocation; poor integration

management; lack of post-project review

Scope

Poor definition of scope or work packages; incomplete definition

of quality requirements; inadequate scope control

Time

Errors in estimating time or resource availability; poor allocation

and management of float; early release of competitive products

Cost

Estimating errors; inadequate productivity, cost, change, or

contingency control; poor maintenance, security, purchasing, etc.

Quality

Poor attitude toward quality; substandard

design/materials/workmanship; inadequate quality assurance
program

Human Resources

Poor conflict management; poor project organization and

definition of responsibilities; absence of leadership

Communications

Carelessness in planning or communicating; lack of consultation

with key stakeholders

Risk

Ignoring risk; unclear assignment of risk; poor insurance

management

Procurement

Unenforceable conditions or contract clauses; adversarial relations

61

Risk Register

The main output of the risk identification process is a list

of identified risks and other information needed to begin
creating a risk register.
A risk register is:

A document that contains the results of various risk management

processes and that is often displayed in a table or spreadsheet
format.
A tool for documenting potential risk events and related
information.

Risk events refer to specific, uncertain events that may

occur to the detriment or enhancement of the project.
62

Risk Register Contents

An identification number for each risk event.

A rank for each risk event.
The name of each risk event.
A description of each risk event.
The category under which each risk event falls.
The root cause of each risk.
Triggers for each risk; triggers are indicators or symptoms of
actual risk events.
Potential responses to each risk.
The risk owner or person who will own or take responsibility
for each risk.
The probability and impact of each risk occurring.
The status of each risk.

63

Probability/Impact Matrix

A probability/impact matrix or chart lists the

relative probability of a risk occurring on one side
of a matrix or axis on a chart and the relative
impact of the risk occurring on the other.
List the risks and then label each one as high,
medium, or low in terms of its probability of
occurrence and its impact if it did occur.
Can also calculate risk factors:

Numbers that represent the overall risk of specific

events based on their probability of occurring and the
consequences to the project if they do occur.
64

Sample Probability/Impact Matrix

65

Sample Probability/Impact Matrix for

Qualitative Risk Assessment

66

Chart Showing High-, Medium-, and

Low-Risk Technologies

67

Top Ten Risk Item Tracking

Top Ten Risk Item Tracking is a qualitative

risk analysis tool that helps to identify risks and
maintain an awareness of risks throughout the
life of a project.
Establish a periodic review of the top ten project
risk items.
List the current ranking, previous ranking,
number of times the risk appears on the list
over a period of time, and a summary of
progress made in resolving the risk item.
68

Example of Top Ten Risk Item

Tracking
Monthly Ranking
Risk Item

This

Last

Number
Risk Resolution
of Months Progress

Month

Month

Inadequate
planning

Working on revising the

entire project plan

Poor definition
of scope

Holding meetings with

project customer and
sponsor to clarify scope

Absence of
leadership

Just assigned a new

project manager to lead
the project after old one
quit

Poor cost
estimates

Revising cost estimates

Poor time
estimates

Revising schedule
estimates
69

What Is Quality?

The International Organization for Standardization

(ISO) defines quality as the degree to which a
set of inherent characteristics fulfils requirements
(ISO9000:2000).
Other experts define quality based on:

Conformance to requirements: The projects

processes and products meet written specifications.
Fitness for use: A product can be used as it was
intended.
70

Software quality management

Concerned with ensuring that the required level

of quality is achieved in a software product
Involves defining appropriate quality standards
and procedures and ensuring that these are
followed
Should aim to develop a quality culture where
quality is seen as everyones responsibility

71

What is quality?

Quality, simplistically, means that a product

should meet its specification
This is problematical for software systems

Tension between customer quality requirements

(efficiency, reliability, etc.) and developer quality
requirements (maintainability, reusability, etc.)
Some quality requirements are difficult to specify in
an unambiguous way
Software specifications are usually incomplete and
often inconsistent
72

What Is Project Quality

Management?

Processes include:

Quality planning: Establish organisational procedures and

standards for quality. Identifying which quality standards
are relevant to the project and how to satisfy them.
Quality assurance: Periodically evaluating overall project
performance to ensure the project will satisfy the relevant
quality standards.
Quality control: Monitoring specific project results to
ensure that they comply with the relevant quality
standards. Ensure that procedures and standards are
followed by the software development team.
73

Quality management and software development

Software development
process

D1

D2

D3

D4

D5

Quality management
process

Standards and
procedures

Quality
plan

Quality review reports

74

Scope Quality Aspects of IT

Projects

Functionality is the degree to which a system performs

its intended function.
Features are the systems special characteristics that
appeal to users.
System outputs are the screens and reports the system
generates.
Performance addresses how well a product or service
performs the customers intended use.
Reliability is the ability of a product or service to perform
as expected under normal conditions.
Maintainability addresses the ease of performing
maintenance on a product.
75

Quality Assurance

Quality assurance includes all the activities related to

satisfying the relevant quality standards for a project.
Another goal of quality assurance is continuous quality
improvement.
Benchmarking generates ideas for quality improvements
by comparing specific project practices or product
characteristics to those of other projects or products within
or outside the performing organization.
A quality audit is a structured review of specific quality
management activities that help identify lessons learned
that could improve performance on current or future
projects.

76

Table of Contents for a

Quality Assurance Plan*
1.0 Draft Quality Assurance Plan
1.1 Introduction
1.2 Purpose
1.3 Policy Statement
1.4 Scope
2.0 Management
2.1 Organizational Structure
2.2 Roles and Responsibilities
2.2.1 Technical Monitor/Senior
Management
2.2.2 Task Leader
2.2.3 Quality Assurance Team
2.2.4 Technical Staff
3.0 Required Documentation
*U.S. Department of Energy

4.0 Quality Assurance Procedures

4.1 Walkthrough Procedure
4.2 Review Process
4.2.1 Review Procedures
4.3 Audit Process
4.3.1 Audit Procedures
4.4 Evaluation Process
4.5 Process Improvement
5.0 Problem Reporting Procedures
5.1 Noncompliance Reporting Procedures
6.0 Quality Assurance Metrics
Appendix
Quality Assurance Checklist Forms
77

Pareto Analysis

Pareto analysis involves identifying the vital few

contributors that account for the most quality
problems in a system.
Also called the 80-20 rule, meaning that 80 percent
of problems are often due to 20 percent of the
causes.
Pareto diagrams are histograms, or column
charts representing a frequency distribution, that
help identify and prioritize problem areas.
78

Sample Pareto Diagram

79

Types of Tests

Unit testing tests each individual component (often a

program) to ensure it is as defect-free as possible.
Integration testing occurs between unit and system
testing to test functionally grouped components.
System testing tests the entire system as one entity.
User acceptance testing is an independent test
performed by end users prior to accepting the delivered
system.

80

Testing Alone Is Not Enough

Watts S. Humphrey, a renowned expert on software quality, defines a

software defect as anything that must be changed before delivery
of the program.
Testing does not sufficiently prevent software defects because:

The number of ways to test a complex system is huge.

Users will continue to invent new ways to use a system that its
developers never considered.

Humphrey suggests that people rethink the software development

process to provide no potential defects when you enter system
testing; developers must be responsible for providing error-free code
at each stage of testing.
81

The Cost of Quality

The cost of quality is the cost of conformance plus

the cost of nonconformance.

Conformance means delivering products that meet

requirements and fitness for use.
Cost of nonconformance means taking responsibility
for failures or not meeting quality expectations.

A 2002 study reported that software bugs cost the

U.S. economy $59.6 billion each year and that one
third of the bugs could be eliminated by an
improved testing infrastructure.*
*RTI International, Software Bugs Cost U.S. Economy $59.6 Billion Annually, RTI Study
Finds, July 1, 2002.
82

Five Cost Categories Related to

Quality

Prevention cost: Cost of planning and executing a project

so it is error-free or within an acceptable error range.
Appraisal cost: Cost of evaluating processes and their
outputs to ensure quality.

Internal failure cost: Cost incurred to correct an

identified defect before the customer receives the product.
External failure cost: Cost that relates to all errors not
detected and corrected before delivery to the customer.
Measurement and test equipment costs: Capital cost
of equipment used to perform prevention and appraisal
activities.
83

Maturity Models

Maturity models are frameworks for helping

organizations improve their processes and
systems.

The Software Quality Function Deployment

Model focuses on defining user requirements and
planning software projects.
The Software Engineering Institutes Capability
Maturity Model is a five-level model laying out a
generic path to process improvement for software
development in organizations.
84

CMM Levels and CMMI

CMM levels, from lowest to highest, are:

Initial
Repeatable
Defined
Managed
Optimizing
The Capability Maturity Model Integration (CMMI) is
replacing the older CMM ratings and addresses software
engineering, system engineering, and program
management.
Companies may not get to bid on government projects
unless they have a CMMI Level 3.
85

ISO 9000

International set of standards for quality

management
Applicable to a range of organisations from
manufacturing to service industries
ISO 9001 applicable to organisations which
design, develop and maintain products
ISO 9001 is a generic model of the quality
process Must be instantiated for each
organisation
86

Documentation standards

Particularly important - documents are the tangible

manifestation of the software
Documentation process standards

Document standards

How documents should be developed, validated and

maintained
Concerned with document contents, structure, and
appearance

Document interchange standards

How documents are stored and interchanged between

different documentation systems
87

Documentation process
Create
initial draft
Stage 1:
Creation

Proofread
text
Stage 2:
Polishing

Layout
text

Incorporate
review
comments

Review
draft

Re-draft
document

Approved document

Produce
final draft

Check
final dr aft

Approved document

Review
layout

Produce
print masters

Print
copies

Stage 3:
Pr oduction
88

Document standards

Document identification standards

Document structure standards

Standard structure for project documents

Document presentation standards

How documents are uniquely identified

Define fonts and styles, use of logos, etc.

Document update standards

Define how changes from previous versions are

reflected in a document
89

Document interchange
standards

Documents are produced using different

systems and on different computers
Interchange standards allow electronic
documents to be exchanged, mailed, etc.
Need for archiving. The lifetime of word
processing systems may be much less than the
lifetime of the software being documented
XML is an emerging standard for document
interchange which will be widely supported in
future
90

Software quality attributes

Safety
Security
Reliability
Resilience
Robustness

Underst andability
Test abilit y
Adapt ability
Modularit y
Complexity

Port abilit y
Usabilit y
Reusabilit y
Efficiency
Learnability

91

Quality control

Checking the software development process

to ensure that procedures and standards
are being followed
Two approaches to quality control

Quality reviews
Automated software assessment and software
measurement

92

Quality reviews

The principal method of validating the quality

of a process or of a product
Group examined part or all of a process or
system and its documentation to find
potential problems
There are different types of review with
different objectives

Inspections for defect removal (product)

Reviews for progress assessment(product and
process)
Quality reviews (product and standards)
93

Types of review
Revie w type
Design or
inspection s

Principal purpo se
program T o detect det ailed errors in t he design or
co de and t o check wh et her st andards h ave
been follo wed. T h e review should be driven
by a checklist of po ssible errors.
Progress rev iews
T o prov ide in fo rmation for
man agemen t
about th e overall progress of the p ro ject .
T his is both a process an d a product rev iew
an d is con cern ed with costs,
plan s an d
schedules.
Qualit y reviews
T o carry out a t echnical an alysis of product
co mpon ent s o r document at io nt o find fault s
or mismatches bet ween t he specificat ion
an d th e design , co de o r do cument at ion. It
may also be concerned wit h broader qualit y
issues such as adherence t o stan dards an d
ot her qualit y at tributes.
94

Quality reviews

A group of people carefully examine part or all

of a software system and its associated
documentation.
Code, designs, specifications, test plans,
standards, etc. can all be reviewed.
Software or documents may be 'signed off' at a
review which signifies that progress to the next
development stage has been approved by
management.
95

Software measurement and

metrics

Software measurement is concerned with deriving

a numeric value for an attribute of a software
product or process
This allows for objective comparisons between
techniques and processes
Although some companies have introduced
measurement programmes, the systematic use of
measurement is still uncommon
There are few standards in this area
96

Metrics assumptions

A software property can be measured

The relationship exists between what we
can measure and what we want to know
This relationship has been formalized and
validated
It may be difficult to relate what can be
measured to desirable quality attributes
97

Internal and external

attributes

Number of procedur e
par ameters

Maintainability
Cyclomatic complexity
Reliability
Program size in lines
of code
Portability
Number of error
messages
Usability
Length of user manual

98

Product metrics

A quality metric should be a predictor of

product quality
Classes of product metric

Dynamic metrics which are collected by measurements

made of a program in execution
Static metrics which are collected by measurements
made of the system representations
Dynamic metrics help assess efficiency and reliability;
static metrics help assess complexity, understandability
and maintainability
99

Dynamic and static metrics

Dynamic metrics are closely related to software

quality attributes

It is relatively easy to measure the response time of a

system (performance attribute) or the number of
failures (reliability attribute)

Static metrics have an indirect relationship with

quality attributes

You need to try and derive a relationship between

these metrics and properties such as complexity,
understandability and maintainability
100