The document discusses various topics related to managing software projects, including cost estimation and control, scope management, scheduling, and risk management. It provides information on processes for project management, defining activities and their relationships, estimating activity durations and resource needs, developing project schedules, and controlling changes to maintain the schedule. Key aspects covered are the project management process groups, developing a preliminary scope statement, integrated change control, monitoring project work, and managing conflicts that arise over the life of a project.

1. 1
Management of Software
Projects
 Management of software development
 Cost (and its estimation):
 Scope:
 Time:
 Risk:
 Quality:

2. 2
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

3. 3
Level of Activity and Overlap of
Process Groups Over Time

4. 4
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.

5. 5
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.

6. 6
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.

7. 7
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.

8. 8
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.

9. 9
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.

10. 10
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.

11. 11
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.

12. 12
Earned Value Formulas

13. 13
 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
Productivity measures

14. 14
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

15. 15
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 200-
300 for assembly language to 2-40 for a 4GL
 FPs are very subjective. They depend on the
estimator.
 Automatic function-point counting is impossible

16. 16
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

17. 17
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

18. 18
 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
Productivity estimates

19. 19
Factors affecting productivity
Factor Description
Application domain
experience
Knowledge ofthe application domain is essential for
effective software development. Engineers who already
understand a domain are likely to be the most
productive.
Process quality The development process used can have a significant
effect on productivity. This is covered in Chapter 31.
Project size The larger a project, the more time required for team
communications. Less time is available for
development so individual productivity is reduced.
Technology support Good support technology such as CASE tools,
supportive configuration management systems, etc.
can improve productivity.
Working environment As discussed in Chapter 28, a quiet working
environment with private work areas contributes to
improved productivity.

20. 20
 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
Quality and productivity

21. 21
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

22. 22
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.

23. 23
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
sub-systems
 Bottom-up
 Start at the component level and estimate the effort
required for each component. Add these efforts to
reach a final estimate

24. 24
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

25. 25
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

26. 26
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

27. 27
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.

28. 28
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

29. 29
Monitoring and Controlling
Project Work
 Changes are inevitable on most projects, so it’s
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.

30. 30
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.

31. 31
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.

32. 32
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.

33. 33
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.

34. 34
Managing time:Conflict Intensity Over
the Life of a Project
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
Project
Formation
Early Phases Middle Phases End Phases
ConflictIntensity
Schedules
Priorities
Manpower
Technical opinions
Procedures
Cost
Personality conflicts
Average
Total Conflict

35. 35
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.

36. 36
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.

37. 37
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.

38. 38
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 sign-
off on key documents and completion of specific
products.

39. 39
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.

40. 40
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.

41. 41
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.

42. 42
Sample Activity-on-Arrow (AOA)
Network Diagram for Project X

43. 43
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.

44. 44
Process for Creating AOA
Diagrams
1. 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.
2. 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.
3. Continue drawing the project network diagram until all activities that
have dependencies are included in the diagram.
4. As a rule of thumb, all arrowheads should face toward the right, and
no arrows should cross in an AOA network diagram.

45. 45
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.

46. 46
Task Dependency Types

47. 47
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 organization’s history in doing similar
activities?
 Are the required resources available?

48. 48
Three-Point Estimates
 Instead of providing activity estimates as a discrete
number, such as four weeks, it’s 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.

49. 49
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

50. 50
Gantt Chart for Project X
Note: In Project 2003 darker bars are red to represent critical tasks.

51. 51
Gantt Chart for Software Launch Project

52. 52
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.

53. 53
Sample Tracking Gantt Chart

54. 54
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.

55. 55
Project Risk Management
Processes (cont’d)
 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.

56. 56
Risk Management Planning
 The main output of risk management planning is a
risk management plan—a plan that documents
the procedures for managing risk throughout a
project.
 The project team should review project documents
and understand the organization’s and the
sponsor’s approaches to risk.
 The level of detail will vary with the needs of the
project.

57. 57
Topics Addressed in a Risk
Management Plan
 Methodology
 Roles and responsibilities
 Budget and schedule
 Risk categories
 Risk probability and impact
 Risk documentation

58. 58
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.

59. 59
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.

60. 60
Information Technology Success
Potential Scoring Sheet

61. 61
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

62. 62
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.

63. 63
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.

64. 64
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.

65. 65
Sample Probability/Impact Matrix

66. 66
Sample Probability/Impact Matrix for
Qualitative Risk Assessment

67. 67
Chart Showing High-, Medium-, and
Low-Risk Technologies

68. 68
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.

69. 69
Example of Top Ten Risk Item
Tracking
Monthly Ranking
Risk Item This
Month
Last
Month
Number
of Months
Risk Resolution
Progress
Inadequate
planning
1 2 4 Working on revising the
entire project plan
Poor definition
of scope
2 3 3 Holding meetings with
project customer and
sponsor to clarify scope
Absence of
leadership
3 1 2 Just assigned a new
project manager to lead
the project after old one
quit
Poor cost
estimates
4 4 3 Revising cost estimates
Poor time
estimates
5 5 3 Revising schedule
estimates

70. 70
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 project’s
processes and products meet written specifications.
 Fitness for use: A product can be used as it was
intended.

71. 71
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 everyone’s responsibility

72. 72
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

73. 73
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.

74. 74
Quality management and software development
Software development
process
Quality management
process
D1 D2 D3 D4 D5
Standards and
procedures
Quality
plan
Quality review reports

75. 75
Scope Quality Aspects of IT
Projects
 Functionality is the degree to which a system performs
its intended function.
 Features are the system’s 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 customer’s 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.

76. 76
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.

77. 77
Table of Contents for a
Quality Assurance Plan*
*U.S. Department of Energy
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
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

78. 78
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.

79. 79
Sample Pareto Diagram

80. 80
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.

81. 81
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.

82. 82
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.

83. 83
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.

84. 84
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 Institute’s Capability
Maturity Model is a five-level model laying out a
generic path to process improvement for software
development in organizations.

85. 85
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.

86. 86
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

87. 87
Documentation standards
 Particularly important - documents are the tangible
manifestation of the software
 Documentation process standards
 How documents should be developed, validated and
maintained
 Document standards
 Concerned with document contents, structure, and
appearance
 Document interchange standards
 How documents are stored and interchanged between
different documentation systems

88. 88
Documentation process
Create
initial draft
Review
draft
Incorporate
review
comments
Re-draft
document
Proofread
text
Produce
final draft
Check
final draft
Layout
text
Review
layout
Produce
print masters
Print
copies
Stage 1:
Creation
Stage 2:
Polishing
Stage 3:
Production
Approved document
Approved document

89. 89
Document standards
 Document identification standards
 How documents are uniquely identified
 Document structure standards
 Standard structure for project documents
 Document presentation standards
 Define fonts and styles, use of logos, etc.
 Document update standards
 Define how changes from previous versions are
reflected in a document

90. 90
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

91. 91
Software quality attributes
Safety Understandability Portability
Security Testability Usability
Reliability Adaptability Reusability
Resilience Modularity Efficiency
Robustness Complexity Learnability

92. 92
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

93. 93
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)

94. 94
Types of review
Reviewtype Principal purpose
Design or program
inspections
To detect detailed errors in the design or
code and to check whether standards have
been followed. The reviewshould be driven
by a checklist ofpossible errors.
Progress reviews To provide information for management
about the overall progress ofthe project.
This is both a process and a product review
and is concerned with costs, plans and
schedules.
Quality reviews To carry out a technical analysis ofproduct
components or documentation to find faults
or mismatches between the specification
and the design, code or documentation. It
may also be concerned with broader quality
issues such as adherence to standards and
other quality attributes.

95. 95
 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.
Quality reviews

96. 96
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

97. 97
 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
Metrics assumptions

98. 98
Internal and external attributes
Reliability
Number of procedure
parameters
Cyclomaticcomplexity
Programsizeinlines
ofcode
Number of error
messages
Lengthof usermanual
Maintainability
Usability
Portability

99. 99
 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
Product metrics

100. 100
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