Unit-3

Managing Software
Projects
 Outline
Looping
 W5HH of Project Management
 Software Metrics
 Process, Product and Project Metrics
 Software Project Estimations
 Software Project Planning
 Project Scheduling and Tracking
 Risk Analysis and Management
 Risk Identification
 Risk Projection
 Risk Refinement
 Risk Mitigation
Software Project Management
W5HH of Project Management
Boehm suggests an approach (W5HH) that addresses project
objectives, milestones and schedules, responsibilities, management
and technical approaches, and required resources
Why is the system being developed?
Enables all parties to assess the validity of business reasons for the software
work. In another words - does the business purpose justify the expenditure of
people, time, and money?

What will be done?

The answers to these questions help the team to establish a project schedule
by identifying key project tasks and the milestones that are required by the
customer

When will it be accomplished?

Project schedule to achieve milestone
Unit 3 – Managing Software Projects 3
W5HH of Project Management Cont.
Who is responsible?
Role and responsibility of each member

Where are they organizationally located?

Customer, end user and other stakeholders also have responsibility

How will the job be done technically and managerially?

Management and technical strategy must be defined

How much of each resource is needed?

Develop estimation

W5HH
It is applicable regardless of size or complexity of
software project
Unit 3 – Managing Software Projects 4
Terminologies
 Measure  Indirect Metrics
 It provides a quantitative indication of the  Aspects that are not immediately quantifiable
extent (range), amount, dimension, capacity or  Ex., Functionality, Quality, Reliability
size of some attributes of a product or process
 Ex., the number of uncovered errors  Indicators
 It is a metric or combination of metrics that
 Metrics provides insight into the software process, project
 It is a quantitative measure of the degree or the product itself
(limit) to which a system, component or  It enables the project manager or software
process possesses (obtain) a given attribute engineers to adjust the process, the project or the
 It relates individual measures in some way product to make things better
 Ex., number of errors found per review  Ex., Product Size (analysis and specification
metrics) is an indicator of increased coding,
 Direct Metrics integration and testing effort
 Immediately measurable attributes
 Faults
 Ex., Line of Code (LOC), Execution Speed,
Defects Reported  Errors - Faults found by the practitioners during
software development
 Defects - Faults found by the customers after
release
Unit 3 – Managing Software Projects 5
Why to Measure Software?
1 To determine (to define) quality of a product or process.
2 To predict qualities of a product or process.
3 To improve quality of a product or process.
Metric Classification
Base
 Process
 Specifies activities related to production of software.
 Specifies the abstract set of activities that should be performed to go from user needs to final product.
 Project
 Software development work in which a software process is used
 The actual act of executing the activities for some specific user needs
 Product
 The outcomes of a software project
 All the outputs that are produced while the activities are being executed
Unit 3 – Managing Software Projects 6
Process Metrics
 Process Metrics are an invaluable tool for We measure the effectiveness of a process by
companies to monitor, evaluate and improve deriving a set of metrics based on outcomes
their operational performance across the of the process such as,
enterprise
Errors uncovered before release of the software
 They are used for making strategic decisions
 Process Metrics are collected across all Defects delivered to and reported by the end
users
projects and over long periods of time Work products delivered
 Their intent is to provide a set of process
Human effort expanded
indicators that lead to long-term software
process improvement Calendar time expanded

Conformance to the schedule

Ex., Defect Removal Efficiency (DRE)
metric Time and effort to complete each generic
Relationship between errors (E) and defects activity
(D)
The ideal is a DRE of 1 Unit 3 – Managing Software Projects 7
Project Metrics
 Project metrics enable a software project manager to,
 Assess the status of an ongoing project
 Track potential risks
 Uncover problem areas before their status becomes critical
 Adjust workflow or tasks
 Evaluate the project team’s ability to control quality of software work products
 Many of the same metrics are used in both the process and project domain
 Project metrics are used for making tactical (smart) decisions
 They are used to adapt project workflow and technical activities
 Project metrics are used to
 Minimize the development schedule by making the adjustments necessary to avoid delays
and mitigate (to reduce) potential (probable) problems and risks
 Assess (evaluates) product quality on an ongoing basis and guides to modify the technical
approach to improve quality
Unit 3 – Managing Software Projects 8
Product Metrics
 Product metrics help software engineers to gain insight into the design and construction
of the software they build
 By focusing on specific, measurable attributes of software engineering work products
 Product metrics provide a basis from which analysis, design, coding and testing can be
conducted more objectively and assessed more quantitatively
 Ex., Code Complexity Metric

Unit 3 – Managing Software Projects 9

Types of Measures
Categories of Software Measurement Software Measurement
Direct measures of the Indirect measures of Metrics for Software
Software process the
Software product Cost and Effort estimations
Ex., cost, effort, etc. Ex. functionality, quality, Size Oriented Metrics
complexity, efficiency,
Software product
reliability, etc. Function Oriented Metrics
Ex., lines of code produced,
execution speed, Object Oriented Metrics
defects reported, etc.
Use Case Oriented Metrics

Unit 3 – Managing Software Projects 10

Size-Oriented Metrics
 Derived by normalizing (standardizing) quality and/or productivity measures by
considering the size of the software produced
 Thousand lines of code (KLOC) are often chosen as the normalization value
A set of simple size-oriented metrics  Size-oriented metrics are not universally accepted
can be developed for each project as the best way to measure the software process
Errors per KLOC (thousand lines of code)
Defects per KLOC $ per KLOC Opponents argue that KLOC measurements
Pages of documentation per KLOC Are dependent on the programming language
In addition, other interesting metrics Penalize well-designed but short programs
can be computed, like Cannot easily accommodate nonprocedural languages
Errors per person-month Require a level of detail that may be difficult to achieve
KLOC per person-month
$ per page of documentation
Unit 3 – Managing Software Projects 11
Function Oriented Metrics
 Function-oriented metrics use a measure of the functionality delivered by the application
as a normalization value
 Most widely used metric of this type is the Function Point
 FP = Count Total * [0.65 + 0.01 * Sum (Value Adjustment Factors)]
 Function Point values on past projects can be used to compute,
 for example, the average number of lines of code per function point
 Advantages
 FP is programming language independent
 FP is based on data that are more likely to be known in the early stages of a project, making it more
attractive as an estimation approach
 Disadvantages
 FP requires some “sleight of hand” because the computation is based on subjective data
 Counts of the information domain can be difficult to collect
 FP has no direct physical meaning, it’s just a number

Unit 3 – Managing Software Projects 12

Object-Oriented Metrics Use Case Oriented Metrics
 Conventional software project metrics  Like FP, the use case is defined early in the
(LOC or FP) can be used to estimate software process, allowing it to be used for
object-oriented software projects estimation before significant (valuable)
 However, these metrics do not provide modeling and construction activities are
enough granularity (detailing) for the initiated
schedule and effort adjustments that are  Use cases describe (indirectly, at least) user-
required as you iterate through an visible functions and features that are basic
evolutionary or incremental process requirements for a system
 Lorenz and Kidd suggest the following set  The use case is independent of programming
of metrics for OO projects language, because use cases can be created at
 Number of scenario scripts vastly different levels of abstraction, there is
 Number of key classes (the highly no standard “size” for a use case
independent components)
 Without a standard measure of what a use
 Number of support classes
case is, its application as a normalization
measure is suspect (doubtful).
 Ex., effort expended / use case
Unit 3 – Managing Software Projects 13
Function Point Metrics
 The function point (FP) metric User / Event
can be used effectively as a means
for measuring the functionality Other
delivered by a system User / Event external
Application
 Using historical data, the FP inquiries (EQs) s
metric can be used to
 Estimate the cost or effort required external
inputs (EIs) external interface
to design, code, and test the software files (EIFs)
 Predict the number of errors that
will be encountered during testing
external
 Forecast the number of outputs (EOs) Internal
components and/or the number of
projected source lines in the Logic Files
implemented system

Function / Application

Unit 3 – Managing Software Projects 14

Function Point Components Cont.
Information domain values (components) are defined in the following manner
 Number of external inputs (EIs)
 input data originates from a user or is transmitted from another application
 Number of external outputs (EOs)
 external output is derived data within the application that provides information to the user
 output refers to reports, screens, error messages, etc.
 Number of external inquiries (EQs)
 external inquiry is defined as an online input that results in the generation of some immediate software
response in the form of an online output
 Number of internal logical files (ILFs)
 internal logical file is a logical grouping of data that resides within the application’s boundary and is
maintained via external inputs
 Number of external interface files (EIFs)
 external interface file is a logical grouping of data that resides external to the application but provides
information that may be of use to another application

Unit 3 – Managing Software Projects 15

Compute Function Points
Value Adjustment Factors
FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]
• F1. Data Communication
Count Total is the sum of all FP entries • F2. Distributed Data Processing
• F3. Performance
Fi (i=1 to 14) are complexity value adjustment factors (VAF).
• F4. Heavily Used Configuration
• F5. Transaction Role
Value adjustment factors are used to provide an indication of
problem complexity
• F6. Online Data Entry
• F7. End-User Efficiency
• F8. Online Update
• F9. Complex Processing
• F10. Reusability
• F11. Installation Ease
• F12. Operational Ease
• F13. Multiple Sites
• F14. Facilitate Change

Unit 3 – Managing Software Projects 16

Function Point Calculation Example
Used Adjustment
Factors and assumed
values are,
F09. Complex internal
processing = 3
F10. Code to be reusable =
2
F03. High performance =
4
FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ] F13. Multiple sites = 3
F02. Distributed
FP = [50]* [0.65 + 0.01 * 17]
processing = 5
FP = [50]* [0.65 + 0.17]
Project Adjustment
FP = [50]* [0.82] = 41 Factor (VAF) = 17
Unit 3 – Managing Software Projects 17
Function Point Calculation Example 2
Study of requirement specification
for a project has produced
following results 7 28
10 40
6 18
Need for 7 inputs, 10 outputs, 6
inquiries, 17 files and 4 external 17 119
interfaces 4 28
233
Input and external interface
function point attributes are of
Value adjustment factors (VAF) = 32 given
average complexity and all other
function points attributes are of
low complexity FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]
= 233 * [ 0.65 + 0.01 * 32]
Determine adjusted function
points assuming complexity = 233 * 0.97 = 226.01
adjustment value is 32.
Unit 3 – Managing Software Projects 18
Software Project Estimation
To achieve reliable cost and effort estimates, several options arise:
 Delay estimation until late in the project (obviously, we can
achieve 100 percent accurate estimates after the project is
complete!)
 Base estimates on similar projects that have already been
completed
 Use relatively simple decomposition techniques to generate
project cost and effort estimates
It can be  Use one or more empirical models for software cost and effort
transformed from a estimation.
black art to a series
of systematic steps
that provide
estimates with
acceptable risk
Unit 3 – Managing Software Projects 19
Software Project Decomposing
 Software project estimation is a form of problem solving and in most cases, the problem to
be solved is too complex to be considered in one piece
 For this reason, decomposing the problem, re-characterizing it as a set of smaller problems
is required
 Before an estimate can be made, the project planner must understand the scope of the
software to be built and must generate an estimate of its “size”

Decomposition Techniques

1. Software Sizing 3. Process based Estimation

2. Problem based Estimation 4. Estimation with Use-cases
LOC (Lines of Code) based,
FP (Function Point) based

Unit 3 – Managing Software Projects 20

Software Sizing
Putnam and Myers suggest four different approaches to the sizing problem
 “Fuzzy logic” sizing
 This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic.
 Function Point sizing
 The planner develops estimates of the information domain characteristics
 Standard Component sizing
 Estimate the number of occurrences of each standard component
 Use historical project data to determine the delivered LOC size per standard component.
 Change sizing
 Used when changes are being made to existing software
 Estimate the number and type of modifications that must be accomplished
 An effort ratio is then used to estimate each type of change and the size of the change

Unit 3 – Managing Software Projects 21

Problem Based Estimation
 Start with a bounded statement of scope
 Decompose the software into problem functions that can each be estimated individually
 Compute an LOC or FP value for each function
 Derive cost or effort estimates by applying the LOC or FP values to your baseline
productivity metrics
 Ex., LOC/person-month or FP/person-month
 Combine function estimates to produce an overall estimate for the entire project
 In general, the LOC/pm and FP/pm metrics should be computed by project domain
 Important factors are team size, application area and complexity

Unit 3 – Managing Software Projects 22

Problem Based Estimation Cont.
 LOC and FP estimation differ in the level of detail required for decomposition with each
value
 For LOC, decomposition of functions is essential and should go into considerable detail (the more detail,
the more accurate the estimate)
 For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment
factors
 External Inputs, External Outputs, External Inquiries, Internal Logical Files, External Interface Files
 For both approaches, the planner uses lessons learned to estimate,
 An optimistic (Sopt), most likely (Sm), and pessimistic (Spess) estimates Size (S) value for each function or
count
 Then the expected Size value S is computed as
 S = (Sopt + 4 Sm + Spess)/6
Historical LOC or FP data is then compared to S in order to cross-check it.

Unit 3 – Managing Software Projects 23

Process Based Estimation
 This is one of the most commonly used technique
Process-based estimation is
 Identify the set of functions that the software needs to perform as
obtained from “process
obtained from the project scope
framework”
 Identify the series of framework activities that need to be
performed for each function
Framework Activities
Frame
 Estimate the effort (in person months) that will be required to
accomplish each software process activity for each function
Effort required  Apply average labor rates (i.e., cost/unit effort) to the effort
Application
Functions

to accomplish estimated for each process activity

each framework  Compute the total cost and effort for each function and each
activity for each framework activity.
application  Compare the resulting values to those obtained by way of the
function LOC and FP estimates
 If both sets of estimates agree, then your numbers are highly
reliable
 Otherwise, conduct further investigation and analysis concerning
the function andSoftware
Unit 3 – Managing activity breakdown
Projects 24
Estimation with Use Cases
Developing an estimation approach with use  Before use cases can be used for estimation,
cases is problematic for the following reasons:  the level within the structural hierarchy
is established,
 Use cases are described using many
 the average length (in pages) of each use
different formats and styles—there is no case is determined,
standard form.  the type of software (e.g., real-time,
 Use cases represent an external view (the business, engineering/scientific, WebApp,
user’s view) of the software and can therefore embedded) is defined, and
be written at many different levels of  a rough architecture for the system is
abstraction considered
 Use cases do not address the complexity of  Once these characteristics are established,
the functions and features that are described  empirical data may be used to establish the
estimated number of LOC or FP per use
 Use cases can describe complex behavior case (for each level of the hierarchy).
(Ex., interactions) that involve many  Historical data are then used to compute the
functions and features effort required to develop the system.
 Although a number of investigators have
considered use cases as an estimation input.
Unit 3 – Managing Software Projects 25
Empirical Estimation Models
Source Lines of Code (SLOC)

 The project size helps to determine the resources, effort,

and duration of the project.
 SLOC is defined as the Source Lines of Code that are
delivered as part of the product
 The effort spent on creating the SLOC is expressed in
relation to thousand lines of code (KLOC)
Source Lines of Code (SLOC)  This technique includes the calculation of Lines of
Code, Documentation of Pages, Inputs, Outputs, and
Function Point (FP) Components of a software program
Constructive Cost Model  The SLOC technique is language-dependent
(COCOMO)  The effort required to calculate SLOC may not be the
same for all languages

Unit 3 – Managing Software Projects 26

 Based on the development
Software Development Project complexity
Software Development Project Classification

Organic Semidetached Embedded

Application programs Utility programs System programs

e.g. data processing programs e.g Compilers, linkers e.g OS real-time systems
A development project can A development project can be A development project is
be considered of organic type, considered of semidetached type, considered to be of
if the project deals with if the development consists of a embedded type, if the
developing a well understood mixture of experienced & software being developed is
application program, the size inexperienced staff. Team strongly coupled to complex
of the development team is members may have limited hardware, or if the strict
reasonably small, and the experience on related systems regulations on the
team members are but may be unfamiliar with some operational procedures exist
experienced in developing aspects of the system being
similar types of projects developed.
Unit 3 – Managing Software Projects 27
 Software Development Project Cont.

Not Tight Dead Line

Little Innovatio
Projec Development
Model t Nature of Project Environment

n
Size
Organic Typically Small Size Project, Experienced developers
Familiar &
2-50 in the familiar environment, e.g. Payroll,
KLOC
In-house
Inventory projects etc.
Semi Typically Medium Size Project, Medium Size Team,

Medium

Medium
Detached 50-300 Average Previous Experience, e.g. Utility Medium
KLOC Systems like Compilers, Database Systems,
editors etc.
Complex hardware

Significant

Tight
Embedded Typically Large Project, Real Time Systems, Complex

Required
Over 300 interfaces, very little previous Experience. & customer
KLOC E.g. ATMs, Air Traffic Controls Interfaces

Unit 3 – Managing Software Projects 28

COCOMO Model Basic COCOMO Model
COCOMO The basic COCOMO model gives an approximate estimate of the project
parameters
(Constructive Cost The basic COCOMO estimation model is given by the following
Estimation Model) 𝑎
expressions 𝑏
𝑬𝒇𝒇𝒐𝒓𝒕 =𝑎 1 + ( 𝐾𝐿𝑂𝐶 ) 𝑃𝑀 𝑻𝒅𝒆𝒗 =𝑏 1 × ( 𝐸𝑓𝑓𝑜𝑟𝑡 ) 𝑀𝑜𝑛𝑡h𝑠
2 2

was proposed by
Boehm • KLOC is the estimated size of the software product expressed in Kilo Lines of
Code
According to Boehm, • a1, a2, b1, b2 are constants for each category of software products,
software cost • Tdev is the estimated time to develop the software, expressed in months,
• Effort is the total effort required to develop the software product, expressed in
estimation should be
person months (PMs).
done through three Project a1 a2 b1 b2
stages:
Basic COCOMO Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Intermediate COCOMO
Embedded 3.6 1.20 2.5 0.32
Complete COCOMO
Unit 3 – Managing Software Projects 29
Basic COCOMO Model Cont.
 The effort estimation is expressed in units of person-months (PM)
 It is the area under the person-month plot (as shown in fig.)
 An effort of 100 PM
 does not imply that 100 persons should work for 1 month
 does not imply that 1 person should be employed for 100 months
 it denotes the area under the person-month curve (fig.)
 Every line of source text should be calculated as one LOC irrespective of the actual
number of instructions on that line
 If a single instruction spans several lines (say n lines), it is considered to be nLOC
 The values of a1, a2, b1, b2 for different categories of products (i.e. organic, semidetached,
and embedded) as given by Boehm
 He derived the expressions by examining historical data collected from a large number of
actual projects

Unit 3 – Managing Software Projects 30

Basic COCOMO Model Cont.
 Insight into the basic COCOMO model can be obtained by plotting
the estimated characteristics for different software sizes
 Fig.1 shows a plot of estimated effort versus product size
 From fig. we can observe that the effort is somewhat superlinear in
the size of the software product
 The effort required to develop a product increases very rapidly with
project size Fig. 1
 The development time versus the product size in KLOC is plotted in
fig. 2
 From fig., it can be observed that the development time is a sublinear
function of the size of the product
 i.e. when the size of the product increases by two times, the time to
develop the product does not double but rises moderately Fig. 2
 From fig., it can be observed that the development time is roughly the
same for all the three categories of products
Unit 3 – Managing Software Projects 31
Basic COCOMO Model Cont.
 Effort and the duration estimations obtained using the COCOMO model are called as
nominal effort estimate and nominal duration estimate
 The term nominal implies that
 if anyone tries to complete the project in a time shorter than the estimated duration, then the cost will
increase drastically
 But, if anyone completes the project over a longer period than the estimated, then there is almost no
decrease in the estimated cost value

Example: Assume that the size of an organic type software product has been estimated to be 32,000 lines
of source code. Assume that the average salary of software engineers be Rs. 15,000/- per month.
Determine the effort required to develop the software product and the nominal development time
𝑎2
𝑬𝒇𝒇𝒐𝒓𝒕 =𝑎 1 + ( 𝐾𝐿𝑂𝐶 ) 𝑃𝑀 𝑻𝒅𝒆𝒗 =𝑏 1 × ( 𝐸𝑓𝑓𝑜𝑟𝑡 )𝑏 𝑀𝑜𝑛𝑡h𝑠 2

1.05
¿ 2.4 + ( 32 ) 𝑃𝑀 ¿ 2.5 × ( 91 )0.38 𝑀𝑜𝑛𝑡h𝑠
¿ 9 1 𝑃𝑀 ¿ 14 𝑀𝑜𝑛𝑡h𝑠
Cost required to develop the product = 14 x 15000 = Rs. 2,10,000/-
Unit 3 – Managing Software Projects 32
Intermediate COCOMO model
 The basic COCOMO model assumes that effort and development time are functions of
the product size alone
 However, a host of other project parameters besides the product size affect the effort
required to develop the product as well as the development time
 Therefore, in order to obtain an accurate estimation of the effort and project duration, the
effect of all relevant parameters must be considered
 The intermediate COCOMO model recognizes this fact and refines the initial estimate
obtained using the basic COCOMO expressions by using a set of 15 cost drivers
(multipliers) based on various attributes of software development
 For example, if modern programming practices are used, the initial estimates are scaled downward by
multiplication with a cost driver having a value less than 1
 It requires the project manager to rate these 15 different parameters for a particular project
on a scale of one to three.
 Then, depending on these ratings, appropriate cost driver values which should be
multiplied with the initial estimate obtained using the basic COCOMO.
Unit 3 – Managing Software Projects 33
Intermediate COCOMO model Cont.
The cost drivers can be classified as being attributes of the following items
 Product: The characteristics of the product that are considered include the inherent
complexity of the product, reliability requirements of the product, etc.
 Computer: Characteristics of the computer that are considered include the execution speed
required, storage space required etc.
 Personnel: The attributes of development personnel that are considered include the
experience level of personnel, programming capability, analysis capability, etc.
 Development Environment: Development environment attributes capture the development
facilities available to the developers. An important parameter that is considered is the
sophistication of the automation (CASE) tools used for software development

Unit 3 – Managing Software Projects 34

Intermediate COCOMO model Cont.
Very Very
Cost Drivers Low Nominal High Project A is to be a 32,000 DSI semi-
Low High
Product detached software. It is in a mission
Required Software Reliability 0.75 0.88 1.00 1.15 1.40 critical area, so the reliability is high.
Size of Application Database 0.94 1.00 1.08 1.16 Then we can estimate:
Complexity of The Product 0.70 0.85 1.00 1.15 1.30
Computer
Effort = 1.15*3.0*(32)1.12
Runtime Performance Constraints 1.00 1.11 1.30
Memory Constraints 1.00 1.06 1.21
= 167 man-months
Volatility of the virtual machine environment 0.87 1.00 1.15 1.30
Required turnabout time 0.94 1.00 1.07 1.15 Schedule = 2.5*(167)0.35
Personnel = 15 months
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82 Productivity
Software engineer capability 1.42 1.17 1.00 0.86 0.70 = 32,000 DSI/167 MM
Virtual machine experience 1.21 1.10 1.00 0.90 = 192 DSI/MM
Programming language experience 1.14 1.07 1.00 0.95
Development Environment
Average Staffing
Application of software engineering methods 1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83 = 167 MM/15 months
Required development schedule 1.23 1.08 1.00 1.04 1.10 = 11 FSP
Unit 3 – Managing Software Projects 35
Complete COCOMO model
 A major shortcoming of both the basic and intermediate COCOMO models is that they
consider a software product as a single homogeneous entity
 Most large systems are made up several smaller sub-systems
 These sub-systems may have widely different characteristics
 E.g., some sub-systems may be considered as organic type, some semidetached, and some embedded
 Also, for some subsystems the reliability requirements may be high, for some the development team might
have no previous experience of similar development etc.
 The complete COCOMO model considers these differences in characteristics of the
subsystems and estimates the effort and development time as the sum of the estimates for
the individual subsystems
 The cost of each subsystem is estimated separately
 This approach reduces the margin of error in the final estimate

Unit 3 – Managing Software Projects 36

Project Scheduling & Tracking

It is an action that distributes estimated effort across the planned project duration, by
allocating the effort to specific software engineering tasks

Scheduling Principles

Compartmentalization Interdependency Time Allocation Define

Responsibilities
Define Outcomes Define Milestones Effort Validation

Unit 3 – Managing Software Projects 37

Scheduling Principles
 Compartmentalization
 The product and process must be decomposed into a manageable number of activities and tasks
 Interdependency
 Tasks that can be completed in parallel must be separated from those that must be completed serially
 Time Allocation
 Every task has start and completion dates that take the task interdependencies into account
 Effort Validation
 Project manager must ensure that on any given day there are enough staff members assigned to complete
the tasks within the time estimated in the project plan
 Define Responsibilities
 Every scheduled task needs to be assigned to a specific team member
 Define Outcomes
 Every task in the schedule needs to have a defined outcome (usually a work product or deliverable)
 Defined Milestones
 A milestone is accomplished when one or more work products from an engg task have passed quality
review 38
Unit 3 – Managing Software Projects
Effort Distribution
 General guideline: 40-20-40 rule
 40% or more of all effort allocated to analysis and design tasks
 20% of effort allocated to programming
 40% of effort allocated to testing
 Characteristics of each project dictate the distribution of effort
 Although most software organizations encounter the following projects types:
 Concept Development
 initiated to explore new business concept or new application of technology
 New Application Development
 new product requested by customer
 Application Enhancement
 major modifications to function, performance or interfaces (observable to user)
 Application Maintenance
 correcting, adapting or extending existing software (not immediately obvious to user).
 Reengineering
 rebuilding all (or part) of an existing (legacy) system
Unit 3 – Managing Software Projects 39
Scheduling methods
 Two project scheduling methods that can be applied to software development.
 Program Evaluation and Review Technique (PERT)
 Critical Path Method (CPM)
 Both techniques are driven by information already developed in earlier project planning
activities:
 estimates of effort
 a decomposition of the product function
 the selection of the appropriate process model and task set
 decomposition of the tasks that are selected
 Both PERT and CPM provide quantitative tools that allow you to:
 Determine the critical path—the chain of tasks that determines the duration of the project
 Establish “most likely” time estimates for individual tasks by applying statistical models
 Calculate “boundary times” that define a “time window” for a particular task

Unit 3 – Managing Software Projects 40

Project Schedule Tracking Gantt chart
 The project schedule provides a road map for a A Gantt chart, commonly used in
software project manager. project management, is one of the
most popular and useful ways of
 It defines the tasks and milestones. showing activities (tasks or events)
 Several ways to track a project schedule: displayed against time.
 Conducting periodic project status meeting
On the left of the chart is a list of the
 Evaluating the review results in the software process
activities and along the top is a
 Determine if formal project milestones have been
suitable time scale.
accomplished
 Compare actual start date to planned start date for each
task Each activity is represented by a bar;
 Informal meeting with practitioners the position and length of the bar
 Using earned value analysis to assess progress reflects the start date, duration and
quantitatively end date of the activity. This allows
you to see briefly:
 Project manager takes the control of the schedule in
the aspects of
 Project Staffing, Project Problems, Project Resources,
Reviews, Project Budget Unit 3 – Managing Software Projects 41
Gantt chart Cont.
What the various
activities are

When each activity

begins and ends

How long each activity

is scheduled to last

Where activities
overlap with other
activities, and by how
much

The start and end date

of the whole project
Unit 3 – Managing Software Projects 42
CPM (Critical Path Method)
Key Points

• What tasks must be carried out.

• Where parallel activity can be performed.
• The shortest time in which you can complete a project.
• Resources needed to execute a project.
• The sequence of activities, scheduling and timings involved.
• Task priorities.
• The most efficient way of shortening time on urgent projects.

Unit 3 – Managing Software Projects 43

CPM (Critical Path Method)

• The critical path is the sequence of activities with the longest duration.
• A delay in any of these activities will result in a delay for the whole project.

Unit 3 – Managing Software Projects 44

CPM (Critical Path Method)

• Float is the amount of time an activity can slip before it causes your project to be delayed.
Float is sometimes referred to as slack.
• Each of the activities on critical path has a float of
zero.
• If any of those activities slips, the project will be
delayed.
• Then take the next longest path. Subtract its duration
from the duration of the critical path. That's the float
for each of the activities on that path.
• Continue doing the same for each subsequent longest
path until each activities float has been determined.
• If an activity is on two paths, it's float will be based
on the longer path that it belongs to.
Unit 3 – Managing Software Projects 45
CPM (Critical Path Method) - Example
Possible paths
Start  A  C  F  Finish: 13
Start  B  D  E  Finish : 09
Start  A  D  E  Finish : 08
Start  B  F  Finish : 09

Critical Path

Unit 3 – Managing Software Projects 46

CPM (Critical Path Method) - Example

Slack = 0
Slack = 0 Slack = 0
EST = 0 EST = 7
EST = 2
EFT = 2 EFT = 13
EFT = 7
LF = 2 LF = 7 LF = 13
LS = 0 LS = 2 LS = 7

Slack = 4 Slack = 4 Slack = 4

EST = 0 EST = 3 EST = 7
EFT = 3 EFT = 7 EFT = 9
47
LF = 7 LF = 11 LF = 13
LS = 4 LS = 7 LS = 11

Unit 3 – Managing Software Projects 47

Risk analysis & Management Risk
A risk is a potential (probable) problem – which might happen and
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 Loss
The risk may or may not
If the risk becomes a reality
happen, so there are no 100%
and unwanted consequences
risks (some of those may called
or losses occur
constraints)
Unit 3 – Managing Software Projects 48
Risk Categorization: Approach-1
 Project risks Sub-categories of Business risks
 They threaten the project plan  Market risk
 If they become real, it is likely that the  Building an excellent product or system that no one
project schedule will slip and that costs really wants
will increase
 Strategic risk
 Technical risks  Building a product that no longer fits into the
 They threaten the quality and timeliness overall business strategy for the company
of the software to be produced
 If they become real, implementation may
 Sales risk
become difficult or impossible  Building a product that the sales force doesn't
understand how to sell
 Business risks
 They threaten the feasibility of the
 Management risk
software to be built  Losing the support of senior management due to a
 If they become real, they threaten the change in focus or a change in people
project or the product  Budget risk
 Losing budgetary or personnel commitment

Unit 3 – Managing Software Projects 49

Risk Categorization: Approach-2
 Known risks
 Those risks that can be uncovered after careful evaluation of
o the project plan, the business and technical environment in which the project is being developed, and other reliable
information sources (Ex. unrealistic delivery date)
 Predictable risks
 Those risks that are deduced (draw conclusion) from past project experience (Ex. past turnover)
 Unpredictable risks
 Those risks that can and do occur, but are extremely difficult to identify in advance

Risk Strategies (Reactive vs.

Reactive risk strategies Proactive) Proactive risk strategies
• "Don't worry, I will think of something“. • Steps for risk management are
• Most software teams and managers rely on this approach followed
• Nothing is done about risks until something goes wrong • Primary objective is to avoid risk and
• The team then flies into action to correct the problem rapidly (fire
to have an emergency plan in place to
fighting)
• Crisis management is the choice of management techniques
handle unavoidable risks in a
controlled and effective manner
Unit 3 – Managing Software Projects 50
Steps for Risk Management Risk Identification
1. Identify possible risks and recognize  Risk identification is a systematic attempt to
what can go wrong specify threats to the project plan
2. Analyze each risk to estimate the  By identifying known and predictable risks,
probability that it will occur and the the project manager takes a first step toward,
impact (i.e., damage) that it will do if  avoiding them when possible
it does occur  controlling them when necessary
3. Rank the risks by probability and  Generic Risks
impact. Impact may be negligible,  Risks that are a potential threat to every software
marginal, critical, and catastrophic. project
4. Develop a contingency plan to  Product-specific Risks
manage those risks having high  Risks that can be identified only by clear
probability and high impact understanding of the technology, the people and
the environment, that is specific to the software
that is to be built

Unit 3 – Managing Software Projects 51

Known and Predictable Risk Categories
 One method for identifying risks is to create a risk item checklist
 The checklist can be used for risk identification which focuses on some subset of known
and predictable risks in the following generic subcategories:
 Product Size: risks associated with overall size of the software to be built
 Business Impact: risks associated with constraints imposed by management or the marketplace
 Customer Characteristics: risks associated with sophistication of the customer and the developer's
ability to communicate with the customer in a timely manner
 Process Definition: risks associated with the degree to which the software process has been defined and is
followed
 Development Environment: risks associated with availability and quality of the tools to be used to build
the project
 Technology to be Built: risks associated with complexity of the system to be built and the “newness” of
the technology in the system
 Staff Size and Experience: risks associated with overall technical and project experience of the software
engineers who will do the work

Unit 3 – Managing Software Projects 52

Risk Estimation (Projection)
 Risk projection (or estimation) attempts to rate each risk in two ways
 The probability that the risk is real
 The consequence (effect) of the problems associated with the risk
 Risk Projection/Estimation Steps
 Establish a scale that reflects the perceived likelihood (probability) of a risk. Ex., 1-low, 10-high
 Explain the consequences of the risk
 Estimate the impact of the risk on the project and product.
 Note the overall accuracy of the risk projection so that there will be no misunderstandings

Unit 3 – Managing Software Projects 53

 RMMM
 Risk Mitigation, Monitoring, and Management (RMMM)
 An effective strategy for dealing with risk must consider three issues
 Risk mitigation (i.e., avoidance)
 Risk monitoring
 Risk management and contingency planning

RMM
M
Risk Mitigation is a problem avoidance activity

Risk Monitoring is a project tracking activity

Risk Management includes contingency plans that risk will occur

Unit 3 – Managing Software Projects 54

Risk Mitigation
 Risk mitigation (avoidance) is the primary strategy and is achieved through a plan
 For Ex., Risk of high staff turnover
 To mitigate this risk, you would develop a strategy for reducing turnover.
 The possible steps to be taken are:
 Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, and
competitive job market)
 Mitigate those causes that are under your control before the project starts
 Once the project commences, assume turnover will occur and develop techniques to ensure continuity
when people leave
 Organize project teams so that information about each development activity is widely dispersed
 Define work product standards and establish mechanisms to be sure that all models and
documents are developed in a timely manner
 Conduct peer reviews of all work (so that more than one person is “up to speed”).
 Assign a backup staff member for every critical technologist

Unit 3 – Managing Software Projects 55

RMMM PLAN
 The RMMM PLAN documents all work Risk information sheet (RIS)
performed as part of risk analysis and used by
the project manager as part of the overall
project plan
 Some software teams do not develop a formal
RMMM document, rather each risk is
documented individually using a Risk
information sheet (RIS)
 In most cases, RIS is maintained using a
database system.
 So, Creation and information entry, priority
ordering, searches and other analysis may be
accomplished easily.
 The format of RIS is describe in diagram

Unit 3 – Managing Software Projects 56

Thank
You