SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT I

Software Project
Management

Complete Study Notes

UNIT I UNIT II

Introduction to Software
Project Management Technical Planning

Comprehensive Academic Reference Material

Page 1
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT I

TABLE OF CONTENTS

UNIT I — Introduction to Software Project Management 3

1. The Nature of Software Production 3

2. Key Objectives of Effective Management 3

3. Quality, Productivity & Risk Reduction 4

4. Role of the Software Project Manager 4

5. Technology & Human Factors 4

6. Tools and Environments 5

7. Transition of the Product to the User 5

UNIT II — Technical Planning 6

1. Life-Cycle Models 6

2. Types of Plans & Plan Documentation Methods 6

3. Work Breakdown Structures 7

4. PERT, CPM & Gantt Charts 7

5. Standards 8

6. Risk Management, Entry & Exit Criteria 8

7. Performance Prediction & People 9

8. Prototyping & Modelling 9

9. Inspections, Reviews & Process Assessment 9

10. Development Methods & Metrics 10

Page 2
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT I

UNIT I
Introduction to Software Project Management

1. The Nature of Software Production

Software production is fundamentally different from traditional manufacturing. Unlike physical goods, software is
intangible, highly complex, and continuously evolving. Understanding its unique characteristics is the first step in
effective project management.

Characteristic Description

Intangibility Software cannot be physically touched or measured by weight/size

Complexity Even small systems can have millions of interactions

Changeability Software is easily modifiable, leading to scope creep

Conformity Must conform to human institutions and interfaces

Invisibility Software structure is not inherently visible or spatial

Challenges in Software Production:

• Estimating effort and schedule is notoriously difficult due to project uniqueness.
• Requirements are often incomplete or change during development.
• Technical debt accumulates when quick fixes override best practices.
• Coordination among large teams with different skill sets poses significant hurdles.

2. Key Objectives of Effective Management

SCOPE TIME COST QUALITY

Meet functional &

Define & control what is Deliver on schedule; Stay within approved
non-functional
and is not included manage milestones budget
requirements

The Iron Triangle (Scope–Time–Cost) defines the classic constraints. Quality is often considered a fourth dimension.
Effective management balances all four without sacrificing one for another.

3. Quality, Productivity & Risk Reduction

QUALITY PRODUCTIVITY RISK REDUCTION

• Conformance to requirements • Lines of code / function points per person-month

• Identify risks early
• Fitness for purpose • Improved by better tools, training, and • Quantify
processprobability
maturity & impact
• McCall's quality factors: correctness,• CMMI
reliability,
levels
efficiency,
reflect productivity
integrity, usability
capability
• Mitigation strategies
• IEEE standards compliance • Contingency planning
• Risk register maintenance

4. Role of the Software Project Manager

Page 3
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT I

The Software Project Manager (SPM) is the central coordinator responsible for planning, executing, monitoring, and
closing software projects. Key responsibilities span technical, human, and organisational dimensions:

Planning & Scheduling Define WBS, estimate effort, allocate resources, set milestones.

Team Leadership Motivate team, resolve conflicts, conduct performance reviews.

Communication Report to stakeholders, facilitate team meetings, manage expectations.

Risk Management Identify, analyze, and mitigate project risks proactively.

Quality Assurance Enforce coding standards, oversee reviews and testing.

Change Management Evaluate change requests, update plans, manage scope creep.

5. Technology, Human Factors & Usability

Technology Factors Human Factors Usability

• Programming languages & • Team skills and • Learnability & efficiency
paradigms experience • Error prevention &
• Frameworks and • Communication and recovery
middleware collaboration • Accessibility (WCAG)
• Hardware constraints • Motivation and morale • User testing & feedback
• Interoperability standards • Cognitive biases in • ISO 9241 standards
• Emerging tech: AI, cloud, estimation
DevOps • Distributed/remote teams

6. Tools and Environments

Software project management relies on a rich ecosystem of tools to plan, track, and control work:

Category Examples Purpose

Project Planning MS Project, Jira, Asana Schedule, WBS, resource allocation

Version Control Git, SVN, Mercurial Source code management & history

CI/CD Jenkins, GitHub Actions, CircleCI Automated build, test & deploy

Issue Tracking Jira, Bugzilla, Redmine Bug reporting & task management

Communication Slack, Teams, Confluence Team collaboration & documentation

IDE & Editors VS Code, IntelliJ, Eclipse Code development & debugging

Testing Selenium, JUnit, PyTest Automated functional & unit testing

7. Transition of the Product to the User

Product transition is the final, critical phase where the developed software is delivered and operationalized by the end
user. A poorly managed transition can undermine even a technically excellent product. Key activities include:
1. Acceptance Testing: User Acceptance Testing (UAT) verifies the system meets contractual and user
requirements before go-live.
2. Training: Users and administrators are trained on system features, workflows, and troubleshooting.

Page 4
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT I

3. Documentation: User manuals, API references, admin guides, and online help are finalized and delivered.
4. Deployment: The system is installed in the production environment — phased rollout, pilot, or big-bang
deployment strategies may be used.
5. Support & Maintenance: Post-release support plans are established: helpdesk, SLAs, bug-fix schedules, and
enhancement pipelines.
6. Knowledge Transfer: Development team knowledge is transferred to the operations/maintenance team.

Key Point: Successful transition requires stakeholder engagement throughout the project, not just
at the end. Change management and organizational readiness are as important as technical
delivery.

Page 5
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT II

UNIT II
Technical Planning

1. Life-Cycle Models
A software life-cycle model (SDLC model) defines the phases a project passes through, their sequence, and the
criteria for transitioning between them. Choosing the right model is a critical early project decision.

Model Key Characteristics Best Suited For

Waterfall Sequential phases; each phase completed beforeWell-defined,

the next; easy
stable
to manage
requirements

Incremental Delivered in increments; early working versions; feedback

Large systems
integrated
with phased delivery

Spiral Risk-driven; iterative prototyping; four quadrants per

High-risk,
cycle complex projects

V-Model Each dev phase paired with a test phase; verification

Safety-critical
& validation
systems

Agile/Scrum Sprints; daily stand-ups; backlog; iterative delivery;

Evolving
customer
requirements;
collab fast delivery

RAD Rapid prototyping; reuse; parallel development; short

Business
cyclesapps;
(60–90
UI-heavy
days) systems

DevOps CI/CD; continuous delivery; dev & ops integration;Cloud-native,

automated pipelines
frequent releases

2. Types of Plans & Plan Documentation Methods

Project Management Plan Master plan encompassing all subsidiary plans; approved by
stakeholders.

Requirements Management How requirements will be gathered, analysed, traced, and controlled.
Plan

Quality Management Plan Standards, processes, and responsibilities for ensuring quality.

Risk Management Plan Risk identification, analysis, response strategies, and monitoring.

Communication Plan Who receives what information, when, and through which channels.

Configuration Management How software baselines and changes are controlled and tracked.
Plan

Test Plan Test strategies, environments, scope, entry/exit criteria, and schedules.

Documentation Methods:
• IEEE 1058 — Standard for Software Project Management Plans
• Structured documents — Title, objectives, scope, assumptions, constraints, schedule
• Templates — Reusable plan skeletons that enforce consistency across projects
• Wiki-based docs — Confluence or Notion pages for living documentation

3. Work Breakdown Structures (WBS)

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the total project scope into manageable work
packages. It is the foundation for scheduling, cost estimation, and resource planning.

Page 6
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT II

• Level 1: Project — The entire project at the top.

• Level 2: Major deliverables or phases (e.g., Requirements, Design, Implementation, Testing, Deployment).
• Level 3: Sub-deliverables or work packages broken from level 2.
• Work Package: Lowest level; assignable to a person/team; has duration, cost, and outputs.

WBS Dictionary: Accompanies the WBS; describes each element's scope, deliverables, assigned resources, and
acceptance criteria.

100% Rule: The WBS must capture 100% of the project scope — no more, no less.

4. PERT, CPM & Gantt Charts

Technique Full Form Key Features Output

PERT Program Evaluation & Review

3-point
Technique
estimates: Optimistic (O), Most LikelyExpected
(M), Pessimistic
duration,(P)
variance, probability of comp
Expected time = (O+4M+P)/6
Focuses on uncertainty

CPM Critical Path Method Deterministic durations; identifies critical path

Critical
(longest
path,
path);
earliest/latest
calculatesstart
float/slack
& finish,
forfloat
non-c

Gantt Chart Bar Chart (by Henry Gantt)

Visual timeline; bars represent task duration;Visual
showsproject
dependencies;
schedule;easy
progress
stakeholder
trackingcomm

Critical Path: The sequence of tasks that determines the minimum project duration. Any delay in a critical-path task
delays the entire project. Tasks off the critical path have float/slack — they can slip by that amount without affecting the
end date.

5. Standards

Standard Scope

IEEE 1058 Software Project Management Plans

IEEE 830 Software Requirements Specifications

ISO/IEC 12207 Software life-cycle processes

ISO/IEC 15288 System life-cycle processes

CMMI Capability Maturity Model Integration — process improvement framework (Levels 1–5)

ISO 9001 Quality management system requirements

IEEE 829 Software Test Documentation

PMBOK Project Management Body of Knowledge — PMI's process groups and knowledge areas

6. Risk Management, Entry & Exit Criteria

• Risk Identification: Brainstorming, checklists, assumption analysis, SWOT — produce a risk register.
• Risk Analysis: Qualitative (probability × impact matrix) and Quantitative (EMV, Monte Carlo simulation).
• Risk Response Planning: Avoid, Transfer, Mitigate, or Accept. Assign risk owners.
• Risk Monitoring: Track triggers, reassess risks periodically, update register at each milestone.

Entry Criteria Exit Criteria

Page 7
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT II

Conditions that must be met BEFORE a phase begins: Conditions that must be met BEFORE a phase is declared complete:
• Previous phase deliverables reviewed & approved • All planned tasks completed
• Resources allocated • Defect density below threshold
• Test environment ready • Stakeholder sign-off obtained
• Requirements baselined • Documentation complete

Intermediate Checkpoints:
Milestones within a phase (e.g., design review, code freeze, integration complete) allow early detection of problems.
They provide management visibility and serve as decision points for go/no-go decisions before major commitments.

7. Performance Prediction, Analysis & People

Performance Prediction:
• Earned Value Management (EVM): Tracks schedule performance index (SPI) and cost performance index (CPI).
• SPI = EV/PV (> 1 means ahead of schedule); CPI = EV/AC (> 1 means under budget).
• Estimate at Completion (EAC) = BAC/CPI — predicts final project cost based on current performance.
• Control charts and trend analysis identify process instability and predict future defect rates.

People Management:
• Tuckman's stages: Forming → Storming → Norming → Performing → Adjourning.
• Motivation theories: Maslow's hierarchy, Herzberg's two-factor theory, McGregor's Theory X/Y.
• Roles: Business analyst, architect, developer, tester, DBA, scrum master, product owner.
• Skills matrix: Identifies team competencies; guides training and hiring decisions.

8. Prototyping & Modelling

Type Description Advantage

Throwaway/Rapid Quick prototype built to clarify requirements; discardedCheap

after requirement validation

Evolutionary Prototype evolved into final product; continuous refinement

Reduces rework; faster delivery

Incremental System built as a series of builds, each adding functionality

Early delivery of core features

Extreme (XP) Small releases with pair programming and TDD High quality & customer satisfaction

Modelling: UML (Unified Modelling Language) provides standard diagrams — Use Case, Class, Sequence, Activity,
State, Component — to document and communicate system design. BPMN models business processes. SysML
extends UML for systems engineering.

9. Inspections, Reviews & Process Assessment

Review Type Description

Walkthrough Author explains work to peers; informal; educational purpose; no formal defect log required

Technical Review Formal; evaluates conformance to specs; produces defect list; moderator-led

Inspection (Fagan) Most rigorous; defined roles (moderator, author, reader, inspector); formal defect log; re-inspection if nee

Audit Independent evaluation by external/internal auditors; checks process compliance

Management Review Senior review of project status, risks, and go/no-go decisions

Process Assessment Models:

• CMMI (Capability Maturity Model Integration): 5 levels — Initial, Managed, Defined, Quantitatively Managed,
Optimizing.

Page 8
SOFTWARE PROJECT MANAGEMENT — STUDY NOTES UNIT II

• ISO/IEC 15504 (SPICE): Process capability assessment framework — 6 capability levels (0–5).
• ISO 9001: Quality management system standard; process-based approach; Plan-Do-Check-Act cycle.

10. Development Methods & Metrics

Development Methods:

Structured Methods SA/SD; top-down decomposition; DFDs; structure charts (Yourdon, DeMarco)

Object-Oriented OOA/OOD; UML; encapsulation, inheritance, polymorphism; Booch, Rumbaugh

Agile Methods Scrum, XP, Kanban, SAFe; sprint-based; customer collaboration; adaptive
planning

Formal Methods Z notation, VDM, B Method; mathematical specification; safety-critical systems

Component-Based Reuse of COTS/open-source components; reduces development time

Software Metrics:

Metric Category Examples What It Measures

Size Metrics LOC, KLOC, Function Points, Story PointsVolume and scope of software

Quality Metrics Defect density, MTBF, MTTR, test coverage

Reliability
% and correctness

Process Metrics Cycle time, velocity, lead time, defect removal

Process
efficiency
performance

Productivity Metrics FP/person-month, LOC/hour, velocity per Developer

sprint output rate

Complexity Metrics Cyclomatic complexity (McCabe), Halstead

Code
metrics
maintainability & risk

EVM Metrics SPI, CPI, EAC, TCPI, VAC, SV, CV Schedule & cost performance

GQM Paradigm (Goal-Question-Metric): Define a measurement GOAL → formulate

QUESTIONS to characterise the goal → identify METRICS that answer those questions. Ensures
metrics are purpose-driven rather than collected arbitrarily.

Page 9