Chapter 3 Software Estimation Metrics

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 32

Chapter 3- Software Estimation Metrics

Syllabus Content

3.1 Software Metrics, Software Project Estimation (LOC, FP, COCOMO II )


3.2 Project Scheduling & Tracking

Exam Question-: Explain management spectrum

Explain 3Ps in Software Project Spectrum

Management Spectrum

• In software engineering, the management spectrum describes the management of

a software project.

• The management of a software project starts from requirement analysis and finishes
based on the nature of the product, it may or may not end because almost all

software products face changes and requires support.


• It is about turning the project from plan to reality.

• The management spectrum focuses on the four P’s: people, product, process and
project.

• Here, the manager of the project has to control all these P’s to have a smooth flow
in the progress of the project and to reach the goal.

The four P's of management spectrum are


1. People

2. Product
3. Process

4. Project

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


People :
• People of a project includes from manager to developer, from customer to end

user.
• But mainly people of a project highlight the developers.

• It is so important to have highly skilled and motivated developers that the Software
Engineering Institute has developed a People Management Capability Maturity

Model (PM-CMM),
• Organizations that achieve high levels of maturity in the people management area

have a higher likelihood of implementing effective software engineering practices.

The Product:
• The product is the ultimate goal of the project.

• To develop a software product successfully, all the product objectives and scopes
should be established, alternative solutions should be considered, and technical and

management constraints should be identified beforehand.


• Lack of these information, it is impossible to define reasonable and accurate

estimation of the cost, an effective assessment of risks, a realistic breakdown of


project tasks or a manageable project schedule that provides a meaningful

indication of progress.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


The Process:
• A software process provides the framework from which a comprehensive plan for

software development can be established.


• A number of different tasks sets— tasks, milestones, work products, and quality

assurance points—enable the framework activities to be adapted to the


characteristics of the software project and the requirements of the project team.

• Finally, umbrella activities overlay the software process model. Umbrella activities
are independent of any one framework activity and occur throughout the process.

Project
• The project is the complete software project that includes requirement analysis,

development, delivery, maintenance and updates.


• The project manager of a project or sub-project is responsible for managing the

people, product and process.


• The responsibilities or activities of software project manager would be a long list

but that has to be followed to avoid project failure.


• A software project could be extremely complex and as per the industry data the

failure rate is high. Its merely due to the development but mostly due to the steps
before development and sometimes due to the lack of maintenance.

Exam Questions: Write short note on Process Metrics


Write short note on Project Metrics

Software Metrics:
• Software metrics is a standard of measure that contains many activities which

involve some degree of measurement.


• It can be classified into three categories: product metrics, process metrics, and

project metrics.
Product metrics describe the characteristics of the product such as size, complexity,
design features, performance, and quality level.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Process metrics can be used to improve software development and
maintenance. Examples include the effectiveness of defect removal during

development, the pattern of testing defect arrival, and the response time of the fix
process.

Project metrics describe the project characteristics and execution. Examples


include the number of software developers, the staffing pattern over the life cycle

of the software, cost, schedule, and productivity


Scope of Software Metrics

• Cost and effort estimation


• Productivity measures and model

• Data collection
• Quantity models and measures

• Reliability models
• Performance and evaluation models

• Structural and complexity metrics


• Capability – maturity assessment

• Management by metrics
• Evaluation of methods and tools

Advantage of Software Metrics


• Comparative study of various design methodology of software systems.

• For analysis, comparison, and critical study of different programming language


concerning their characteristics.

• In comparing and evaluating the capabilities and productivity of people involved in


software development.

• In the preparation of software quality specifications.


• In the verification of compliance of software systems requirements and

specifications.
• In making inference about the effort to be put in the design and development
of the software systems.
• In getting an idea about the complexity of the code.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• In taking decisions regarding further division of a complex module is to be done or
not.

• In guiding resource manager for their proper utilization.


• In comparison and making design tradeoffs between software development and

maintenance cost.
• In providing feedback to software managers about the progress and quality during

various phases of the software development life cycle.


• In the allocation of testing resources for testing the code.

Disadvantage of Software Metrics


• The application of software metrics is not always easy, and in some cases, it is

difficult and costly.


• The verification and justification of software metrics are based on

historical/empirical data whose validity is difficult to verify.


• These are useful for managing software products but not for evaluating the

performance of the technical staff.


• The definition and derivation of Software metrics are usually based on assuming

which are not standardized and may depend upon tools available and working
environment.

Software Measurement:
• A measurement is an manifestation of the size, quantity, amount or dimension

of a particular attributes of a product or process.


• Software measurement is a input of a characteristic of a software product or the

software process.
• It is an authority within software engineering. Software measurement process is

defined and governed by ISO Standard.


Need of Software Measurement:

• Create the quality of the current product or process.


• Anticipate future qualities of the product or process.
• Enhance the quality of a product or process.
• Regulate the state of the project in relation to budget and schedule.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• Classification of Software Measurement:
• There are 2 types of software measurement:

• Direct Measurement:
• In direct measurement the product, process or thing is measured directly using

standard scale.
• Indirect Measurement:

• In indirect measurement the quantity or quality to be measured is measured using


related parameter i.e. by use of reference.

• Metrics:
• A metrics is a measurement of the level that any impute belongs to a system product

or process. There are 4 functions related to software metrics:


➢ Planning

➢ Organizing
➢ Controlling

➢ Improving
Types of software metrics:

• Product Metrics:
• Product metrics are used to evaluate the state of the product, tracing risks and

under covering prospective problem areas. The ability of team to control quality
is evaluated.

• Process Metrics:
• Process metrics pay particular attention on enhancing the long term process of

the team or organisation.


• Project Metrics:

• Project matrix is describes the project characteristic and execution process.


Number of software developer, Staffing pattern over the life cycle of software, Cost

and schedule, Productivity

Terms

Measure: Quantitative indication of the extent, amount, dimension, or size of some

attribute of a product or process. A single data point

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Metrics: The degree to which a system, component, or process possesses a given attribute.
Relates several measures (e.g. average number of errors found per person hour)

Indicators: A combination of metrics that provides insight into the software process,

project or product

Direct Metrics: Immediately measurable attributes (e.g. line of code, execution speed,
defects reported)

Indirect Metrics: Aspects that are not immediately quantifiable (e.g. functionality,
quantity, reliability)

Faults:

− Errors: Faults found by the practitioners during software development

− Defects: Faults found by the customers after release

Goal Metrics

• To improve product quality and development-team productivity

• Concerned with productivity and quality measures

• Measures of Software development output as function of effort and time

• Measures of usability

Process Metrics

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:

l All errors and defects are categorized by origin

l The cost to correct each error and defect is recorded

l The number of errors and defects in each category is computed

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


l Data is analyzed to find categories that result in the highest cost to the
organization

l Plans are developed to modify the process

Defect Removal Efficiency (DRE). Relationship between errors (E) and defects (D). The ideal

is a DRE of 1:

DRE = E /( E + D)
• Used by a project manager and software team to adapt project work flow and

technical activities. Tactical and Short Term.

• Purpose:

− Minimize the development schedule by making the necessary adjustments


to avoid delays and mitigate problems

− Assess product quality on an ongoing basis

• Metrics:

− Effort or time per SE task

− Errors uncovered per review hour

− Scheduled vs. actual milestone dates

− Number of changes and their characteristics

− Distribution of effort on SE tasks

Exam Questions

• Explain Software Project Estimation in detail

• Explain Size Oriented Software Engineering metrics

• Explain Function Point Estimation Technique in detail

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• Explain COCOMO model in detail

Software Cost Estimation

• Estimation of the size of software is an essential part of

Software Project Management.

• It helps the project manager to further predict the effort and

time which will be needed to build the project.

• Various measures are used in project size estimation. Some of

these are:

1. Lines of Code

2. Number of entities in ER diagram

3. Total number of processes in detailed data flow diagram

4. Function points

1. Lines of Code
Lines of Code (LOC): As the name suggest, LOC count the total number of lines
of source code in a project.
2. The units of LOC are:
3. KLOC- Thousand lines of code

4. NLOC- Non comment lines of code


5. KDSI- Thousands of delivered source instruction

6. The size is estimated by comparing it with the existing systems of same kind.
7. The experts use it to predict the required size of various components of

software and then add them to get the total size.


8. Advantages:

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


9. Universally accepted and is used in many models like COCOMO.
10. Estimation is closer to developer’s perspective.

Simple to use.
Disadvantages:

• Different programming languages contains different number of lines.


• No proper industry standard exists for this technique.

• It is difficult to estimate the size using this technique in early stages of project.

Software Cost Estimation-Number of Entities in ER diagram


• ER model provides a static view of the project.

• It describes the entities and its relationships.


• The number of entities in ER model can be used to measure the estimation of size

of project.
• Number of entities depends on the size of the project.

• This is because more entities needed more classes/structures thus leading to more
coding

Advantages:
• Size estimation can be done during initial stages of planning.

• Number of entities is independent of programming technologies used.


Disadvantages:

• No fixed standards exist. Some entities contribute more project size than others.
Just like FPA, it is less used in cost estimation model. Hence, it must be

converted to LOC.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Software Cost Estimation-Total number of processes in detailed data
flow diagram

• Data Flow Diagram(DFD) represents the functional view of a software.


• The model depicts the main processes/functions involved in software and flow of

data between them.


• Utilization of number of functions in DFD to predict software size.

• Already existing processes of similar type are studied and used to estimate the size
of the process. Sum of the estimated size of each process gives the final estimated

size.
Advantages:

• It is independent of programming language.


• Each major processes can be decomposed into smaller processes. This will

increase the accuracy of estimation


Disadvantages:

• Studying similar kind of processes to estimate size takes additional time and effort.
• All software projects are not required to construction of DFD.

Function Points

⚫ Based on a combination of program characteristics

⚫ The number of :
− External (user) inputs: input transactions that update internal files

− External (user) outputs: reports, error messages


− User interactions: inquiries

− Logical internal files used by the system:


Example a purchase order logical file composed of 2 physical files/tables

Purchase Order and Purchase_Order_Item


− External interfaces: files shared with other systems

⚫ A weight (ranging from 3 for simple to 15 for complex features) is associated with
each of these above

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


⚫ The function point count is computed by multiplying each raw count by the
weight and summing all values
weighting factor
measurement parameter count simple avg. complex
number of user inputs X 3 4 6 =
number of user outputs X 4 5 7 =
number of user inquiries X 3 4 6 =
number of files X 7 10 15 =
number of ext.interfaces X 5 7 10 =
count-total
complexity multiplier
function points

Measuring Count Weighing Factor Total


Parameters
Simple Average Complex

No. of user 50 3 150


Inputs

No. of user 40 5 200

Outputs

No. of user 35 6 210

inquiries

No. of user Files 06 15 90

No. of external 04 7 28

interfaces

Count Total 678

FP=Count Total X(0.65+adjustment factor X ∑(Fi))


Where ∑(Fi)= adjusted function point
Hence

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


FP=678 X (0.65+0.01 x 32)
FP=657.66

Advantages:
• It can be easily used in the early stages of project planning.

• It is independent of the programming language.


• It can be used to compare different projects even if they use different technologies

(database, language etc).


Disadvantages:

• It is not good for real time systems and embedded systems.


• Many cost estimation models like COCOMO uses LOC and hence FPC must be

converted to LOC.
Example

A system is composed of 7 subsystems as below.

• Given for each subsystem the size in LOC and the 2 metrics: productivity LOC/pm
(pm: person month), Cost $/LOC

• Calculate the system total cost in $ and effort in months

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Functions estimated LOC LOC/pm $/LOC Cost Effort (months)

UICF 2340 315 14 32,000 7.4

2DGA 5380 220 20 107,000 24.4

3DGA 6800 220 20 136,000 30.9

DSM 3350 240 18 60,000 13.9

CGDF 4950 200 22 109,000 24.7

PCF 2140 140 28 60,000 15.2

DAM 8400 300 18 151,000 28.0

Totals 33,360 655,000 145.0

COCOMO Model

• Cocom (Constructive Cost Model) is a regression model based on LOC,


i.e., number of Lines of Code.

• It is a procedural cost estimate model for software projects and often used as a

process of reliably predicting the various parameters associated with making a


project such as size, effort, cost, time and quality.

• It was proposed by Barry Boehm in 1970 and is based on the study of 63 projects,
which make it one of the best-documented models.

• The key parameters which define the quality of any software products, which are

also an outcome of the COCOMO are primarily Effort & Schedule:

• Effort: Amount of labor that will be required to complete a task. It is measured in


person-months units.

• Schedule: Simply means the amount of time required for the completion of the
job, which is, of course, proportional to the effort put. It is measured in the units of

time such as weeks, months.

• Different models of Cocomo have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required. All of

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


these models can be applied to a variety of projects, whose characteristics
determine the value of constant to be used in subsequent calculations.

• Boehm’s definition of organic, semidetached, and embedded systems:

• Organic – A software project is said to be an organic type if the team size required

is adequately small, the problem is well understood and has been solved in the
past and also the team members have a nominal experience regarding the

problem.

• Semi-detached – A software project is said to be a Semi-detached type if the vital

characteristics such as team-size, experience, knowledge of the various


programming environment lie in between that of organic and Embedded. E.g.:

Compilers or different Embedded Systems can be considered of Semi-Detached


type.

• Embedded – A software project with requiring the highest level of complexity,

creativity, and experience requirement fall under this category. Such software
requires a larger team size than the other two models and also the developers

need to be sufficiently experienced and creative to develop such complex models.

• COCOMO consists of a hierarchy of three increasingly detailed and accurate forms.

Any of the three forms can be adopted according to our requirements. These are
types of COCOMO model:

• Basic COCOMO Model

• Intermediate COCOMO Model

• Detailed COCOMO Model

Basic COCOMO Model

• Basic COCOMO can be used for quick and slightly rough calculations of Software

Costs.

• Its accuracy is somewhat restricted due to the absence of sufficient factor


considerations.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• 1) Effort estimation(E) = 𝒂𝒃 (KLOC) 𝒃𝒃 person-month

• 2)Duration estimation(D)= 𝒄𝒃 (E) 𝒅𝒃 months

• 3)Person Estimation i.e., Productivity(P)= (E/D) persons

Advantages

• It is good for quick, early, rough order of magnitude estimates of software project

Disadvantages

• Accuracy of model is limited because it does not consider factors like hardware
constraints, personal quality and experience, modern techniques and tools

Example

Suppose that a system is developed and LOC instructions are 1,00,000 .

Computer nominal effort and development time for organic, semi-detached model
and embedded

Software project 𝒂𝒃 𝒃𝒃 𝒄𝒃 𝒅𝒃

Organic 3.2 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

1) Effort estimation(E) = 𝒂𝒃 (KLOC/FP) 𝒃𝒃 person-month

2)Duration estimation(D)= 𝐜𝐛 (E) 𝐝𝐛 months

3)Person Estimation i.e., Productivity(P)= (E/D) persons

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


For Organic Model

Effort estimation(E) = 𝐚𝐛 (KLOC/FP) 𝐛𝐛 person-month

= 3.2(100) 1.05

=402.8 which is app 403

Duration estimation(D)= 𝐜𝐛 (𝐄) 𝐝𝐛 months

=2.5(403)0.38

=24 months

Person Estimation i.e., Productivity(P)= (E/D) persons

=403/24=16.7

=17 persons

For Semidetached Model

Effort estimation(E) = 𝐚𝐛 (KLOC/FP) 𝐛𝐛 person-month

= 3.0(100) 1.12

=521 person-month

Duration estimation(D)= 𝐜𝐛 (E) 𝐝𝐛 months

=2.5(521)0.35

=22 months

Person Estimation i.e., Productivity(P)= (E/D) persons

=521/22

=24 persons

For Embedded System

Effort estimation(E) = 𝐚𝐛 (KLOC/FP) 𝐛𝐛 person-month

= 2.8(100) 1.20

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


=703 person-month

Duration estimation(D)= 𝐜𝐛 (E) 𝐝𝐛 months

=2.5(703)0.32

=20 months

Person Estimation i.e., Productivity(P)= (E/D)

=703/20

=35 persons

Exam Questions
• Explain Work Break Down Structure in detail

• Explain Scheduling techniques in Software Engineering (CPM & PERT)


• Write short note on Timeline Chart

• Short note on Earned Value Analysis

Project Scheduling

Project scheduling is a significant project planning activity. It comprises deciding which

functions would be taken up when.

To schedule the project plan, a software project manager wants to do the following:

• Identify all the functions required to complete the project.

• Break down large functions into small activities.

• Determine the dependency among various activities.

• Establish the most likely size for the time duration required to complete the
activities.

• Allocate resources to activities.

• Plan the beginning and ending dates for different activities.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• Determine the critical path. A critical way is the group of activities that decide the
duration of the project.

Work Break Down Structure (WBS)

• Dividing complex projects to simpler and manageable tasks is the process


identified as Work Breakdown Structure (WBS).

• In WBS, much larger tasks are broken down to manageable chunks of work. These

chunks can be easily supervised and estimated.

• WBS is not restricted to a specific field when it comes to application.

• This methodology can be used for any type of project management.

Reasons for creating a WBS in a project:

• Accurate and readable project organization.

• Accurate assignment of responsibilities to the project team.

• Indicates the project milestones and control points.

• Helps to estimate the cost, time and risk.

• Illustrate the project scope, so the stakeholders can have a better understanding

of the same.

Construction of WBS

• Identifying the main deliverables of a project is the starting point for deriving a

work breakdown structure.

• This important step is usually done by the project managers and the subject
matter experts (SMEs) involved in the project. Once this step is completed, the

subject matter experts start breaking down the high-level tasks into smaller
chunks of work.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• In the process of breaking down the tasks, one can break them down into different
levels of detail. One can detail a high-level task into ten sub-tasks while another

can detail the same high-level task into 20 sub-tasks.

• Therefore, there is no hard and fast rule on how you should breakdown a task in
WBS. Rather, the level of breakdown is a matter of the project type and the

management style followed for the project.

• In general, there are a few "rules" used for determining the smallest task chunk. In
"two weeks" rule, nothing is broken down smaller than two weeks’ worth of work.

• This means, the smallest task of the WBS is at least two-week long. 8/80 is another
rule used when creating a WBS. This rule implies that no task should be smaller

than 8 hours of work and should not be larger than 80 hours of work.

• One can use many forms to display their WBS. Some use tree structure to illustrate
the WBS, while others use lists and tables. Outlining is one of the easiest ways of

representing a WBS.

Outline of WBS

Designing goals of WBS

• Giving visibility to important work efforts.

• Giving visibility to risky work efforts.

• Illustrate the correlation between the activities and deliverables.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• Show clear ownership by task leaders.

WBS Diagram

• In a WBS diagram, the project scope is graphically expressed. Usually, the diagram
starts with a graphic object or a box at the top, which represents the entire project.

Then, there are sub-components under the box.

• These boxes represent the deliverables of the project. Under each deliverable,

there are sub-elements listed. These sub-elements are the activities that should be
performed in order to achieve the deliverables.

• Although most of the WBS diagrams are designed based on the deliveries, some

WBS are created based on the project phases. Usually, information technology
projects are perfectly fit into WBS model.

• Therefore, almost all information technology projects make use of WBS.

• WBS is the input for Gantt charts, a tool that is used for project management
purpose.

• Gantt chart is used for tracking the progression of the tasks derived by WBS.

Example of WBS

Benefits of WBS

• Project budget and schedule can be easily calculated

• Helps for identifying project risk in given project

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• If project is failing, the WBS can find out the major deliverables impacted.

Project Scheduling Techniques

1. CRM: Critical Path Method

2. PERT: Program Evaluation Review Technique

1. CRM: Critical Path Method

• Critical path is the sequential activities from start to the end of a project.

• Although many projects have only one critical path, some projects may have more
than one critical path depending on the flow logic used in the project.

• If there is a delay in any of the activities under the critical path, there will be a

delay of the project deliverables.

• Most of the times, if such delay is occurred, project acceleration or re-sequencing

is done in order to achieve the deadlines.

• Critical path method is based on mathematical calculations and it is used for


scheduling project activities. T

• his method was first introduced in 1950s as a joint venture between Remington

Rand Corporation and DuPont Corporation

• The initial critical path method was used for managing plant maintenance projects.

• Although the original method was developed for construction work, this method

can be used for any project where there are interdependent activities.

• In the critical path method, the critical activities of a program or a project are
identified. These are the activities that have a direct impact on the completion

date of the project.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Key Steps in Critical Path Method

Step 1: Activity specification

Step 2: Activity sequence establishment

Step 3: Network diagram

Step 4: Estimates for each activity

Step 5: Identification of the critical path

Step 6: Critical path diagram to show project progresses

Step 1: Activity specification

You can use the Work Breakdown Structure (WBS) to identify the activities involved in the
project. This is the main input for the critical path method.

In activity specification, only the higher-level activities are selected for critical path
method.

When detailed activities are used, the critical path method may become too complex to

manage and maintain.

Step 2: Activity sequence establishment

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


In this step, the correct activity sequence is established. For that, you need to ask three
questions for each task of your list.

• Which tasks should take place before this task happens?

• Which tasks should be completed at the same time as this task?

• Which tasks should happen immediately after this task?

• Step 3: Network diagram

• Once the activity sequence is correctly identified, the network diagram can be
drawn (refer to the sample diagram above).

• Although the early diagrams were drawn on paper, there are a number of
computers softwares, such as Primavera, for this purpose nowadays.

• Step 4: Estimates for each activity

• This could be a direct input from the WBS based estimation sheet. Most of the
companies use 3-point estimation method or COCOMO based (function points

based) estimation methods for tasks estimation.

Step 5: Identification of the critical path

For this, you need to determine four parameters of each activity of the network.

• Earliest start time (ES) - The earliest time an activity can start once the previous

dependent activities are over.

• Earliest finish time (EF) - ES + activity duration.

• Latest finish time (LF) - The latest time an activity can finish without delaying the
project.

• Latest start time (LS) - LF - activity duration.

The float time for an activity is the time between the earliest (ES) and the latest (LS) start
time or between the earliest (EF) and latest (LF) finish times.

During the float time, an activity can be delayed without delaying the project finish date.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


The critical path is the longest path of the network diagram. The activities in the critical
path have an effect on the deadline of the project. If an activity of this path is delayed,

the project will be delayed.

In case if the project management needs to accelerate the project, the times for critical
path activities should be reduced.

Step 6: Critical path diagram to show project progresses

Critical path diagram is a live artefact. Therefore, this diagram should be updated with
actual values once the task is completed.

This gives more realistic figure for the deadline and the project management can know

whether they are on track regarding the deliverables.

Advantages of Critical Path Method

Following are advantages of critical path methods:

• Offers a visual representation of the project activities.

• Presents the time to complete the tasks and the overall project.

• Tracking of critical activities.

• Summary

• Critical path identification is required for any project-planning phase. This gives

the project management the correct completion date of the overall project and
the flexibility to float activities.

• A critical path diagram should be constantly updated with actual information

when the project progresses in order to refine the activity length/project duration
predictions.

• 2. PERT

• PERT (Program Evaluation and Review Technique) is one of the successful and
proven methods among the many other techniques, such as, CPM, Function Point

Counting, Top-Down Estimating, WAVE, etc.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• PERT was initially created by the US Navy in the late 1950s. The pilot project was
for developing Ballistic Missiles and there have been thousands of contractors

involved.

• After PERT methodology was employed for this project, it actually ended two years
ahead of its initial schedule.

PERT also breaks down the tasks into detailed activities.

Then, a Gantt chart will be prepared illustrating the interdependencies among the

activities. Then, a network of activities and their interdependencies are drawn in an


illustrative manner.

In this map, a node represents each event. The activities are represented as arrows and
they are drawn from one event to another, based on the sequence.

Next, the Earliest Time (TE) and the Latest Time (TL) are figured for each activity and

identify the slack time for each activity.

When it comes to deriving the estimates, the PERT model takes a statistical route to do
that. We will cover more on this in the next two sections.

The Three Chances

There are three estimation times involved in PERT; Optimistic Time Estimate (TOPT), Most
Likely Time Estimate (TLIKELY), and Pessimistic Time Estimate (TPESS).

1. TOPT

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


This is the fastest time an activity can be completed. For this, the assumption is made that
all the necessary resources are available and all predecessor activities are completed as

planned.

2. TLIKELY

Most of the times, project managers are asked only to submit one estimate. In that case,
this is the estimate that goes to the upper management.

3. TPESS

This is the maximum time required to complete an activity. In this case, it is assumed that
many things go wrong related to the activity. A lot of rework and resource unavailability

are assumed when this estimation is derived.

The PERT Mathematics

BETA probability distribution is what works behind PERT. The expected completion time

(E) is calculated as below:

E = (TOPT + 4 x TLIEKLY + TPESS) / 6

At the same time, the possible variance (V) of the estimate is calculated as below:

V = (TPESS - TOPT) ^2 / 6^2

Now, following is the process we follow with the two values:

For every activity in the critical path, E and V are calculated.

Then, the total of all Es is taken. This is the overall expected completion time for the
project.

Now, the corresponding V is added to each activity of the critical path. This is the

variance for the entire project. This is done only for the activities in the critical path as

only the critical path activities can accelerate or delay the project duration.

Then, standard deviation of the project is calculated. This equals to the square root of the
variance (V).

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Now, the normal probability distribution is used for calculating the project completion
time with the desired probability.

Advantages

• A PERT chart allows managers to evaluate the time and resources necessary to

manage a project.

• PERT analysis incorporates data and information from multiple departments.

• PERT charts are useful for what-if analyses

Disadvantages

• The use of a PERT chart is highly subjective and its success depends on the

management’s experience.

• PERT charts are deadline-focused and they might not fully communicate

the financial positioning of a project.

• Summary

• The best thing about PERT is its ability to integrate the uncertainty in project times
estimations into its methodology.

• It also makes use of many assumption that can accelerate or delay the project
progress. Using PERT, project managers can have an idea of the possible time
variation for the deliveries and offer delivery dates to the client in a safer manner.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


TimeLine Charts

• A timeline chart is an effective way to visualize a process using chronological

order.

• Since details are displayed graphically, important points in time can be easy seen
and understood.

• Often used for managing a project’s schedule, timeline charts function as a sort of
calendar of events within a specific period of time.

Why make Timeline Charts?

• Staying on track can be a struggle.

• It becomes much easier to see what needs to be done, how long it will take,
and what the next steps are.

• Since each step is documented along an easy-to-follow timescale, there’s no

misunderstanding of when goals should be met and how many hours a project
should take.

How to make a timeline chart

• Begin by listing each milestone throughout your project.

• Place these milestones along a horizontal line, from start to finish.

• Associate each step with a specific date to represent a deadline.

• Include titles to clarify key points along the process (phases, testing, planning,

etc.).

Gantt Chart

• Generalized Activity Normalization Time Table (GANTT) chart is type of chart

in which series of horizontal lines are present that show the amount of work done
or production completed in given period of time in relation to amount planned for
those projects.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• It is horizontal bar chart developed by Henry L. Gantt (American engineer and
social scientist) in 1917 as production control tool.

• It is simply used for graphical representation of schedule that helps to plan in

an efficient way, coordinate, and track some particular tasks in project.

• The purpose of Gantt chart is to emphasize scope of individual tasks. Hence


set of tasks is given as input to Gantt chart.

• Gantt chart is also known as timeline chart.

• It can be developed for entire project or it can be developed for individual


functions.

• In most of projects, after generation of timeline chart, project tables are prepared.

• In project tables, all tasks are listed in proper manner along with start date and
end date and information related to it.

Gantt chart represents following things:

• All the tasks are listed at leftmost column.

• The horizontal bars indicate or represent required time by corresponding


particular task.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


• When occurring of multiple horizontal bars takes place at same time on calendar,
then that means concurrency can be applied for performing particular tasks.

• The diamonds indicate milestones.

Advantages:

• Simplify Project –
Gantt charts are generally used for simplifying complex projects.

• Establish Schedule –
It simply establishes initial project schedule in which it mentions who is going to

do what, when, and how much time it will take to complete it.

• Provide Efficiency –
It brings efficiency in planning and allows team to better coordinate project

activities.

• Emphasize on scope –
It helps in emphasizing i.e., gives importance to scope of individual tasks.

• Ease at understanding –
It makes it for easy stakeholders to understand timeline and brings clarity of dates.

• Visualize project –
It helps in clearly visualizing project management, project tasks involved.

• Organize thoughts and Highly visible –

It organizes your thoughts and can be highly visible so that everyone in


enterprises can have basic level of understanding and have knowledge about

what’s happening in project even if they are not involved in working.

• Make Practical and Realistic planning –


It makes the project planning practical and realistic as realistic planning generally
helps to avoid any kind of delays and losses of many that can arise.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)


Disadvantages:

• Sometimes, using Gantt chart makes project more complex.

• The size of bar chart dost not necessarily indicate amount of work done in project.

• Gantt charts and projects are needed to be updated on regular basis.

• It is not possible or difficult to view this chart on one sheet of paper.

• The software products that produce Gantt chart needed to be viewed on


computer screen so that whole project can be seen easily.

Applications

• Advertising Manager –
Advertising Managers generally controls and supervises end result of advertising

companies, scheduling advertisements in different media, etc.

• Operations Manager –

Operations Managers generally control and handle resources that are essential for
company operations.

• Project Manager –

Project Managers generally motivates project teams, collaborate with team


members, schedule task and complete that on time, and report to stakeholders,

etc.

Chapter 3. Software Estimation Metrics Prepared by Prita PatilVIT-CMPN)

You might also like