1|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Unit – III
Estimation and Scheduling
This PDF is watermarked and traceable. Unauthorized sharing will result in
permanent access ban and legal action.
Su

1. Estimation for Software Projects

dh
an

Estimation in software projects is the process of predicting the effort, time, cost, and
resources required to develop a software product.
sh

It is an essential part of project planning, helping teams make informed decisions, allocate
u

resources effectively, and set realistic deadlines.

De

Why is Estimation Important?

sh

 To plan budget and schedule accurately

m

 To determine team size and resource needs

uk

 To set milestones and monitor progress

h

 To manage customer expectations

-+

Need for Project Estimation:

91

1. Resource Planning: Helps in determining the resources (e.g., developers, tools,

90

infrastructure) needed for the project.

75

2. Budgeting: Provides an estimate of the cost to complete the project, which is vital for
budget allocation and financial planning.
61

3. Scheduling: Helps in setting realistic deadlines and tracking progress throughout the
62

project lifecycle.
64

4. Risk Management: Identifies potential risks early, allowing teams to mitigate them
before they affect the project.

5. Stakeholder Communication: Keeps stakeholders informed and aligned on project

timelines, scope, and costs.
 2|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

6. Scope Management: Prevents scope creep by helping teams understand the effort
required for the project and aligning expectations accordingly.

Steps in Project Estimation:

1. Understand Scope: Gather and analyze project requirements; break into smaller tasks.

2. Select Estimation Method: Choose from expert judgment, analogous, parametric,

Su

Delphi, or story points.

dh

3. Estimate Effort & Time: Calculate how long each task may take considering
an

complexity and risks.

sh

4. Assign Resources: Allocate team members to tasks based on skills.

u

5. Add Buffer Time: Include extra time (10–30%) for uncertainties or delays.
De

6. Estimate Cost: Calculate cost based on time, effort, and resources (if needed).
sh

7. Review Estimates: Validate estimates with the team and stakeholders.

m

8. Track & Revise: Monitor progress and adjust estimates as the project evolves.
uk

1.1 The Project Planning Process

h

Project planning is a vital activity in software engineering where the project manager
-+

estimates resources, cost, and schedule. A project plan is prepared at the beginning and
updated as the project progresses.
91

The planning process involves several steps to ensure the project is well-organized and
90

manageable.
75

Steps in Project Planning

61
62
64
 3|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1. Scope and Feasibility Determination

 Defines the project’s features and functions for the end-user.

 Feasibility checks if the project can be completed within time, cost, and technical
limits.

2. Risk Identification and Analysis

Su

 Identifies possible risks and analyzes their impact and likelihood.

dh

 Helps in planning risk mitigation strategies.

an

3. Resource Determination
sh

 Identifies needed human, environmental, and software resources.

u

4. Cost and Effort Estimation

De

 Breaks down the project and uses techniques like function points or use cases to
sh

estimate effort and cost.

m

5. Schedule Preparation
uk

 Prepares a timeline using tools like Gantt charts or task networks to manage project
h

flow.
-+

1.2 Defining Software Scope and Checking Feasibility

91

1. Defining Software Scope

90

Software scope defines the boundaries of a software project by specifying what the system will
and will not do. It includes:
75

 Functions & Features: The capabilities and functionalities delivered to end-users.

61

 Input & Output Data: The data that the system will process and produce.
62

 User Content: The information presented to users (e.g., UI elements, reports).

64

 Performance, Constraints, Reliability & Interfaces:

o Performance: Processing speed, response time, and efficiency.

o Constraints: Limitations (e.g., hardware, compatibility with existing systems).

 4|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Reliability: Expected uptime and error tolerance.

o Interfaces: How the system interacts with users and other systems.

Methods to Define Scope:

1. Narrative Description: A written document based on stakeholder discussions.

Su

2. Use Cases: Scenarios describing how end-users will interact with the system.
dh

2. Refining Scope for Estimation

an

 Functions are evaluated and detailed before cost and effort estimation.

 Performance requirements (e.g., response time) are analyzed.

sh

 Constraints (e.g., hardware limitations) are identified.

u
De

3. Checking Feasibility

After defining scope, feasibility must be assessed to ensure the project is viable. Four key
sh

dimensions are evaluated:

m

1. Technical Feasibility:
uk

o Can the project be built with current technology?

h

Are there technical risks (e.g., performance, security)?

-+

Can defects be reduced to acceptable levels?

91

2. Financial Feasibility:
90

o Is the development cost within budget?

75

o Will the return on investment (ROI) justify the expense?

61

3. Time Feasibility:
62

o Can the project be completed within the required timeline?

64

o Will the software launch in time to compete in the market?

4. Resource Feasibility:

o Does the organization have enough skilled personnel, tools, and infrastructure?

Key Questions After Scope Definition:

 5|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Can we build this software as scoped?

 Is the project feasible in terms of technology, cost, time, and resources?

1.3 Resources Management

Resource management in software development involves identifying, allocating, and

optimizing resources to ensure project success. The diagram categorizes Software Resources
Su

into People, Reusable Software, and Environment, each with subcomponents to manage
dh

effectively.
an
sh
u
De
sh
m
uk
h

Overview of Software Resources

-+

These are divided into three key categories:

91

1. People
90

2. Reusable Software
75

3. Environment
61

Each category includes sub-elements that need to be managed to ensure the project meets its
62

scope, timeline, and feasibility requirements.

64

1. People

The "People" category represents the human resources essential for software development.
Effective management here involves:
 6|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Number: Determining the quantity of personnel needed (e.g., 5 developers, 2 testers).

This ties into resource estimation during project planning to avoid understaffing or
overstaffing.

 Skill: Assessing the expertise required (e.g., proficiency in Python, experience with
cloud systems). Matching skills to tasks ensures quality work and reduces delays.
Su

 Location: Considering where team members are based (e.g., onsite, remote, or
dh

distributed across time zones). Location affects coordination, communication, and

potentially costs, so it must be planned to optimize collaboration.
an

2. Reusable Software
sh

The "Reusable Software" category focuses on pre-existing or adaptable software components

u

that can save time and effort. This includes:

De

 OTS Component (Off-The-Shelf Component): Ready-made software or libraries (e.g.,

sh

a prebuilt payment gateway like PayPal SDK) that can be integrated. Managing these
involves selecting reliable vendors and ensuring compatibility.
m

 Full Experience Component: Fully developed reusable modules with extensive

uk

documentation (e.g., a login system from a previous project). Management here means
h

verifying they meet current project needs and are maintained.

-+

 Part Experience Component: Partially developed components that need

91

customization (e.g., a template UI). This requires planning for additional development
time and testing.
90

 New Component: Custom-built software created for this project. Management

75

involves allocating development resources and tracking progress to integrate it

61

seamlessly.
62

3. Environment

The "Environment" category covers the technical infrastructure and tools that support
64

development. Effective management here includes:

 Software Tools: Development tools like IDEs (e.g., Visual Studio), version control
(e.g., Git), or testing frameworks (e.g., Selenium). Management involves ensuring
licenses, training, and updates are handled.
 7|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Hardware: Physical resources like servers, computers, or testing devices. This requires
budgeting for purchases or maintenance and ensuring availability.

 Network Resources: Connectivity and bandwidth for collaboration, cloud services, or

data transfer. Management involves monitoring uptime, security, and capacity to handle
project demands.
Su

Need for Defining Software Scope

dh

Defining software scope means clearly identifying what the software will do and not do.
an

Why It’s Important:

sh

1. Prevents Scope Creep – Avoids unexpected changes or additions.

u

2. Sets Clear Boundaries – Defines features, functions, and limits.

De

3. Helps Planning – Supports accurate estimation of time, cost, and resources.

sh

4. Improves Communication – Aligns client and team expectations.

m

5. Guides Development – Acts as a reference throughout the project.

uk

1.4 Software Project Estimation

h

Software project estimation predicts the effort, time, cost, and resources needed to complete a
-+

project, following scope definition and feasibility assessment. It’s key to project planning.
91

 Effort Estimation: Estimates work (e.g., hours) for tasks like coding or testing, using
expert judgment or models like COCOMO.
90

 Time Estimation: Forecasts duration (e.g., weeks) based on effort and team capacity,
75

using tools like Gantt charts.

61

 Cost Estimation: Calculates expenses (e.g., salaries, tools) by multiplying effort by

62

rates and adding overheads.

64

 Resource Estimation: Identifies people, reusable software, and environment needs

(e.g., developers, OTS components, servers).

1.5 Decomposition Techniques

Decomposition techniques are systematic approaches used in software project estimation to

break down complex problems into smaller, more manageable components. By dividing the
 8|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

project into smaller parts, teams can estimate each component more accurately and then
combine the results for an overall estimate. Below is a detailed explanation of each technique
with examples.

1.6 Software Sizing

Software sizing is a crucial step in project estimation. It refers to estimating the size of the
Su

software product to be developed, which acts as a foundation for further calculations related
dh

to effort, time, and cost.

Factors Affecting Estimation Accuracy

an

The accuracy of a software project estimate depends on:

sh

1. How accurately the size of the product is estimated.

u
De

2. The ability to convert size into human effort, calendar time, and budget.

3. How well the plan reflects the team's capabilities.

sh

4. Stability of requirements and the development environment.

m
uk

Putnam and Myers' Four Sizing Techniques

Technique Description
h
-+

1. Fuzzy Logic Sizing Estimates size qualitatively (e.g., small/medium/large), then

refined based on past project data. Requires application type and
91

historical references.
90

2. Function Point Sizing Estimates based on inputs, outputs, files, inquiries, and
75

interfaces — part of the information domain.

61

3. Standard Component Counts standard software components like screens, modules,

Sizing reports, batch programs, files, etc. Uses historical data to
62

calculate total LOC.

64

4. Change Sizing Used when modifying existing software. Size is based on the
amount of reused, added, changed, or deleted code.

Three-Point Estimate (Expected Value)

To improve accuracy, multiple sizing results are statistically combined using this formula:
 9|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Expected Size = , where:

 O = Optimistic estimate

 M = Most likely estimate

 P = Pessimistic estimate
Su

1.7 Problem-Based Estimation

dh

Breaking down the software problem into functional components and estimating each
an

separately.
sh

Steps in Problem-Based Estimation:

u

1. Understand the requirements of the project.

De

2. Divide the problem into smaller tasks or functions.

sh

3. Estimate effort (in person-hours or days) for each task.

m

4. Add buffer for risk or uncertainty.

uk

5. Calculate total time & resources needed.

h

Example: Suppose you're developing a Student Management System

-+

Feature/Task Estimated Effort

91

Login/Registration 2 days
90

Student Profile Module 3 days

75

Attendance Tracking 4 days

61

Marks Entry & Result 3 days

62

Reports & Export 2 days

64

Total Effort = 14 days

With buffer (10%) = ~15.5 days

1.8 LOC-Based Estimation

Estimating based on the number of lines of code required.

 10 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Formula:

Effort (person-days) = LOC / Productivity

Time (days) = Effort / Number of Developers

Steps in LOC-Based Estimation:

Su

1. Estimate the total LOC required for the project (based on similar past projects or
experience).
dh

2. Use productivity data (e.g., LOC/person-month) to calculate the required effort.

an

3. Estimate time, cost, and resources based on this effort.

sh

Example:
u

 Historical data shows that a login authentication module typically requires 200-300
De

LOC.
sh

 For a new system requiring 10 such modules, estimate would be 10 × 250 = 2500 LOC.
m

 If productivity is 500 LOC/month, estimated effort = 2500/500 = 5 person-months.

uk

1.9 FP-Based Estimation

h

Measures software size in Function Points (FP), which are based on user-visible
-+

functionality rather than code. Components like inputs, outputs, interfaces, and data files are
91

counted and weighted.

90

Steps in FP-Based Estimation:

1. Identify and count:

75

External Inputs (EI) – data entering the system

61

o External Outputs (EO) – data leaving the system

62

o External Inquiries (EQ) – user queries

64

o Internal Logical Files (ILF) – data stored internally

o External Interface Files (EIF) – data used from outside systems

2. Assign complexity weights (low, average, high) to each based on their complexity.
 11 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. Calculate Unadjusted Function Points (UFP): Sum of (count × weight) for all
components.

4. Adjust with complexity factor (based on 14 general system characteristics like

performance, security, etc.)

5. Compute Final Function Points (FP)

Su

FP = UFP × [0.65 + (0.01 × Total Complexity Factor)]

dh

Example:
an

A Customer Relationship Management (CRM) system has:

sh

 5 inputs (customer data, orders, etc.)

u

 8 outputs (reports, dashboards)

De

 3 interfaces (payment gateway, email system)

sh

 2 queries
m

 4 data files
uk

Let’s say after counting and applying weights, the UFP = 100, and complexity factor total is
20.
h
-+

Final FP = 100 × [0.65 + (0.01 × 20)] = 100 × 0.85 = 85 FP

91

Then, based on historical productivity data (e.g., 5 FP/month), you estimate:

90

 Effort = 85 / 5 = 17 person-months

1.10 Object Point (OP)-based estimation

75

Estimates software size based on Object Points (OP), which count screens, reports, and
61

components. Simpler than FP but useful for GUI-based applications.

62

Steps in OP-Based Estimation:

64

1. Count the number of each type of screen, report, and module.

2. Multiply by weights to get Unadjusted Object Points (UOP).

3. Adjust for reuse (if some components are reused or auto-generated):

 12 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

100 − %reuse
OP = UOP ×
100

4. Estimate Effort: Use a productivity rate (OP/month) based on developer experience.

OP
Effort =
Productivity Rate
Su

Example:
dh

Component Type Count Weight Total

an

Screens Medium 5 2 10
sh

Reports Simple 3 2 6
u

Modules Complex 2 10 20
De

UOP = 10 + 6 + 20 = 36
sh

If 20% reuse → OP = 36 × (100−20)/100 = 36 × 0.8 = 28.8 ≈ 29

m

Assume productivity rate = 7 OP/month

uk

Effort = 29/7 ≈ 4.14 person-months

h

1.11 Process-Based Estimation

-+

The entire software development process is broken down into phases (requirements, design,
91

coding, testing, etc.), and effort is estimated for each phase.

90

Steps in Process-Based Estimation:

75

1. Identify all major activities in the software process.

61

o Example: Requirement gathering, Design, Coding, Testing, Maintenance, etc.

62

2. Estimate effort for each activity

64

o Use historical data, experience, or expert judgment.

3. Add up all estimated efforts to get the total.

Example:
For a web application, the breakdown is:
 13 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Process Step Estimated Effort (Person-Days)

Requirements Gathering 10

Design 15

Coding 30
Su

Testing 20
dh

Deployment 5
an

Total Effort = 10 + 15 + 30 + 20 + 5 = 80 person-days

sh

1.12 Estimation with Use Cases

u

Uses use cases (scenarios of user interactions) to estimate effort. Each use case is assigned an
De

estimated time based on complexity.

sh

Steps Involved:
m

1. Identify all use cases in the system.

uk

2. Classify use cases into:

h

o Simple (few steps, no complex logic)

-+

o Average (moderate number of steps, some logic)

91

o Complex (many steps, includes validations, business rules)

90

3. Assign weight to each use case:

75

o Simple: 5 points
61

o Average: 10 points
62

o Complex: 15 points
64

4. Calculate Unadjusted Use Case Points (UUCP): Add all points for simple, average,
and complex use cases.

5. Apply adjustment factors (based on technical and environmental factors) to get

Adjusted Use Case Points.

6. Estimate effort using a productivity factor:

 14 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o For example: 1 UCP = 20 person-hours

Example:
A library management system has the following use cases:

 "Check out book": 3 days

 "Return book": 2 days

Su

 "Search catalog": 5 days

dh

 "Pay fine": 4 days

an

Total effort for these 4 use cases = 14 days.

sh

Use-Case–Based Estimation
u

A more structured approach using Use Case Points (UCP), which consider actors, scenarios,
De

and technical/environmental factors.

sh

Steps in Estimation Using Use Case Points:

m

1. Identify and Classify Actors:

uk

o Simple: System interacting via API – 1 point

h

o Average: Interactive system via protocol – 2 points

-+

o Complex: Human interacting via UI – 3 points

91

➤ Calculate Unadjusted Actor Weight (UAW)

90

2. Identify and Classify Use Cases:

75

o Simple: ≤3 transactions – 5 points

61

o Average: 4–7 transactions – 10 points

62

o Complex: ≥7 transactions – 15 points

64

➤ Calculate Unadjusted Use Case Weight (UUCW)

3. Calculate Unadjusted Use Case Points (UUCP):

UUCP = UAW + UUCW

 15 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

4. Determine Technical Complexity Factor (TCF): Rate 13 technical factors (e.g.,

performance, usability) from 0–5, use formula:

TCF = 0.6 + (0.01 × Total Technical Factor Score)

5. Determine Environmental Factor (EF): Rate 8 environmental factors (e.g., team

experience) from 0–5, use formula:
Su

EF = 1.4 + (−0.03 × Total Environmental Factor Score)

dh

6. Calculate Final Use Case Points (UCP):

an

UCP = UUCP × TCF × EF

sh

7. Estimate Effort: Multiply UCP by Productivity Factor (PF) (usually between 20–28
u

hours per UCP).

De

Effort (in person-hours) = UCP × PF

sh

Example: Library Management System

m

Step 1: Identify & Classify Actors

uk

 Librarian (Human - via UI) → Complex → 3 points

h

 Student (Human - via UI) → Complex → 3 points

-+

 Payment Gateway (via API) → Simple → 1 point

91

➤ UAW = 3 + 3 + 1 = 7
90

Step 2: Identify & Classify Use Cases

75

 Issue Book – Average (5 steps) → 10 points

61

 Return Book – Simple (2 steps) → 5 points

62

 Pay Fine – Complex (8 steps) → 15 points

64

➤ UUCW = 10 + 5 + 15 = 30

Step 3: Calculate UUCP

UUCP = UAW + UUCW = 7 + 30 = 37

Step 4: Technical Complexity Factor (TCF)

 16 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Let’s say we rated technical aspects like performance, reusability, etc., and got a total score of
20

TCF = 0.6 + (0.01×20) = 0.6 + 0.2 = 0.8

Step 5: Environmental Factor (EF)

Suppose our team is experienced and factors like motivation, stability, etc. total to 15
Su

EF = 1.4 + (−0.03×15) = 1.4 − 0.45 = 0.95

dh

Step 6: Calculate Final UCP

an

UCP = UUCP × TCF × EF = 37 × 0.8 × 0.95 = 28.12

sh

Step 7: Estimate Effort

u

Assume Productivity Factor (PF) = 20 hours per UCP

De

Effort = 28.12 × 20 ≈ 562.4 hours

sh

1.13 Reconciling Estimates

m

When multiple estimation techniques give different results, teams reconcile them to reach a
uk

balanced estimate.
h

Example:
-+

 LOC estimate: 6 months

91

 FP estimate: 7.5 months

90

 Process-based estimate: 5 months

75

 Final reconciled estimate: 6.5 months (considering all factors).

61

1.14 Empirical Estimation Models

62

Empirical estimation models rely on experience, observation, and practical judgment rather
64

than strict theoretical formulas. They are commonly used when precise data is unavailable but
a reasonable estimate is still required.

Key Features

 Based on educated guesses and common sense.

 17 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Use estimated values of LOC (Lines of Code) or FP (Function Points).

 Apply the Three-Point Estimation or Expected Value Estimation model:

Expected Size = , where:

o O = Optimistic estimate
Su

o M = Most likely estimate

dh

o P = Pessimistic estimate
an

 These estimated sizes are then plugged into the cost/effort estimation formula.
sh

1.15 The Structure of Estimation Models

u

Estimation models provide a systematic way to predict effort, cost, and schedule for software
De

projects. Despite differences in approaches (e.g., LOC-based, FP-based, use-case-based), most

models follow a common structural form.
sh

General Structure of an Estimation Model

m
uk

Most estimation models are represented using the following formula:

h

Effort = a × (Size)b
-+

Where:
91

 Effort = Predicted effort (in person-months)

90

 Size = Software size (e.g., in LOC or FP)

75

 a, b = Constants derived from historical data and organizational experience

61

Optional Extensions

Many models include adjustment factors to improve accuracy:

62

Effort = a × (Size)b × EAF

64

 EAF = Effort Adjustment Factor, based on cost drivers such as:

o Product complexity

o Team experience
 18 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Tool usage

o Required reliability

Example: Simple Effort Estimation

Let’s assume:
Su

 Size = 3,000 LOC

dh

 Constants: a = 2.5, b = 1.05

Effort = 2.5 × (3000)1.05 ≈ 2.5 × 3877 = 9692.5 person-hours

an

1.16 The COCOMO II Model

sh

The COCOMO II (Constructive Cost Model II) is a software cost estimation model used to
u

predict the effort, schedule, and cost of a software project. It is an evolution of the
De

original COCOMO (1981) and is better suited for modern software development practices,
sh

including iterative, agile, and component-based development.

m

Key Features of COCOMO II

uk

1. Supports Modern Software Development

h

o Accounts for reuse, prototyping, and incremental development.

-+

o Suitable for object-oriented, web-based, and commercial-off-the-shelf (COTS)

91

software.
90

2. Three Submodels for Different Project Stages

Application Composition Model (prototyping, GUI-based apps)

75

o Early Design Model (high-level architectural decisions)

61

o Post-Architecture Model (detailed development and maintenance)

62

3. Uses Scale Factors and Cost Drivers

64

o Adjusts estimates based on project complexity, team experience, and

technology.

COCOMO II Submodels:

1. Application Composition Model

 19 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Used for prototyping and projects with heavy GUI development.

 Estimates based on Object Points (similar to function points but for visual
components).

 Formula:

Effort (Person−Months) = NOP/PROD

Su

o NOP (New Object Points) = Adjusted count of screens, reports, and

dh

components.
an

o PROD (Productivity Rate) = Based on developer experience and tools.

sh

2. Early Design Model

u

 Used when only high-level requirements and architecture are known.

De

 Estimates based on Function Points (FP) or Lines of Code (LOC).

sh

 Formula:
m
uk

Effort = A × Size × 𝐸𝑀
h

o A: Constant (usually 2.94).

-+

o Size: In KLOC (thousands of lines of code) or FP.

91

o E: Scale factor (accounts for economies/diseconomies of scale).

90

o EM: Effort Multipliers (7 cost drivers like team experience, risk resolution).
75

3. Post-Architecture Model
61

 Most detailed, used when full requirements and design are known.
62

 Formula similar to Early Design but with 17 cost drivers (instead of 7).
64

 Formula:

Effort = A × Size × 𝐸𝑀

o Includes factors like reuse, documentation, security, and tool support.

 20 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Key Parameters in COCOMO II

1. Scale Factors (Exponent E)

o Precedentedness (how similar the project is to past ones)

o Development Flexibility (rigidity of requirements)

Su

o Architecture/Risk Resolution (early risk handling)

dh

o Team Cohesion (team dynamics)

an

o Process Maturity (CMMI level)

2. Effort Multipliers (EM)

sh

Product Factors (reliability, complexity, database size)

u

o
De

o Platform Factors (execution constraints)

Personnel Factors (team capability, experience)

sh

Project Factors (tool use, distributed teams)

m

o
uk

Example Calculation (Post-Architecture Model)

h

Suppose:
-+

 Size (S) = 50 KLOC

91

 Scale Factor (E) = 1.1 (calculated from 5 scale drivers)

90

 Effort Multipliers (EM) = 1.15 (average of 17 cost drivers)

75

 A = 2.94 (constant)
61

Effort = 2.94 × 501.1 × 1.15 ≈ 330 Person-Months

Advantages of COCOMO II
62

 More accurate than the original COCOMO for modern projects.

64

 Flexible across different development methodologies.

 Adjusts for team skill, tools, and project risks.

Limitations

 Requires accurate size estimation (LOC or FP).

 21 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Relies on expert judgment for cost drivers.

 Less accurate for very small or extremely large projects.

Difference between COCOMO and COCOMO II Model:

Feature COCOMO (1981) COCOMO II (1997)

Purpose Estimate cost/effort for Estimate cost/effort for modern,

Su

traditional projects complex projects

dh

Development Model Waterfall Iterative, Agile, Object-Oriented

an

Estimation Based KLOC (Thousands of Lines KLOC, Function Points, Object

sh

On of Code) Points
u

Types / Levels Basic, Intermediate, Application Composition, Early

De

Detailed Design, Post-Architecture

Support for Reuse Limited Strong (accounts for reuse and

sh

COTS)
m

Tool & Method Not considered Supports modern tools and

uk

Integration techniques
h

Complexity Simple models with fixed More flexible and detailed estimation
-+

Handling formulas
91

Cost Drivers 15 cost drivers 22 cost drivers and 5 scale factors

90

Modularity Support Not supported Supported

75

Types of COCOMO Model Modes

61

1. Organic Mode
62

 Used For: Small, simple software projects

64

 Team: Small teams with good experience working in a familiar domain

 Example: Simple accounting or inventory system

Characteristics:

 Low complexity
 22 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 In-house development

 Few constraints

2. Semi-Detached Mode

 Used For: Medium-size, moderately complex projects

Su

 Team: Mixed team of experienced and less-experienced members

dh

 Example: Payroll systems, database applications

an

Characteristics:

 Intermediate complexity
sh

 Balance of familiarity and unfamiliarity

u
De

 More external constraints than organic mode

3. Embedded Mode
sh

Used For: Complex systems with tight hardware, software, and operational constraints
m


uk

 Team: Large teams, often with multidisciplinary collaboration

h

 Example: Real-time systems, defense software, aerospace systems

-+

Characteristics:
91

 High complexity
90

 Rigid standards and tight deadlines

75

 Developed for a specific environment

61

1.17 Preparing Requirement Traceability Matrix

A Requirement Traceability Matrix (RTM) is a document that maps and traces user
62

requirements with test cases to ensure all requirements are covered during testing.
64

It helps track:

 Whether all requirements are implemented,

 Whether each requirement is tested, and

 The status of development or testing.

 23 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Steps to Prepare an RTM

1. Gather Requirements: Collect all functional and non-functional requirements from the SRS
(Software Requirements Specification).

2. Assign Requirement IDs: Give each requirement a unique ID (e.g., R1, R2...) for tracking.

3. Identify Test Cases: Write test cases corresponding to each requirement.

Su

4. Map Requirements to Test Cases: Create a table that shows which test case verifies which
dh

requirement.
an

5. Add Status Column: Include a column to track the testing status (Pass/Fail/In Progress).
sh

6. Update Continuously: Keep the RTM updated throughout the software development
u

lifecycle.
De

Example RTM Table

sh

Requirement Requirement Description Test Case Test Case Status

ID ID Description
m
uk

R1 User should log in securely TC1 Test valid Pass

login
h

R2 Forgot Password TC2 Test password In Prog.

-+

functionality reset link

91

R3 Display dashboard after TC3 Test dashboard Not Run

90

login visibility
75
61

Benefits of RTM
62

 Ensures complete test coverage

64

 Helps with impact analysis when requirements change

 Makes auditing and validation easier

 Bridges the gap between requirements, development, and testing

 24 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

2. Project Scheduling

2.1 Project Scheduling

Project Scheduling is the process of planning, organizing, and managing time and tasks for
a software project to ensure it is completed within deadlines and allocated resources.
Su

It defines:
dh

 What tasks need to be done

When they need to be done

an

 Who will perform them

sh

 How long each task will take

u
De

Basic Principles of Software Project Scheduling:

1. Compartmentalization
sh

Divide the project into smaller tasks (Work Breakdown Structure – WBS).
m

o
uk

o Helps in better planning and assignment.

h

2. Interdependency
-+

o Identify task dependencies (what must be done before or after other tasks).
91

o Allows better sequencing of tasks.

90

3. Time Allocation
75

o Assign a start and end date to each task.

Ensures time is well-planned and deadlines are realistic.

61

4. Effort Validation
62

o Validate if the time and effort estimated for each task are achievable.
64

o Avoids underestimating work.

5. Defined Responsibilities

o Assign clear responsibility for each task to individuals or teams.

 25 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Promotes accountability and ownership.

6. Defined Outcomes

o Each task should have a clear deliverable (document, code, report, etc.)

o Helps track progress easily.

Su

7. Defined Milestones
dh

o Mark major events or checkpoints in the schedule (e.g., design complete, testing
start).
an

o Helps monitor progress and control the project.

sh
u
De
sh
m

Tasks of Project Scheduling

uk

1. Identify Project Tasks

h

o Break down the entire project into smaller workable tasks.

-+

o This is done using Work Breakdown Structure (WBS).

91

2. Establish Task Dependencies

90

o Determine the sequence in which tasks should be performed.

75

o Identify which tasks depend on others.

61

3. Estimate Time and Resources

Calculate the time, effort, and resources (people, hardware, software) needed for
62

each task.
64

o Use historical data or estimation models (like COCOMO) if required.

4. Assign Responsibilities

o Allocate each task to a specific team member or team.

o Ensures accountability and smooth workflow.

 26 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

5. Define Milestones

o Identify key checkpoints in the project where progress is evaluated (e.g., design
complete, testing done).

o Helps in tracking progress.

6. Develop the Schedule

Su

o Use tools like Gantt charts or Timeline charts to visually represent task durations,
dh

dependencies, and milestones.

an

7. Monitor and Revise the Schedule

sh

o Track the actual progress vs. planned progress.

u

o Make adjustments if delays or changes occur.

De

Resources Required for Development

sh

 Human effort (developers, designers, testers, etc.)

m

 Sufficient disk space (especially on servers)

uk

 Specialized hardware (if the project demands)

h

 Software tools and technologies

-+

 Travel allowance or logistics for project staff

91

Advantages of Project Scheduling

90

 Keeps everyone on the same page regarding tasks, dependencies, and deadlines.
75

 Helps identify potential issues early, such as resource shortages.

61

 Shows relationships between tasks and helps monitor project progress.

62

 Supports better budgeting and risk mitigation.

64

2.2 Defining a Task for the Software Project

A Task Set is a collection of software engineering work tasks, milestones, and work products
that need to be completed to deliver a software project successfully.

Purpose of a Task Set:

 27 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Helps define and guide the software development process

 Allows teams to plan, track, and support the project systematically

 Ensures high quality software is built by avoiding unnecessary tasks

Key Points:
Su

 Every process model (like Waterfall, Agile, etc.) is made up of one or more task sets.
dh

 There is no universal task set for all projects — task sets must be customized based
on the project type and characteristics.
an

 Effective software processes adapt the task set to match the project's needs and goals.
sh

Types of Software Projects & Their Task Sets:

u

1. Concept Development Projects

De

o Focus: New business ideas or innovative tech applications

sh

o Typical Tasks:
m

 Defining Scope: Set project goals and objectives

uk

 Planning: Estimate time, cost, and human effort

h

Evaluating Technology Risks: Assess risks in using new technologies

-+

 Concept Implementation: Create a model or prototype for end-users

91

2. New Application Development Projects

90

o Designed to fulfill specific customer needs

75

3. Application Upgradation Projects

61

o Modify existing applications for better performance or updated features

62

4. Application Maintenance Projects

64

o Perform bug fixes, adaptations, or feature extensions to current software

5. Reengineering Projects

o Rebuild or modernize legacy systems (partially or completely)

Factors Influencing Task Sets:

 28 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Size of the project

 Number of users

 Project team size

 Application lifetime
Su

 Application complexity
dh

 Performance constraints
an

 Technologies used

2.3 Scheduling with a Time Line Chart

sh

Scheduling is the process of planning what tasks need to be done, when, and by whom in a
u

software project. A Time Line Chart helps visualize this schedule in a clear, time-based
De

format.
sh

What is a Time Line Chart?

m

A Time Line Chart (also called a Gantt Chart) is a horizontal bar chart that shows:
uk

 Tasks or activities on the vertical axis

h

 Time (days/weeks/months) on the horizontal axis

-+
91
90
75
61
62
64

Each bar represents a task and spans from its start date to end date.

In time line chart

 29 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1) All the tasks are listed at the leftmost column.

2) The horizontal bars indicate the time required by the corresponding task.

3) When multiple horizontal bars occur at the same time on the calendar, then that means

concurrency can be applied for performing the tasks.

Su

4) The diamonds indicate the milestones.

dh

Benefits of Time Line Chart

an

 Easy to understand project progress at a glance

 Shows overlapping tasks (parallel execution)

sh

 Helps track delays and dependencies

u
De

 Useful for resource management

Project Table:
sh
m

Tasks Planned Actual start Planned end Actual end Effort

start assignment
uk

Requirement 6th Sept’24 6th Sept’24 20th Sept’24 22nd Sept’24 John, Chris,
h

analysis Mary
-+

Architectural 27th Sept’24 27th Sept’24 3rd Oct’24 7th Oct’24 Bruce, Matt
design
91

Procedural 10th Oct’24 12th Oct’24 24th Oct’24 25th Oct’24 Akash,
90

design Samay, Ravi

. . . . . .
75

. . . . . .
. . . . . .
61

Customer 1st Jan’25 4th Jan’25 22nd Jan’25 25th Jan’25 Gwen, Peter
training
62
64