Dr. A.P.J.

Abdul Kalam Technical University (AKTU)

[Link] — 6th Semester | Subject Code: BOE-068

SOFTWARE PROJECT
MANAGEMENT

UNIT – 2

rk
A
Software Process Models &
Estimation Techniques
ic
em
Topics Covered:
• Project Life Cycle & Software Process Models
• Waterfall, Incremental, Spiral, RAD & Prototyping
• Agile Methods, DSDM, Extreme Programming
ad

• Software Estimation: Techniques & Models

• COCOMO II & COSMIC Full Function Points
• Parametric Productivity Models
Ac

Prepared By AcademicArk – Premium Notes

Website: [Link]

Academic Year: 2025–2026 | AKTU [Link]. (CSE / IT / All Branches)

AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026 Visit: [Link]
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

Table of Contents

Contents
1 Project Life Cycle and Effort Estimation 4
1.1 Phases of the Software Project Life Cycle . . . . . . . . . . . . . . . . . . . 4
1.2 Relationship Between Project Life Cycle and Effort Estimation . . . . . . . 4

2 Software Process 6
2.1 Definition of Software Process . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Importance of Software Process . . . . . . . . . . . . . . . . . . . . . . . . 6

rk
3 Software Process Models 8
3.1 1. Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 Advantages . . .
3.1.3 Disadvantages . .
A
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
8
8
3.1.4 Best Suited For .
ic
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 2. Incremental Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
em

3.2.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 Best Suited For . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 3. Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ad

3.3.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.4 Best Suited For . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 4. Prototyping Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Ac

3.4.1 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 5. Incremental Model vs. Waterfall vs. Spiral – Quick Comparison . . . . . 12

4 Choice of Process Models 13

4.1 Factors Affecting Choice of Process Model . . . . . . . . . . . . . . . . . . 13
4.2 Decision Matrix – Selecting the Right Model . . . . . . . . . . . . . . . . . 14

5 Rapid Application Development (RAD) 15

5.1 Concept of RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Phases of RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1 Phase Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Advantages and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

6 Agile Methods 18
6.1 Agile Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Characteristics of Agile Development . . . . . . . . . . . . . . . . . . . . . 18
6.3 Agile Lifecycle Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Dynamic System Development Method (DSDM) 21

7.1 Overview of DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Phases of DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2.1 Phase Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3 Benefits of DSDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Extreme Programming (XP) 23

8.1 Core Values of XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2 Practices of XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.3 XP Workflow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

rk
8.4 Advantages of XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.5 Challenges of XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

9 Managing Interactive Processes 26

A
9.1 Challenges in Managing Interactive Processes . . . . . . . . . . . . . . . . 26
9.2 Management Strategies for Interactive Processes . . . . . . . . . . . . . . . 27
ic
10 Basics of Software Estimation 29
10.1 Need for Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
em
10.2 Types of Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.3 Estimation Accuracy vs. Project Phase . . . . . . . . . . . . . . . . . . . . 30

11 Effort and Cost Estimation Techniques 31

11.1 1. Expert Judgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ad

11.1.1 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.4 Best Used For . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Ac

11.2 2. Estimation by Analogy . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

11.2.1 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.2.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.2.3 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.2.4 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.3 3. Algorithmic Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.3.1 General Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.2 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.3.4 Best Used For . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

12 COSMIC Full Function Points 34

12.1 Concept of COSMIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.2 Functional Size Measurement – COSMIC Approach . . . . . . . . . . . . . 34
12.2.1 Calculation Formula . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.2.2 Example – COSMIC Measurement . . . . . . . . . . . . . . . . . . 35

2 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

12.3 Applications of COSMIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

12.4 Advantages and Limitations of COSMIC . . . . . . . . . . . . . . . . . . . 35
12.4.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.4.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

13 COCOMO II 37
13.1 Overview of COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.2 COCOMO II Sub-Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.2.1 1. Composition Model (Early Project Stage) . . . . . . . . . . . . . 37
13.2.2 2. Application Composition Model (RAD Development) . . . . . . 37
13.2.3 3. Post-Architecture Model (Full Development) . . . . . . . . . . . 37
13.3 COCOMO II Effort Estimation Formula . . . . . . . . . . . . . . . . . . . 38
13.4 COCOMO II Cost Drivers (Effort Multipliers) . . . . . . . . . . . . . . . . 38
13.4.1 Key Cost Drivers and Multiplier Values . . . . . . . . . . . . . . . . 38
13.5 Example – COCOMO II Calculation . . . . . . . . . . . . . . . . . . . . . 40

rk
13.6 Advantages of COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.7 Limitations of COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A
14 Parametric Productivity Model 42
14.1 Concept of Parametric Models . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.2 Parametric Estimation Process . . . . . . . . . . . . . . . . . . . . . . . . 42
14.3 Role in Effort Estimation . . . . . .
ic
. . . . . . . . . . . . . . . . . . . . . . 42
14.4 Example – Parametric Productivity Model . . . . . . . . . . . . . . . . . . 43
14.5 Advantages and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 43
em

14.5.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Unit–2 Quick Revision Summary 45

ad
Ac

3 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

1. Project Life Cycle and Effort Estimation

D DEFINITION
Project Life Cycle (PLC) is a series of phases through which a project passes from
its conception (idea) to its completion (closure). Each phase is distinct and has specific
objectives, activities, and deliverables.
Effort Estimation is the process of quantifying the amount of work (typically
measured in person-months or person-days) required to complete each task or the
entire project.

1.1. Phases of the Software Project Life Cycle

Concept Requirements Design Development Testing

rk
Feasibility study Gather & analyze Architecture & Coding & unit System testing
Charter requirements design docs testing UAT

Deployment & Maintenance – Installation, support, bug fixes, enhancements

Figure 1: Software Project Life Cycle Phases.

A
ic
1.2. Relationship Between Project Life Cycle and Effort Estimation
em
Effort estimation is critical at multiple points in the PLC:

• Concept Phase: High-level order-of-magnitude estimate (ROM) to assess project

feasibility.
• Requirements Phase: Refined estimate based on detailed requirements analysis;
ad

used for budgeting.

• Design Phase: Baseline estimate finalized; used for project scheduling and resource
allocation.
Ac

• Development Phase: Actual effort tracked against estimate; variances identified and
corrected.
• Testing Phase: Test effort estimated separately; often 20–40% of total project effort.
• Deployment Phase: Effort for installation, configuration, user training, cutover
planning.

E REAL-WORLD EXAMPLE
Example – E-commerce Portal Project:
• Concept: ROM estimate 12–18 months (±50% accuracy).
• Requirements: Refined to 14 months, 15 developers, Rs. 1.2 crores.
• Design: Baseline finalized as 14 months with detailed task breakdown (WBS).
• Development: Actual effort 15.2 months (8% variance – acceptable).

4 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• Testing: Effort = 3.5 months (25% of project effort) – payment gateway bugs
delayed by 2 weeks.
• Deployment: 2 weeks for data migration and user training.

rk
A
ic
em
ad
Ac

5 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

2. Software Process
D DEFINITION
A Software Process is a set of activities, methods, practices, and transformations
that people employ to develop and maintain software and associated products (e.g.,
project plans, designs, code, test cases, user manuals). It describes how software is
built, not what is built.

2.1. Definition of Software Process

A software process encompasses:

• Activities: Concrete work tasks (requirements analysis, coding, testing).

• Methods: Techniques and tools used to perform activities (structured analysis, code

rk
reviews, automated testing).
• Practices: Guidelines and standards (code naming conventions, documentation tem-

A
plates, peer review checklists).
• Roles: Individuals involved (developer, tester, architect, project manager).
ic
• Control Flow: The sequence and dependencies among activities (which activity must
complete before another starts).
em

• Artifacts: Outputs of each activity (requirements document, design specification,

source code, test report).

2.2. Importance of Software Process

ad

• Consistency: Ensures that software is developed following established best practices,

improving quality.
• Predictability: Structured processes enable better effort estimation, scheduling, and
Ac

risk management.
• Traceability: Clear documentation of decisions and artifacts enables traceability from
requirements to code to tests.
• Repeatability: Processes can be replicated across multiple projects, teams, and
organizations.
• Quality Assurance: Built-in review and testing checkpoints catch defects early.
• Risk Mitigation: Structured risk management and monitoring activities reduce
project failures.
• Team Alignment: Clear processes ensure all team members understand their roles
and responsibilities.
• Customer Confidence: Documented processes demonstrate professionalism and
competence to clients.

6 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• Continuous Improvement: Metrics and retrospectives drive incremental process

improvements.
• Compliance: Ensures adherence to regulatory requirements (ISO 27001 for security,
HIPAA for healthcare data).

E REAL-WORLD EXAMPLE
Example – Healthcare Software Development: A hospital’s electronic health
records (EHR) system must follow strict FDA and HIPAA regulations. A well-defined
software process ensures: (1) Requirements traceability for regulatory audits, (2)
Design reviews for patient safety, (3) Code reviews for security vulnerabilities, (4)
Comprehensive testing including edge cases, (5) Change control to prevent unauthorized
modifications, (6) Documentation for compliance. Without a solid process, the hospital
risks system failures affecting patient care or data breaches violating patient privacy.

rk
A
ic
em
ad
Ac

7 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

3. Software Process Models

D DEFINITION
A Software Process Model (or Software Development Methodology) is a standard-
ized representation of the phases, activities, and deliverables involved in developing
software. Different models suit different project contexts, team sizes, and requirements.

3.1. 1. Waterfall Model

Document all
Requirements requirements

Complete system
Design Rare
architecture

rk
Code all modules
Implementation in sequence

A
System testing,
Testing UAT
ic
Production
Deployment release
em
Bug fixes,
Maintenance enhancements

Figure 2: Waterfall Model – Sequential, phase-by-phase approach.

3.1.1. Characteristics
ad

• Linear and Sequential: Each phase completes before the next begins; no overlap.
• Document-Driven: Heavy emphasis on documentation at each phase.
Ac

• Rigid: Changes to requirements after design approval are very costly.

• Testing Late: Testing begins after implementation is complete.

3.1.2. Advantages
• Clear structure; easy for managers to understand and track progress.
• Good for projects with well-understood, stable requirements.
• Extensive documentation aids knowledge transfer and maintenance.
• Works well with geographically distributed teams (document-based handoffs).

3.1.3. Disadvantages
• Inflexible: Cannot easily accommodate requirement changes.
• Integration risk: Modules integrated only near the end; integration problems discov-
ered late.

8 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• User dissatisfaction: Users see working software only at deployment.

• Unrealistic: Assumes all requirements are known and stable upfront.

3.1.4. Best Suited For

Projects with fixed, well-defined requirements such as government contracts, embedded
systems, or regulatory-driven development.

3.2. 2. Incremental Model

Req 1 Req 2 Req 3

Design 1 Design 2 Design 3

Code 1 Code 2 Code 3

rk
Test 1 Test 2 Test 3

Increment 1 Increment 2 Increment 3

Integration & Final Release

Figure 3: Incremental Model – Build and release in increments.

A
ic
3.2.1. Characteristics
em
• Software is built in increments (each increment implements a subset of requirements).
• Each increment goes through all phases (requirements, design, coding, testing).
• Increments are integrated to form the final product.
ad

• Client feedback after each increment can influence subsequent increments.

3.2.2. Advantages
• Early and frequent delivery of working software.
Ac

• Easier to test each increment than the entire system.

• Reduced risk: early detection of problems allows course correction.
• User involvement throughout; better requirement validation.

3.2.3. Disadvantages
• Requires careful planning to partition requirements into increments.
• Integration complexity if increments have dependencies.
• Difficult to apply to systems where all features must be available initially.

3.2.4. Best Suited For

Projects where requirements are partially known or can be prioritized, and early delivery
of partial functionality is valuable.

9 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

3.3. 3. Spiral Model

Spiral Model – Risk-Driven Incremental

Evaluation Engineering
Prototype review Build & test

Iter 3
Iter 4
Risk

Iter 2
Iter 1

Planning Risk
Objectives, Analysis

rk
constraints Risks & mitigation

Figure 4: Spiral Model – Risk-driven iterative approach with 4 quadrants per spiral.

A
3.3.1. Characteristics
• Combines elements of Waterfall and Incremental models.
ic
• Each spiral cycle consists of 4 quadrants: Planning, Risk Analysis, Engineering, and
Evaluation.
em

• Risk assessment is central; high-risk items addressed first.

• Each spiral can produce a prototype or partial release.
• The spiral continues outward until project completion.
ad

3.3.2. Advantages
• Excellent risk management; risks identified and mitigated early.
Ac

• Accommodates requirement changes more gracefully than Waterfall.

• Early prototypes reduce user uncertainty.
• Works well for large, complex, high-risk projects.

3.3.3. Disadvantages
• Spiral management is complex; requires experienced practitioners.
• Difficult to predict project schedule and cost in advance.
• Not suitable for small, low-risk projects (overhead not justified).

3.3.4. Best Suited For

Large, complex projects with significant technical or business risks, such as mission-critical
systems or novel technology applications.

10 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

3.4. 4. Prototyping Model

D DEFINITION
The Prototyping Model emphasizes the early construction of a working prototype to
refine system requirements and design before full-scale development. The prototype is
an early, incomplete version of the system built to explore specific features or interfaces.

3.4.1. Process Flow

1. Initial Concept: Gather rough requirements and project vision.
2. Prototype Development: Build a working prototype focusing on user interface and
key features.
3. User Evaluation: Demonstrate prototype to users; gather feedback.

rk
4. Refinement: Modify prototype based on feedback.
5. Repeat: Steps 2–4 may repeat multiple times until requirements are sufficiently
refined.

A
6. Full Development: Once requirements are stable, develop the complete system using
a traditional methodology.
ic
3.4.2. Advantages
• Reduces requirement ambiguity through tangible prototypes.
em

• Early user feedback catches design flaws before full development.

• Faster time to initial working version.

3.4.3. Disadvantages
ad

• Prototype development cost; may be discarded or become basis for suboptimal final
system.
Ac

• Users may expect prototype to be the final product.

• May lead to scope creep if prototyping is not managed carefully.

E REAL-WORLD EXAMPLE
Example – Mobile Banking App UI Prototyping: A bank’s development team
builds a clickable prototype of a mobile banking app using Figma or Adobe XD,
focusing on login, fund transfer, and bill payment screens. Users (customers and bank
employees) review the prototype and suggest changes: “Move the logout button to the
top-right corner” or “Use biometric login for faster authentication.” After 3 iterations
of feedback and refinement, the prototype is approved. The development team then
uses it as the design specification for full-scale development in React Native.

11 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

3.5. 5. Incremental Model vs. Waterfall vs. Spiral – Quick Comparison

S SUMMARY TABLE

Aspect Waterfall Incremental Spiral Prototyping

Sequencing Linear Iterative Spiral loops Iterative

Re- Fixed upfront Evolve over Evolve, Evolve via
quirements time risk-driven prototypes
Testing Late phase Each increment Each loop After prototype
Risk Mgmt Minimal Moderate Excellent Moderate
User In- Low High Medium Very high
volvement
Documen- Extensive Moderate Moderate Minimal

rk
tation
Best For Fixed scope Evolving High risk UI/UX
features refinement

A
ic
em
ad
Ac

12 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

4. Choice of Process Models

D DEFINITION
Choice of Process Model is the decision to select an appropriate software devel-
opment methodology based on project characteristics, organizational context, and
business objectives. The selection is crucial because it directly impacts project success.

4.1. Factors Affecting Choice of Process Model

• Project Size:

– Small projects (1–5 developers): Agile, Prototyping.

– Medium projects (5–20 developers): Incremental, Scrum.

rk
– Large projects (20+ developers): Spiral, RUP (Rational Unified Process), Waterfall
with governance.

• Requirements Clarity:

– Well-defined, stable: Waterfall.

A
ic
– Partially known: Incremental, Spiral.
– Uncertain or volatile: Agile, Prototyping.
em

• Risk Level:

– Low risk: Waterfall.

– Moderate risk: Incremental.
ad

– High risk: Spiral (with dedicated risk management).

• Technology Novelty:
Ac

– Proven, established technology: Waterfall.

– Emerging technology: Prototyping, Spiral.

• User Involvement:

– Low availability: Waterfall.

– High availability: Agile, Incremental, Prototyping.

• Time-to-Market Pressure:

– Flexible timeline: Waterfall.

– Tight deadline: Agile, RAD.

• Regulatory Compliance:

– Heavy regulatory (medical, finance): Waterfall with strong documentation.

13 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

– Light regulatory: Agile is acceptable.

• Team Experience:

– Inexperienced team: Waterfall (structured, well-documented).

– Experienced team: Agile, Spiral.

• Customer Contract Type:

– Fixed-price contract: Waterfall (scope fixed, price fixed).

– Time-and-materials: Agile (flexible scope and price).

• Geographical Distribution:

– Co-located team: Agile (face-to-face daily standups).

rk
– Distributed team: Waterfall or Incremental (document-based communication).

4.2. Decision Matrix – Selecting the Right Model

Model Req. Clarity

A
Risk Level Size

Waterfall High
ic Low Any

Incremental Medium Medium Medium

em

Spiral Low High Large

Agile Low Moderate Small-Med

E REAL-WORLD EXAMPLE
ad

Example – Process Model Selection for Different Projects:

1. Government Defense System: Waterfall (fixed requirements, strong documen-
tation for audits, low tolerance for changes, large team).
Ac

2. Mobile Banking App: Spiral (high security risk, evolving requirements, need
for user feedback on UX).
3. Startup MVP: Agile (uncertain requirements, fast time-to-market, small co-
located team).
4. ERP System for Large Enterprise: Incremental or RUP (complex system,
can be broken into modules, phased deployment across departments).
5. Social Media Platform: Agile (rapidly evolving features, frequent releases, user
feedback-driven, scalability as secondary concern initially).

14 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

5. Rapid Application Development (RAD)

D DEFINITION
Rapid Application Development (RAD) is an agile software development method-
ology that prioritizes speed of development and early delivery over perfect design. It
uses visual development tools, COTS (Commercial Off-The-Shelf) components, and
iterative development to reduce time-to-market from months to weeks.

5.1. Concept of RAD

• Time-Box Development: Projects are organized into 60–90 day cycles (timeboxes).
• Visual Development: Use of visual tools (drag-and-drop UI builders, low-code
platforms) instead of traditional coding.

rk
• Reusable Components: Leverage pre-built business components, frameworks, and
libraries.

A
• Minimal Planning: Focus on quick prototypes rather than exhaustive upfront design.
• User Involvement: Users/clients actively participate in reviews and feedback at each
timebox end.
ic
• Iterative Refinement: Each cycle delivers working software with refined features.
em

5.2. Phases of RAD

1. Business 2. Data 3. Process
Modeling Modeling Modeling
ad

Understand business Design database Define workflows

processes & rules schema & events
4. Application 5. Testing & 6. Deployment
Generation Turnover & Support
Ac

Auto-generate code QA, UAT, Install & provide

using RAD tools hand off ongoing support

Figure 5: RAD Phases.

5.2.1. Phase Details

• Business Modeling: Analysts document business processes, rules, and requirements.
Deliverable: Business process model.
• Data Modeling: Design database entities, attributes, relationships. Deliverable:
Data model (ER diagram).
• Process Modeling: Define workflows, events, and data flows. Deliverable: Process
flows.
• Application Generation: Use RAD tools to auto-generate screens, forms, reports
from models. Developers customize as needed. Deliverable: Application code.

15 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• Testing & Turnover: QA tests, client performs UAT. Refinements made based on
feedback. Deliverable: Tested, signed-off application.
• Deployment & Support: Install in production, provide user training and support.
Deliverable: Live system.

5.3. Advantages and Limitations

5.3.1. Advantages
• Speed: RAD can deliver working applications in 60–90 days vs. 6–12 months for
traditional Waterfall.
• Reduced Development Cost: Visual tools reduce coding effort; reuse of components
saves time.
• Early User Feedback: Working prototypes at end of each timebox enable quick

rk
validation.
• Flexibility: Changes can be incorporated in the next timebox.

A
• Lower Rework: Early and frequent testing catches defects quickly.

5.3.2. Limitations
ic
• Requires Active User Involvement: High user participation demand; not always
feasible.
em

• Team Expertise: RAD tool expertise is essential; learning curve for traditional
developers.
• Scalability: RAD-generated code may not be as optimized or maintainable as hand-
crafted code.
ad

• Large Projects: Difficult to apply RAD to very large, distributed systems.

• Domain Mismatch: RAD works well for business applications but not for real-time
or embedded systems.
Ac

E REAL-WORLD EXAMPLE
Example – RAD for CRM System: A company needs a Customer Relation-
ship Management (CRM) system quickly. Using a RAD platform (e.g., Microsoft
PowerApps, Salesforce Customization):
• Week 1: Business analysts interview sales and support teams to understand
processes.
• Week 2: Data model created (Customers, Contacts, Opportunities, Activities).
• Week 3: Process workflows defined (lead creation, deal progression, customer
communication).
• Week 4: RAD tool auto-generates screens, forms, dashboards from the model.
• Week 5: Sales team tests prototype; requests “Add Notes field to Contact.”
• Week 6: Developer adds Notes field; system regenerated.

16 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• Week 7: Final UAT and sign-off.

• Week 8: Deployment to production. Total timeline: 8 weeks. Without RAD,
this project might take 4–5 months with traditional development.

rk
A
ic
em
ad
Ac

17 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

6. Agile Methods
D DEFINITION
Agile Methods are a family of iterative, incremental software development approaches
that emphasize:
• Responding to change over following a plan.
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
Based on the Agile Manifesto (2001), Agile is a mindset and culture, not just a set
of practices.

6.1. Agile Principles

rk
The Agile Manifesto is built on 12 core principles:

• Customer Satisfaction: Early and continuous delivery of valuable software.

A
• Change Acceptance: Welcome changing requirements, even late in development.
ic
• Frequent Delivery: Release working software every 1–4 weeks (sprints).
• Collaboration: Business and development teams work together daily.
em

• Motivated Teams: Build projects around motivated individuals; provide support

and trust.
• Face-to-Face Communication: Most efficient information transfer in a development
ad

team.
• Working Software: Primary measure of progress is working, tested software.
• Sustainable Pace: Maintain a constant, sustainable pace throughout the project.
Ac

• Technical Excellence: Continuous attention to technical excellence and good design.

• Simplicity: Maximize the amount of work not done; keep designs simple.
• Self-Organizing Teams: Architecture and requirements emerge from self-organizing
teams.
• Reflection and Adaptation: Teams regularly reflect on effectiveness and adjust
behavior.

6.2. Characteristics of Agile Development

• Iterative Development: Development organized into short iterations (1–4 weeks),
each delivering a working increment.
• Incremental Delivery: Each sprint delivers new features; full product emerges over
multiple sprints.

18 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• User Stories: Requirements expressed as user stories (e.g., “As a user, I want to reset
my password so that I can regain access.”).
• Continuous Feedback: Product backlog prioritized and refined based on user feed-
back.
• Adaptive Planning: Plans are continuously adjusted based on actual progress and
changing requirements.
• Minimal Documentation: Documentation is created as needed; working software is
the primary output.
• Daily Collaboration: Daily standup meetings (15 minutes) ensure team alignment.
• Test-Driven Development: Tests written before code; automated testing throughout.
• Continuous Integration: Code changes integrated multiple times per day; automated

rk
build and test.
• Retrospectives: Teams reflect on what went well and what to improve after each
sprint.

6.3. Agile Lifecycle Diagram

A
ic
Product Backlog (Prioritized List of Requirements / User Stories)
Backlog Refinement
em

Sprint Daily Sprint

Sprint
Planning Standup Review & Retro
ad

Increment (Potentially Shippable Product Increment)

Typical Sprint Duration: 1–4 weeks

Figure 6: Agile Development Lifecycle – Iterative sprint-based model.

Ac

E REAL-WORLD EXAMPLE
Example – Agile Development of Mobile Fitness App:
• Product Backlog: User registration, workout logging, progress charts, social
sharing, push notifications.
• Sprint 1 (2 weeks): Implement user registration and login. Daily standups
ensure developers align. Review at end: “Successfully implemented OAuth login.”
Feedback: “Add fingerprint authentication for mobile.” (Added to backlog).
• Sprint 2 (2 weeks): Implement workout logging and progress charts. Retrospec-
tive: “We spent too much time on chart UI. Next time, use existing library.”
• Sprint 3 (2 weeks): Social sharing and push notifications.
• After 3 sprints (6 weeks): MVP released to beta users for feedback.
• Sprint 4: Based on user feedback, prioritize features and continue development.

19 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

This approach delivers value incrementally, enables rapid course correction, and keeps
the team motivated with visible progress.

rk
A
ic
em
ad
Ac

20 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

7. Dynamic System Development Method (DSDM)

D DEFINITION
Dynamic System Development Method (DSDM) is a UK-originated framework
for Agile software development that provides a structured approach to rapid, iterative
development. It extends Agile principles with formal project governance and risk
management suitable for enterprise environments.

7.1. Overview of DSDM

DSDM was created in the 1990s by a consortium of UK software companies to address
limitations of RAD and early Agile approaches in enterprise settings. It combines best
practices from RAD, Agile, and traditional project management.
Core Philosophy:

rk
• People-Centric: Focus on skilled, motivated teams.
• Iterative and Incremental: Deliver working software in short cycles.

A
• Business-Focused: Align with business objectives; deliver business value early.
ic
• Governance: Formal controls and reviews (unlike pure Agile).
• MoSCoW Prioritization: Must have, Should have, Could have, Won’t have.
em

7.2. Phases of DSDM

Refinement
3. 4. 5.
ad

1. 2. 6.
Business Functional Design
Pre-Project Feasibility Impl.
Study Model Build

Charter project Feasibility Deploy &

Approval study Business Create Build & review
Ac

processes prototypes test code

Figure 7: DSDM Phases.

7.2.1. Phase Details

• Phase 1 – Pre-Project: Project initiation, charter creation, business case justification.
Duration: 1–2 weeks.
• Phase 2 – Feasibility: Technical and organizational feasibility assessment. Duration:
2–4 weeks.
• Phase 3 – Business Study: Understand business processes, rules, requirements
through workshops and interviews. Deliverable: Business model. Duration: 4–8 weeks.
• Phase 4 – Functional Model Iteration: Build prototypes with increasing function-
ality; iterative refinement. Duration: 4–12 weeks.
• Phase 5 – Design and Build Iteration: Design architecture, build and unit test

21 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

code in iterative cycles. Duration: 4–16 weeks.

• Phase 6 – Implementation: Deploy to production, user training, go-live support.
Duration: 2–4 weeks.

7.3. Benefits of DSDM

• Time-to-Market: Faster delivery compared to Waterfall; structured iterations similar
to RAD.
• Business Focus: MoSCoW prioritization ensures high-value features are built first.
• Risk Management: Iterative delivery reduces risk; issues identified and corrected
early.
• Enterprise Governance: Formal phase gates and steering committees provide control.

rk
• Flexible Scope: Can adjust scope within timeboxes; less scope creep.
• Reduced Rework: Frequent prototyping catches design flaws early.

A
• User Involvement: Active participation in iterations ensures alignment with user
needs.

E REAL-WORLD EXAMPLE
ic
Example – DSDM for Bank’s Internet Banking Portal:
em
• Pre-Project: Bank CIO approves project; business case shows 15% reduction in
branch traffic.
• Feasibility: Technology stack ([Link], React, PostgreSQL) deemed feasible;
security requirements identified.
• Business Study: Analyze customer journey for account viewing, fund transfer,
ad

bill payment, investment.

• Functional Model Iteration (Week 1–8):
– Iteration 1: Account viewer prototype; stakeholder feedback: “Add transaction
Ac

search.”
– Iteration 2: Add search; new feedback: “Show investment portfolio value.”
– Iteration 3: Investment portfolio added; approved for next phase.
• Design & Build (Week 9–20):
– Sprint 1: Implement authentication and account viewer.
– Sprint 2: Fund transfer with approval workflow.
– Sprint 3: Payment processing integration with RBI-certified gateway.
– User acceptance testing after Sprint 3.
• Implementation: Soft launch to 1000 customers; monitor for issues; full rollout
after 2 weeks.
• Total Timeline: 6 months vs. 12 months with Waterfall.

22 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

8. Extreme Programming (XP)

D DEFINITION
Extreme Programming (XP) is an Agile software development methodology that
emphasizes technical excellence and responsiveness to changing requirements through
specific engineering practices. It pushes best practices to “extreme” levels to manage
risk and ensure quality.

8.1. Core Values of XP

• Communication: Open, frequent, honest communication among team members and
with customers.
• Simplicity: Do the simplest thing that could possibly work; avoid over-engineering.

rk
• Feedback: Continuous feedback from tests, customer, and team; short feedback loops.
• Courage: Make aggressive changes; refactor code without fear; throw away code if

A
needed.
• Respect: Mutual respect among team members; confidence in each other’s abilities.
ic
8.2. Practices of XP
• Pair Programming: Two developers share one workstation; one writes code, the
em

other reviews and provides real-time feedback. Reduces defects, spreads knowledge.
• Test-Driven Development (TDD): Write automated test cases before writing code.
Process: Red (test fails) → Green (code passes test) → Refactor (improve code).
ad

• Continuous Integration: Code changes integrated multiple times per day (ideally
every few hours). Automated build and test runs after each integration. Catches
integration issues early.
Ac

• Refactoring: Continuously improve code structure without changing functionality.

Reduces complexity, improves maintainability, reduces defects.
• Coding Standards: Team agrees on naming conventions, formatting, comment
standards. Consistent code is easier to understand and maintain.
• Simple Design: Implement features with simplest design that meets current require-
ments. Avoid premature optimization.
• Collective Ownership: Any developer can improve any part of the codebase; no
individual “owns” modules. Spreads knowledge, prevents bottlenecks.
• Continuous Delivery: Release working software very frequently (weekly or more).
Business gets value incrementally.
• Planning Game: Customer and developers collaborate to prioritize features and
estimate effort. Estimates guide planning.
• Metaphor: Team develops a consistent vocabulary (metaphor) for discussing the

23 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

system’s behavior.

8.3. XP Workflow Diagram

Refactor

Write Test Write Code Pair Review Integrate

TDD Cycle: 15–30

Issuemin per iteration
XP Practices Across the Development Process
Continuous Integration (hourly) | Collective Code Own-
ership | Coding Standards | Simple Design | Refactoring

Figure 8: Extreme Programming Workflow – TDD cycle integrated with pair programming and CI.

rk
8.4. Advantages of XP
• High Quality: TDD and pair programming drastically reduce defects (up to 50%

A
fewer bugs reported).
• Flexibility: Refactoring and simple design make code easy to modify; requirements
ic
changes manageable.
• Knowledge Sharing: Pair programming and collective ownership ensure knowledge
em

spreads across the team.

• Reduced Risk: Continuous integration and testing identify problems immediately;
no “integration surprises” at the end.
ad

• Team Morale: Pair programming reduces isolation; continuous delivery gives team
visibility and satisfaction.

8.5. Challenges of XP
Ac

• Cost: Pair programming doubles labor cost in the short term (though quality gains
may offset this).
• Learning Curve: Team must learn TDD, refactoring, and CI practices; productivity
initially decreases.
• Infrastructure: Requires automated testing framework, CI/CD tools, build servers.
• Team Stability: Works best with stable, co-located teams; difficult with high turnover
or remote work.
• Scalability: Designed for small teams (5–10); unclear how to scale XP to large
projects.

24 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

E REAL-WORLD EXAMPLE
Example – XP for Financial Trading Engine:
• Requirements: Build a low-latency trading system to execute stock orders within
10 milliseconds.
• Pair Programming: Junior developer and experienced developer work on critical
trading logic together, catching edge cases in real time.
• TDD Approach:
– Test 1: “Order placed with insufficient funds should be rejected.” Write test;
fails.
– Write code to reject order; test passes.
– Test 2: “Multiple orders should not execute in parallel (concurrency issue).”
Write test; fails.
– Write thread-safe code; test passes.

rk
• Continuous Integration: Every 2 hours, code merged to mainline; automated
tests run; latency benchmarks measured. If latency degraded, developers refactor
immediately.

A
• Refactoring: After release, team refactors critical path from 12ms to 8ms latency;
no new features added, but quality improved.
ic
• Result: Extremely reliable trading engine with <5 critical bugs found in production
over 2 years vs. 50+ bugs in previous iteration.
em
ad
Ac

25 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

9. Managing Interactive Processes

D DEFINITION
Interactive Processes (also called Iterative or Adaptive Processes) refer to software
development methodologies such as Agile, Scrum, Kanban, and Spiral where devel-
opment occurs in cycles with continuous feedback and adaptation. Managing these
processes involves overcoming unique challenges and applying tailored strategies.

9.1. Challenges in Managing Interactive Processes

• Scope Management: In Agile, scope is flexible, leading to potential scope creep if
not carefully controlled. Features keep getting added, delaying release.

– Mitigation: Use MoSCoW prioritization; strictly timeboxed sprints; no mid-sprint

rk
changes.

• Estimation Difficulty: Without detailed upfront planning, estimating effort for

future sprints/iterations is hard.

A
– Mitigation: Use velocity-based planning (measure avg. story points completed
per sprint); three-point estimation.
ic
• Customer Availability: Agile requires continuous customer involvement (product
owner, review meetings), which busy customers can’t always provide.
em

– Mitigation: Designate a dedicated product owner; asynchronous feedback mecha-

nisms (video reviews).

• Documentation Debt: Agile’s “minimal documentation” philosophy can leave the

ad

system poorly documented, making maintenance hard.

– Mitigation: Generate documentation as a “story”; use auto-doc tools (Swagger

for APIs).
Ac

• Distributed Teams: Daily standups and pair programming require synchronous

communication; distributed teams across time zones struggle.

– Mitigation: Asynchronous standups (Slack updates); recorded code reviews; time

zone rotations.

• Quality Regression: Early iterations may prioritize speed over quality; technical
debt accumulates.

– Mitigation: Allocate 20% of each sprint to refactoring; enforce code review

standards.

• Requirements Evolution: Changing requirements mid-project can break the archi-

tecture; adaptive design needed.

– Mitigation: Use modular design; separate concerns; avoid tight coupling.

• Team Dynamics: Self-organizing teams require high trust and communication;

26 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

conflicts can derail progress.

– Mitigation: Team building activities; skilled Scrum Master as facilitator; clear

conflict resolution process.

9.2. Management Strategies for Interactive Processes

• Product Backlog Management:

– Maintain a prioritized, groomed backlog (top 2–3 sprints well-defined, future items
rough estimates).
– Regularly refine estimates as understanding improves.
– Remove or defer low-value items to prevent scope creep.

• Velocity Tracking:

rk
– Measure story points completed per sprint (velocity).
– Use historical velocity to predict how many story points can fit in future sprints.

A
– Example: If velocity is 40 points/sprint and the backlog has 400 points, estimate
10 sprints (5 months) to completion.
ic
• Burn-Down Charts:
em
– Visual representation of work remaining vs. time in a sprint.
– X-axis: Sprint days; Y-axis: Story points remaining.
– If burn-down line is above the ideal line, team is behind; accelerate or reduce scope.
ad

• Retrospectives:

– At the end of each sprint, team reflects: What went well? What could improve?
What will we commit to next sprint?
Ac

– Continuous improvement culture reduces issues accumulating.

• Communication Protocols:

– Daily standup (15 min): Each team member: (1) What did I do? (2) What will I
do? (3) Any blockers?
– Weekly demo: Show working features to stakeholders; gather feedback.
– Sprint planning: Team estimates and commits to upcoming sprint’s work.

• Risk Management:

– In iterative processes, risks are identified early (first few sprints); mitigation strate-
gies implemented.
– Example: If architectural risk identified in Sprint 1, allocate Sprint 2 to proof-of-
concept; mitigate before scaling.

27 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• Metrics and Transparency:

– Track key metrics: velocity, burn-down rate, defect density, deployment frequency.
– Make metrics visible to team and stakeholders (dashboard); data-driven decisions.

E REAL-WORLD EXAMPLE
Example – Managing Scrum for Enterprise ERP Rollout:
• Challenge: Large enterprise ERP project (200+ story points total) spanning 6
months; distributed team across Bangalore, Singapore, US.
• Strategies Applied:
– Velocity Tracking: Sprint 1 velocity = 35 points. Sprint 2 = 38 points.
Stabilized at 40 points/sprint.
– Burn-Down Management: Sprint 4 behind schedule; Scrum Master identi-

rk
fied: “Payment gateway integration delayed.” Team decided to defer less critical
reports to Sprint 5.
– Asynchronous Standups: Teams in different zones post 5-min video updates

A
in Slack instead of live 3am calls.
– Retrospectives: Sprint 3 retro identified: “Integration tests take 8 hours;
slows down CI.” Action: Parallelize test execution; reduced to 2 hours in Sprint
ic
4.
– Metrics Dashboard: Stakeholders see real-time velocity, burn-down, defect
em
counts; confidence in project health increased.
• Outcome: Project delivered in 6 months (on time); 98% of original scope completed
(2% deferred with business agreement).
ad
Ac

28 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

10. Basics of Software Estimation

D DEFINITION
Software Estimation is the process of quantifying the resources (time, effort, cost,
people, equipment) required to develop, test, and deploy a software project or com-
ponents thereof. Accurate estimation is crucial for project planning, budgeting, and
schedule management.

10.1. Need for Estimation

• Feasibility Analysis: Determine whether the project is worth undertaking within
budget and time constraints.
• Resource Allocation: Plan for team size, skill mix, equipment, and training needs.

rk
• Budget Planning: Set budget baselines; identify cost risks.
• Schedule Planning: Estimate project duration; identify critical path; plan milestones.

A
• Risk Assessment: Understand estimation uncertainty; prepare contingencies.
• Change Impact Analysis: When requirements change, estimate impact on effort
ic
and schedule.
• Performance Tracking: Actual vs. estimated effort reveals productivity trends;
em

enables corrective action.

• Vendor Negotiation: Detailed estimates support negotiations with outsourcing
vendors or clients.
ad

10.2. Types of Estimation

• Effort Estimation: Measured in person-months (PM), person-days (PD), or story
points.
Ac

– Example: “This project requires 12 person-months” (60 developers × 12 days, or

12 developers × 30 days).

• Duration Estimation: Measured in calendar months, weeks, or days.

– Example: “This project will take 6 calendar months with 2 developers” (12 PM / 2
devs = 6 months).

• Cost Estimation: Measured in monetary units (Rs., USD, EUR).

– Example: “12 PM @ Rs. 5 lakhs/PM = Rs. 60 lakhs project cost.”

• Resource Estimation: Estimating quantity and skills of team members.

– Example: “Need 1 architect, 5 developers, 2 testers, 1 BA.”

• Order-of-Magnitude (ROM): Rough estimate, ±50% accuracy. Done early in

project.

29 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

– Example: “Estimate: 8–12 months” (during concept phase).

• Budget Estimate: Refined estimate, ±20% accuracy. Done during planning.

– Example: “Estimate: 10 months, Rs. 50 lakhs” (after requirements analysis).

• Baseline Estimate: Final estimate, ±10% accuracy. Done at end of planning; used
for tracking.

– Example: “Baseline: 10 months, Rs. 50 lakhs, 6 developers.”

10.3. Estimation Accuracy vs. Project Phase

Estimation
Estimation Accuracy Improves as Project Progresses
Accuracy

High

rk
±3%

±5%

A
Medium ±10% ic
±20%
Low
em
±50%

0% Project Phase
Concept Planning Design Development Testing
ad

Figure 9: Estimation accuracy vs. project phase. Early estimates are rough; later estimates are more
precise.
Ac

30 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

11. Effort and Cost Estimation Techniques

D DEFINITION
Effort and Cost Estimation Techniques are structured methods to quantify
the work (effort) and monetary cost required for software development. Different
techniques suit different scenarios; often, multiple techniques are used and their results
compared for validation.

11.1. 1. Expert Judgment

D DEFINITION
Expert Judgment relies on the experience and intuition of seasoned professionals
to estimate project effort, duration, and cost based on past projects and domain

rk
knowledge.

11.1.1. Process

A
1. Identify 2–3 experts with experience in similar projects.
2. Present project requirements and scope.
ic
3. Each expert independently provides their estimate.
em
4. Discuss estimates; resolve disagreements.
5. Aggregate estimates (often using median or average).

11.1.2. Advantages
• Quick; doesn’t require formal data collection.
ad

• Incorporates real-world experience and context.

• Recognizes project nuances that may not be captured by models.
Ac

11.1.3. Disadvantages
• Subjective; prone to bias (overoptimism, anchoring).
• Accuracy depends on expert’s experience; outdated experts may miss new technologies.
• Lacks scientific rigor; hard to explain or justify estimates.

11.1.4. Best Used For

Rapid ROM estimates; projects where experts are available; familiar project types.

31 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

11.2. 2. Estimation by Analogy

D DEFINITION
Estimation by Analogy compares the current project with similar historical projects
and uses their actual effort as a basis for the current project’s estimate.

11.2.1. Process
1. Identify a historical project similar in scope, technology, and complexity.
2. Note the actual effort and cost of the historical project.
3. Identify differences between historical and current project (size, complexity, team
experience).
4. Adjust historical effort based on differences.

rk
5. Formula: Estimated Effort = Historical Effort × Adjustment Factors

11.2.2. Example

A
• Historical Project: Web portal for 50 users took 12 months with 6 developers = 72
person-months.
ic
• Current Project: Web portal for 500 users (10× larger user base).
• Adjustment: Database size 10× larger (2× complexity), but reusing framework (0.8×
em

factor).
• Estimated Effort: 72 × 10 × 2 × 0.8 = 1152 person-months (unrealistic; need to
reconsider approach or split into phases).

11.2.3. Advantages
ad

• Based on actual data; more objective than pure expert judgment.

• Incorporates learning from past mistakes and successes.
Ac

11.2.4. Disadvantages
• Requires good historical data repository (many organizations lack this).
• Similar projects are hard to find; projects always differ in some way.
• Adjustment factors are subjective.

11.3. 3. Algorithmic Estimation

D DEFINITION
Algorithmic Estimation uses mathematical models and historical data to quantify
effort as a function of project size and other variables. Models like COCOMO II,
Function Points, and Parametric models fall into this category.

32 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

11.3.1. General Form

Effort = a × (Size)b ×
Y
(Adjustment Factors)

Where:

• a, b are constants derived from historical data.

• Size is measured in KLOC (1000 Lines of Code), Function Points, or Story Points.
• Adjustment factors account for team experience, complexity, development environment.

11.3.2. Advantages
• Objective, repeatable, scientific.
• Transparently documented; easy to explain and justify.

rk
• Incorporates multiple factors (size, complexity, environment).
• Can be validated against historical data.

11.3.3. Disadvantages

A
• Requires calibration with historical data; new organizations may lack data.
ic
• Models assume certain project characteristics; may not apply to novel project types.
em
• Garbage in, garbage out: if size estimates are wrong, effort estimates are wrong.

11.3.4. Best Used For

Portfolio management; justifying effort estimates to clients; organizations with good
historical data.
ad

E REAL-WORLD EXAMPLE
Example – Combining Three Estimation Techniques for Validation:
A software company is asked to estimate effort for a new financial analytics application
Ac

(estimated at 50 KLOC).
1. Expert Judgment: Three analysts estimate 18, 20, 22 months → Median = 20
months.
2. Estimation by Analogy: Similar financial app 2 years ago was 40 KLOC, took
16 months. Scale factor = (50/40)1.2 (accounting for complexity) = 1.32. Adjusted
estimate: 16 × 1.32 = 21 months.
3. COCOMO II: Effort = 2.94 × (50)1.0 × 1.08 (moderate complexity) ×1.1 (new
team) = 2.94 × 50 × 1.1 × 1.08 = 174 person-months → 174/10 = 17.4 months.
Results: Expert = 20 months; Analogy = 21 months; COCOMO II = 17.4 months.
Average = 19.5 months. The PM proposes a baseline of 20 months. The range (17–21
months) provides a confidence band for stakeholders.

33 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

12. COSMIC Full Function Points

D DEFINITION
COSMIC (Common Software Measurement International Consortium) is an inter-
national standard for measuring functional size of software. Full Function Points
(FFP) quantify the size and complexity of software based on its functionality, inde-
pendent of technology, team, or implementation approach.

12.1. Concept of COSMIC

COSMIC was developed as a successor to Function Point Analysis (FPA), addressing
limitations of earlier function point methods:

• Purpose: Measure functional size of software for effort estimation, productivity

rk
analysis, and benchmarking.
• Basis: Software functionality is characterized by the data it processes (data movements,
transformations, storage).

A
• Universality: Applicable to all software types (business, real-time, embedded, scien-
tific).
ic
• Granularity: Can measure at project level or individual requirement level.
em

12.2. Functional Size Measurement – COSMIC Approach

COSMIC measures functional size based on four types of data movements:

• Entry (E): User or external system provides data to the software (e.g., “Login button
clicked”, “API request received”).
ad

• Exit (X): Software provides data to user or external system (e.g., “Display user
dashboard”, “Send email notification”).
Ac

• Read (R): Software reads data from persistent storage (database, file).

– Example: “Retrieve customer record from database.”

• Write (W): Software writes data to persistent storage.

– Example: “Save order to database.”

12.2.1. Calculation Formula

For a given user requirement or feature:

Size (in COSMIC FP) = (E + X + R + W) × Complexity Factor

Complexity Factor (1 to 3):

• 1 = Simple (straightforward data movement, no validation).

• 2 = Medium (some validation, minor conditional logic).

34 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• 3 = Complex (multiple validations, complex decision logic, error handling).

12.2.2. Example – COSMIC Measurement

Requirement: User Login

1. Entry: Username and password entered by user. E=1

2. Read: Verify credentials against user database. R=1
3. Write: Log login attempt to audit table. W=1
4. Exit: Display welcome message or error message. X=1
5. Complexity: Password validation, HTTPS security, failed attempt tracking. CF
=2

COSMIC Size = (1 + 1 + 1 + 1) × 2 = 8 COSMIC FP

rk
12.3. Applications of COSMIC
• Effort Estimation: Correlate COSMIC FP with effort from historical projects.

A
– Example: If historical data shows 1 COSMIC FP = 0.5 person-days, then 8 COSMIC
FP = 4 person-days for login feature.
ic
• Productivity Analysis: Measure output (COSMIC FP) per person-day; benchmark
against industry.
em

• Scope Validation: COSMIC identifies all data movements; ensures requirements are
complete.
• Quality Assessment: High COSMIC per unit effort might indicate quality issues;
ad

need for reviews.

• Benchmarking: Compare COSMIC productivity across projects and organizations.

12.4. Advantages and Limitations of COSMIC

Ac

12.4.1. Advantages
• Universal: Applicable to all software types (unlike FPA which is business-focused).
• Objective: Based on data movements, not technology; independent of implementation.
• Decomposable: Can measure at feature level or system level; flexible granularity.
• Tool Support: Automated COSMIC measurement tools available.

12.4.2. Limitations
• Learning Curve: Requires training to properly identify data movements and com-
plexity.
• Subjectivity: Determining complexity factor and boundary of “a requirement” involves
judgment.
• Not Applicable to All Domains: Less effective for algorithmic or UI-heavy systems

35 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

where functional data movements don’t capture all complexity.

• Historical Data Needed: Without calibration with historical data, COSMIC alone
doesn’t provide effort estimates.

E REAL-WORLD EXAMPLE
Example – COSMIC Measurement of E-Commerce Checkout
Requirement: Process Payment
• Entry: User clicks “Pay Now”; cart data sent. E = 1
• Read: Retrieve payment gateway API URL from config; fetch customer discount
rules. R = 2
• Transformation: Validate card number (Luhn algorithm); apply discount; calculate
tax. Complexity = 2 (multiple validations).
• Write: Save transaction record to database; update inventory. W = 2

rk
• Exit: Display payment confirmation; send confirmation email. X = 2
COSMIC Size = (1 + 2 + 2 + 2) × 2 = 14 COSMIC FP
Estimation: Assume 1 COSMIC FP = 0.75 person-hours (based on historical data).

A
Effort = 14 × 0.75 = 10.5 hours for checkout feature.
ic
em
ad
Ac

36 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

13. COCOMO II
D DEFINITION
COCOMO II (Constructive Cost Model Version 2) is an advanced algorithmic effort
estimation model developed at USC by Barry Boehm. It estimates software project
effort and schedule based on software size and a set of cost drivers (factors affecting
productivity).
COCOMO II is an update to the original COCOMO model (1981), tailored for modern
software development practices (OOP, COTS, agile).

13.1. Overview of COCOMO II

Core Philosophy:

rk
• Size-Based: Effort is primarily a function of software size (measured in KLOC or
Function Points).
• Cost Driver Adjustments: Effort is multiplied by factors representing team experi-

A
ence, development environment, technology risk, etc.
• Empirical: Derived from analysis of 100+ actual software projects; continuously
ic
updated with new data.
• Scalable: Works for small (<5 KLOC) to very large (> 1000 KLOC) projects.
em

13.2. COCOMO II Sub-Models

COCOMO II provides three sub-models for different stages of a project:
13.2.1. 1. Composition Model (Early Project Stage)
ad

• Used during concept and requirement phase when detailed architecture not yet defined.
• Assumes COTS components available; integration effort primary concern.
Ac

• Formula: Effort (PM) = 2.45 × (KLOC)1.1 (simple, no cost drivers yet).

• Accuracy: ±50% (order-of-magnitude estimate).

13.2.2. 2. Application Composition Model (RAD Development)

• Used for Rapid Application Development using visual tools and COTS.
• Accounts for modern development practices (reuse, visual development).
• Formula: Combines visual development effort and integration effort.
• Effort (PM) = (Total Object Points) / (Productivity Rate)
• Productivity Rate adjusted based on experience and tool sophistication.

13.2.3. 3. Post-Architecture Model (Full Development)

• Used after architecture is designed and development begins.
• Most comprehensive; used for detailed project planning.

37 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

• Takes into account all cost drivers (team experience, development environment, risk,
etc.).
• Formula: (described in detail below).

13.3. COCOMO II Effort Estimation Formula

The Post-Architecture Model is most commonly used:

Effort (Person-Months) = A × (KLOC)B ×

Y
(EMi )
i

Where:

• A = Calibration constant (typically 2.94).

• KLOC = Estimated size in thousands of lines of code.

rk
• B = Exponential constant (typically 1.0–1.2) accounting for economies/diseconomies
of scale.
• EMi = Effort Multipliers (cost drivers).

A
13.4. COCOMO II Cost Drivers (Effort Multipliers)
ic
Cost drivers are categorized into four groups:
em

1. Product Factors
Size, Complex-
ity, Reliability
2. Platform Factors
Constraints, De-
velopment Env.
ad

3. People Factors
Experience, Capability
4. Process Factors
Methodology,
Ac

Tools, Quality

13.4.1. Key Cost Drivers and Multiplier Values

38 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

S SUMMARY TABLE

Cost Driver Very Low Nominal High

Product Com- 0.73 1.0 1.40

plexity
Reusability Re- 1.19 1.0 0.81
quired
Documentation 0.85 1.0 1.30
Required

Time Constraint 1.43 1.0 1.0

Development 1.19 1.0 0.86
Flexibility

rk
Analyst Capabil- 1.42 1.0 0.71
ity
Programmer Ca- 1.42 1.0 0.71
pability
Team Experi- 1.29 1.0
A
0.85
ic
ence

Process Matu- 1.17 1.0 0.87

em

rity
Use of Tools 1.17 1.0 0.90

Interpretation:
ad

• Multiplier > 1.0 = Increases effort (makes project harder).

• Multiplier < 1.0 = Decreases effort (makes project easier).
Ac

• Example: High analyst capability (0.71) = 29% less effort than nominal.
• Example: Very high complexity (1.40) = 40% more effort than nominal.

39 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

13.5. Example – COCOMO II Calculation

Project: Banking Portal Upgrade
Estimated
Cost Size: 80 KLOC
Drivers:
• Product Complexity: High (1.40)
• Team Experience: Nominal (1.0)
• Analyst Capability: High (0.71)
• Process Maturity: Nominal (1.0)
• Use of Tools: Nominal (1.0)
COCOMO II Calculation:
A = 2.94, B = 1.0
Effort = 2.94 × (80)1.0 × 1.40 × 1.0 × 0.71 × 1.0 × 1.0
= 2.94 × 80 × 1.40 × 0.71
= 2.94 × 80 × 0.994
= 234.5 Person-Months
Result:

rk
Estimated Effort: 234.5 PM
With 10 developers: Duration = 234.5 / 10 = 23.5
months
Cost @ Rs. 5 lakh/PM = Rs. 117.25 crores

13.6. Advantages of COCOMO II

A
ic
• Comprehensive: Incorporates 22+ cost drivers; captures most factors affecting effort.
• Empirical: Based on analysis of real projects; continuously calibrated.
em

• Scalable: Works across wide range of project sizes and types.

• Flexible: Three sub-models for different project stages.
• Reproducible: Scientific approach; easy to document and explain.
ad

• Tool Support: Free and commercial COCOMO II estimation tools available.

13.7. Limitations of COCOMO II

Ac

• KLOC Estimation Difficulty: Primary input is KLOC; estimating lines of code is

challenging and subjective.
• Calibration Needed: Multiplier values based on USC projects; may not apply to all
organizations.
• Not Agile-Focused: Originally designed for plan-driven projects; less suitable for
Agile teams using story points.
• Complexity Overhead: 22+ factors to estimate; requires expertise; time-consuming.
• Historical Data Requirement: Best results when calibrated with organization’s
historical project data.

40 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

E REAL-WORLD EXAMPLE
Example – COCOMO II for Different Project Types:
• Small Internal Tool (10 KLOC): A = 2.94, B = 1.0. Effort = 2.94 × 10 × 1.0
(all nominal) = 29.4 PM. With 2 developers = 14.7 months.
• Medical Device Software (100 KLOC, High Reliability): Reliability multi-
plier = 1.40. Effort = 2.94 × 100 × 1.40 = 411.6 PM. With 10 developers = 41.2
months.
• E-Commerce Platform (200 KLOC, High Reuse): Reusability multiplier =
0.81. Effort = 2.94 × 200 × 0.81 = 476.8 PM. With 15 developers = 31.8 months.

rk
A
ic
em
ad
Ac

41 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

14. Parametric Productivity Model

D DEFINITION
Parametric Productivity Model is an estimation approach based on the rela-
tionship between input parameters (size, technology, team, environment) and output
productivity (work produced per unit time). Productivity is the inverse of effort per
unit size: Productivity = Size / Effort (e.g., KLOC/PM or Function Points/Person-
Day).

14.1. Concept of Parametric Models

Parametric models are based on statistical analysis of historical data to identify correlations
between project parameters and productivity:

rk
• Primary Metric: Productivity = Size of Deliverable / Effort Expended

– Example: 50 KLOC delivered in 100 PM = 0.5 KLOC/PM productivity.

A
• Inverse Relationship: Productivity and Effort are inversely related.

– High productivity = Low effort per unit size.

ic
– Low productivity = High effort per unit size.
em
• Key Formula: Effort = Size/Productivity
• Productivity Factors: Influenced by technology, team experience, development
environment, methodology.

14.2. Parametric Estimation Process

ad

1. Historical Data Collection: Gather data from past projects: size (KLOC or FP),
effort (PM), productivity (size/effort).
Ac

2. Identify Productivity Drivers: Analyze which factors influence productivity

(programming language, team experience, tools, process).
3. Build Regression Model: Use statistical regression to model productivity as a
function of factors:

Productivity = f (Language, Experience, Tools, Methodology, . . .)

4. Estimate Current Project Productivity: Based on current project’s characteris-

tics, predict expected productivity using the model.
5. Calculate Effort: Effort = Estimated Size/Predicted Productivity

14.3. Role in Effort Estimation

• Productivity Benchmarking: Compare current project’s expected productivity
with industry benchmarks or organizational historical data.
• Project Risk Assessment: If expected productivity is significantly lower than

42 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

historical average, project is high-risk (schedule/budget risk).

• Resource Planning: If productivity is low, more people or longer duration needed to
deliver the same size.
• Technology / Tool Evaluation: By measuring productivity before and after adopting
a new tool or methodology, the benefit of the tool/methodology can be quantified.
• Continuous Improvement: Organizations track productivity trends over time;
increases indicate process improvements.

14.4. Example – Parametric Productivity Model

Organization’s Historical Data:
Project Size Effort Productivity Technology Experience
(KLOC) (PM) (KLOC/PM)

rk
A 20 40 0.50 Java Low
B 50 75 0.67 Java Medium
C 30 40 0.75 C# Medium
D
E
60
40
80
50
0.75
0.80
A C#
Python
High
High
ic
Analysis:

• Average Productivity = (0.50 + 0.67 + 0.75 + 0.75 + 0.80) / 5 = 0.694 KLOC/PM

em

• Trend: Python + High experience → highest productivity (0.80).

• Java + Low experience → lowest productivity (0.50).

Current Project Estimation:

ad

• Project: Mobile app, 25 KLOC, Team has Python experience, high maturity.
• Expected Productivity: Similar to Project E (0.80 KLOC/PM).
Ac

• Estimated Effort: 25 KLOC / 0.80 KLOC/PM = 31.25 PM.

• Duration: 31.25 PM / 5 developers = 6.25 months.

14.5. Advantages and Limitations

14.5.1. Advantages
• Data-Driven: Based on empirical data; objective and repeatable.
• Actionable Insights: Productivity metrics directly inform scheduling and resource
planning.
• Improvement Tracking: Over time, productivity improvements due to tools, training,
or process changes are quantifiable.
• Comparative Analysis: Can compare productivity across teams, departments, or
organizations.

43 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

14.5.2. Limitations
• Historical Data Dependency: Requires substantial historical project data (10+
projects minimum); new organizations may lack this.
• Context Variability: Productivity factors may vary across domains, technologies,
and team compositions; hard to generalize.
• Statistical Expertise Needed: Building and interpreting regression models requires
statistical knowledge.
• Changing Environment: Productivity models become outdated as technology, tools,
and processes evolve.

rk
A
ic
em
ad
Ac

44 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

Unit–2 Quick Revision Summary

K KEY POINTS
Essential Definitions to Memorise:
• Software Process: Set of activities, methods, practices to develop and maintain
software.
• Waterfall: Linear, sequential phases; document-driven; inflexible to change.
• Incremental: Build in cycles; each increment delivers partial functionality; user
involved throughout.
• Spiral: Risk-driven iterative model with 4 quadrants per spiral (Planning, Risk
Analysis, Engineering, Evaluation).
• RAD: Rapid Application Development; timeboxed 60–90 day cycles; visual tools;

rk
COTS components.
• Agile: Iterative development, working software every 1–4 weeks, continuous
feedback, change acceptance.

A
• DSDM: Dynamic System Development Method; enterprise Agile with formal
governance.
ic
• XP: Extreme Programming; emphasis on technical practices (TDD, pair program-
ming, CI, refactoring).
• Software Estimation: Quantifying resources (time, effort, cost) required for
em

software development.
• COCOMO II: Effort = A × (KLOC)B × (EMi ) ; uses KLOC size as input.
Q

• COSMIC: Data-movement based functional size measurement (Entry, Exit, Read,

Write).
ad

• Parametric Model: Productivity = Size / Effort; use historical data to predict

effort.
Ac

S SUMMARY TABLE
Unit–2 Process Models Quick Comparison:
Model Approach Testing Risk Flexibility
Mgmt
Waterfall Sequential Late Minimal Very Low
Incremental Iterative Each Inc. Good Medium
Spiral Risk-Driven Each Loop Excel- High
lent
RAD Timeboxed Continuous Good High
Agile Sprint- Continuous Good Very High
Based
XP Extreme TDD Good Very High

45 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 BOE-068 | Software Project Management
Unit – 2 AcademicArk

! IMPORTANT / EXAM TIP

Top 5 Most Frequently Asked AKTU Questions – Unit 2:

1. Explain Waterfall, Spiral, and Incremental models with diagrams. [10 marks]
2. What is Agile? Explain principles, characteristics, and advantages. [10 marks]
3. Compare Extreme Programming (XP) practices; explain TDD and pair program-
ming. [7 marks]
4. Explain COCOMO II effort estimation model with an example calculation. [10
marks]
5. What is RAD? Explain phases and advantages/limitations. [7 marks]

K KEY POINTS

rk
Estimation Techniques Comparison:
• Expert Judgment: Quick, intuitive, but subjective.
• Estimation by Analogy: Uses historical similar projects; adjustment-based.
•
•
A
Algorithmic (COCOMO II): Scientific, reproducible, needs KLOC input.
COSMIC: Functional size based on data movements; universal.
ic
• Parametric Productivity: Uses historical productivity to predict effort.
em
ad
Ac

46 AKTU | [Link] 6th Sem | 2025–26

Prepared for AcademicArk – Premium Notes
AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026
 rk
End of Unit – 2 Notes

A
Subject: BOE-068 | Software Project Management
University: Dr. A.P.J. Abdul Kalam Technical University (AKTU)
ic
Semester: [Link] 6th Semester | Academic Year: 2025–26
em

Prepared By AcademicArk – Premium Notes

[Link]
ad

These notes cover Software Process Models (Waterfall to Agile),

Rapid Application Development (RAD), and Estimation Techniques
(COCOMO II, COSMIC, Parametric Models).
Ac

All topics strictly aligned with AKTU BOE-068 syllabus.

Best of luck for your examinations!

AcademicArk
Downloaded by Rahul • AcademicArk • 05 May 2026 Visit: [Link]