UNIT 3

Managing Software Project

Content

Software Metrices (Process, Product and Project Metrices)

Software Project Estimations

Software Project Planning (MS Project Tool)

Project Scheduling and Tracking

Risk Analysis & Management (Risk Identification, Risk Projection, Risk refinement, Risk Mitigation)

Unit 3
The Four P’s

 People — the most important element of a

successful project
 Product — the software to be built
 Process — the set of framework activities and
software engineering tasks to get the job done
 Project — all work required to make the product a
reality

Unit 3
 People includes:
 The stakeholders
 Team Leaders
 Software Team
 Agile Teams
 Coordination and communication Issues

 Product includes:
 Software Scope
 Problem Decomposition

 Process includes:
 Melding the product and the process
 Process Decomposition

 Project includes:
 Start on the right foot
 Maintain momentum
 Track progress
 Make smart decisions
 Conduct a postmortem analysis

Unit 3
Stakeholders
 Senior managers who define the business issues that often have
significant influence on the project.
 Project (technical) managers who must plan, motivate, organize,
and control the practitioners who do software work.
 Practitioners who deliver the technical skills that are necessary to
engineer a product or application.
 Customers who specify the requirements for the software to be
engineered and other stakeholders who have a peripheral interest
in the outcome.
 End-users who interact with the software once it is released for
production use.

Unit 3
Software Teams

How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

Unit 3
Team Leader
 The MOI Model
 Motivation. The ability to encourage (by “push or
pull”) technical people to produce to their best ability.
 Organization. The ability to mold existing processes
(or invent new ones) that will enable the initial concept
to be translated into a final product.
 Ideas or innovation. The ability to encourage people
to create and feel creative even when they must work
within bounds established for a particular software
product or application.

Unit 3
Software
Teams
 the difficulty of the problem to be solved
 the size of the resultant program(s) in lines of code or function
points
 the time that the team will stay together (team lifetime)
 the degree to which the problem can be modularized
 the required quality and reliability of the system to be built
 the rigidity of the delivery date
 the degree of sociability (communication) required for the project

Unit 3
Agile Teams
 Team members must have trust in one another.
 The distribution of skills must be appropriate to the
problem.
 Mavericks may have to be excluded from the team, if team
cohesiveness is to be maintained.
 Team is “self-organizing”
 An adaptive team structure
 Uses elements of Constantine’s random, open, and
synchronous paradigms
 Significant autonomy

Unit 3
Team Coordination & Communication
 Formal, impersonal approaches include software engineering documents
and work products (including source code), technical memos, project
milestones, schedules, and project control tools (Chapter 23), change
requests and related documentation, error tracking reports, and repository
data (see Chapter 26).
 Formal, interpersonal procedures focus on quality assurance activities
(Chapter 25) applied to software engineering work products. These include
status review meetings and design and code inspections.
 Informal, interpersonal procedures include group meetings for information
dissemination and problem solving and “collocation of requirements and
development staff.”
 Electronic communication encompasses electronic mail, electronic bulletin
boards, and by extension, video-based conferencing systems.
 Interpersonal networking includes informal discussions with team members
and those outside the project who may have experience or insight that can
Unit 3
The Product Scope
 Scope

Context. How does the software to be built fit into a larger
system, product, or business context and what constraints
are imposed as a result of the context?

Information objectives. What customer-visible data
objects (Chapter 8) are produced as output from the
software? What data objects are required for input?

Function and performance. What function does the
software perform to transform input data into output? Are
any special performance characteristics to be addressed?
 Software project scope must be unambiguous and understandable
at the management and technical levels.
Problem Decomposition
 Sometimes called partitioning or problem
elaboration
 Once scope is defined …
 It is decomposed into constituent functions
 It is decomposed into user-visible data objects
or
 It is decomposed into a set of problem classes
 Decomposition process continues until all
Unit 3
Product Metrices
 Focus on the quality of deliverables
 Product metrics are combined across several projects to
produce process metrics
 Metrics for the product:
– Measures of the Analysis Model
– Complexity of the Design Model
– Internal algorithmic complexity
– Architectural complexity
– Data flow complexity
– Code metrics
Unit 3
McCall’s Triangle of Quality

Maintainability Portability
Flexibility Reusability
Testability Interoperability

PRODUCT REVISION PRODUCT TRANSITION

PRODUCT OPERATION
Correctness Usability Efficiency
Reliability Integrity

Unit 3
The Process
 Once a process framework has been established
 Consider project characteristics
 Determine the degree of rigor required
 Define a task set for each software engineering activity

Task set =
 Software engineering tasks
 Work products
 Quality assurance points
 Milestones

Unit 3
Process Metrics

 Process metrics are collected across all projects and over long periods of
time. Their intent is to provide a set of process indicators that lead to long-
term software process improvement.
 Focus on quality achieved as a consequence of a repeatable or managed
process.
 Strategic and Long Term.
 Statistical Software Process Improvement (SSPI).
 Error Categorization and Analysis:
– All errors and defects are categorized by origin
– The cost to correct each error and defect is recorded
– The number of errors and defects in each category is computed
– Data is analyzed to find categories that result in the highest cost to the
organization Unit 3
The Project
 Projects get into trouble when …
 Software people don’t understand their customer’s needs.
 The product scope is poorly defined.
 Changes are managed poorly.
 The chosen technology changes.
 Business needs change [or are ill-defined].
 Deadlines are unrealistic.
 Users are resistant.
 Sponsorship is lost [or was never properly obtained].
 The project team lacks people with appropriate skills.
 Managers [and practitioners] avoid best practices and lessons
learned. Unit 3
 Common-Sense Approach to
Projects
 Start on the right foot. This is accomplished by working hard (very hard) to
understand the problem that is to be solved and then setting realistic
objectives and expectations.
 Maintain momentum. The project manager must provide incentives to keep
turnover of personnel to an absolute minimum, the team should emphasize
quality in every task it performs, and senior management should do
everything possible to stay out of the team’s way.
 Track progress. For a software project, progress is tracked as work
products (e.g., models, source code, sets of test cases) are produced and
approved (using formal technical reviews) as part of a quality assurance
activity.
 Make smart decisions. In essence, the decisions of the project manager
and the software team should be to “keep it simple.”
 Conduct a postmortem analysis. Establish a consistent mechanism for
extracting lessons learned for each Unit 3
project.
Project Metrices
 Project metrics enable a software project manager to assess the status of
an ongoing project, track potential risks, uncover problem areas before
they go “critical,” adjust work flow or tasks, and evaluate the project
team’s ability to control quality of software work products.
 Project metrics on most software projects occurs during estimation.
 Metrics collected from past projects are used as a basis from which effort
and time estimates are made for current software work. Production rates
represented in terms of models created, review hours, function points, and
delivered source lines are measured.
 These metrics are used to minimize the development schedule by making
the adjustments necessary to avoid delays and mitigate potential problems
and risks.
 Project metrics are used to assess product quality on an ongoing basis and,
when necessary, modify the technical
Unit 3approach to improve quality.
Software Project Estimations
 Software Project Management begins with a set of activities
that are collectively called project planning.
 The overall goal of project planning is to establish a
pragmatic strategy for controlling, tracking, and monitoring
a complex technical project.
Why?
 So the end result gets done on time, with quality!

Unit 3
Project Planning Task Set-I
 Establish project scope
 Determine feasibility
 Analyze risks
 Risk analysis is considered in detail in Chapter
25.
 Define required resources
 Determine require human resources
 Define reusable software resources
 Identify environmental
Unit 3 resources
Project Planning Task Set-II
 Estimate cost and effort
 Decompose the problem
 Develop two or more estimates using size, function points,
process tasks or use-cases
 Reconcile the estimates
 Develop a project schedule
 Scheduling is considered in detail in Chapter 27.

Establish a meaningful task set

Define a task network

Use scheduling tools to develop a timeline chart

Define schedule tracking mechanisms
Unit 3
Estimation
 Estimation of resources, cost, and schedule for a software
engineering effort requires
 experience
 access to good historical information (metrics)
 the courage to commit to quantitative predictions when
qualitative information is all that exists
 Estimation carries inherent risk and this risk leads to
uncertainty

Unit 3
Project Estimation
 Project scope must be understood
 Elaboration (decomposition) is necessary
 Historical metrics are very helpful
 At least two different techniques should be used
 Uncertainty is inherent in the process

Unit 3
Estimation Accuracy
 Predicated on …
 the degree to which the planner has properly estimated the
size of the product to be built
 the ability to translate the size estimate into human effort,
calendar time, and dollars (a function of the availability of
reliable software metrics from past projects)
 the degree to which the project plan reflects the abilities of the
software team
 the stability of product requirements and the environment that
supports the software engineering effort.

Unit 3
Functional Decomposition

Statement functional
of decomposition
Scope
Perform a
Grammatical “parse”

Unit 3
Conventional Methods:
LOC/FP Approach
 compute LOC/FP using estimates of information domain
values
 use historical data to build estimates for the project.
 A three-point or expected value can then be computed. The
expected value for the estimation variable (size) S can be
computed as a weighted average of the optimistic (Sopt),
most likely (Sm), and pessimistic (Spess) estimates.
 S = Sopt+4Sm+Spess
6

Unit 3
 Example: LOC
Approach

Average productivity for systems of this type = 620 LOC/pm.

Burdened labor rate =$8000 per month, the cost per line of code is
approximately $13.
Based on the LOC estimate and the historical productivity data, the
total estimated project cost is $431,000 and the estimated effort is 54
person-months.

Unit 3
Example: FP
Approach

The estimated number of FP is derived:

FPestimated = count-total 3 [0.65 + 0.01 3 S (Fi)]
FPestimated = 375
organizational average productivity = 6.5 FP/pm.
burdened labor rate = $8000 per month, approximately $1230/FP.
Based on the FP estimate and the historical productivity data, total
estimated project cost is $461,000 and estimated effort is 58 person-
months.

Unit 3
Process-Based Estimation

Obtained from “process framework”

framework activities

application Effort required to

functions accomplish
each framework
activity for each
application function

Unit 3
Process-Based Estimation Example

Activity Risk Construction

CC Planning Analysis Engineering Release CE Totals
Task analysis design code test

Function

UICF 0.50 2.50 0.40 5.00 n/a 8.40

2DGA 0.75 4.00 0.60 2.00 n/a 7.35
3DGA 0.50 4.00 1.00 3.00 n/a 8.50
CGDF 0.50 3.00 1.00 1.50 n/a 6.00
DSM 0.50 3.00 0.75 1.50 n/a 5.75
PCF 0.25 2.00 0.50 1.50 n/a 4.25
DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals 0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

% effort 1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

Based on an average burdened labor rate of $8,000 per

month, the total estimated project cost is $368,000 and the
estimated effort is 46 person-months.
Unit 3
Tool-Based Estimation

project characteristics

calibration factors

LOC/FP data

Unit 3
Use-Case–Oriented Metrics
 Like FP, the use case is defined early in the software process,
allowing it to be used for estimation before significant modeling
and construction activities are initiated.
 Use cases describe (indirectly, at least) user-visible functions and
features that are basic requirements for a system. The use case is
independent of programming language.
 Because use cases can be created at vastly different levels of
abstraction, there is no standard “size” for a use case.
 Without a standard measure of what a use case is, its application
as a normalization measure (e.g., effort expended per use case) is
suspect.

Unit 3
Empirical Estimation Models
General form:

exponent
effort = tuning coefficient * size

usually derived
as person-months empirically
of effort required derived

usually LOC but

may also be
function point
either a constant or
a number derived based
on complexity of project

Unit 3
COCOMO (constructive cost
model)-II
 COCOMO II is actually a hierarchy of estimation models that address the
following areas:

Application composition model. Used during the early stages of
software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are
paramount.

Early design stage model. Used once requirements have been
stabilized and basic software architecture has been established.

Post-architecture-stage model. Used during the construction of the
software.

Unit 3
 The Software Equation

A dynamic multivariable model

E = [LOC x B0.333/P]3 x (1/t4)

where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”

Unit 3
 The basic COCOMO model gives an approximate estimate of the project
parameters. The basic COCOMO estimation model is given by following
expressions:
Effort = a1 x (KLOC)a2 PM (person Month)
Time of Development = b1 x (Effort) b2 Months
Where, a1,a2,b1,b2 are constants for each category of software
products
Estimation of Effort
 Organic: Effort = 2.4 (KLOC) 1.05 PM
 Semi-detached: Effort = 3.0 (KLOC) 1.12 PM
 Embedded: Effort = 3.6 (KLOC) 1.20 PM
Estimation Time of Development
 Organic: Time of Development = 2.5 (Effort) 0.38 Months
 Semi-detached: Time of Development = 2.5 (Effort) 0.35 Months
 Embedded: Time of Development = 2.5 (Effort) 0.32 Months

Unit 3
 Organic, Semidetached and Embedded
software projects

Organic: A development project can be considered of organic type, if

the project deals with developing a well understood application
program, the size of the development team is reasonably small, and
the team members are experienced in developing similar types of
projects.

Semidetached: A development project can be considered of

semidetached type, if the development consists of a mixture of
experienced and inexperienced staff. Team members may have
limited experience on related systems but may be unfamiliar with
some aspects of the system being developed.

Embedded: A development project is considered to be of embedded

type, if the software being developed is strongly coupled to complex
Example:
Assume that the size of an organic s/w product has been estimated to
be 32,000 lines of source code. Assume that the average salary of
software be Rs. 15,000/- month. Determine the effort required to
develop the software product and the nominal development time.
 Effort= 2.4 x (32) 1.05 = 91 PM
 Time of development = 2.5 x (91) 0.38 = 14 months
 Cost= 14 x 15,000 = Rs. 2,10,000/-

Unit 3
Project scheduling &
Tracking
 The scheduling principles:

 compartmentalization—define distinct tasks

 interdependency—indicate task interrelationship

 effort validation—be sure resources are available

 defined responsibilities—people must be assigned

 defined outcomes—each task must have an output

 defined milestones—review for quality

Unit 3
Effort and Delivery Time

Effort
Cost
Ea = m (td4 / ta4)

Impossible Ea = effort in person-months

region td = nominal delivery time for schedule
to = optimal development time (in terms of cost)
ta = actual delivery time desired
Ed

Eo

td to development time
Tmin = 0.75T d

Unit 3
Effort Allocation

 “front end” activities


customer
40-50% communication

analysis

design

review and
modification
 construction activities
15-20%  coding or code
generation
 testing and installation

unit, integration

white-box, black box
30-40% 
regression

Unit 3
Defining Task
Sets
 determine type of project
 assess the degree of rigor required
 identify adaptation criteria
 select appropriate software engineering tasks

Unit 3
Task Set
Refinement
1.1 Concept scoping determines the overall
scope of the project.
Task definition: Task 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 FTR: Review written description of need
FTR indicates that a formal technical review (Chapter 26) is to be conducted.
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 FTR: Review outputs/inputs with customer and revise as required;
endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 FTR: Review output and input data objects derived in task 1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 FTR: Review functions/behaviors with customer and revise as
required;
endtask Task 1.1.3
is refined to 1.1.4 Isolate those elements of the technology to be implemented in software;
1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a Scope Definition;
endTask definition: Task 1.1

Unit 3
Define a Task
Network
I.5a
I.3a
Concept
Tech. Risk
Implement.
Assessment

I.1 I.2 I.3b I.4 I.5b I.6

Proof of Concept Integrate Customer
Concept Concept Tech. Risk
Implement. a, b, c Reaction
scoping planning Assessment Concept

I.3c I.5c
Tech. Risk Concept
Assessment Implement.

Three I.3 tasks are Three I.3 tasks are

applied in parallel to applied in parallel to
3 different concept 3 different concept
functions functions

Unit 3
Timeline Charts

Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Tas
k4 5
Task
Task 6
Task 7
Task 8
Task 9
Task 10
Task
11 12
Task

Unit 3
Use Automated Tools to
Derive a Timeline Chart
Work tasks week 1 week 2 week 3 week 4 week 5

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

Unit 3
Schedule Tracking
 conduct periodic project status meetings in which each team
member reports progress and problems.
 evaluate the results of all reviews conducted throughout the
software engineering process.
 determine whether formal project milestones (the diamonds) have
been accomplished by the scheduled date.
 compare actual start-date to planned start-date for each project
task listed in the resource table.
 meet informally with practitioners to obtain their subjective
assessment of progress to date and problems on the horizon.
 use earned value analysis to assess progress quantitatively.
Unit 3
Earned Value Analysis (EVA)
 Earned value
 is a measure of progress
 enables us to assess the “percent of completeness” of a
project using quantitative analysis rather than rely on a
gut feeling
 “provides accurate and reliable readings of performance
from as early as 15 percent into the project.” [Fle98]

Unit 3
Progress on an OO Project-I
 Technical milestone: OO analysis completed

All classes and the class hierarchy have been defined and reviewed.

Class attributes and operations associated with a class have been defined
and reviewed.

Class relationships have been established and reviewed.

A behavioral model has been created and reviewed.

Reusable classes have been noted.

 Technical milestone: OO design completed


The set of subsystems has been defined and reviewed.

Classes are allocated to subsystems and reviewed.

Task allocation has been established and reviewed.

Responsibilities and collaborations have been identified.

Attributes and operations have been designed and reviewed.

The communication model has been created and reviewed.
Progress on an OO Project-II
 Technical milestone: OO programming completed

Each new class has been implemented in code from the design
model.

Extracted classes (from a reuse library) have been implemented.

Prototype or increment has been built.
 Technical milestone: OO testing

The correctness and completeness of OO analysis and design
models has been reviewed.

A class-responsibility-collaboration network (Chapter 6) has been
developed and reviewed.

Test cases are designed and class-level tests (Chapter 19) have
been conducted for each class.

Test cases are designed and cluster testing (Chapter 19) is
completed and the classes are integrated.
Computing Earned Value-I
 The budgeted cost of work scheduled (BCWS) is determined
for each work task represented in the schedule.
 BCWSi is the effort planned for work task i.

 To determine progress at a given point along the project

schedule, the value of BCWS is the sum of the BCWSi values for
all work tasks that should have been completed by that point
in time on the project schedule.
 The BCWS values for all work tasks are summed to derive
the budget at completion, BAC. Hence,

BAC = ∑ (BCWS ) for all tasks k

Computing Earned Value-II
 Next, the value for budgeted cost of work performed (BCWP) is
computed.
 The value for BCWP is the sum of the BCWS values for all work tasks
that have actually been completed by a point in time on the project
schedule.

 “the distinction between the BCWS and the BCWP is that the
former represents the budget of the activities that were planned to
be completed and the latter represents the budget of the activities
that actually were completed.” [Wil99]
 Given values for BCWS, BAC, and BCWP, important progress
indicators can be computed:

Schedule performance index, SPI = BCWP/BCWS

Schedule variance, SV = BCWP – BCWS
Computing Earned Value-III
 Percent scheduled for completion = BCWS/BAC
 provides an indication of the percentage of work that should have been
completed by time t.

 Percent complete = BCWP/BAC

 provides a quantitative indication of the percent of completeness of the
project at a given point in time, t.
 Actual cost of work performed, ACWP, is the sum of the effort
actually expended on work tasks that have been completed by a
point in time on the project schedule. It is then possible to
compute

Cost performance index, CPI = BCWP/ACWP

Cost variance, CV = BCWP – ACWP
Unit 3
Risk management
 A risk is a potential problem – it might happen and it might not
 Conceptual definition of risk

– Risk concerns future happenings

– Risk involves change in mind, opinion, actions, places, etc.

– Risk involves choice and the uncertainty that choice entails

 Two characteristics of risk:
 Uncertainty – the risk may or may not happen, that is, there
are no 100% risks (those, instead, are called constraints)
 Loss – the risk becomes a reality and unwanted consequences
or losses occur

Unit 3
Categories of Risk
 Project risks
– They threaten the project plan . If they become real, it is likely that
the project schedule will slip and that costs will increase.
 Technical risks
– They threaten the quality and timeliness of the software to be
produced. If they become real, implementation may become difficult or
impossible
 Business risks
-They threaten the feasibility of the software to be built. If they
become real, they threaten the project or the product
 Known risks
– Those risks that can be uncovered after careful evaluation of the
project plan, the business and technical environment in which the project is
being developed, and other reliable
Unit 3information sources (e.g., unrealistic
Contd…
 Predictable risks
– Those risks that are deduced from past project
experience (e.g., past turnover)
 Unpredictable risks
– Those risks that can and do occur, but are
extremely difficult to identify in advance

Unit 3
Sub-Categories of risk
 Market risk – building an excellent product or system that
no one really wants
 Strategic risk – building a product that no longer fits into
the overall business strategy for the company
 Sales risk – building a product that the sales force doesn’t
understand how to sell
 Management risk – losing the support of senior
management due to a change in focus or a change in
people
 Budget risk – losing budgetary or personnel commitment
Unit 3
Risk Identification
 One method for identifying risks is to create a risk item
checklist.
 The checklist can be used for risk identification and focuses
on some subset of known and predictable risks in the
following generic subcategories:
 Product size—risks associated with the overall size of the
software to be built or modified.
 Business impact—risks associated with constraints
imposed by management or the marketplace.
 Stakeholder characteristics—risks associated with the
sophistication of the stakeholders and the developer’s
Contd…
 Process definition—risks associated with the degree to
which the software process has been defined and is followed
by the development organization.
 Development environment—risks associated with the
availability and quality of the tools to be used to build the
product.
 Technology to be built—risks associated with the complexity
of the system to be built and the “newness” of the
technology that is packaged by the system.
 Staff size and experience—risks associated with the overall
technical and project experience of the software engineers
Unit 3
Assessing Project Risk
 Have top software and customer managers formally
committed to support the project?
 Are end-users enthusiastically committed to the project and
the system/product to be built?
 Are requirements fully understood by the software
engineering team and their customers?
 Have customers been involved fully in the definition of
requirements?
 Do end-users have realistic expectations?

Unit 3
Contd..
 Is project scope stable?
 Does the software engineering team have the right mix of
skills?
 Are project requirements stable?
 Does the project team have experience with the technology
to be implemented?
 Is the number of people on the project team adequate to do
the job?
 Do all customer/user constituencies agree on the
importance of the project and on the requirements for the
system/product to be built?Unit 3
Risk Components
 performance risk—the degree of uncertainty that the
product will meet its requirements and be fit for its
intended use.
 cost risk—the degree of uncertainty that the project budget
will be maintained.
 support risk—the degree of uncertainty that the resultant
software will be easy to correct, adapt, and enhance.
 schedule risk—the degree of uncertainty that the project
schedule will be maintained and that the product will be
delivered on time.
Unit 3
Risk Projection
 Steps of Risk Projection/risk estimation are as follows:
1. Establish a scale that reflects the perceived likelihood of a
risk (e.g., 1-low, 10-high)
2. Explain the consequences of the risk
3. Estimate the impact of the risk on the project and product
4. Note the overall accuracy of the risk projection so that
there will be no misunderstandings

Unit 3
Building a Risk Table

Risk Probability Impact RMMM

Risk
Mitigation
Monitoring
&
Management

Unit 3
Building the Risk Table

 Estimate the probability of

occurrence
 Estimate the impact on the project
on a scale of 1 to 5, where
 1 = low impact on project success
 5 = catastrophic impact on project
success Unit 3
Risk Exposure (Impact)

The overall risk exposure, RE, is

determined using the following
relationship [Hal98]:
RE = P x C
where
P is the probability of occurrence for
a risk, and
C is the cost to the project should the
risk occur.

Unit 3
Risk Exposure Example
 Risk identification. Only 70 percent of the software components
scheduled for reuse will, in fact, be integrated into the application.
The remaining functionality will have to be custom developed.
 Risk probability. 80% (likely).
 Risk impact. 60 reusable software components were planned. If
only 70 percent can be used, 18 components would have to be
developed from scratch (in addition to other custom software that
has been scheduled for development). Since the average
component is 100 LOC and local data indicate that the software
engineering cost for each LOC is $14.00, the overall cost (impact)
to develop the components would be 18 x 100 x 14 = $25,200.
 Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
 Risk Mitigation, Monitoring, and
Management
 Risk mitigation (proactive planning for risk avoidance)
 Risk monitoring (assessing whether predicted risks occur or
not, ensuring risk aversion steps are being properly applied,
collect information for future risk analysis, attempt to
determine which risks caused which problems)
 Risk management and contingency planning (actions to be
taken in the event that mitigation steps have failed and the
risk has become a live problem)
 The goal of the risk mitigation, monitoring and
management plan is to identify as many potential risks as
possible. Unit 3
Contd…
 When all risks have been identified, they will then be
evaluated to determine their probability of occurrence.
 Plans will then be made to avoid each risk, to track each
risk to determine if it is more or less likely to occur, and to
plan for those risks should they occur.
 It is the organization’s responsibility to perform risk
mitigation, monitoring, and management in order to
produce a quality product.
 The quicker the risks can be identified and avoided, the
smaller the chances of having to face that particular risk’s
consequence.
Unit 3
Risk Mitigation
 To mitigate this risk, you would develop a strategy for
reducing turnover.
 Among the possible steps to be taken are:
i. Meet with current staff to determine causes for
turnover (e.g., poor working conditions, low pay, and
competitive job market).
ii. Mitigate those causes that are under your control
before the project starts.
iii. Once the project commences, assume turnover will
occur and develop techniques to ensure continuity when
people leave. Unit 3
Contd…
iv. Organize project teams so that information
about each development activity is widely
dispersed.
v. Define work product standards and establish
mechanisms to be sure that all models and
documents are developed in a timely manner.
vi. Conduct peer reviews of all work (so that more
than one person is “up to speed”).
vii. Assign a backup staff member for every critical
Unit 3
Risk Monitoring
 The project manager monitors factors that may provide an
indication of whether the risk is becoming more or less likely.
 In the case of high staff turnover, the general attitude of team
members based on project pressures, the degree to which the
team has jelled, inter-personal relationships among team
members, potential problems with compensation and benefits,
and the availability of jobs within the company and outside it are
all monitored.
 In addition to monitoring these factors, a project manager should
monitor the effectiveness of risk mitigation steps.
 The project manager should monitor work products carefully to
ensure that each can stand on its own and that each imparts
information that would be necessary if a newcomer were forced to
Risk Management
 Risk management and contingency planning assumes that
mitigation efforts have failed and that the risk has become
a reality.
 If the mitigation strategy has been followed, backup is
available, information is documented, and knowledge has
been dispersed across the team.
 In addition, you can temporarily refocus resources (and
readjust the project schedule) to those functions that are
fully staffed, enabling newcomers who must be added to
the team to “get up to speed.” Those individuals who are
leaving are asked to stopUnitall
3 work and spend their last
Risk Due to Product Size

Attributes that affect risk:

• estimated size of the product in LOC or FP?

• estimated size of product in number of programs,

files, transactions?

• percentage deviation in size of product from

average for previous products?

• size of database created or used by the product?

• number of users of the product?

• number of projected changes to the requirements

for the product? before delivery? after delivery?

• amount of reused software?

Unit 3
Risk Due to Business Impact
Attributes that affect risk:
• affect of this product on company revenue?
• visibility of this product by senior management?
• reasonableness of delivery deadline?
• number of customers who will use this product
• interoperability constraints
• sophistication of end users?
• amount and quality of product documentation that
must be produced and delivered to the customer?
• governmental constraints
• costs associated with late delivery?
• costs associated with a defective product?

Unit 3
Risks Due to the Customer

Questions that must be answered:

• Have you worked with the customer in the past?
• Does the customer have a solid idea of requirements?
• Has the customer agreed to spend time with you?
• Is the customer willing to participate in reviews?

• Is the customer technically sophisticated?

• Is the customer willing to let your people do their

job—that is, will the customer resist looking over your
shoulder during technically detailed work?
• Does the customer understand the software
engineering process?

Unit 3
Risks Due to Process
Maturity
Questions that must be answered:
• Have you established a common process framework?
• Is it followed by project teams?
• Do you have management support for
software engineering
• Do you have a proactive approach to SQA?
• Do you conduct formal technical reviews?
• Are CASE tools used for analysis, design and
testing?
• Are the tools integrated with one another?
• Have document formats been established?

Unit 3
Technology Risks
Questions that must be answered:
• Is the technology new to your organization?
• Are new algorithms, I/O technology required?
• Is new or unproven hardware involved?
• Does the application interface with new software?
• Is a specialized user interface required?
• Is the application radically different?
• Are you using new software engineering methods?
• Are you using unconventional software development
methods, such as formal methods, AI-based approaches,
artificial neural networks?
• Are there significant performance constraints?
• Is there doubt the functionality requested is "do-able?"

Unit 3
RMMM Plan
 A risk management strategy can be included in the
software project plan, or the risk management steps can be
organized into a separate risk mitigation, monitoring and
management plan (RMMM Plan)
 This plan documents all work performed as part of risk
analysis and is used by the project manager as a part of
overall project plan.
 Some software teams do not develop a formal RMMM
document , rather the risk is documented individually using
a risk information sheet (RIS).
Unit 3
Contd…
 RIS includes:
1. Risk ID
2. Date
3. Probability
4. Impact
5. Description
6. Refinement
7. Mitigation / Monitoring
8. Management / contigency plan / trigger
9. Current status

Unit 3
RIS Sample

Unit 3