SOFTWARE ENGINEERING

SEN-22413

UNIT-IV
SOFTWARE PROJECT ESTIMATION

Mr. Naresh A. Kamble

 POINTS TO BE COVERED
• THE MANAGEMENT SPECTRUM – 4Ps

• METRICS FOR SIZE ESTIMATION

• PROJECT COST ESTIMATION APPROACHES

• COCOMO

• RISK MANAGEMENT
 MANAGEMENT SPECTRUM

• Effective software project management focuses on 4 Ps.

• PEOPLE

• PRODUCT

• PROCESS

• PROJECT

• The successful project management is done with the help of these 4

factors.

• Project manager has to motivate the communication between

stakeholders.
 MANAGEMENT SPECTRUM

• THE PEOPLE

• It is important issue in software industry.

• There is strong need for motivated and highly skilled people for developing
the software product.

• The SOFTWARE ENGINEERING INSTITUTE (SEI) has developed the PEOPLE

MANAGEMENT CAPABILITY MATURITY MODEL (PM-CMM).

• By using this PM-CMM model software organizations become capable for

undertaking complex applications which ultimately attracts or motivates
the talented people.
 MANAGEMENT SPECTRUM

• KEY PRACTICE AREAS FOR SOFTWARE PEOPLE

• RECRUITMENT

• SELECTION

• PERFORMANCE MANAGEMENT

• TRAINING COMPENSATION

• CAREER DEVELOPMENT

• ORGANIZATION AND WORK DESIGN

• CULTURE DEVELOPMENT
 MANAGEMENT SPECTRUM

• THE PRODUCT

• Before planning the project 3 important tasks needs to be

done.

• Product objectives and scope must be established.

• Alternative solutions should be considered.

• Technical and management constraints must be identified.

 MANAGEMENT SPECTRUM

• There should be communication between developer and customer.

• The scope of the project identifies primary data, functions and

behavior of the product.

• After establishing the objectives and scope of the product the

alternative solutions are considered.

• Finally the constraints imposed by

– Delivery deadline

– Budget restrictions

– Personal availability
 MANAGEMENT SPECTRUM

• THE PROCESS

• The process provides the framework from which software

development plan can be established.

• Various framework activities that needs to carried out are

mentioned.

• Different set-tasks, milestones, work products and quality

assurance points enable framework activities.

• Finally the umbrella activities such as software quality assurance

(SQA) & software configuration management (SCM) are conducted.
 MANAGEMENT SPECTRUM

• THE PROJECT

• For a successful software project, it is necessary to

understand the mistakes in the project and how to correct
them.

• There are 10 symptoms to indicate why the software project

fails.
 Change
Understanding Scope of project
management not
customer needs not defined
done properly

Change in Technological Non-cooperative

business needs Changes users

Unrealistic Lack of skilled

No sponsorship
deadlines people

No adaption of
best practices
 METERICS FOR SIZE ESTIMATION

METRICS FOR SIZE

ESTIMATION

FUNCTION POINT
LOC BASED
BASED
ESTIMATION
ESTIMATION
 METERICS FOR SIZE ESTIMATION

• LOC BASED ESTIMATION

• LOC stands for Line of Code.

• Size oriented measure is derived by considering the size of

software that has been produced.

• The organization builds a simple measure for software

projects.

• It is built on past experiences of organizations.

 METERICS FOR SIZE ESTIMATION

IT IS DIRECRT MEASURE OF SOFTWARE

DOC(pgs
PROJECT LOC EFFORTS COST ($) ERRORS DEFECTS PEOPLE
.)

ABC 10,000 20 170 400 100 12 4

POR 20,000 60 300 1000 129 32 6

XYZ 35,000 65 522 1290 280 87 7

----- ----- ----- ----- ----- ----- ----- -----

 METERICS FOR SIZE ESTIMATION

• MEASURING SIZE

• Size = Kilo Lines of Code (KLOC)

• Efforts = Person/month

• Productivity = KLOC / person-month

• Quality = Number of faults / KLOC

• Cost = $/KOLC

• Documentation = Pages of documentation KLOC

 METERICS FOR SIZE ESTIMATION

• Size measure is based on Line of Code.

• While counting the LOC a simple standard is measured:

• Don’t count blank lines.

• Don’t count comments.

• Count everything else.

 METERICS FOR SIZE ESTIMATION

• FUNCTION POINTS

• The software product is developed based on functionalities.

• The function points are derived using:

• Countable measures of the software requirements domain.

• Assessments of the software complexity.

 METERICS FOR SIZE ESTIMATION

• HOW TO CALCULATE FUNCTION POINTS?

• NUMBER OF USER INPUTS

• NUMBER OF USER OUTPUTS

• NUMBER OF USER INQUIRIES

• NUMBER OF FILES

• NUMBER OF EXTERNAL INTERFACES

 WEIGNTING FACTOR
DOMAIN
COUNT X COUNT
CHARACTERISTICS
SIMPLE AVERAGE COMPLEX

NUMBER OF USER INPUT X 3 4 6

NUMBER OF USER
X 4 5 7
OUTPUTS

NUMBER OF USER
X 3 4 6
INQUIRIES

NUMBER OF FILES X 7 10 15

NUMBER OF EXTERNAL
X 5 7 10
INTERFACES

COUNT TOTAL
 METERICS FOR SIZE ESTIMATION

Function Points (FP) = Count total x(0.65 + (0.01 x Sum(Fi))

• Once the FP is calculated then we can compute other

measures

• Productivity = FP / person-month

• Quality = Number of faults / FP

• Cost = $/FP

• Documentation = Pages of documentation FP

 METERICS FOR SIZE ESTIMATION

EXAMPLE

• Study of requirements specifications for ABC project has

produced following results: Need for 7 inputs , 10 outputs, 6
inquiries, 17 files and 4 external interfaces. Input and external
interface function point attributes are of average complexity
and all other function points attributes are of low complexity.
Determine adjusted function points assuming complexity
adjustment value is 32.
 WEIGNTING FACTOR
MEASUREMENT
COUNT X COUNT
PARAMETERS
SIMPLE AVERAGE COMPLEX

NUMBER OF USER INPUT 7 X ---- 4 ---- 28

NUMBER OF USER
10 X 4 ---- ---- 40
OUTPUTS

NUMBER OF USER
6 X 3 ---- ---- 18
INQUIRIES

NUMBER OF FILES 17 X 7 ---- ---- 119

NUMBER OF EXTERNAL
4 X ---- 7 ---- 28
INTERFACES

COUNT TOTAL 233

 METERICS FOR SIZE ESTIMATION

Function Points (FP) = Count total x(0.65 + (0.01 x Sum(Fi))

= 233 x (0.65 + 0.01 x 32)

= 233 x (0.65 + 032)

= 233 x 0.97

FP = 226.0.1

Hence the adjusted function point is 226.01

 PROJECT COST ESTIMATION APPROACHES

COST ESTIMATION APPROACHES

HEURISTICS EMPIRICAL ANALYTICAL

TECHNIQUES TECHNIQUES TECHNIQUES
 PROJECT COST ESTIMATION APPROACHES

• HEUTRISTIC TECHNIQUE
• Heuristic word is derived from a Greek word that means “to discover”.

• The heuristic technique is a technique or model that is used for solving

problems, learning, or discovery in the practical methods which are used
for achieving immediate goals.

• These techniques are flexible and simple for taking quick decisions
through shortcuts and good enough calculations, most probably when
working with complex data.
 PROJECT COST ESTIMATION APPROACHES

• HEUTRISTIC TECHNIQUE
• But the decisions that are made using this technique are necessary to be
optimal.

• In this technique, the relationship among different project parameters is

expressed using mathematical equations.

• This technique is also used to increase or speed up the analysis and

investment decisions.
 PROJECT COST ESTIMATION APPROACHES

• EMPIRICAL TECHNIQUE
• Empirical estimation is a technique or model in which empirically derived
formulas are used for predicting the data that are a required and essential
part of the software project planning step.

• These techniques are usually based on the data that is collected previously
from a project and also based on some guesses, prior experience with the
development of similar types of projects, and assumptions.

• It uses the size of the software to estimate the effort.

• For example Delphi technique and Expert Judgement technique.

 PROJECT COST ESTIMATION APPROACHES

• ANALYTICAL TECHNIQUE
• Analytical estimation is a type of technique that is used to measure work.

• In this technique, firstly the task is divided or broken down into its basic
component operations or elements for analyzing.

• Second, if the standard time is available from some other source, then
these sources are applied to each element or component of work.

• Third, if there is no such time available, then the work is estimated based
on the experience of the work.

• In this technique, results are derived by making certain basic assumptions

about the project.
 COCOMO

• DEFINITION

• The COCOMO (Constructive Cost Model) is one of the most

popularly used software cost estimation models i.e. it
estimates or predicts the effort required for the project, total
project cost and scheduled time for the project.

• This model depends on the number of lines of code for

software product development.

• It was developed by a software engineer Barry Boehm in

1981.
 COCOMO

• WHAT IS COCOMO MODEL?

• The COCOMO estimates the cost for software product development in
terms of effort (resources required to complete the project work) and
schedule (time required to complete the project work) based on the size
of the software product.

• It estimates the required number of Man-Months (MM) for the full

development of software products.

• According to COCOMO, there are three modes of software development

projects that depend on complexity.
 COCOMO

• ORGANIC PROJECT

• It belongs to small & simple software projects which are

handled by a small team with good domain knowledge and
few rigid requirements.

• Example: Small data processing or Inventory management

system.
 COCOMO

• SEMI-DEATCHED PROJECT

• It is an intermediate (in terms of size and complexity) project,

where the team having mixed experience (both experience &
inexperience resources) to deals with rigid/nonrigid
requirements.

• Example: Database design or OS development.

 COCOMO

• EMBEDDED PROJECT

• This project having a high level of complexity with a large

team size by considering all sets of parameters (software,
hardware and operational).

• Example: Banking software or Traffic light control software.

 COCOMO

TYPES OF COCOMO MODEL

INTERMEDIATE DETAILED
BASIC MODEL
MODEL MODEL
 COCOMO

• BASIC MODEL

• It is the one type of static model to estimates software

development effort quickly and roughly.

• It mainly deals with the number of lines of code and the level
of estimation accuracy is less as we don’t consider the all
parameters belongs to the project.
 COCOMO

• The estimated effort and scheduled time for the project are given by the
relation:

Effort (E) = a*(KLOC)b PM

Scheduled Time (D) = c*(E)d Months (M)

• Where,

• E = Total effort required for the project in Person-Months (PM).

• D = Total time required for project development in Months (M).

• KLOC = the size of the code for the project in Kilo lines of code.

• a, b, c, d = The constant parameters for a software project.

 COCOMO

SOFTWARE PROJECTS a b c d

ORGANIC 2.4 1.05 2.5 0.38

SEMI-DETACHED 3.0 1.12 2.5 0.35

EMBEDDED 3.6 1.20 2.5 0.32

 COCOMO

• Consider a software project using semi-detached mode with

30,000 LOC.

• Effort Estimation

• Effort (E) = a*(KLOC)b PM

• Effort (E) = 3.0 (30)1.12

• Effort (E) = 135 PM

 COCOMO
• Effort Estimation

• Scheduled Time (D) = c*(E)d Months (M)

• Scheduled Time (D) = 2.5*(135)0.35

• Scheduled Time (D) = 14 Months (M)

• Person Estimation

• Person (P) = E/D

• Person (P) = 135/14 = 10

 COCOMO

• INTERMEDIATE MODEL

• The intermediate model estimates software development

effort in terms of size of the program and other related cost
drivers parameters (product parameter, hardware parameter,
resource parameter, and project parameter) of the project.
 COCOMO
• The estimated effort and scheduled time are given by the relationship:

Effort (E) = a*(KLOC)b *EAF PM

Scheduled Time (D) = c*(E)d Months (M)

• Where,

• E = Total effort required for the project in Man-Months (MM).

• D = Total time required for project development in Months (M).

• KLOC = The size of the code for the project in Kilo lines of code.

• a, b, c, d = The constant parameters for the software project.

• EAF = It is an Effort Adjustment Factor, which is calculated by multiplying

the parameter values of different cost driver parameters.

• For ideal, the value is 1.

 RATINGS
COST DRIVEN VERY VERY EXTRA
LOW NOMINAL HIGH
LOW HIGH HIGH
PRODUCT ATTRIBUTE
Required Software
0.75 0.88 1.00 1.15 1.40
Reliability
Size of application
0.94 1.00 1.08 1.16
database
Complexity of Software 0.70 0.85 1.00 1.15 1.30 1.65
HARDWARE ATTRIBUTE
Runtime performance
1.00 1.11 1.30 1.66
constraints
Memory constraints 1.00 1.06 1.21 1.56
Volatility of Virtual
0.87 1.00 1.15 1.30
Machine
Computer turnabout
0.87 1.00 1.07 1.15
time
 RATINGS
COST DRIVEN VERY VERY EXTRA
LOW NOMINAL HIGH
LOW HIGH HIGH
PRESONNEL ATTRIBUTE
Analyst capability 1.46 1.19 1.00 0.86 0.71
S/W engg. Capability 1.42 1.17 1.00 0.86 0.70
Application experience 1.29 1.13 1.00 0.91 0.82
Virtual machine
1.21 1.10 1.00 0.90
experience
Programming language
1.14 1.07 1.00 0.95
experience
PROJECT ATTRIBUTE
Use of software tool 1.24 1.10 1.00 0.91 0.82
Application of S/W
1.24 1.10 1.00 0.91 0.83
engg. Methods
Required development
1.23 1.08 1.00 1.04 1.10
schedule
 COCOMO

• Example: For a given project was estimated with a size of 300 KLOC.
Calculate the Effort, Scheduled time for development by considering
developer having high application experience and very low experience in
programming.

• EAF = 0.82*1.14 = 0.9348

• Effort (E) = a*(KLOC)b *EAF = 3.0*(300)1.12 *0.9348 = 1668.07 PM

• Scheduled Time (D) = c*(E)d = 2.5*(1668.07)0.35 = 33.55 Months (M)

 COCOMO

• DETAILED MODEL

• It is the advanced model that estimates the software

development effort like Intermediate COCOMO in each stage
of the software development life cycle process.
 COCOMO

• PHASES IN DETAILED MODEL

• REQUIREMENT PLANNING AND PRODUCT DESIGN (RPD).

• DETAILED DESIGN (DD).

• CODE AND UNIT TEST (CUT).

• INTEGRATE AND TEST (IT).

PHASES VERY LOW LOW NOMINAL HIGH VERY HIGH

RPD 1.80 0.85 1.00 0.75 0.55

DD 1.35 0.85 1.00 0.90 0.75

CUT 1.35 0.85 1.00 0.90 0.75

IT 1.50 1.20 1.00 0.85 0.70

 COCOMO

• ADVANTAGES OF COCOMO MODEL

• Easy to estimate the total cost of the project.

• Easy to implement with various factors.

• Provide ideas about historical projects.

• DISADVANTAGES OF COCOMO MODEL

• It ignores requirements, customer skills, and hardware issues.

• It limits the accuracy of the software costs.

• It mostly depends on time factors.

 COCOMO-II

• COCOMO-II MODEL

• COCOMO-II is the revised version of the original COCOMO

(Constructive Cost Model) and is developed at University of
Southern California.

• It is the model that allows one to estimate the cost, effort and
schedule when planning a new software development activity.
 COCOMO-II
• THE SUB-MODELS IN COCOMO-II:

• APPLICATION COMPOSITION MODEL.

– Used when software is composed from existing parts.

• EARLY DESIGN MODEL.

– Used when requirements are available but design has not yet started.

• REUSE MODEL.
– Used to compute the effort of integrating reusable components.

• POST-ARCHITECTURE MODEL.
– Used once the system architecture has been designed and more information
about the system is available.
 COCOMO-II
• APPLICATION COMPOSITION MODEL

• Supports prototyping projects and projects where there is

extensive reuse.

• Based on standard estimates of developer productivity in

application (object) points/month.

• Takes CASE tool use into account.

 COCOMO-II
• FORMULA : Effort Computation in application composition
model

PM = ( NAP (1 - %reuse/100 ) ) / PROD

• WHERE,

• PM is the effort in person-months.

• NAP is the number of application points.

• PROD is the productivity.

Developers experience and VERY VERY
LOW NOMINAL HIGH
capability LOW HIGH

VERY VERY
CASE maturity LOW NOMINAL HIGH
LOW HIGH

Productivity
4 7 13 25 50
(NOP/months)
 COCOMO-II
• EARLY DESIGN MODEL

• This model is used in the early stage of the project

development.

• The estimation can be made based on the function points.

• In early stage of development different ways of implementing

user requirements can be estimated.
 COCOMO-II
• Effort estimation can be done by:

Effort = A x sizeB x M

• Where,

• A = 2.94 in initial calibration

• Size in KLOC

• B varies from 1.1 to 1.24 depending on the project.

 COCOMO-II
• M is based on

• Personnel Capability (PERS)

• Product reliability & complexity (RCPX)

• Reuse required (RUSE)

• Platform difficulty (PDIF)

• Personnel experience (PREX)

• Support facilities (FCIL)

• Schedule (SCED)
 COCOMO-II

• Hence Effort Estimation can be done as:

PM = A x sizeB x M

M = RUSE x PDIF x PERS x PREX x SCED x FCIL

 COCOMO-II
• THE REUSE MODEL

• Takes into account black-box code that is reused without change and code
that has to be adapted to integrate it with new code.

• There are two versions:

• Black-Box reuse where code is not modified. An effort estimate (PM) is

computed.

• White-Box reuse where code is modified. A size estimate equivalent to

the number of lines of new source code is computed. This then adjusts the
size estimate for new code.
 COCOMO-II
• The third category of code is generated automatically.

• The effort required for automatic generated code is:

PM = (ASLOC * AT/100)/ATPROD

• Where,

• ASLOC is the number of lines of generated code.

• AT is the percentage of code automatically generated.

• ATPROD is the productivity of engineers in integrating this

code.
 COCOMO-II
• When code has to be understood and integrated using
WHITE-BOX:

ESLOC = ASLOC * (1-AT/100) * AAM

• ASLOC and AT as before.

• AAM is the adaptation adjustment multiplier computed from

the costs of changing the reused code, the costs of
understanding how to integrate the code and the costs of
reuse decision making.
 COCOMO-II
• THE POST ARCHITECTURE MODEL

• Uses the same formula as the early design model but with 17 rather than
7 associated multipliers.

• The code size is estimated as:

• Number of lines of new code to be developed;

• Estimate of equivalent number of lines of new code computed using the

reuse model.

• An estimate of the number of lines of code that have to be modified

according to requirements changes.
 SCALE FACTOR FOR
DESCRIPTION
COMPONENT B

This factor is for previous experience of

organization. Very low means no previous
PRECEDENTEDNESS
experience and high means the organization knows
the application domain.

Flexibility in development process. Very low means

DEVELOPMENT
FLEXIBILITY the typical process is used. Extra high means client
is responsible for defining the process goals.

Amount of risk that is allowed to carry out. Very

ARCHITECTURE / RISK
RESOLUTION low means little risk analysis is permitted and extra
high means high risk analysis is made.
SCALE FACTOR FOR
DESCRIPTION
COMPONENT B

Represents the working environment of the team.

Very low cohesion means poor communication or
TEAM COHESION interaction between the team members and extra
high means there is no communication problem
and team can work in a good spirit.
This factor affects the process maturity of the
organization. This value can be computed using
PROCESS MATURITY Capacity Maturity Model (CMM) questionnaire, for
computing the estimates CMM maturity level can
be subtracted from 5.
 COCOMO-II
• All 5 scale factors are summed up and then divided by 100 and then added
to 1.01.

• A company takes on a project in a new domain. The client has not

defined the process to be used and has not allowed time for risk
analysis. The company has a CMM level 2 rating.
– Precedentedness - new project (4)

– Development flexibility - no client involvement - Very high (1)

– Architecture/risk resolution - No risk analysis - V. Low .(5)

– Team cohesion - new team - nominal (3)

– Process maturity - some control - nominal (3)

• 4 + 1 + 5 + 3 + 3 = 16/100 = 0.16 + 1.01 = 1.17.

 RISK MANAGEMENT
• DEFINITION OF RISK

• The risk denotes the uncertainty that may occur in the choices
due to past actions and risk is something which causes heavy
losses.

• DEFINITION OF RISK MANAGEMENT

• Risk management refers to the process of making decisions

based on an evaluation of the factors that threats to the
business.
 RISK MANAGEMENT
• VARIOUS ACTIVITIES THAT ARE CARRIED OUT FOR RISK
MANAGEMENT

• RISK IDENTIFICATION

• RISK ASSESSMENT

• RISK CONTATINMENT

• RMMM STRATEGY
 RISK MANAGEMENT
• CATEGORIES OF SOFTWARE RISK
• PROJECT RISKS

• Project risks concern differ forms of budgetary, schedule, personnel,

resource, and customer-related problems.

• A vital project risk is schedule slippage.

• Since the software is intangible, it is very tough to monitor and control a

software project.

• It is very tough to control something which cannot be identified.

• For any manufacturing program, such as the manufacturing of cars, the

plan executive can recognize the product taking shape.
 RISK MANAGEMENT
• CATEGORIES OF SOFTWARE RISK
• TECHNICAL RISKS

• Technical risks concern potential method, implementation, interfacing,

testing, and maintenance issue.

• It also consists of an ambiguous specification, incomplete specification,

changing specification, technical uncertainty, and technical obsolescence.

• Most technical risks appear due to the development team's insufficient

knowledge about the project.
 RISK MANAGEMENT
• CATEGORIES OF SOFTWARE RISK
• BUISNESS RISKS

• This type of risks contain risks of building an excellent product that no one
need, losing budgetary or personnel commitments, etc.

• Business risks can be further categorized as:

• MARKET RISK

• STRATEGIC RISK

• SALES RISK

• MANAGEMENT RISK

• BUDGET RISK
 RISK MANAGEMENT
• OTHER RISK CATEGORIES

• KNOWN RISKS

• Those risks that can be uncovered after careful assessment of

the project program, the business and technical environment
in which the plan is being developed, and more reliable data
sources (e.g., unrealistic delivery date)
 RISK MANAGEMENT
• OTHER RISK CATEGORIES

• PREDICTABLE RISKS

• Those risks that are hypothesized from previous project

experience (e.g., past turnover)

• UNPREDICTABLE RISKS

• Those risks that can and do occur, but are extremely tough to
identify in advance.
 RISK MANAGEMENT
• RISK MANAGEMENT ACTIVITIES

• RISK IDENTIFICATION

• It is defined as the effort taken to specify threats to the project

plan. Risks identification can be done by identifying the
known and predictable risks.

• It is based on 2 approaches:

• Generic Risk Identification

• Product-Specific Risk Identification

 PRODUCT SIZE

TECHNOLOGY BUISNESS
TO BUILT IMPACT

PREPARATION
OF RISK ITEM
STAFF SIZE &
EXPERIENCE
CHECK LIST CUSTOMER
CHARACTERISTICS

DEVELOPMENT PROCESS
ENVIRONMENT DEFINITION
 RISK MANAGEMENT
• CREATING RISK COMPONENTS AND DRIVERS LIST
• There are different types of risks which can affect a software project:

• Technology risks: Risks that assume from the software or hardware technologies
that are used to develop the system.

• People risks: Risks that are connected with the person in the development team.

• Organizational risks: Risks that assume from the organizational environment

where the software is being developed.

• Tools risks: Risks that assume from the software tools and other support software
used to create the system.

• Requirement risks: Risks that assume from the changes to the customer
requirement and the process of managing the requirements change.

• Estimation risks: Risks that assume from the management estimates of the
resources required to build the system.
 RISK MANAGEMENT
• RISK MANAGEMENT ACTIVITIES

• RISK PROJECTION

• It is also called as risk estimation.

• There are steps followed by project planner, technical staff, project

manager etc.

• Establish a scale that indicates the probability of risk being real.

• Enlist the consequences of the risk.

• Estimate the impact of the risk on the project & product.

• Maintain the overall accuracy of the risk projection in order to have clear
understanding of the software that is to be built.
 RISK MANAGEMENT
• RISK MANAGEMENT ACTIVITIES

• RISK ASSESSMENT

• The objective of risk assessment is to division the risks in the

condition of their loss, causing potential.

• For risk assessment, first, every risk should be rated in two

methods:

• The possibility of a risk coming true (denoted as r).

• The consequence of the issues relates to that risk (denoted as

s).
 RISK MANAGEMENT
• RISK ASSESSMENT

• Based on these two methods, the priority of each risk can be

estimated:

p=r*s

• Where,

• p is the priority with which the risk must be controlled.

• r is the probability of the risk becoming true.

• s is the severity of loss caused due to the risk becoming true.

 RISK ASSESSMENT
STEPS

RISK
RISK ANALYSIS RISK PRIORITIZED
IDENTIFICATION
SR.
RISK ITEM MANAGEMENT TECHNIQUES
NO.

Training the people, recruiting top talent people,

1 Personnel Shortfall
Key personnel agreement.

Unrealistic Schedule or Detailed schedule and cost estimation, Software

2
Budget reuse.

Developing wrong Making user survey, understanding the concepts,

3
functions adopting prototyping techniques.

Gold platting i.e. adding

4 Reviewing the requirements, prototyping.
features to project

Developing wrong user

5 Performing prototyping, task analysis
interface
SR.
RISK ITEM MANAGEMENT TECHNIQUES
NO.

Requirement changes
6 Incremental Development.
occur frequently

Shortfall in externally
7 Reference checking, auditing, prototyping.
done tasks

Shortfall in externally
8 Reference checking and inspections.
developed components

Real-Time performance
9 Simulation, Modelling, Prototyping.
shortfall

Straining computer Technical analysis, reference checking,

10
knowledge capability prototyping.
 RISK MANAGEMENT
• RISK ANALYSIS

• During the risk analysis process, you have to consider every

identified risk and make a perception of the probability and
seriousness of that risk.

• There is no simple way to do this. You have to rely on your

perception and experience of previous projects and the problems
that arise in them.

• It is not possible to make an exact, the numerical estimate of the

probability and seriousness of each risk.
 RISK MANAGEMENT
• RISK ANALYSIS

• Instead, you should authorize the risk to one of several bands:

• The probability of the risk might be determined as very low (0-

10%), low (10-25%), moderate (25-50%), high (50-75%) or very high
(+75%).

• The effect of the risk might be determined as catastrophic (threaten

the survival of the plan), serious (would cause significant delays),
tolerable (delays are within allowed contingency), or insignificant.
 RISK MANAGEMENT
• RISK PRIORITIZATION

• Risk exposure computing is done for prioritizing the risks.

• It is also called as risk impact.

• It is calculated as:

Risk exposure = Probability of occurrence of risk * Loss due to

unsatisfactory outcome
 RISK MANAGEMENT
• RISK MANAGEMENT ACTIVITIES

• RISK CONTAINMENT

• It means reduction of risks.

• The project manager & team will be able to identify strategies to

minimize or eliminate the risk factors.

• Example – If a project is facing high risk due to lack of experience in

development platform, then the recruiter or hiring expert contractor
can control this risk by hiring the skilled & experienced employee for
the desired project.
 RISK MANAGEMENT
• RISK MANAGEMENT ACTIVITIES

• RMMM STRATEGY

• A risk management technique is usually seen in the software

Project plan.

• This can be divided into Risk Mitigation, Monitoring, and

Management Plan (RMMM).

• In this plan, all works are done as part of risk analysis.

• As part of the overall project plan project manager generally uses

this RMMM plan.
 RMMM STRATEGIES

RISK RISK RISK

MITIGATION MONITORING MANAGEMENT
 RISK MANAGEMENT
• RISK MITIGATION

• It is an activity used to avoid problems (Risk Avoidance).

• Steps for mitigating the risks as follows.

• Finding out the risk.

• Removing causes that are the reason for risk creation.

• Controlling the corresponding documents from time to time.

• Conducting timely reviews to speed up the work.

 RISK MANAGEMENT
• RISK MONITORING

• It is an activity used for project tracking.

• It has the following primary objectives as follows.

• To check if predicted risks occur or not.

• To ensure proper application of risk aversion steps defined for

risk.

• To collect data for future risk analysis.

• To allocate what problems are caused by which risks

throughout the project.
 RISK MANAGEMENT
• RISK MANAGEMENT

• It assumes that the mitigation activity failed and the risk is a reality.

• This task is done by Project manager when risk becomes reality and causes
severe problems.

• If the project manager effectively uses project mitigation to remove risks

successfully then it is easier to manage the risks.

• This shows that the response that will be taken for each risk by a manager.

• The main objective of the risk management plan is the risk register.

• This risk register describes and focuses on the predicted threats to a

software project.