UNIT -3

Project Scheduling
and Tracking
 Introduction
Project scheduling and Tracking begins with:
● Identification of process models,
● Identification of software tasks and activities,
● Estimation of effort and work.
and ends with:
● Creation of network of tasks
● On time delivery of the project.
This network is adapted on encountering of changes and risks.
The project schedule evolves over time.
2
 Project Scheduling
Project scheduling involves organizing tasks efficiently in software
projects.
The key steps a software project manager follows:
● Identify Activities: List all major tasks that need to be completed.
● Break Down Tasks: Divide tasks into smaller, manageable steps for
easier execution.
● Understand Dependencies: Determine which tasks depend on
others and the sequence in which they must be completed.
● Time Estimates: Estimate the time required for each task,
considering factors like complexity and resources.
3
 Project Scheduling
● Create Activity Network: Visualize task relationships using an
activity network or flowchart to see how tasks are
interconnected.
● Task Dates: Set start and end dates for each task, considering
dependencies and resource availability.
● Critical Path Analysis: Tasks on the critical path must be
completed on time to avoid project delays. The critical path is the
path with the longest duration.
● Allocate Resources to Tasks: This involves assigning the right
people, equipment, and materials to each task to ensure smooth
execution.
4
 Project Scheduling Basic principle
● Modularization: Divide the project into manageable activities
and tasks
● Interdependency: Determine how tasks relate to each other -
some must happen sequentially, while others can happen
simultaneously or independently.
● Time Allocation: Assign start and end dates to each task.
● Effort Validation: People working on tasks at any given time
doesn't exceed the allocated resources.

5
 Project Scheduling Basic principle
● Defined Responsibilities: Assign each task to a specific team
member.
● Defined Outcomes: Each task should have a clear goal or
outcome, such as producing a work product like a component
design.
● Defined Milestones: Associate each task with project
milestones that mark completion of significant work products.

6
 Defining Task Set For Software Project
● A task set is a collection of software engineering work tasks,
milestones, and deliverables that must be accomplished to complete a
particular project.
● Task set is dependant upon types of projects and degrees of rigor with
which the software team decides to do the work.
Degree of Rigor:
It is function of several project characteristics. As an example, small,
non-business-critical projects can generally be addressed with less rigor
than large, complex business-critical applications.
7
 Defining Task Set For Software Project
Four different degrees of rigor defined are:
● Casual: Umbrella tasks will be minimized and documentation
requirements will be reduced.
● Structured: Framework activities and umbrella activities necessary to
ensure high quality will be applied. SQA, SCM measurement and
documentation tasks will be conducted in a streamlined manner.
● Strict: The umbrella activities will be applied with discipline which will
ensure high quality of project and robust documentation will be
produced.
● Quick Reaction: Tasks essential to maintain a good quality will be
applied because of emergency situation. A complete set of
documentation, conducting additional reviews will be accomplished.
8
 Gantt Chart
● A Gantt chart is a project management tool that illustrates work
completed over a period of time in relation to the time planned
for the work.
● It is introduced by Henry Gantt.
● It typically includes two sections: a list of tasks and a timeline
with schedule bars that visualize work.
● To prepare Gantt chart, JIRA software is used by the project
manager.

9
 Gantt Chart
Gantt charts gives a clear overview of:

● The entire project schedule

● Time estimates
● Assigned project team members
● Task priorities
● Task dependency

10
 Gantt Chart
Project managers use Gantt charts for three main reasons:
● Build and manage a comprehensive project: Gantt charts
visualize a project and organize it into smaller, manageable tasks.
These small tasks are scheduled on the Gantt chart’s timeline, along
with dependencies between tasks.
● Determine logistics and task dependencies: The goal of logistics
is to meet customer requirements in a timely, cost-effective manner.
Task dependencies ensure that a new task can only start once
another task is completed.
● Monitor progress of a project: Gantt chart can include release
dates, milestones, or other important metrics to track your project’s
progress.
11
Gantt Chart

12
13
 PERT Chart
● PERT stands for Program/Project Evaluation & Review
Technique.
● PERT chart is a project management tool that provides a
graphical representation of a project’s tasks.
● It helps you to estimate the time required to complete each task
and identify dependencies between tasks.

14
 PERT Chart
Basic layout of a PERT chart consists of three main components:
● A network diagram that shows the sequence and dependencies
between project tasks [flow]
● Time estimates for each task, along with their estimated
completion date [duration]
● Critical path analysis to determine which tasks are most
important and must be completed on schedule
[priorities/dependencies]
15
 PERT Chart

PERT chart for constructing a House

16
PERT Chart

17
PERT Chart

18
19
 Software Project Estimation
● Estimation is a process to predict the time and the cost that a
project requires to be finished appropriately.
● Software project estimation is a form of problem solving i.e.,
developing a cost and effort estimate for a software project.
The four basic steps in Software Project Estimation are −
● Estimate the size of the development product.
● Estimate the cost of project in agreed currency.
● Estimate the effort in person-months or person-hours.
● Estimate the schedule in calendar months.

20
 Size-oriented Software metrics
● It derived by normalizing quality and productivity measures by
considering software size that has been produced.
● The organization builds a simple record of size measure for the
software projects. It is built on past experiences of
organizations.

21
 Size-oriented Software metrics
● This metrics is one of simplest and earliest metrics that is used for
computer program to measure size.
● It is also used for measuring and comparing productivity of
programmers.
● The size measurement is based on lines of code computation. The
lines of code are defined as one line of text in a source file.
● While counting lines of code, simplest standard is:
+ Don’t count blank lines
+ Don’t count comments
+ Count everything else
22
 Size-oriented Software metrics
Simple set of size measure that can be developed is:

23
 Size estimation: Line Of Code (LOC)
+ Line Of Code is simplest among all metrics available to
estimate project size.
+ It count the total number of lines of source code in a
project.
+ The units of LOC are:
• KLOC- Thousand lines of code
• NLOC- Non comment lines of code
• KDSI- Thousands of delivered source instruction

24
 Line Of Code (LOC)
If LOC simply contains
the lines of code, then
figure shown has 18 LOC.
When comments and
blank lines are ignored
then it has 17 LOC.

Fig.: Function for sorting an array

25
 Line Of Code (LOC)
Advantages:
• Universally accepted and is used in many models like COCOMO.
• Estimation is closer to developer’s perspective.
• Simple to use.

Disadvantages:
• Different programming languages contains different number of
lines.
• No proper industry standard exist for this technique.
• It is difficult to estimate the size using this technique in early
stages of project.
26
 Function Points (FP)
+ Alan Albrecht while working for IBM, recognized the problem
in size measurement in the 1970s, and developed a
technique (which he called Function Point Analysis), which
appeared to be a solution to the size measurement problem.

+ Function Point Analysis (FPA) is a method or set of rules of

Functional Size Measurement.

27
 Objectives of FPA
1. To measure functionality that the user can request and
receives.
2. To measure software development and maintenance
independently of technology used for implementation.
3. To minimize the overhead of the measurement process.
4. To be a consistent measure among various projects and
organizations.

28
 Function Points (FP)- Special features
• Function point approach is independent of the language, tools,
or methodologies used for implementation; i.e. they do not take
into consideration programming languages, database
management systems, processing hardware or any other
database technology.
• Function points can be estimated from requirement
specification or design specification, thus making it possible to
estimate development efforts in early phases of development.

29
 Function Points (FP)- Special features
• Function points are directly linked to the statement of
requirements; any change of requirements can easily be
followed by a re-estimate.
• Function points are based on the system user’s external view
of the system, non-technical users of the software system have
a better understanding of what function points are measuring.

30
 Function Points (FP) Merits
• FPA measures the size of the solution instead of the size of
the problem
• It helps in estimating overall project costs, schedule, and
effort
• It is independent of technology/programming language
• It helps in the estimation of testing projects
• FPA gives clarity in contract negotiations as it provides a
method of easier communication with business groups.

31
 Types of FP Attributes
Various functions used in an application can be put under five
functional units, as shown in Table:

All these parameters are then individually assessed for complexity.

32
33
34
 Function Points (FP) computing steps
Step1:
Each function point is ranked according to the complexity
i.e., Low(simple), Average, High(Complex).
There exists pre-defined weights.

Table:
Functional
units with
weighting
factors
35
Step2:
Calculate Unadjusted Function Point (UFP) by manipulating
each function point by its corresponding weight factor.

Where = counting functional units

And = weighing factors
For example, if we have 5 EI and 6 EO of Low and Complex
category respectively, then
UFP = 5 * 3 + 6* 7 = 57
36
Step 3:
Calculate Complexity Adjustment factor (CAF) using 14 aspects of
processing complexity.

∑(fi) is the sum of all 14 questionnaires (where i ranges from 1 to

14). Usually, a student is provided with the value of ∑(fi).

All 14 questions are answered

on the scale of 0 to 5.

37
Step 4:
Calculate final
Function point.
FP = UFP * CAF

The Fi (i = 1 to 14)
are "complexity
adjustment values"
based on responses
to the following
questions :
38
Function Points (FP)
Functions points may compute the following important
metrics:
Productivity = FP / Efforts in persons-months
Quality = Defects / FP
Cost per function= Rupees / Productivity
Documentation = Pages of documentation / FP

39
 Function Points Example-1
Given the following values, compute function point when all
complexity adjustment factor (CAF) and weighting factors are
average.

User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4

40
Step 1: As complexity adjustment factor is average so scale is
3.
Scale varies from 0 to 5 according to character of Complexity
Adjustment Factor (CAF) as shown below:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average ∑(fi) = 14 * 3 = 42
4 - Significant
5 - Essential
41
Step 2: Calculate Unadjusted Function Point (UFP).

= 50*4 + 40*5 + 35*4 + 6*10 + 4*7

= 628

User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Step 3: Calculate Complexity Adjustment Factor (CAF).

= 0.65+ 0.01 * 42
= 0.65 + 0.42
= 1.07
Step 4: Compute FP.
FP = UFP * CAF
= 628 * 1.07
= 671.96

43
 Function Points Example-2
Compute the function point when complexity adjustment
factor (CAF) is significant and weighting factor is complex
for the following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
44
 Function Points Example-3
Calculate the function point, productivity, documentation, and
cost per function for software application with multiple
adjustment Factors 5, 1, 0, 4, 3, 5, 4, 3, 4, 5, 2, 3, 4, 2 by using
following given Date: The number of EI(Avg): 22, The number
of EO(Low): 45, The number of EQ(High): 06, The number of
ILF(Avg): 05, The number of ELF(Low): 02, Effort:37 MM,
Software technical documents: 250 pages, User related
documents: 120 pages and Budgeting/Cost: $7520 per
month.
45
Step 1: ∑(fi) = 5+1+0+4+3+ 5+4+3+4+5+ 2+3+ 4+2 = 45
Step 2:

= (22*4) + (45*4) + (6*6) + (5*10) + (2*5)

= 364
Step 3:
= 0.65 + 0.01*45
= 1.10
Step 4: FP = UFP * CAF
= 364 * 1.10
= 400.4
Productivity = FP / Efforts
= 404.4 / 37
= 10.82
Total Page of Documentation (PD) = Software Technical Documents + User
related documents
= 250 + 120
= 370 pages
Documentation = Pages of documentation / FP
= 370/404.4 = 0.91
Cost per function= Rupees / Productivity
= $7520 / 10.82 = $695
47
 Empirical Estimation Models
• Empirical estimation technique are based on the data taken
from the previous project and some based on guesses and
assumptions.
• While using this technique, prior experience with development
of similar products is helpful.
• Although empirical estimation techniques are based on
common sense, different activities involved in estimation have
been formalized over the years.
• Two popular empirical estimation techniques are: Expert
judgment technique and Delphi cost estimation.
48
 1. Expert Judgment Technique
• Expert judgment is one of the most widely used estimation
techniques. In this approach, an expert makes an educated guess
of the problem size after analyzing the problem thoroughly.
• Usually, the expert estimates the cost of the different components
that is modules and sub-modules of the system and finally
combines them to arrive at the overall estimate.
• However, this technique is subject to human errors and individual
bias. Also, it is possible that the expert may overlook some factors
inadvertently.
49
 1. Expert Judgment Technique
• Further, an expert making an estimate may not have experience and
knowledge of all aspects of a project.
• A more refined form of expert judgment is the estimation made by
group of experts.
• Estimation by a group of experts minimizes factors such as individual
oversight, lack of familiarity with a particular aspect of a project,
personal bias, and the desire to win contract through overly
optimistic estimates.
• However, the estimate made by a group of experts may still exhibit
bias on issues where the entire group of experts may be biased due
to reasons such as political considerations.
50
 2. Delphi Cost Estimation
• Delphi cost estimation approach tries to overcome some of the
shortcomings of the Expert judgment approach.
• Delphi estimation is carried out by a team comprising of a group of
experts and a coordinator.
• In this approach, the coordinator provides each estimator with a
copy of the SRS document and a form for recording his cost
estimate.
• Estimators complete their individual estimates anonymously and
submit to the coordinator.
51
 2. Delphi Cost Estimation
• The coordinator prepares and distributes the summary of the
responses of all the estimators, and includes any unusual
rationale noted by any of the estimators.
• Based on this summary, the estimators re-estimate. This
process is iterated for several rounds.
• However, no discussion among the estimators is allowed during
the entire estimation process.

52
 2. Delphi Cost Estimation
• The idea behind this is that if any discussion is allowed among
the estimators, then many estimators may easily get influenced
by the rationale of an estimator who may be more experienced
or senior.
• After the completion of several iterations of estimations, the
coordinator takes the responsibility of compiling the results and
preparing the final estimate.

53
 COCOMO Model
• The Constructive Cost Model was first developed by Barry W.
Boehm.
• The model is for estimating effort, cost, and schedule for software
projects.
• It 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:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
54
Comparison of COCOMO I and COCOMO II

55
 COCOMO Model-II
• It is the revised version of the original COCOMO (Constructive
Cost Model) and is developed at University of Southern
California by Barry Boehm.
• It is the model that allows one to estimate the cost, effort and
schedule when planning a new software development activity.
• It is useful in non-sequential, rapid development and reuse
models of software.

56
 COCOMO Model-II
• Like its predecessor, COCOMO II is actually a hierarchy of
estimation models that address different “stages” of the
software process.
• It has four different models:
1. Application-composition model
2. Early design model
3. Reuse model
4. Post-architecture model

57
58
 1. Application composition model
It was introduced to support the estimation of effort required for
prototyping projects and for projects where the software is
developed by composing existing components.

• PM is the effort estimate in person-months.

• NAP is the total number of application points in the delivered
system.
• % reuse is an estimate of the amount of reused code in the
development.
• PROD is the object-point productivity
59
 2. An early design model
This model is used during early stages of the system design after the
requirements have been established.

• A should be 2.94 (Boehm)

• The size of the system is expressed in KLOC
• B reflects the increased effort required as the size of the project
increases. It varies from 1.1. to 1.24
• M is based on a simplified set of seven project and process
characteristics that influence the estimate
60
These characteristics used in the early design model are
1. Personnel capability (PERS)
2. Product reliability and complexity (RCPX),
3. Reuse required (RUSE),
4. Platform difficulty(PDIF),
5. Personnel experience (PREX),
6. Schedule (SCED)
7. Support facilities (FCIL).
61
 3. A reuse model
● It is used to compute the effort required to integrate reusable
components and/or program code that is automatically generated by
design or program translation tools.
● For code that is automatically generated, the model estimates the
number of person-months required to integrate this code.
E = (ALOC x AT/100)/ATPROD
○ ALOC represents the number of LOC.
○ AT represents the automatically produced adapted code percentage.
○ ATPROD represents the productivity. It may be worth up to 2400 LOC
every month.
62
Example:
If there is a total of 20,000 lines of white-box reuse code in a
system and 30% of this is automatically generated, then the
effort required to integrate this generated code is:

(20,000 * 30/100) / 2400 = 2.5 person months

63
 4. Post-architecture model
• Once the system architecture has been designed, a more
accurate estimate of the software size can be made.
• The size estimate for the software should be more accurate by
this stage in the estimation process.

64
 4. Post-architecture model
The estimate of the code size in the post-architecture model is
computed using three components:
1. An estimate of the total number of lines of new code to be
developed.
2. An estimate of the equivalent number of source lines of code
(ESLOC) calculated using the reuse model
3. An estimate of the number of lines of code that have to be
modified because of changes to the requirements.

65