TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

Project Scheduling and Tracking in Software Engineering

1. Introduction
Project scheduling and tracking are essential activities in software engineering that help manage time,
resources, and progress to ensure successful project completion.

2. Project Scheduling

Project scheduling involves planning and defining the timeline of tasks and activities to complete a software
project efficiently.

2.1 Key Steps in Project Scheduling

1. Define Project Scope: Identify objectives, deliverables, and constraints.

2. Work Breakdown Structure (WBS): Divide the project into smaller tasks and subtasks.

3. Estimate Time and Resources: Determine effort, duration, and required resources for each
task.

4. Sequence Tasks: Establish dependencies using techniques such as:

o Gantt Charts: Visual representation of tasks over time.

o PERT (Program Evaluation and Review Technique): Graphical method for

analyzing dependencies.

o CPM (Critical Path Method): Identifies the longest sequence of dependent tasks to
determine the shortest completion time.

5. Allocate Resources: Assign team members to tasks based on expertise and availability.

6. Set Milestones and Deadlines: Define important checkpoints for progress tracking.

7. Use Scheduling Tools: Utilize software like Microsoft Project, Jira, or Trello.

3. Project Tracking
Project tracking ensures the project remains on schedule and meets objectives by continuously monitoring
progress.

3.1 Key Steps in Project Tracking

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

1. Monitor Task Progress: Regularly review task status and compare with planned timelines.

2. Track Team Performance: Assess productivity and resolve bottlenecks.

3. Use Project Tracking Metrics:

o Schedule Variance (SV): Difference between planned and actual progress.

o Cost Variance (CV): Difference between estimated and actual costs.

o Burn-down Charts: Track remaining work versus time.

o Velocity (in Agile): Measures work completed in a sprint.

4. Conduct Regular Meetings: Use daily stand-ups (Scrum), weekly reviews, or milestone
meetings.
5. Identify Risks and Issues: Track potential risks and apply mitigation strategies.

6. Adjust Plans as Needed: Reschedule tasks or reallocate resources if necessary.

7. Use Project Management Tools: Tools like Jira, Asana, or Monday.com facilitate tracking and
collaboration.

4. Importance of Project Scheduling and Tracking

• Ensures timely project completion.

• Helps in resource optimization.

• Improves team collaboration and communication.

• Reduces project risks and bottlenecks.

• Enhances project quality and customer satisfaction.

Project scheduling provides a structured approach for planning software development tasks, while tracking
ensures projects stay on course. Utilizing proper methodologies, tools, and regular monitoring, teams can
efficiently deliver software projects within scope, time, and budget.

Software Project Estimation:

1. Introduction to Software Project Estimation

Software project estimation is the process of predicting the effort, time, cost, and resources required to develop
a software system. It plays a crucial role in project planning, budgeting, and scheduling to ensure successful
project completion.
1.1 Importance of Software Project Estimation

• Helps in setting realistic project timelines.

Asst. Prof Aadarsh Shinde
TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

• Assists in budget allocation and cost management.

• Ensures efficient resource utilization.

• Reduces project risks and uncertainties.

• Enhances customer satisfaction by setting achievable expectations.

2. Software Project Estimation Techniques

Several estimation techniques are used in software engineering, with the most common being Lines of Code
(LOC) and Function Point (FP) Analysis.
2.1 Lines of Code (LOC) Estimation
LOC-based estimation measures the size of a software project by counting the number of lines in the source
code.
Definition: LOC represents the total number of lines in the source code, including executable statements but
excluding comments and blank lines.
2.1.1 Steps in LOC Estimation

1. Identify the programming language to be used.

2. Estimate the expected number of lines of code.

3. Determine productivity (LOC per person-month).

4. Use historical data to refine estimates.

2.1.2 LOC Estimation Formula

• Estimated Effort (Person-Months) = (Estimated LOC) / (Productivity Rate)

• Estimated Time (Months) = Effort / Number of Developers

2.1.3 Advantages of LOC Estimation

• Simple and easy to understand.

• Useful for projects where historical LOC data is available.

• Works well for projects using similar technology and programming languages.

2.1.4 Disadvantages of LOC Estimation

• Language-dependent: Different languages require different LOC for the same functionality.
• Ignores complexity: A simple function may require many lines, while a complex function may
require fewer lines.

• Difficult for early estimation: LOC is unknown in the early stages of development.

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

2.2 Function Point (FP) Estimation

Function Point (FP) estimation focuses on measuring the functionality delivered to the user rather than the size
of the code. It is independent of programming languages.

Definition: A function point represents a unit of business functionality, considering user inputs, outputs, and
data management.

2.2.1 Steps in FP Estimation

1. Identify system functionalities, including:

• Formula:

2. FP = (UFP) × (Value Adjustment Factor)

Where UFP (Unadjusted Function Points) is calculated based on:

o External Inputs (EI)

o External Outputs (EO)

o External Inquiries (EQ)

o Internal Logical Files (ILF)

o External Interface Files (EIF)

3. Assign complexity weights to each function (Simple, Average, or Complex).

4. The Value Adjustment Factor (VAF) adjusts for complexity and environment.
5. Calculate Unadjusted Function Points (UFP):

o UFP = Sum of (Function Count × Complexity Weight)

6. Determine the Value Adjustment Factor (VAF) based on system characteristics (ranging
from 0.65 to 1.35).

7. Compute Adjusted Function Points (FP):

o FP = UFP × VAF
2.2.2 Advantages of FP Estimation

• Language-independent: Can be applied across different technologies.

• Considers complexity: Provides a better measure of system functionality.

• Useful for early estimation: Can be done in the planning phase.

2.2.3 Disadvantages of FP Estimation

• Complex to calculate: Requires expertise to evaluate function weights.

Asst. Prof Aadarsh Shinde
TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

• Subjective assessment: Different evaluators may estimate different FP values.

3. Other Software Estimation Techniques

3.1 COCOMO (Constructive Cost Model)

A mathematical model for estimating cost and effort based on LOC.

• Basic COCOMO: Simple projects.

• Intermediate COCOMO: Includes cost drivers like experience and hardware.

• Detailed COCOMO: Covers all aspects of software development.

3.2 Use Case Point Estimation

Estimates project size based on Use Case Diagrams by considering actors, transactions, and system
complexity.

3.3 Expert Judgment Estimation

• Based on past experience and expert opinions.

• Useful for quick estimates but can be subjective.

3.4 Delphi Method

• A group-based expert judgment technique where multiple rounds of estimation are conducted
until a consensus is reached.

Comparison of LOC and FP Estimation

Software project estimation is a vital process for planning and executing software projects successfully.
Choosing the right estimation technique—LOC, FP, or other models—depends on the project’s scope,
complexity, and available historical data.

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

Empirical Estimation Models in Software Engineering

1. Introduction

Empirical estimation models are mathematical models used to estimate the effort, cost, and schedule of
software projects based on historical data and statistical analysis. These models rely on empirical evidence
from past projects and provide realistic and data-driven estimates.

1.1 Importance of Empirical Estimation Models

• Provides data-based predictions rather than subjective guesses.

• Helps in early-stage estimation of project effort and cost.

• Useful for risk management by identifying potential overruns.

• Improves decision-making for resource allocation.

2. Types of Empirical Estimation Models

Several empirical models exist, with the most commonly used ones being:

1. COCOMO (Constructive Cost Model)

2. Putnam Model (SLIM - Software Lifecycle Management)

3. Function Point Analysis

4. Halstead’s Software Science

2.1 COCOMO (Constructive Cost Model)

COCOMO is one of the most widely used empirical models for estimating effort, cost, and schedule based on
the size of the software (measured in LOC - Lines of Code). It was developed by Barry Boehm in 1981 and
has different versions:
• Basic COCOMO (Simplest form)

• Intermediate COCOMO (Includes cost drivers like experience, hardware, etc.)

• Detailed COCOMO (Considers different phases of software development)

2.1.1 Basic COCOMO Model Formula

The basic formula for estimating effort (E), time (T), and cost is:

• Effort (E) = a × (KLOC)ᵇ (in Person-Months)

• Time (T) = c × (E)ᵈ (in Months)

Where:

• KLOC = Thousands of Lines of Code

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

• a, b, c, d = Constants based on project type

• Project Types in COCOMO:

o Organic: Simple projects (e.g., payroll systems)

o Semi-detached: Moderate complexity (e.g., database systems)

o Embedded: Complex, real-time systems (e.g., air traffic control)

Example of COCOMO Calculation

Suppose a software project has an estimated KLOC = 10 and follows an Organic project model.

For Organic Projects:

• a = 2.4, b = 1.05, c = 2.5, d = 0.38

Using the formulas:

• Effort (E) = 2.4 × (10)¹.⁰⁵ = 25.12 person-months

• Time (T) = 2.5 × (25.12)⁰.³⁸ = 7.5 months

This means the project will require 25.12 person-months of effort and approximately 7.5 months to
complete.

2.2 Putnam Model (SLIM - Software Lifecycle Management)

The Putnam model is based on the Rayleigh Curve and is useful for predicting manpower allocation over
time.
2.2.1 Putnam Model Formula

• Effort (E) = (Size / Productivity)^(4/3)

• Time (T) = (Effort)^(1/3) / Productivity Factor

Example of Putnam Model

If a project has an estimated size of 100 KLOC and the productivity factor is 500,

• Effort = (100 / 500)^(4/3) = 0.0128 person-years

• Time = (0.0128)^(1/3) / 500 ≈ 0.01 years

This means a very small team can complete the project quickly. The Putnam model is best used for long-term
resource allocation and cost estimation.

2.3 Function Point Analysis (FPA)

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

Instead of measuring software in lines of code, FPA estimates software functionality based on user
requirements.

2.3.1 Function Point Formula

• FP = UFP × VAF
Where:

• UFP (Unadjusted Function Points) = sum of all function types (inputs, outputs, files, etc.).

• VAF (Value Adjustment Factor) = adjusts for system complexity.

Example of Function Point Analysis

If a project has:

• 5 External Inputs (EI) = 5 × 3 = 15

• 4 External Outputs (EO) = 4 × 4 = 16

• 3 External Inquiries (EQ) = 3 × 3 = 9

• 2 Internal Logical Files (ILF) = 2 × 7 = 14

• 1 External Interface File (EIF) = 1 × 5 = 5

UFP = 15 + 16 + 9 + 14 + 5 = 59
If VAF = 1.1, then:

• FP = 59 × 1.1 = 64.9 function points

This helps estimate effort based on historical productivity rates.

2.4 Halstead’s Software Science Model

Developed by Maurice Halstead, this model estimates software effort based on the number of operators and
operands in the source code.

2.4.1 Halstead’s Formulas

• Program Length (N) = N₁ + N₂

• Program Volume (V) = N × log₂ (n₁ + n₂)

• Effort (E) = V / Productivity Factor

Where:
• N₁ = Number of operators

• N₂ = Number of operands

• n₁ = Unique operators

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

• n₂ = Unique operands

Example of Halstead’s Model

If a program has:

• N₁ = 20, N₂ = 30

• n₁ = 5, n₂ = 10

Then:
• N = 20 + 30 = 50

• V = 50 × log₂(5 + 10) = 50 × 3.91 = 195.5

If the productivity factor is 5,

• Effort = 195.5 / 5 = 39.1 person-hours

COCOMO II Model

1. Introduction to COCOMO II

COCOMO II (Constructive Cost Model II) is an updated version of the original COCOMO (Constructive
Cost Model) developed by Barry Boehm in 1981. COCOMO II was introduced in the 1990s to address
modern software development challenges, such as object-oriented programming, rapid application
development, and reusable components.

1.1 Purpose of COCOMO II

• Provides accurate effort and cost estimation for modern software projects.
• Supports different development methodologies, including agile and iterative models.

• Improves estimation for reusable software and emerging technologies.

• Adapts to changes in software development practices over time.

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

2. COCOMO II vs. Original COCOMO

3. COCOMO II Estimation Process

COCOMO II has three stages of estimation based on the software development lifecycle:

1. Application Composition Model (For early prototyping and small projects)

2. Early Design Model (For initial planning and cost estimation)

3. Post-Architecture Model (For detailed estimation after project architecture is defined)

4. COCOMO II Sub-Models and Formulas

4.1 Application Composition Model

Used in the early prototyping stage, based on object points instead of LOC.

• Effort (Person-Months) = (Object Points) / Productivity Rate

• Productivity Rate depends on developer experience and tools (e.g., 10-50 Object Points per
month).

Example: If a project has 500 Object Points and the team productivity is 20 points/month,

• Effort = 500 / 20 = 25 Person-Months

4.2 Early Design Model

Used during the initial planning phase when requirements are known, but architecture is not finalized.
Formula for Early Design Model:

• Effort (E) = A × (Size)ᵉ × EAF

o A = 2.94 (default constant)

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

o Size = KLOC (Thousands of Lines of Code) or Function Points

o e = 1.10 to 1.24 (scale factor based on project complexity)

o EAF = Effort Adjustment Factor (based on cost drivers)

Example Calculation:
If a project has 10 KLOC, a scale factor (e) of 1.15, and an EAF of 1.2,

• Effort = 2.94 × (10)¹.¹⁵ × 1.2 = 39.8 Person-Months

4.3 Post-Architecture Model

Used when the project architecture is defined, allowing for more accurate estimation.
Formula for Post-Architecture Model:

• Effort (E) = A × (Size)ᵉ × EAF

o Similar to the Early Design Model but with more refined cost drivers.

o Includes 17 cost drivers (e.g., reliability, complexity, team experience).

Example Calculation:
If a project has 50 KLOC, a scale factor (e) of 1.20, and an EAF of 1.15,

• Effort = 2.94 × (50)¹.² × 1.15 = 176.5 Person-Months

5. Cost Drivers in COCOMO II

COCOMO II refines project estimation using cost drivers that affect project effort and schedule. These are
categorized into four groups:

Example of Cost Driver Impact:

If developer experience is low, the effort increases due to a higher learning curve. If the team is highly
skilled, the effort decreases due to higher productivity.

Advantages & Disadvantages of COCOMO II

6.1 Advantages

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

✔ More Accurate Than Traditional COCOMO – Accounts for modern development practices.
✔ Supports Agile & Object-Oriented Development – Works well with iterative models.
✔ Considers Cost Drivers & Scale Factors – Improves estimation accuracy.
✔ Useful for Large & Complex Projects – Scalable across different industries.

6.2 Disadvantages

Complex to Apply – Requires experience to estimate cost drivers correctly.

Needs Historical Data – Accuracy depends on past project data.
Assumes Defined Architecture – Less useful in the early design phase without enough details.

Estimation in Agile: Planning Poker & User Story Planning

1. Introduction to Agile Estimation

Agile estimation focuses on relative sizing, collaboration, and flexibility rather than strict time-based
calculations. Unlike traditional estimation methods, Agile estimation helps teams quickly estimate effort and
complexity while adapting to changes.

1.1 Importance of Agile Estimation

• Helps teams prioritize work effectively.

• Encourages team collaboration and shared understanding.

• Focuses on relative effort rather than absolute time.

• Allows for continuous improvement and adaptation.

2. Planning Poker

Planning Poker is a consensus-based Agile estimation technique that helps teams estimate the effort required
for user stories. It is widely used in Scrum and Kanban frameworks.

2.1 How Planning Poker Works

1. Select a Moderator (usually the Scrum Master or Product Owner).

2. Present a User Story from the product backlog.

3. Discuss the Story to clarify scope, assumptions, and risks.

4. Each Team Member Selects a Card from a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.).

5. Reveal the Cards Simultaneously to avoid bias.

6. Discuss Discrepancies if estimates vary widely.

7. Repeat Until Consensus is Reached on an estimate.

2.2 Advantages of Planning Poker

Asst. Prof Aadarsh Shinde
TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

✔ Encourages team collaboration.

✔ Reduces estimation bias.
✔ Balances technical and business perspectives.
✔ Works well for small to medium projects.

2.3 Example of Planning Poker

• The team is estimating a "Login Feature".

• Team members choose estimates: 3, 5, 8, 5, 5.

• The majority votes for 5, and after discussion, the team agrees on 5 story points.

3. User Story Planning & Estimation

3.1 What is a User Story?

A User Story is a small, self-contained piece of functionality that describes a software feature from an end-
user’s perspective. It follows this format:

“As a [user], I want [feature] so that [benefit].”

3.2 Estimating User Stories in Agile

1. Break Down Large Stories into smaller, manageable tasks.

2. Use Relative Sizing by comparing stories to previously completed ones.

3. Assign Story Points using techniques like Fibonacci series or T-Shirt Sizing (S, M, L, XL).
4. Validate with Team to ensure a shared understanding.

3.3 Example of User Story Estimation

• User Story: “As a user, I want to reset my password via email so that I can regain access to
my account.”

• Estimation:

o Frontend work: 3 story points

o Backend work: 5 story points

o Testing: 2 story points

o Total: 5 story points (rounded based on complexity)

Comparison of Planning Poker & User Story Planning

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

Agile estimation techniques like Planning Poker and User Story Planning make estimation collaborative,
flexible, and effective. They help teams estimate effort and complexity rather than focusing on fixed
deadlines. By using these methods, Agile teams can improve accuracy, enhance team collaboration, and adapt
to changing requirements.

Project Scheduling: Timeline Charts, CPM, and Fishbone Diagram

1. Introduction to Project Scheduling

Project scheduling is the process of defining, planning, and organizing project tasks within a specified
timeframe. It helps in allocating resources, setting deadlines, and tracking progress. Various techniques are
used for effective scheduling, including Timeline Charts, Critical Path Method (CPM), and Fishbone
Diagrams.

2. Timeline Charts
2.1 What is a Timeline Chart?

A Timeline Chart is a graphical representation of project tasks arranged sequentially over a specified period. It
helps in visualizing task dependencies, deadlines, and milestones.
2.2 Features of Timeline Charts:

• Tasks are displayed in chronological order.

• Shows start and end dates of tasks.

• Helps in tracking progress and identifying delays.

• Often used in Gantt Charts for project scheduling.

2.3 Example of a Timeline Chart

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

3. Critical Path Method (CPM)

3.1 What is CPM?

The Critical Path Method (CPM) is a project scheduling technique used to identify the longest sequence of
dependent tasks and determine the shortest project completion time.

3.2 Steps in CPM:

1. List all project tasks and their dependencies.

2. Estimate duration for each task.

3. Identify dependencies between tasks.

4. Draw a network diagram to visualize task sequences.
5. Determine the critical path (longest path through the network).

3.3 Example of CPM Calculation

Consider a project with the following tasks:

4. Fishbone Diagram (Ishikawa Diagram)

4.1 What is a Fishbone Diagram?

A Fishbone Diagram, also known as the Ishikawa Diagram, is a visual tool used to identify potential causes of
problems in project scheduling. It helps in root cause analysis by categorizing issues into different factors.

4.2 Components of a Fishbone Diagram:

• Head (Effect): Represents the problem (e.g., project delay).

• Bones (Causes): Represent major factors contributing to the problem, such as:

o Manpower: Lack of skilled employees.

o Method: Poor planning or incorrect estimation.

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

o Machine: Technical failures or software bugs.

o Material: Unavailability of necessary resources.

o Management: Poor communication or leadership.

4.3 Example of a Fishbone Diagram in Project Scheduling

Problem: Project delay in software development

Causes:

• Manpower: Lack of trained developers.

• Method: Unclear requirements, improper scheduling.

• Machine: Outdated tools, slow servers.

• Material: Shortage of hardware or software resources.

• Management: Poor communication, ineffective decision-making.

5. Comparison of Techniques

Effective project scheduling requires visual tools and analytical methods to plan, track, and troubleshoot
project timelines. Timeline Charts offer a simple way to track progress, CPM helps in identifying critical
tasks, and the Fishbone Diagram assists in problem analysis. Using these techniques together ensures
successful project completion.

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

Difference Between PERT and CPM

PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are two popular
project scheduling techniques used in project management.

Asst. Prof Aadarsh Shinde

TCET SOFTWARE ENGINEERING_MODULE_3 SY_BVOC

Example for Better Understanding

PERT Example (Uncertain Activity Times)

Imagine you are developing a new mobile app and do not have exact time estimates.
For a task like UI design, you estimate:

• Optimistic Time (O) = 10 days

• Most Likely Time (M) = 15 days

• Pessimistic Time (P) = 25 days

Using PERT formula:

This means UI design may take around 16 days on average.

CPM Example (Fixed Activity Times)

For a road construction project, we know that tasks like laying the foundation take exactly 10 days.

• There is no uncertainty; we simply use a deterministic schedule to find the critical path.

Point to be noted

✔ Use PERT when project timing is uncertain (e.g., software development, R&D).
✔ Use CPM when project timing is well-defined (e.g., construction, manufacturing).

Asst. Prof Aadarsh Shinde