DEPARTMENT OF COMPUTER APPLICATIONS

SOFTWARE PROJECT MANAGEMENT

Handled by: [Link]

Subject Code: SCAPT51
Class: III BCA
Semester: ODD(2025-26)

SOFTWARE PROJECT MANAGEMENT 1

 SOFTWARE PROJECT MANAGEMENT
No. of
Unit Contents
Hours
Introduction to Competencies - Product Development
Techniques - Management Skills - Product Development Life
I 12
Cycle - Software Development Process and models - The SEI
CMM - International Organization for Standardization.
Managing Domain Processes - Project Selection Models - Project
Portfolio Management - Financial Processes - Selecting a Project
Team - Goal and Scope of the Software Project -Project Planning
II 12
- Creating the Work Breakdown Structure - Approaches to
Building a WBS - Project Milestones - Work Packages -
Building a WBS for Software.
Tasks and Activities - Software Size and Reuse Estimating - The
SEI CMM - Problems and Risks - Cost Estimation - Effort
III Measures - COCOMO: A Regression Model - COCOMO II - 12
SLIM: A Mathematical Model - Organizational Planning -
Project Roles and Skills Needed.
Project Management Resource Activities - Organizational Form
and Structure - Software Development Dependencies -
IV Brainstorming - Scheduling Fundamentals - PERT and CPM - 12
Leveling Resource Assignments - Map the Schedule to a Real
Calendar - Critical Chain Scheduling.
Quality: Requirements – The SEI CMM - Guidelines -
Challenges - Quality Function Deployment - Building the
Software Quality Assurance - Plan - Software Configuration
V 12
Management: Principles - Requirements - Planning and
Organizing - Tools - Benefits - Legal Issues in Software - Case
Study
Textbooks
Robert T. Futrell, Donald F. Shafer, Linda I. Safer, ―Quality Software Project
Management‖, Pearson Education Asia 2002.

SOFTWARE PROJECT MANAGEMENT 2

 UNIT I
Introduction to Competencies - Product Development Techniques - Management Skills -
Product Development Life Cycle - Software Development Process and models - The SEI
CMM - International Organization for Standardization.

The Software Development Life Cycle (SDLC) is a structured process for developing high-
quality software, encompassing various phases from initial planning to ongoing
maintenance. It provides a framework for teams to systematically plan, design, develop, test,
deploy, and maintain software, ensuring it meets user requirements and quality standards.
Here's a breakdown of the typical SDLC phases:
1. Planning and Requirement Analysis: This initial phase involves defining the project scope,
goals, and requirements. It includes identifying user needs, gathering information, and
outlining the project's objectives.
2. Design: The design phase focuses on creating a blueprint for the software. This includes
defining the architecture, user interface (UI), database design, and other technical
specifications.
3. Development: This is where the actual coding takes place, transforming the design into a
working software product. Developers write code based on the design specifications.
4. Testing: Testing involves various activities to ensure the software functions correctly and
meets the defined requirements. This includes unit testing, integration testing, system testing,
and user acceptance testing (UAT).
5. Deployment: Once the software has been tested and approved, it is deployed to the
production environment, making it available for users.
6. Maintenance: After deployment, the software requires ongoing maintenance to address bugs,
fix issues, and implement new features or enhancements.

SOFTWARE PROJECT MANAGEMENT 3

Introduction to Compentencies:
Software project management competencies are the skills, knowledge, and behaviors that
enable a project manager to effectively lead and deliver successful software projects. These
competencies can be broadly categorized into hard and soft skills, with both playing a crucial
role in project execution and overall success.
Hard Skills in software project management include:
• Technical Knowledge:
Understanding the software development lifecycle (SDLC), different methodologies
(Agile, Waterfall, etc.), and specific technologies relevant to the project.
• Project Planning:
Defining project scope, setting objectives, and developing detailed schedules, resource
allocation, and risk management plans.
• Cost Management:
Creating and managing project budgets, tracking expenses, and ensuring projects stay
within financial constraints.
• Risk Management:
Identifying potential risks, assessing their impact, and developing mitigation
strategies.
• Quality Management:
Ensuring the software meets defined quality standards through testing, quality
assurance processes, and adherence to best practices.
• Procurement Management:
In projects involving external vendors, this includes managing contracts, negotiations,
and relationships with suppliers.
Soft Skills in software project management encompass:
• Communication:
Effectively conveying information to all stakeholders (team members, clients,
management) through various channels (written, verbal, presentations).
• Leadership:
Motivating and inspiring the project team, fostering collaboration, and delegating tasks
effectively.
• Team Management:

SOFTWARE PROJECT MANAGEMENT 4

 Building and maintaining a cohesive team, resolving conflicts, and fostering a positive
work environment.
• Problem-Solving:
Identifying and analyzing project issues, developing creative solutions, and making
informed decisions.
• Decision-Making:
Evaluating options, considering potential consequences, and selecting the best course
of action.
• Negotiation:
Interacting with stakeholders to reach agreements, manage expectations, and resolve
conflicts.
• Time Management:
Prioritizing tasks, setting realistic deadlines, and managing time effectively to meet
project milestones.
• Adaptability:
Responding to changes in project requirements, technologies, or team dynamics with
flexibility and resilience.
• Business Acumen:
Understanding the business context of the project, its impact on the organization, and
relevant industry trends.
A software project manager's success depends on their ability to integrate these hard and
soft skills, fostering a collaborative environment, and navigating the complexities of
software development to deliver successful projects.
Introduction to Competencies
🔹 What are Competencies?
Competencies refer to the skills, knowledge, abilities, and behaviors that individuals
need to perform their roles effectively in a professional environment.
They are not just about what you know (knowledge), but also about how you apply it
(skills and behavior).

🔹 Types of Competencies
1. Core Competencies
o Essential for all employees in an organization.

SOFTWARE PROJECT MANAGEMENT 5

 o Examples: Communication, teamwork, problem-solving, adaptability.
2. Functional (Technical) Competencies
o Specific to a role or department.
o Examples: Programming, software testing, product design, system analysis.
3. Behavioral Competencies
o Attitudes and actions that affect performance.
o Examples: Leadership, time management, accountability.
4. Managerial Competencies
o Required by those in supervisory roles.
o Examples: Planning, decision-making, strategic thinking.

🔹 Importance in Software Project Management

• Improves team performance through better role clarity.
• Aligns tasks with people’s strengths.
• Helps in training and development planning.
• Ensures project quality, productivity, and success.

🔹 How Competencies are Used

• Hiring – Matching job roles with candidate capabilities.
• Performance Appraisal – Measuring effectiveness and outcomes.
• Training Needs – Identifying gaps and developing learning paths.
• Career Development – Helping individuals grow professionally.

🔹 Example in a Software Development Context

Role Key Competencies Needed

Software Developer Coding skills, debugging, algorithm design
Project Manager Planning, risk management, leadership
QA Engineer Testing methods, attention to detail, tools
UI/UX Designer Design thinking, creativity, user research

Product Development Techniques

SOFTWARE PROJECT MANAGEMENT 6

software project managers are responsible for delivering a product. Since that is our primary
objective, we will examine product development techniques first, before project skills and
people skills. Product development techniques, competencies 1 through 11

Product (Software) Description Chapter or

Competency Description Appendix
1. Assessing processes Defining criteria for 11. Estimating Duration and
reviews Cost
25. Project Tracking and
Control
26. Continuous Process
Improvement
30. Software Quality
Assurance
2. Awareness of process Understanding Appendix A.
standards process standards Supporting
Organizations
3. Defining the product Identifying customer 7. Defining the Goal and Scope of
environment and the Software Project
product
requirements
4. Evaluating alternative Evaluating various 4. Selecting Software
processes approaches Development Life Cycles
7. Defining the Goal and Scope of
the Software project
13. Choosing an
OrganizationalForm
5. Managing requirements Monitoring 16. Eliciting Requirements
requirements 17. Developing the Software
changes Requirements Specification
6. Managing subcontractors Planning, 6. Selecting a
managing, and Project Team
monitoring 12. Assigning

SOFTWARE PROJECT MANAGEMENT 7

 performance Resources
32. Legal Issues
in Software
7. Performing the initial Assessing 9. Identifying
assessment difficulty, risks, the Tasks and
costs, and Activities
schedule 10. Software
Size and Reuse
Estimating
11. Estimating
Duration and
Cost
18. Determining
Project Risks
8. Selecting methods and Defining selection 24. Use of Tools
tools processes 31. Software
Configuration
Management
Appendix D.
Understanding
Systems
Engineering
9. Tailoring processes Modifying 4. Selecting
standard processes Software
to suit a project Development
Life Cycles
13. Choosing an
Organizational
Form
14. Considering
Dependencies
10. Tracking product quality Monitoring the 30. Software
quality of an Quality

SOFTWARE PROJECT MANAGEMENT 8

 evolving product Assurance
11. Understanding Learning the 4. Selecting
development activities software Software
development cycle Development
Life Cycles
5. Managing
Domain
Processes

Management Skills

Project competency Description Description Chapter or

Appendix
12. Building a work breakdown Building a 4. Selecting
structure work Software
breakdown Development
structure for Life Cycles
a project 8. Creating
the Work
Breakdown

SOFTWARE PROJECT MANAGEMENT 9

 Structure
9. Identifying
the Tasks and
Activities

13. Documenting plans Identifying 4. Selecting

key Software
components Development
Life Cycles
7. Defining
the Goal and
Scope of the
Software
Project
17.
Developing
the Software
Requirements
Specification
28. Post
Performance
Main Analysis
30. Software
Quality
Assurance
31. Software
Configuration
Management
Appendix A.
Supporting
Organizations
14. Estimating cost Estimating 10. Software

SOFTWARE PROJECT MANAGEMENT 10

 cost to Size and
complete a Reuse
project Estimating
11. Estimating
Duration and
Cost
12. Assigning
Resources
16. Eliciting
Requirements
15. Estimating effort Estimating 10. Software
effort Size and
required to Reuse
complete a Estimating
project 11. Estimating
Duration and
Cost
12. Assigning
Resources
16. Eliciting
Requirements
17.
Developing
the Software
Requirements
Specification
16. Managing risks Determining 18. Determining
impact and Project Risks
handling of 21. Software
risks Metrics

SOFTWARE PROJECT MANAGEMENT 11

17. Monitoring development Monitoring 24. Use of
the Tools
production 25. Project
of software Tracking and
Control
26.
Continuous
Process
Improvement
30. Software
Quality Assurance
18. Scheduling Creating a 7. Defining
schedule the Goal and
and key Scope of the
milestones Software
Project
14.
Considering
Dependencies
15.
Scheduling
the Work
19. Selecting metrics Choosing 21. Software
appropriate Metrics
metrics 24. Use of
Tools
Appendix A.
Supporting
Organizations
20. Selecting project management Knowing 24. Use of
tools how to Tools
select PM
tools

SOFTWARE PROJECT MANAGEMENT 12

 21. Tracking process Monitoring 5. Managing
compliance Domain
of project Processes
team 21. Software
Metrics
25. Project
Tracking and
Control
26.
Continuous
Process
Improvement
30. Software
Quality
Assurance
22. Tracking project progress Monitoring 21. Software
progress Metrics
using 30. Software
metrics Quality
Assurance

Product Development Life Cycle and its Stages

The Product Development Life Cycle is a framework used for managing the development of
the Product. PDLC (Product Development Life Cycle) is an iterative approach based on
feedback to ensure that all the requirements of stakeholders are satisfied. PDLC can be further
divided
into 7 Stages.

Product Development Life Cycle and its Stages

Product Development Cycle Stages
These 8 steps have a major impact on the quality of the product developed in Product
Management. Depending on the cost, time, and size of the team these steps can be modified
accordingly.

SOFTWARE PROJECT MANAGEMENT 13

Stage 1: Develop the Idea
• The first thing in PDLC (Product Development Life Cycle) is about developing the idea.
This step involves a lot of brainstorming between the various group members to decide
what product they want to develop. Group discussion plays a vital role in this step.
• A proper idea decides the whole direction of the PDLC (product development Life cycle),
so choosing the right idea is very crucial in any PDLC (Product Development Life Cycle).
Stage 2: Validate the Idea
• After stage 1, the team will have a list of features the product should contain. The goal in
this stage is to check which features or product concepts are the best suited to the Product.
• Validation of an idea can be done through different methods such as setting a set of
criteria to validate the idea and give the scores to the idea respectively.
• Taking reviews or feedback from consumers should also be part of validating ideas.
Because the end users are consumers only, so their opinion also plays a vital role.
Stage 3: Build a Prototype
• Among all the steps in PDLC (Product Development Life Cycle), the prototyping phase
is one of the most important prerequisites for the development stage. Based on the
requirements gathered from stages 1 and 2, the planning of the product and implementing
them to make a basic prototype is done in this step.
• In this stage, the given idea will be implemented in the real world with an MVP(minimum
viable product ) also known as a prototype to check if the given idea will work in real
life.
• Prototyping the product will give a clear idea about what product should be developed.
Prototyping can fix various issues and loopholes in a product before it is developed which
can result in saving time, energy, and cost.
Stage 4: Create the Messaging
• Figuring out what makes your product special: Why should people buy it? Creating
the value of a product in people's lives is very important for making a product successful.
So the reason why people should buy it should be very clear.
• Equipping your sales team: Creating materials like brochures and presentations to help
them sell your product. Product information should be introduced to the consumers
through advertising.

SOFTWARE PROJECT MANAGEMENT 14

• Spreading the word: Building marketing and advertising campaigns to get people
excited. Before realizing the product, the product should be well marketed so it can attract
more and more users.
Stage 5: Build the Product
• The most important phase in PDLC (Product Development Life Cycle) is the
development stage. In this phase, the actual product is developed. The development team
makes sure that all the requirements given should be implemented properly.
• Developers divide the given product into various parts or components and distribute it
among each other to work simultaneously on the product based on each one's
specialization. Developers are responsible for creating the user-friendly UI(if required in
the project).
• In this phase, the development team follows different techniques to get the product
developed based on the retirements of the product. If some set of rules are there in the
requirements, the development team needs to follow them while developing the product.

Stage 6: Test the Product

• The next stage in PDLC (Product Development Life Cycle) is Testing. The developer
team and testing team will work together to check if a given functionality or product
works according to requirements. The QA (Quality Assurance) team will do different
types of testing to make sure the given product works correctly.
• The development phase and testing phase work hand in hand. Testing depends on the
development techniques, if specific functionalities are developed testing team will check
the specific functionality only and will give feedback to the development team. But, if
the whole product is developed then the testing team will make sure all functionalities
are working correctly.
• The testing team will also check the security aspects and user-friendliness of the given
product before passing it to the next stage.
Stage 7: Release the Product
• One of the last stages in PDLC (Product Development Life Cycle) is the Deployment of
the product. In this stage, the final product is made available in the market for the users.
In this stage, depending on the end users different techniques are used for relating the
product.

SOFTWARE PROJECT MANAGEMENT 15

• If the product is for the mass audience then strategically commercializing the product is
also required while releasing the product. Because the product should reach the targeted
audience to make it a success.
Stage 8: Improve the Product
• After realizing the product, collecting feedback from the users of the product is also very
important. Based on the feedback received, improvement is made in the product and then
the product is updated or re-released again.
• Feedback plays a crucial role in making a perfect product because, despite intensive
testing, it provides us with crucial inputs of the product which can make a product more
accessible and easy to use for the users.
• Improvement of a product is a never-ending process throughout the lifetime of the
Product. To fit in a continuously changing market, product improvements are required in
a time-to-time manner.

What is Software Development Process?

The software development process is the approach to developing, and delivering software
applications. This process might include improving design and product management by
splitting the work into smaller steps or processes.
What are the 10 Software Development Processess?

Software Developement Process

The software development process is the sequence of activities that leads to the production
of a software product. The steps of software development process are as follows:

SOFTWARE PROJECT MANAGEMENT 16

1. Communication
The first and foremost step is where the user contacts the service provider i.e. software
organization and initiates the request for a desired software product. The software
organization talks with the customer about its requirement and then work according to its
needs.
2. Requirement Gathering
In this step, the team of software developers holds discussions with various stakeholders from
the problem domain and provides as much as information possible for the requirement of the
software product. The requirements can be of different forms like user requirements, system
requirements, functional requirements, etc.

3. Feasibility Study
After requirement gathering, with the help of many algorithms, the team analyzes that if the
software can be designed to fulfil all requirements of the user and also analyzes if the project
is financially, practically and technologically feasible for the organization or not.
4. System Analysis(A planning phase)
Software developer decides on a roadmap for their plan and tries to bring up the best software
model stable for the project. System analysis may also include understanding product
limitations and identifying and addressing the impact of the project on the organization. The
project analyzes the scope of the project and plans the resources accordingly.
5. Software Design
Software design whole knowledge of requirements and analyses are taken together to plan
up design of software products. It takes input from the user and information gathered in the
requirement-gathering phase. It gives output in the form of logical and physical design.
6. Coding
This step is also known as the programming phase. The implementation of software design
starts in the form of writing code in suitable programming and developing error-free
programs efficiently.
7. Testing
Software testing is done while coding by the testers' developing team members. Testing is
done at various levels i.e. module testing, product testing, program testing and user-end
testing.

SOFTWARE PROJECT MANAGEMENT 17

8. Integration
After writing all the codes for the software such as frontend, backend, and databases, The
software is integrated with libraries, databases and other programs.
9. Implementation
In this step, the software product is finally ready to be installed on the user's machine.
Software is tested for profitability, integration, adaptability, etc.
10. Operation and Maintenance
This phase confirms the software operations in terms of more efficiency and fewer errors. If
required, the users are trained or aided with the documentation on how to operate the software
and how they keep the software operational. This software is maintained timely by updating
the code according to the changes taking place in the user and environment or technology.
In software project management (SPM), a software development process outlines the
structured approach for creating software, while software development models are specific
frameworks that guide this process. These models dictate how the project progresses through
phases like planning, design, coding, testing, and deployment.
Key Concepts:
Software Development Process:
This encompasses the overall approach and activities involved in building software, from
initial concept to final delivery and maintenance.
Software Development Models:
These are frameworks or methodologies that define the specific phases, activities, and
their sequence in the software development process.
Common Software Development Models:
Waterfall Model:
A sequential model where each phase is completed before the next begins.
Pros: Simple, easy to understand, well-defined phases.
Cons: Not flexible for changing requirements, difficult to adapt to evolving
needs.
Iterative and Incremental Model:
Development is done in cycles (iterations), with each cycle adding more functionality.
Pros: Allows for flexibility, early feedback, and continuous improvement.
Cons: Requires careful planning and management of iterations.
Spiral Model:

SOFTWARE PROJECT MANAGEMENT 18

 An iterative model that emphasizes risk assessment in each cycle.
Pros: Manages risks effectively, suitable for complex projects.
Cons: Can be time-consuming and costly due to risk analysis.
Agile Model:
A flexible and iterative approach that emphasizes collaboration, customer feedback, and
rapid development cycles.
Pros: Adaptable to change, promotes collaboration, delivers working software
frequently.
Cons: Requires strong team communication and collaboration, may not be
suitable for all projects.
V-Model:
An extension of the waterfall model that incorporates testing activities at each phase.
Pros: Early testing and validation, good for safety-critical systems.
Cons: Can be rigid, similar to waterfall model's limitations.
Prototyping Model:
A model that involves creating prototypes to gather requirements and validate designs.
Pros: Helps clarify requirements, facilitates user feedback, reduces risk.
Cons: Prototypes may not be suitable for production, potential for misuse.
RAD (Rapid Application Development) Model:
Focuses on rapid development and quick delivery using reusable components.
Pros: Fast development cycles, suitable for time-sensitive projects.
Cons: Requires skilled developers, may not be suitable for complex systems.

The SEI CMM in Software Project Management

SEI CMM stands for:
✅ Software Engineering Institute

✅ Capability Maturity Model

It was developed by the SEI at Carnegie Mellon University in the late 1980s and 1990s.
Purpose:
To help organizations improve their software development process maturity—in other words,
how well they manage and improve their processes over time.

🧭 What is CMM?

SOFTWARE PROJECT MANAGEMENT 19

The Capability Maturity Model (CMM) is:
• A framework to assess and improve software processes.
• Organized into 5 maturity levels (from chaotic to optimized).
• Each level defines:
o Key Process Areas (KPAs)
o Goals
o Practices that must be institutionalized

🎯 Why Use CMM?

CMM helps organizations:
• Deliver better software on time and within budget.
• Improve predictability and quality.
• Reduce risks and defects.
• Move from ad hoc processes to disciplined processes.

🧭 The Five Maturity Levels

Here’s the famous 5-Level CMM Pyramid simplified:

🌱 Level 1 – Initial
• Characteristics:
o Process is ad hoc and chaotic.
o Success depends on individual heroics, not organizational processes.
o No stable environment.
• Example:
o No consistent project plans or reviews.

📝 Level 2 – Repeatable
• Characteristics:
o Basic project management processes are established.
o You can repeat past successes on similar projects.
• Key Process Areas:
o Requirements Management

SOFTWARE PROJECT MANAGEMENT 20

 o Project Planning and Tracking
o Configuration Management
• Example:
o Projects use documented plans and track progress.

⚙️ Level 3 – Defined
• Characteristics:
o Processes are documented, standardized, and integrated into a standard process
for the organization.
o All projects tailor this standard process.
• Key Process Areas:
o Organization Process Focus
o Training Program
o Product Engineering
• Example:
o Teams follow a standard lifecycle model and coding guidelines.

📊 Level 4 – Managed
• Characteristics:
o Processes are measured and controlled quantitatively.
o You can predict process performance using metrics.
• Key Process Areas:
o Quantitative Process Management
o Software Quality Management
• Example:
o Use of metrics to track defect rates and productivity trends.

🏆 Level 5 – Optimizing
• Characteristics:
o Focus on continuous process improvement.
o Innovative techniques are used to prevent defects.
• Key Process Areas:
o Defect Prevention

SOFTWARE PROJECT MANAGEMENT 21

 o Technology Change Management
o Process Change Management
• Example:
o Teams systematically improve processes and adopt new tools.

✨ Summary Table of the Levels

Level Description Focus

1 Initial Unpredictable, chaotic
2 Repeatable Basic project management
3 Defined Organization-wide standardization
4 Managed Measured and controlled processes
5 Optimizing Continuous improvement

🛠️ CMM in Software Project Management

As a project manager, CMM guides you to:
• Assess current maturity.
• Define process improvement goals.
• Implement practices to reach the next maturity level.

🧑🎓 Example Scenario
If your organization is Level 1 (Initial):
• Projects often miss deadlines.
• No process documentation.
If you want to move to Level 2 (Repeatable):
• Start defining project plans.
• Establish configuration management.
• Track project progress.
🌍 International Organization for Standardization (ISO) in Software Project Management

What is ISO?
• ISO stands for the International Organization for Standardization.
• It is an independent, non-governmental international body.

SOFTWARE PROJECT MANAGEMENT 22

 • Purpose: Develop and publish international standards to ensure quality, safety,
efficiency, and consistency across industries.

Why is ISO important in Software Project Management?

• Provides recognized frameworks for managing and improving software quality.
• Helps organizations meet customer expectations and comply with regulations.
• Encourages process standardization, reducing variability and defects.

Key ISO Standards for Software

Here are the most relevant ISO standards you should know:

1️⃣ ISO 9001 – Quality Management Systems

• The most widely used standard for general quality management.
• Not specific to software, but applicable to any industry.
• In software, it helps establish a Quality Management System (QMS) to control:
o Project planning
o Process control
o Documentation
o Audits and reviews
• Focus: “Say what you do, do what you say, prove it.”
Example:
A software company documents its development process and regularly audits adherence to
ensure consistent quality.

2️⃣ ISO 9000 Family

• ISO 9000: Concepts and terminology.
• ISO 9001: Requirements for a QMS (the one organizations get certified against).
• ISO 9004: Guidelines for performance improvement.

3️⃣ ISO/IEC 12207 – Software Life Cycle Processes

• Specifically for software engineering.
• Defines a framework for all activities across the software life cycle:
o Acquisition

SOFTWARE PROJECT MANAGEMENT 23

 o Supply
o Development
o Operation
o Maintenance
• Includes detailed process descriptions.
Example:
A project uses ISO/IEC 12207 to define how requirements are gathered, designs are reviewed,
code is tested, and products are maintained.

4️⃣ ISO/IEC 15504 – Process Assessment (SPICE)

• SPICE = Software Process Improvement and Capability Determination.
• Used to assess the maturity and capability of software processes.
• Similar purpose to CMM/CMMI.
• Helps organizations measure where their processes stand and improve them.

5️⃣ ISO/IEC 27001 – Information Security Management

• Focuses on managing information security risks, which is critical for software
projects handling sensitive data.

Benefits of ISO Standards in Software Projects

Improved Quality: Standardized processes reduce defects and rework.
Customer Confidence: Certification shows commitment to quality.
Process Consistency: Everyone follows the same practices.
Continuous Improvement: Regular audits encourage learning and improvement.
International Recognition: ISO standards are accepted globally.

Example Scenario
Company: Software firm building e-commerce platforms
Needs: Reliable delivery, secure transactions
Approach:
• Implements ISO 9001 QMS for process consistency.
• Follows ISO/IEC 12207 for life cycle activities.

SOFTWARE PROJECT MANAGEMENT 24

 QUESTION BANK
Choose the Best Answer
1. Competency refers to:
a) Knowledge, skills, and attitudes required to perform a task
b) Only technical skills
c) Only management skills
d) Personal hobbies
Answer: a) Knowledge, skills, and attitudes required to perform a task
2. Product development life cycle is also called as:
a) Marketing cycle
b) Software life cycle
c) Business cycle
d) Communication cycle
Answer: b) Software life cycle
3. The first stage of the product development life cycle is:
a) Testing
b) Planning/Requirement Analysis
c) Design
d) Deployment
Answer: b) Planning/Requirement Analysis
4. Management skills mainly include:
a) Technical design
b) Leadership, communication, decision-making
c) Debugging
d) Programming
Answer: b) Leadership, communication, decision-making
5. The SEI CMM model is used for:
a) Software design
b) Measuring software process maturity
c) Hardware testing
d) Marketing analysis
Answer: b) Measuring software process maturity
6. In SEI CMM, the highest level of maturity is:
a) Level 1 – Initial
b) Level 3 – Defined
c) Level 4 – Managed
d) Level 5 – Optimizing
Answer: d) Level 5 – Optimizing
7. ISO 9001 certification is related to:
a) Hardware safety
b) Quality management systems
c) Marketing policies
d) Financial auditing
Answer: b) Quality management systems
8. The waterfall model is best suited for:
a) Dynamic requirements
b) Fixed and well-defined requirements

SOFTWARE PROJECT MANAGEMENT 25

 c) Prototype-based development
d) Agile methods
Answer: b) Fixed and well-defined requirements
9. Iterative model in SDLC means:
a) One-time development only
b) Development is done in repeated cycles
c) Code is written without testing
d) Testing is skipped
Answer: b) Development is done in repeated cycles
10. ISO stands for:
a) International Software Organization
b) International Organization for Standardization
c) Indian Standards Organization
d) International Systems Order
Answer: b) International Organization for Standardization

Important 7-Mark Questions

1. Define competencies. Explain different types of competencies needed in software
industry.
2. Write a short note on Product Development Techniques with examples.
3. Explain the essential management skills required for a project manager.
4. List and explain the phases of Product Development Life Cycle.
5. Write short notes on SEI CMM levels.
6. Differentiate between Waterfall model and Iterative model in SDLC.
7. Explain the role of ISO standards in software development.

Important 10-Mark Questions

1. Explain the concept of competencies and their importance in professional
development.
2. Explain in detail the Product Development Life Cycle with a neat diagram.
3. Discuss Software Development Process Models: Waterfall, Iterative, Prototype,
Agile.
4. With neat diagram, explain the SEI Capability Maturity Model (CMM) and its five
levels.
5. Explain the role of management skills (planning, organizing, leadership, decision
making) in successful product development.
6. Explain the importance of ISO certification in software industry.
7. Compare and contrast SEI CMM and ISO standards for software quality assurance.

SOFTWARE PROJECT MANAGEMENT 26

 UNIT II
II. Managing Domain Processes - Project Selection Models - Project Portfolio
Management - Financial Processes - Selecting a Project Team - Goal and Scope of the
Software Project -Project Planning - Creating the Work Breakdown Structure -
Approaches to Building a WBS - Project Milestones - Work Packages - Building a WBS
for Software.
MANAGING DOMAIN PROCESSES
Managing domain processes in Software Project Management (SPM)
involves understanding the specific business or organizational context where the software will
be used and integrating that knowledge into the project's planning and execution. This includes
identifying relevant stakeholders, understanding their needs, and ensuring the software
effectively addresses those needs. Key aspects include requirements gathering, risk
management, and quality assurance, all tailored to the specific domain.
Here's a more detailed breakdown:
1. Understanding the Domain:
• Business Context:
SPM requires understanding the business goals, objectives, and processes of the organization
that will use the software.
• Stakeholder Needs:
Identifying and understanding the needs of all stakeholders (users, clients, management, etc.)
is crucial for defining requirements and ensuring the software's usability and effectiveness.
• Domain-Specific Processes:
The software project needs to integrate with existing domain processes or provide solutions
to domain-related problems.
2. Planning and Execution:
• Requirement Gathering:
Gathering and documenting requirements, including functional and non-functional
requirements, that are specific to the domain.
• Risk Management:
Identifying and mitigating risks specific to the domain, such as regulatory compliance issues
or integration challenges.
• Quality Management:

SOFTWARE PROJECT MANAGEMENT 27

 Ensuring that the software meets domain-specific quality standards and user expectations.
• Resource Management:
Allocating resources (personnel, budget, time) effectively to address domain-specific needs.
3. Monitoring and Control:
• Progress Monitoring:
Tracking project progress against the plan and making adjustments as needed, taking into
account domain-specific factors.
• Performance Evaluation:
Evaluating the software's performance against domain-specific metrics and making necessary
improvements.
• Change Management:
Managing changes to requirements or scope in a way that considers the impact on the domain
and its processes.
4. Key Activities in Domain Process Management:
• Defining Project Scope: Clearly outlining the boundaries of the project within the domain.
• Developing a Software Project Plan: Creating a plan that incorporates domain-specific
considerations and aligns with the overall project goals.
• Conducting Risk Assessment: Identifying and assessing risks related to the domain and its
processes.
• Managing Stakeholder Expectations: Ensuring that all stakeholders are informed and
aligned with the project's progress and outcomes.

PROJECT SELECTION MODELS

Project selection models in software project management help organizations choose the most
beneficial projects from a pool of potential options. These models can be broadly categorized
as numeric (using financial data and calculations) and non-numeric (relying on qualitative
factors). Effective project selection is crucial for maximizing returns, aligning with strategic
goals, and optimizing resource allocation.
Numeric Models:
• Cost-Benefit Analysis:
Compares the anticipated costs of a project against its expected benefits to determine its
overall value.
• Payback Period:

SOFTWARE PROJECT MANAGEMENT 28

 Calculates the time it takes for a project's cumulative profits to recover its initial investment,
assessing project liquidity.
• Discounted Cash Flow (DCF):
Considers the time value of money by discounting future cash flows to their present value,
providing a more accurate picture of profitability.
• Net Present Value (NPV):
Calculates the present value of all cash inflows and outflows associated with a project,
indicating its profitability.
• Internal Rate of Return (IRR):
Determines the discount rate at which the NPV of a project equals zero, measuring the
project's profitability.
• Profitability Index:
Measures the ratio of present value of future cash flows to the initial investment, aiding in
project prioritization.
• Scoring Models:
Assigns numerical scores to projects based on predefined criteria (e.g., strategic alignment,
risk, ROI) to facilitate comparison and ranking.
• Mathematical Models:
Employ complex algorithms to optimize project selection based on multiple objectives and
constraints.
Non-Numeric Models:
• Sacred Cow: A project favoured by management or a key stakeholder, regardless of its
objective merits.
• Operating Necessity: A project deemed essential for the continued operation of the business.
• Competitive Necessity: A project required to maintain or improve the organization's
competitive position.
• Product Line Extension: A project focused on expanding or enhancing existing product
offerings.
• Comparative Benefit: A model that compares multiple potential projects to identify the most
advantageous.
• SWOT Analysis: Evaluates a project's Strengths, Weaknesses, Opportunities, and Threats.
• Balanced Scorecard: A framework that assesses project performance across multiple
perspectives (financial, customer, internal processes, learning and growth).

SOFTWARE PROJECT MANAGEMENT 29

Project Portfolio Management (PPM)
Project Portfolio Management (PPM) is about overseeing all the projects a company has
going on. It's like organizing a bunch of different tasks to reach a big goal. PPM helps decide
which tasks are most important, how to manage them well, and when to make changes to
keep everything running smoothly.
What is a Project Portfolio?
A project portfolio is a collection of all the projects a company is doing. It's like having a list
of different tasks or jobs that need to be done. Each project in the portfolio is like a piece of
the bigger picture, helping the company reach its goals. Just like a mix of different
investments in a portfolio, there are different projects in a project portfolio, each at various
stages. These projects can be anything from making new products to improving how things
work or promoting products. The goal is to have a balanced portfolio with different kinds of
projects, each important in its way. By managing the portfolio well, a company can make
sure it's spending its time and money wisely and moving closer to its big goals.
What is Project Portfolio Management? (PPM)
Project Portfolio Management (PPM) is like being a team manager where each member has
their tasks to do. It's about overseeing and controlling all the projects a company is working
on. PPM means deciding which projects are most important and how to divide up resources
like time and money among them. It's about steering everything in the right direction to reach
the company's goals and making sure things stay on track. PPM also involves keeping an eye
on progress, spotting and dealing with any problems, and making changes when necessary.
By doing PPM well, a company can make sure its projects fit with its overall plans and that
it's getting the best results.
Project Portfolio Management vs Project Management

Aspect Project Portfolio Management Project Management

Project Portfolio Management

Project Management focuses on
looks at all the projects together
handling one project at a time.
Focus as a whole to manage them.

SOFTWARE PROJECT MANAGEMENT 30

Aspect Project Portfolio Management Project Management

Project Portfolio Management

Project Management deals with the
considers the overall picture of
specific details of each project.
Scope all projects in the portfolio.

In Project Portfolio Management,

In Project Management, decisions
decisions are made about which
are made about how to carry out
Decision projects to prioritize based on
and finish a particular project.
Making strategic goals.

Project Portfolio Management

Project Management allocates
allocates resources like money
resources within a single project to
Resource and people across all projects to
meet its specific needs.
Allocation meet overall objectives.

Project Portfolio Management

handles risks across all projects, Project Management manages risks
Risk considering how they affect the within the context of one project.
Management whole portfolio.

Project Portfolio Management

Project Management monitors the
keeps track of the overall
performance and progress of each
Performance performance and progress of all
project.
Monitoring projects in the portfolio.

Project Portfolio Management Process

Project Portfolio Management (PPM) is all about managing a bunch of different projects in
a structured way.
1. Define Business Objectives
This step involves understanding the strategic goals and objectives of the organization. It
includes identifying key performance indicators (KPIs), market trends, competitive
landscape, and stakeholder expectations. The aim is to align project initiatives with the

SOFTWARE PROJECT MANAGEMENT 31

overarching business strategy to ensure that every project contributes to the organization's
success.
Example: If the business objective is to increase market share, PPM would prioritize projects
that focus on product development, marketing campaigns, or market expansion strategies.
2. Collect Project Ideas for Your Portfolio
In this phase, project ideas are gathered from various sources such as stakeholders,
employees, customers, market research, and industry trends. Idea generation techniques like
brainstorming sessions, surveys, and feedback mechanisms are used to capture a diverse
range of project proposals. Each project idea is evaluated based on its potential to contribute
to the business objectives, feasibility, resource requirements, risks, and expected benefits.
Example: Project ideas may include launching a new product line, improving customer
service processes, implementing a digital transformation initiative, or expanding into new
markets.
3. Select the Best Project for Your Portfolio
Once project ideas are collected, they undergo a selection process to determine which projects
should be included in the portfolio. Criteria for project selection may include strategic
alignment, ROI potential, resource availability, risk assessment, market demand, and
technological feasibility. Projects that align closely with business objectives, offer high ROI,
and fit within resource constraints are prioritized for inclusion in the portfolio.
Example: A project to implement a customer relationship management (CRM) system may
be selected due to its potential to improve customer satisfaction, streamline processes, and
increase sales efficiency.
4. Validate Project Portfolio Feasibility
Before finalizing the project portfolio, each selected project undergoes a feasibility analysis
to assess its technical, financial, and organizational viability. Technical feasibility evaluates
whether the project can be successfully implemented given the available technology and
expertise. Financial feasibility assesses the project's cost estimates, potential revenue or cost
savings, and ROI projections. Organizational feasibility considers factors such as alignment
with organizational culture, resource availability, skills gaps, and change management
requirements.
Example: The CRM system project undergoes feasibility analysis to ensure it can be
implemented within budget, meets technical requirements, and aligns with the organization's
capabilities.

SOFTWARE PROJECT MANAGEMENT 32

5. Execute and Manage Your Project Portfolio
Once the project portfolio is finalized and approved, the projects are executed according to
their respective plans and timelines. Project portfolio management involves monitoring and
controlling each project's progress, managing resources, mitigating risks, and ensuring
alignment with business objectives. Regular performance evaluations, status reports, and
stakeholder communications are essential for effective portfolio management.
Example: The CRM system project is executed with regular progress updates, milestone
reviews, and feedback loops to ensure it meets expectations and delivers the intended
benefits.
What Does a Project Portfolio Manager Do?
A Project Portfolio Manager has a big job to make sure all the projects in a company are on
track and working towards the same goals.
1. Making Sure Projects Fit with Big Plans: They make sure all the projects fit with what
the company wants to achieve in the long run. This means they work closely with the big
bosses to understand what the company's goals are and then figure out how the projects
can help reach those goals.
2. Keeping an Eye on Problems: They're always on the lookout for things that could go
wrong with the projects. They check if the projects are on track if they're using up too
much money or time, or if any other issues need fixing. By spotting problems early, they
can stop them from getting worse and keep the projects moving forward smoothly.
3. Dividing Up Resources Fairly: They make sure each project gets what it needs to get
done. This means they divide up things like money, people, and time so that no project is
left without what it needs to succeed. They have to balance things out so that all projects
have a fair shot at being successful.
4. Talking to Everyone: They're the ones who talk to everyone involved in the projects,
from the big bosses to the people doing the work. They keep everyone informed about
how the projects are going and listen to any concerns or ideas they might have. This helps
make sure everyone is on the same page and working towards the same goals.
5. Always Trying to Do Better: They're always looking for ways to make things run
smoother and get better results. This means they're always trying out new ways of doing
things, like using new tools or changing how projects are evaluated. By always trying to
improve, they help the company stay ahead of the game and get the most out of its
projects.

SOFTWARE PROJECT MANAGEMENT 33

6. Deciding What to Do: Ultimately, they're the ones who decide which projects the
company should focus on and how resources should be used. They look at things like
what projects will help the company the most, what risks they might have, and if the
company has enough resources to do them. By making smart decisions, they help make
sure the company's projects are successful and help it reach its goals.
Project Management Processes for PPM
1. Initiation and Planning: At the start, project ideas are identified and checked if they
make sense. Once approved, detailed plans are made, including what needs to be done,
who does what, and by when. For PPM, this phase ensures that projects fit with the
company's goals.
2. Execution and Monitoring: With plans in place, work begins. Project managers make
sure tasks are done, resources are used well, and everything stays on track. They keep an
eye on how things are going, fix any problems, and adjust plans as needed. For PPM, this
means watching over many projects at once and keeping them in line with the overall
plan.
3. Closure and Lessons Learned: When projects finish, loose ends are tied up, and the
outcomes are handed over to the right people. Project managers look back on what
worked well and what didn't, so they can do better next time. For PPM, this is about
looking at how all the projects were done together and figuring out what can be improved.
4. Integration with PPM Processes: Throughout the project cycle, project managers and
portfolio managers work together closely. They make sure individual projects match the
big picture and share updates regularly. This helps keep everything aligned with the
company's goals and makes sure resources are used wisely.
Financial Processes in Software Project Management
Definition:
Financial processes involve planning, managing, and controlling the project budget to
ensure the project stays financially viable.
✅ Key Activities:
• Budget Estimation: Predict costs of resources, labor, tools.
• Cost Baseline: An approved budget that guides spending.
• Funding: Securing financial resources.
• Cost Control: Tracking actual expenses against budget.
• Financial Reporting: Regular updates for stakeholders.

SOFTWARE PROJECT MANAGEMENT 34

 • Earned Value Management (EVM): Measures performance by comparing planned
and actual progress and costs.
✅ Illustration:

Activity Purpose
Budgeting Plan how much money is needed
Cost Tracking Monitor spending
Variance Analysis Compare planned vs actual
Reporting Keep stakeholders informed

✅ Example Tools:
MS Project, Primavera, Excel spreadsheets.

Selecting a Project Team

Definition:
Choosing individuals with appropriate skills, experience, and availability to execute the
project.
✅ Steps to Select a Team:
1. Identify Roles Needed – Developers, testers, analysts, designers.
2. Define Responsibilities – Who does what?
3. Assess Skills and Experience – Match skills to tasks.
4. Check Availability – Ensure team members can commit time.
5. Assign Roles – Allocate responsibilities.
6. Communicate Expectations – Clear understanding of goals.
✅ Factors to Consider:
• Technical expertise
• Interpersonal skills
• Cost of resources
• Team dynamics
✅ Illustration:

Role Responsibility
Project Manager Planning, monitoring
Developer Coding

SOFTWARE PROJECT MANAGEMENT 35

Role Responsibility
Tester Quality assurance
Business Analyst Requirements gathering

Goal and Scope of the Software Project

Goal:
• The overall objective the project aims to achieve.
o Example: "Develop an e-commerce website to increase online sales."
Scope:
• Defines boundaries and deliverables of the project.
o What is included
o What is excluded
✅ Key Components of Scope:
• Deliverables
• Features and functions
• Constraints
• Assumptions
✅ Why Important?
• Prevents scope creep (uncontrolled changes).
• Clarifies expectations.
• Guides planning and execution.
✅ Illustration:

Goal Scope Includes Scope Excludes

Launch CRM system User management, reporting module Mobile app version
Build e-commerce website Catalog, shopping cart, payment gateway Offline order processing

Project Planning
Definition:
Creating a roadmap detailing what, how, who, and when tasks will be completed.
✅ Steps:
1. Define Scope and Objectives

SOFTWARE PROJECT MANAGEMENT 36

 2. Identify Activities and Tasks
3. Sequence Activities
4. Estimate Resources and Duration
5. Develop Schedule
6. Assign Responsibilities
7. Identify Risks
8. Create Baselines
✅ Outputs:
• Project Management Plan
• Schedule (Gantt chart)
• Resource Plan
• Risk Management Plan
✅ Illustration:
Gantt Chart Example:
Task Start Date Duration Responsible
Requirements Jan 1 2 weeks Analyst
Design Jan 15 3 weeks Designer
Development Feb 5 6 weeks Developer
Testing Mar 20 2 weeks Tester

Creating the Work Breakdown Structure (WBS)

Definition:
Breaking down the project into small, manageable parts called work packages.
✅ Steps:
1. Identify major deliverables.
2. Break down deliverables into smaller components.
3. Continue decomposing until work packages are defined.
✅ Characteristics of a Good WBS:
• Hierarchical structure
• Clear, measurable deliverables
• Assignable work packages

SOFTWARE PROJECT MANAGEMENT 37

✅ Illustration:
Project: E-commerce Website
|
|-- 1. Requirements
| |-- 1.1 Gather Requirements
| |-- 1.2 Approve Requirements
|
|-- 2. Design
| |-- 2.1 UI Design
| |-- 2.2 Database Design
|
|-- 3. Development
| |-- 3.1 Frontend
| |-- 3.2 Backend
|
|-- 4. Testing
| |-- 4.1 Test Case Design
| |-- 4.2 Execute Tests

Approaches to Building a WBS

✅ Top-down Approach:
• Start from the highest level deliverables.
• Break them into smaller components.
✅ Bottom-up Approach:
• Start by listing all tasks.
• Group them into higher-level categories.
✅ Analogy Approach:
• Use a WBS from a similar past project as a template.
✅ Guidelines Approach:
• Follow organizational templates or standards.
✅ Illustration:

SOFTWARE PROJECT MANAGEMENT 38

 Approach Description
Top-down Decompose from general to specific
Bottom-up Aggregate tasks into deliverables
Analogy Reuse previous WBS structures
Guidelines Use pre-defined templates

Project Milestones
Definition:
Significant checkpoints or events in the project lifecycle.
✅ Purpose:
• Measure progress
• Mark phase completion
• Facilitate stakeholder approvals
✅ Examples of Milestones:
• Requirements sign-off
• Design approval
• Prototype completed
• Testing completed
• Final delivery
✅ Illustration:
Milestone Target Date Responsibility
Requirements Approved Jan 15 Business Analyst
Design Completed Feb 15 Design Team
Development Completed Apr 10 Dev Team
Testing Completed Apr 30 QA Team

Work Packages
Definition:
The lowest level components in a WBS, representing a manageable unit of work.
✅ Characteristics:
• Clearly defined scope
• Time and cost estimates
• Assigned resources
SOFTWARE PROJECT MANAGEMENT 39
 • Measurable outcomes
✅ Examples:
• "Develop login module"
• "Create user manual"
• "Perform integration testing"
✅ Illustration:
Work Package Duration Assigned To
Develop Frontend Login 5 days Developer A
Test Payment Gateway 3 days Tester B

Building a WBS for Software

✅ Steps Recap:
1. Identify project scope and deliverables.
2. Decompose deliverables into smaller components.
3. Continue until work packages are defined.
4. Assign identifiers to each element.
5. Validate completeness with stakeholders.
Example:
Project: Online Library System
|
|-- 1. Requirements Gathering
|-- 2. Design
| |-- 2.1 UI Design
| |-- 2.2 Database Design
|-- 3. Development
| |-- 3.1 Admin Module
| |-- 3.2 User Module
|-- 4. Testing
|-- 5. Deployment
Tip: Use mind mapping tools (like XMind or Lucidchart) to draw WBS diagrams.

SOFTWARE PROJECT MANAGEMENT 40

 QUESTION BANK
Choose the Best Answer
1. Project Portfolio Management (PPM) primarily deals with:
a) Managing financial audits
b) Managing a collection of projects to achieve strategic goals
c) Selecting employees
d) Debugging code
Answer: b) Managing a collection of projects to achieve strategic goals
2. The goal of a software project is to:
a) Complete documentation only
b) Deliver software within time, cost, and quality constraints
c) Spend maximum resources
d) Avoid teamwork
Answer: b) Deliver software within time, cost, and quality constraints
3. A project selection model is used to:
a) Reject all new projects
b) Evaluate and choose projects systematically
c) Reduce employee workload only
d) Increase complexity of projects
Answer: b) Evaluate and choose projects systematically
4. In project financial processes, ROI stands for:
a) Rate of Income
b) Return on Investment
c) Rate of Interest
d) Resource on Input
Answer: b) Return on Investment
5. The first step in project planning is:
a) Building WBS
b) Defining project scope and goals
c) Estimating costs
d) Scheduling milestones
Answer: b) Defining project scope and goals
6. A Work Breakdown Structure (WBS) is:
a) A graphical schedule of tasks
b) Hierarchical decomposition of project work into manageable parts
c) A type of financial budget
d) A coding technique
Answer: b) Hierarchical decomposition of project work into manageable parts
7. A work package in WBS refers to:
a) A complete software system
b) The lowest-level deliverable or task in WBS
c) A coding block
d) A project milestone
Answer: b) The lowest-level deliverable or task in WBS
8. Project milestones represent:
a) Routine daily tasks
b) Major significant achievements in a project timeline

SOFTWARE PROJECT MANAGEMENT 41

 c) Budget allocations
d) Hardware procurement
Answer: b) Major significant achievements in a project timeline
9. Which WBS approach starts with project deliverables and breaks them down?
a) Top-down approach
b) Bottom-up approach
c) Hybrid approach
d) Functional approach
Answer: a) Top-down approach
10. Which WBS approach begins by listing tasks at the lowest level and grouping them
upward?
a) Top-down approach
b) Bottom-up approach
c) Hybrid approach
d) Deliverable approach
Answer: b) Bottom-up approach

Important 7-Mark Questions

1. Explain the concept of Project Selection Models with examples.
2. What is Project Portfolio Management? Why is it important?
3. Write short notes on Financial Processes in project management.
4. Explain the process of selecting a project team.
5. Define the goal and scope of a software project with suitable examples.
6. What is a Work Breakdown Structure (WBS)? Explain with a small example.
7. Differentiate between project milestones and work packages.

Important 10-Mark Questions

1. Explain in detail the Project Selection Models and their applications.
2. With neat diagram, explain the concept and importance of Project Portfolio
Management (PPM).
3. Explain various financial processes used in project evaluation (NPV, ROI, Payback
period).
4. Discuss the steps in project planning with special focus on defining scope and
objectives.
5. What is a Work Breakdown Structure (WBS)? Explain top-down and bottom-up
approaches to building a WBS.
6. Explain the significance of project milestones and work packages in project
scheduling.
7. Prepare a sample WBS for a software project (e.g., Online Banking System or
Library Management System) and explain each level.

SOFTWARE PROJECT MANAGEMENT 42

 UNIT III
III. Software Size and Reuse Estimating, SEI CMM, Problems and Risks, Cost
Estimation, Effort Measures, COCOMO, SLIM, Organizational Planning, Project Roles
and Skills Needed
Software Size and Reuse Estimating
Software Size Estimation is the crucial process of predicting the amount of code or
functionality a software system will have before development begins. Accurate size estimation
is paramount because it forms the bedrock for subsequent project planning activities, directly
influencing estimations for effort, cost, schedule, and resource allocation. An underestimation
can lead to missed deadlines, budget overruns, and compromised quality, while overestimation
can result in unnecessary resource allocation and lost opportunities.
• Lines of Code (LOC):
o Definition: This is one of the earliest and simplest metrics, counting the number
of source code lines in a program. Typically, comments, blank lines, and header
lines are excluded to focus on executable statements.
o Pros: It's straightforward to measure once the code is written, making it useful
for post-project analysis and comparing similar projects after completion.
o Cons: LOC is highly dependent on the programming language (e.g., a single
line in Python might achieve the same functionality as multiple lines in C++),
individual coding style, and developer efficiency. It's notoriously difficult to
estimate accurately early in the project lifecycle when design details are sparse.
Furthermore, LOC is not a reliable measure for productivity (a developer might
write fewer lines but more efficient code) or quality (more lines don't
necessarily mean better software). The rise of code generators, reusable
libraries, and low-code/no-code platforms further diminishes its utility as a
primary estimation metric.
o Example: A simple "Hello World" program might be 1-5 LOC, while a
complex operating system could encompass tens of millions of LOC. A specific
module for user authentication in a web application might be estimated at 1,500
LOC.
• Function Points (FP):

SOFTWARE PROJECT MANAGEMENT 43

o Definition: Function Points offer a more robust and technology-independent
measure of software size. Unlike LOC, FP quantifies the functional size of a
software system based on the functionality delivered to the user, irrespective of
the programming language or technology stack. It focuses on the external
interfaces and logical design of the system.
o Components: The International Function Point Users Group (IFPUG) standard
defines five types of user functions, each contributing to the unadjusted function
point count:
▪ External Inputs (EI): Data received from outside the system that
processes information or maintains internal logical files. (e.g., a user
entering data into a form, a data feed from another system).
▪ External Outputs (EO): Data leaving the system that provides
information to the user. (e.g., a report generated, an error message
displayed, a file exported).
▪ External Inquiries (EQ): Requests that result in data retrieval from
internal logical files or external interface files, with no update to internal
data. (e.g., a search query, displaying a customer's profile without
modification).
▪ Internal Logical Files (ILF): User-identifiable groups of logically
related data or control information maintained within the system. (e.g.,
a customer database, a product catalog).
▪ External Interface Files (EIF): User-identifiable groups of logically
related data or control information referenced by the application, but
maintained by another application. (e.g., accessing a credit card
processing system's database).
o Process: Each of these five components is assigned a complexity rating (simple,
average, or complex) based on the number of data element types (DETs) and
file types referenced (FTRs). This complexity rating is then multiplied by a
predefined weighting factor. The sum of these weighted counts yields the
Unadjusted Function Points (UFP).
▪ The UFP is then adjusted by a Value Adjustment Factor (VAF). The
VAF is derived from assessing 14 General System Characteristics
(GSCs), each rated on a scale of 0 (not applicable) to 5 (strong

SOFTWARE PROJECT MANAGEMENT 44

 influence). These GSCs include factors like data communication,
distributed processing, performance, heavily used configuration,
transaction rate, end-user efficiency, online update, complex processing,
reusability, installation ease, operational ease, multiple sites, facilitative
change, and special security. The sum of these 14 GSC ratings (Total
Degree of Influence - TDI) is used to calculate the VAF:
VAF=0.65+(0.01timesTDI).
▪ Finally, Adjusted Function Points (AFP) = UFP times VAF.
o Pros: Function Points are language-independent and can be estimated relatively
early in the project lifecycle, even from high-level requirements, making them
a better indicator of the functional scope and size of the software. They provide
a more consistent and objective measure for comparing projects across different
technologies and organizations.
o Cons: The process requires specific training and experience to apply
consistently, and there can be some subjectivity in assigning complexity ratings.
Initial FP counts might require refinement as requirements become clearer.
Other variations like COSMIC Function Points (ISO 19761) have emerged to
address some limitations and offer a more precise measurement method for real-
time and embedded systems.
o Example:
▪ Consider an "Add New Customer" screen (EI). If it interacts with 3 data
element types and 1 file type, it might be rated "average" (weight 4).
▪ A "Customer Report" (EO) displaying complex aggregated data from
multiple files might be rated "complex" (weight 7).
▪ If we have 10 EIs, 5 EOs, 3 EQs, 8 ILFs, and 2 EIFs, and their respective
complexities lead to a UFP of, say, 250.
▪ If the sum of the 14 General System Characteristics (TDI) is 30, then
VAF=0.65+(0.01times30)=0.65+0.30=0.95.
▪ Adjusted FP = 250times0.95=237.5 Function Points.
Software Reuse Estimating:
• Concept: Software reuse involves leveraging existing software assets (such as code
modules, design patterns, architectures, test cases, or documentation) to build new
systems. Software reuse estimation is the process of predicting what percentage of the

SOFTWARE PROJECT MANAGEMENT 45

 new system's functionality or codebase can be satisfied by these existing, reusable
components.
• Impact: Successful software reuse can significantly reduce development effort, cost,
and time-to-market. It also has the potential to improve software quality by
incorporating components that have already been tested and proven in other contexts.
• Challenges: While beneficial, reuse isn't without its challenges. These include:
o Identification: Finding truly reusable components from existing asset
repositories can be difficult, especially if they are not well-documented or
cataloged.
o Integration Effort: Reusable components may not perfectly fit the new
system's architecture or technology stack, requiring adaptation or significant
integration effort.
o Testing Reused Components: Even "reused" components need to be re-tested
in the context of the new system to ensure compatibility and correct
functionality.
o Intellectual Property: Legal and licensing issues can arise when reusing
components, especially if they are proprietary or have specific open-source
license requirements.
o Maintenance of Reused Code: Maintaining a reused component might become
complex if the original developers are no longer available or if the component
is not designed for easy modification.
• Estimation: Estimation often involves a detailed analysis of the new project's
requirements against the capabilities of available reusable assets. This might include:
o Domain Analysis: Identifying common functionalities and components within
a specific problem domain.
o Asset Repository Analysis: Reviewing existing libraries, frameworks, and
codebases for potential candidates.
o Technical Feasibility Assessment: Determining if identified components are
technically compatible and adaptable to the new system.
o Cost-Benefit Analysis: Comparing the cost of developing a component from
scratch versus adapting and integrating an existing one.
The SEI CMM (Capability Maturity Model)

SOFTWARE PROJECT MANAGEMENT 46

The Software Engineering Institute (SEI) Capability Maturity Model (CMM) is a
foundational framework that describes an organization's maturity in terms of its software
development and maintenance processes. It serves as a structured roadmap for organizations
aiming to improve their software engineering practices and achieve higher levels of quality and
predictability. The CMM provides a set of guidelines for process improvement, allowing
organizations to assess their current state and identify areas for growth.
• Purpose: The primary purpose of the CMM is to help organizations evolve their
software development and maintenance capabilities. It provides a common language
and a shared vision for process improvement, enabling organizations to move from ad-
hoc, chaotic processes to disciplined, managed, and continuously improving ones.
• Five Maturity Levels: The CMM defines a continuum of five stages, or maturity
levels, each representing an evolutionary plateau in an organization's software process
capability. Achieving a higher level signifies a more predictable, controlled, and
effective software development environment.
1. Level 1: Initial (Chaotic, Ad hoc): At this lowest level, software processes are
typically uncharacterized, unpredictable, and often reactive. Success is highly
dependent on individual heroics and the competence of specific individuals
rather than established processes. Projects often exceed budget and schedule
due to a lack of planning and control. There's little formal project management,
and quality is often an afterthought.
2. Level 2: Repeatable (Basic Project Management): Organizations at this level
establish basic project management processes to track cost, schedule, and
functionality. Key process areas include requirements management, project
planning, project tracking and oversight, subcontract management, software
quality assurance, and configuration management. Success is repeatable for
similar projects, as basic controls are in place, allowing for some consistency.
However, processes might still be reactive rather than proactive.
3. Level 3: Defined (Standardized Process): At this level, software processes for
both management and engineering activities are documented, standardized, and
integrated into a standard process for the organization. These processes are
proactive and well-understood. Key process areas include organization process
focus, organization process definition, training program, integrated software
management, software product engineering, intergroup coordination, and peer

SOFTWARE PROJECT MANAGEMENT 47

 reviews. The entire organization uses a consistent, documented set of processes,
leading to greater efficiency and quality.
4. Level 4: Managed (Quantitative Management): Organizations at Level 4
collect detailed measures of software process and product quality. Both the
software process and products are quantitatively understood and controlled.
Statistical process control techniques are used to analyze data and predict
outcomes. Key process areas include quantitative process management and
software quality management. This level focuses on establishing quantitative
objectives for quality and process performance, and using data to manage
deviations.
5. Level 5: Optimizing (Continuous Process Improvement): This highest level
focuses on continuous process improvement. Organizations at this level use
quantitative feedback from the process and from piloting innovative ideas and
technologies to drive ongoing improvements. Key process areas include defect
prevention, technology change management, and process change management.
The organization is proactive in identifying and implementing improvements,
leading to sustained high quality and efficiency.
• Conceptual Diagram (Ladder of Maturity): This diagram visually represents the
progressive nature of the CMM levels, where each level builds upon the capabilities
established in the preceding ones.
Level 5: Optimizing (Continuous Improvement & Innovation)
^
| (Focus on preventing defects, leveraging new tech)
Level 4: Managed (Quantitative Control & Predictability)
^
| (Focus on measurable quality, statistical process control)
Level 3: Defined (Standardized, Integrated Processes)
^
| (Focus on consistent, documented organizational processes)
Level 2: Repeatable (Basic Project Management & Discipline)
^
| (Focus on tracking, basic controls, and consistency)
Level 1: Initial (Chaotic, Ad hoc, Reactive)

SOFTWARE PROJECT MANAGEMENT 48

 • Benefits of CMM Adoption: Moving up the CMM ladder typically leads to several
significant benefits, including improved product quality, reduced development costs,
shorter development cycles, increased customer satisfaction, and enhanced
predictability of project outcomes. It fosters a culture of continuous improvement and
disciplined engineering.
• Evolution to CMMI: It's important to note that the SEI CMM has largely been
superseded by the Capability Maturity Model Integration (CMMI). CMMI
integrates multiple CMMs into a single framework, providing a more comprehensive
approach to process improvement across various organizational functions, not just
software development. CMMI also offers two representations: staged (similar to
CMM's levels) and continuous (allowing organizations to improve specific process
areas without necessarily achieving a full maturity level).
Problems and Risks
Understanding the distinction between problems and risks is fundamental to effective project
management. While both can negatively impact a project, problems are current issues, whereas
risks are potential future issues.
Software Project Problems: These are existing issues or obstacles that are currently hindering
project progress or success. They require immediate attention and resolution.
• Examples of Common Software Project Problems:
o Scope Creep: This is one of the most pervasive problems, referring to the
uncontrolled changes or continuous growth in a project's requirements or scope
after the project has officially started. It leads to increased effort, cost, and
schedule delays.
o Poor Requirements: Ambiguous, incomplete, inconsistent, or frequently
changing requirements are a major source of project failure. If the team doesn't
clearly understand what needs to be built, the final product will likely not meet
user expectations.
o Inaccurate Estimates: Underestimation of effort, cost, or schedule (often
driven by optimism or pressure) leads to unrealistic expectations and subsequent
project overruns. Conversely, overestimation can lead to inefficient resource
allocation.

SOFTWARE PROJECT MANAGEMENT 49

 o Lack of Stakeholder Involvement: Insufficient input, feedback, or buy-in
from key stakeholders (users, clients, senior management) can result in a
product that doesn't meet their needs or a lack of support when issues arise.
o Poor Communication: Ineffective or infrequent information flow within the
development team, between teams, or with external stakeholders can lead to
misunderstandings, duplicated effort, and missed dependencies.
o Technical Challenges: Unforeseen technical difficulties, integration issues,
performance bottlenecks, or limitations of chosen technologies can significantly
derail a project.
o Resource Shortages: Insufficient skilled personnel, equipment, or
infrastructure can lead to delays, burnout, and reduced quality. This includes
both human resources and physical resources.
o Unrealistic Expectations: Stakeholders may have expectations regarding
features, timeline, or budget that are not achievable given the project's
constraints, leading to dissatisfaction and conflict.
o Poor Change Management: An unstructured or reactive approach to managing
changes in requirements, design, or scope can lead to chaos and instability.
o Team Conflicts/Low Morale: Internal disagreements, lack of trust, or low
motivation within the project team can severely impact productivity and quality.
Software Risks: These are uncertain events or conditions that, if they occur, will have a
positive or negative effect on one or more project objectives (scope, schedule, cost, quality). In
software, most risks are negative.
• Risk Management: This is a systematic and proactive process to identify, analyze,
plan responses for, and monitor risks throughout the project lifecycle. Its goal is to
maximize the probability and consequences of positive events and minimize the
probability and consequences of negative events.
o Risk Identification: The first step involves systematically identifying potential
risks. Techniques include brainstorming sessions with the team, using risk
checklists (derived from past projects or industry best practices), conducting
interviews with experts and stakeholders, SWOT analysis (Strengths,
Weaknesses, Opportunities, Threats), and reviewing historical data.
o Risk Analysis: Once identified, risks are analyzed to understand their
characteristics. This typically involves:

SOFTWARE PROJECT MANAGEMENT 50

 ▪ Qualitative Risk Analysis: Assessing the likelihood (probability) of
the risk occurring (e.g., Low, Medium, High) and its impact
(consequence) on project objectives if it does occur (e.g., Low,
Medium, High). Risks are then prioritized based on their "risk exposure"
or "risk score" (Probability times Impact).
▪ Quantitative Risk Analysis: For high-priority risks, a more detailed
numerical analysis might be performed. This involves using techniques
like Monte Carlo simulations, decision tree analysis, or expected
monetary value (EMV) to assign numerical probabilities and impacts,
providing a more precise understanding of potential outcomes.
o Risk Planning/Response (Mitigation): This involves developing strategies to
address identified risks. The four primary strategies are:
▪ Avoidance: Changing the project plan to eliminate the risk entirely.
This might involve changing scope, using a different technology, or
extending the schedule. (e.g., If a specific third-party library is known
to be unstable, avoid using it).
▪ Mitigation: Reducing the probability or impact of a risk to an
acceptable level. This is the most common strategy. (e.g., To mitigate
the risk of a key developer leaving, implement cross-training and
comprehensive documentation).
▪ Transfer: Shifting the responsibility and/or impact of a risk to a third
party. This doesn't eliminate the risk but makes someone else
accountable. (e.g., Purchasing insurance, outsourcing a risky component
to a specialist vendor).
▪ Acceptance: Deciding to acknowledge the risk and not take any action
unless the risk occurs. This is appropriate for low-priority risks or when
the cost of mitigation outweighs the potential impact. Acceptance can
be passive (doing nothing) or active (developing a contingency plan –
a pre-defined response if the risk materializes).
o Risk Monitoring & Control: This ongoing process involves tracking identified
risks, monitoring residual risks (risks remaining after mitigation), identifying
new risks, evaluating the effectiveness of risk responses, and executing
contingency plans as needed. A risk register is a crucial tool for this,

SOFTWARE PROJECT MANAGEMENT 51

 documenting all identified risks, their analysis, planned responses, and current
status.
o Risk Appetite and Thresholds: Organizations often define their risk appetite,
which is the degree of uncertainty an entity is willing to accept in anticipation
of a reward. Risk thresholds are specific points beyond which the organization
is unwilling to accept risk. These guide decision-making in risk management.
• Example (Enhanced Risk Register Entry):
Risk Description Probability Impact Exposure Mitigation Contingency Owner Status Trigger
ID (P*I) Strategy Plan
R001 Key Medium High 0.4 Mitigation: Acceptance Project Open Developer
developer (0.5) (0.8) Implement a (Active): If Manager submits
leaves project knowledge developer resignation.
prematurely. transfer plan resigns,
including pair immediately
programming activate
and mandatory recruitment
documentation for
for critical replacement;
modules. reallocate
Cross-train at critical tasks
least one among
backup remaining
developer for team
each critical members,
area. Offer allowing for a
retention 2-week
bonuses. schedule
buffer.
R002 Requirements High (0.7) Medium 0.42 Mitigation: Acceptance Business Open More than
change (0.6) Implement a (Active): If Analyst 3 major
frequently strict, formal unapproved change
after freeze. change control changes requests
process occur, pause per sprint.
requiring development,
impact analysis re-evaluate
and scope and
stakeholder schedule
approval for all impact, and
changes. renegotiate
Conduct project
frequent, short baseline with
stakeholder stakeholders.
review
sessions to
catch potential
changes early.

SOFTWARE PROJECT MANAGEMENT 52

 Use agile
iterations to
embrace
controlled
change.
R003 Critical third- Low (0.1) High 0.09 Mitigation: Acceptance Software Open API
party API (0.9) Negotiate (Active): Architect downtime
becomes Service Level Switch to a exceeds 4
unavailable. Agreement pre-identified hours.
(SLA) with alternative
API provider. API provider
Implement (if available);
robust error implement a
handling and manual
retry workaround
mechanisms in process for
code. Develop critical
a lightweight features until
mock API for API is
testing. restored.

Cost Estimation
Cost Estimation in software project management is the process of predicting the financial
resources (including personnel salaries, hardware, software licenses, training, travel, and
overheads) required to complete a software project. It's a critical early activity that informs
budgeting, financial planning, bid preparation, project approval, and resource allocation
decisions. Accurate cost estimates are vital for setting realistic expectations and ensuring
project viability.
• Importance:
o Budgeting: Forms the basis for allocating funds.
o Bidding & Contracts: Essential for competitive proposals and establishing
contractual agreements.
o Project Approval: Often a prerequisite for securing funding and management
buy-in.
o Resource Allocation: Helps determine the optimal mix of human and non-
human resources.
o Performance Monitoring: Provides a baseline against which actual costs can
be tracked and controlled.
• Techniques: Various techniques are employed, often in combination, to arrive at a
comprehensive cost estimate:

SOFTWARE PROJECT MANAGEMENT 53

o Expert Judgment (Analogous Estimating): This technique relies on the
knowledge and experience of seasoned professionals or subject matter experts.
They use their understanding of similar past projects to estimate the current
project's cost.
▪ Pros: Quick, inexpensive, and can be relatively accurate if the experts
have relevant experience with very similar projects.
▪ Cons: Highly subjective, prone to bias (e.g., optimism bias), and its
accuracy diminishes significantly if the current project differs
substantially from past ones. It lacks transparency and objective
justification.
o Analogy (Analogous Estimating): Similar to expert judgment but more
formalized. It involves comparing the current project to a past project (or
projects) that is similar in size, complexity, and domain. The cost of the past
project is then adjusted for known differences.
▪ Pros: Relatively quick and simple, useful in early project phases when
detailed information is scarce.
▪ Cons: Requires good historical data from similar projects. If the analogy
is poor, the estimate will be inaccurate.
o Parametric/Algorithmic Models: These techniques use mathematical
formulas or algorithms that relate project characteristics (parameters) to effort
and cost. Models like COCOMO (discussed below) fall into this category. They
are built on historical data and statistical relationships.
▪ Pros: Objective, repeatable, and can provide more precise estimates
than expert judgment or analogy, especially when calibrated with an
organization's own historical data. Can be used for "what-if" analysis.
▪ Cons: Requires reliable historical data to build and calibrate the models.
The accuracy depends heavily on the quality of the input parameters
(e.g., size estimates, cost driver ratings).
o Bottom-Up Estimation: This is a highly detailed and often more accurate
technique. The project is decomposed into its smallest constituent work
packages or activities (often derived from the Work Breakdown Structure -
WBS). Each small task is then estimated individually for resources, duration,

SOFTWARE PROJECT MANAGEMENT 54

 and cost. These individual estimates are then aggregated (summed up) to arrive
at the total project cost.
▪ Pros: High level of detail and accuracy, fosters team buy-in as those
doing the work contribute to estimates.
▪ Cons: Time-consuming and resource-intensive, requires a well-defined
WBS and detailed understanding of tasks. Not feasible in early project
phases when details are scarce.
o Top-Down Estimation (Decomposition): This approach starts with an overall
estimate for the entire project, often provided by senior management or based
on high-level analogies. This total estimate is then progressively broken down
and allocated to major project phases or components.
▪ Pros: Quick, useful in early project phases for feasibility studies and
high-level budgeting.
▪ Cons: Less detailed and potentially less accurate than bottom-up, prone
to overlooking specific complexities.
o Three-Point Estimating (PERT-based): This technique, often used in
conjunction with other methods, involves obtaining three estimates for each
activity's cost: optimistic (best-case), most likely (realistic), and pessimistic
(worst-case). These are then combined using a weighted average (similar to
PERT duration calculation) to provide a more realistic estimate and an
indication of uncertainty.
o Contingency Reserves and Management Reserves:
▪ Contingency Reserves: These are funds or time buffers added to the
cost or schedule estimate to account for known-unknowns – identified
risks that may or may not occur. They are managed by the project
manager and are part of the project's cost baseline.
▪ Management Reserves: These are funds or time buffers added to the
overall project budget or schedule to account for unknown-unknowns
– unforeseen events or scope changes that are not identifiable as specific
risks. They are typically controlled by senior management and are not
part of the project's cost baseline.
Effort Measures

SOFTWARE PROJECT MANAGEMENT 55

Effort in software development quantifies the amount of labor required to complete a task, a
phase, or an entire project. It represents the total person-hours or person-days needed,
independent of the actual calendar time taken.
• Units: Effort is typically measured in person-hours (PH), person-days (PD), person-
weeks (PW), person-months (PM), or person-years (PY). The choice of unit depends
on the project's scale and the level of granularity required for planning. For larger
projects, person-months are a common unit.
• Relationship to Size: Effort is generally (though not linearly) proportional to the size
of the software. Larger software systems inherently require more effort to design,
develop, test, and deploy. However, this relationship is significantly influenced by a
multitude of other factors:
o Complexity: The inherent difficulty of the problem being solved, the intricacy
of algorithms, and the number of interfaces.
o Team Skill and Experience: Highly skilled and experienced teams can often
achieve more with less effort than novice teams.
o Tools and Technology: The availability and effectiveness of development
tools, integrated development environments (IDEs), frameworks, and
automation tools can greatly impact efficiency.
o Development Environment: Factors like stable infrastructure, access to
necessary hardware, and a conducive workspace.
o Process Maturity: Organizations with mature, well-defined processes (as per
CMM/CMMI) tend to have more predictable effort requirements.
o Communication Overhead: As team size increases, communication paths
grow exponentially, leading to increased overhead and potentially diminishing
returns on adding more people. This is famously summarized by Brooks' Law:
"Adding manpower to a late software project makes it later." This highlights the
non-linear relationship between effort, team size, and schedule.
• Example: If a project requires 12 person-months of effort, this means a total of 12
months of work by one person. This effort can be distributed in various ways:
o 1 person working for 12 months.
o 2 people working for 6 months each.
o 3 people working for 4 months each.

SOFTWARE PROJECT MANAGEMENT 56

 o However, it's crucial to understand that simply dividing effort by the number of
people to get the duration is an oversimplification. Adding more people to a
project, especially a complex one, introduces communication overhead,
integration challenges, and new coordination tasks, which can increase the
overall effort and extend the schedule rather than shorten it. For instance, while
2 people might complete a 12-person-month project in less than 12 months, they
are unlikely to do it in exactly 6 months due to the added coordination.
COCOMO: A Regression Model
COCOMO (Constructive Cost Model) is a widely recognized and extensively used
algorithmic cost estimation model developed by Dr. Barry Boehm. It's a regression model,
meaning it uses empirically derived formulas based on historical project data to predict
software development effort and schedule. Its strength lies in its ability to provide a quantitative
estimate based on project size and a set of influencing factors, known as "cost drivers."
• COCOMO 81 (Original Model): The initial version of COCOMO, introduced in
1981, categorized software projects into three modes of development, each with
different constants in its estimation formulas:
o Organic Mode: Characterized by relatively small, simple projects with
experienced teams working in a stable environment. The team members have a
good understanding of the project goals and work together smoothly. (e.g., a
small business application, a simple utility).
o Semi-Detached Mode: Represents projects of intermediate size and
complexity, often with mixed teams (some experienced, some less so) and a
moderate level of environmental stability. (e.g., a new operating system
component, a database management system).
o Embedded Mode: Applies to large, complex projects that operate within tight
constraints (e.g., hardware, operational procedures, regulations). These projects
typically involve highly complex interfaces, stringent performance
requirements, and often require innovative solutions. (e.g., flight control
software, real-time process control systems).
o Basic Formula: The fundamental formula for estimating effort in COCOMO
81 is: Effort=Atimes(KLOC)B Where:
▪ Effort is the estimated effort in Person-Months (PM).

SOFTWARE PROJECT MANAGEMENT 57

 ▪ KLOC is the estimated size of the software in thousands of Lines of
Code.
▪ A and B are empirically derived constants that vary based on the
development mode. For example:
▪ Organic: A = 2.4, B = 1.05
▪ Semi-Detached: A = 3.0, B = 1.12
▪ Embedded: A = 3.6, B = 1.20
o Example (Organic Mode Calculation):
▪ Let's assume we are developing a new module for an existing internal
system, and it's classified as an Organic project.
▪ Constants for Organic mode: A = 2.4, B = 1.05
▪ If the estimated size (KLOC) is 50 (meaning 50,000 Lines of Code).
▪ Effort=2.4times(50)1.05approx2.4times62.4approx149.76 Person-
Months.
▪ To estimate the development schedule (Time), COCOMO 81 also
provided a formula: Time=Ctimes(Effort)D, where C and D are also
mode-dependent constants. For Organic, C = 2.5, D = 0.38. So,
Time=2.5times(149.76)0.38approx2.5times7.6approx19 Months.
o Intermediate and Detailed COCOMO 81: While the Basic COCOMO
provided a quick, rough estimate, the Intermediate and Detailed versions
introduced a set of 15 "cost drivers" (or Effort Multipliers - EMs) to refine
the effort estimate. These drivers represent various attributes of the project,
product, personnel, and development environment. Each cost driver has a rating
scale (e.g., Very Low, Low, Nominal, High, Very High, Extra High), and each
rating corresponds to a specific multiplier. The product of all these multipliers
(Effort Adjustment Factor - EAF) is then applied to the nominal effort.
▪ Examples of Cost Drivers:
▪ Product Attributes: Required Software Reliability (RELY),
Database Size (DATA), Product Complexity (CPLX).
▪ Hardware Attributes: Run-time Performance Constraints
(TIME), Main Storage Constraints (STOR), Virtual Machine
Volatility (VIRT), Computer Turnaround Time (TURN).

SOFTWARE PROJECT MANAGEMENT 58

 ▪ Personnel Attributes: Analyst Capability (ACAP),
Applications Experience (AEXP), Programmer Capability
(PCAP), Virtual Machine Experience (VEXP), Language and
Tool Experience (LEXP).
▪ Project Attributes: Use of Modern Programming Practices
(MODP), Use of Software Tools (TOOL), Required
Development Schedule (SCED).
▪ The formula becomes: Effort=Atimes(KLOC)BtimesEAF, where
EAF=prod_i=115EM_i.
COCOMO II
COCOMO II is the modern evolution of the COCOMO model, developed to address the
significant changes in software development practices since the 1980s (e.g., object-oriented
development, component-based development, reuse, agile methodologies, internet-based
applications). It is a more sophisticated and flexible model designed for a wider range of
software projects.
• Three Stages/Models: COCOMO II provides three distinct models, each applicable at
different points in the software lifecycle, reflecting the increasing availability of
information as a project progresses:
1. Application Composition Model: Used in the early prototyping or "end-user
programming" stage. It estimates effort for applications built using GUI
builders, scripting languages, or integrating off-the-shelf components. The size
metric used here is Object Points, which are counts of screens, reports, and
3GL components. This model is ideal for rapid application development.
2. Early Design Model: Applied once requirements are relatively stable and a
high-level architecture is being considered. It estimates effort based on either
KLOC or Function Points. This model uses a reduced set of 7 Cost Drivers and
5 Scale Factors to provide a preliminary estimate before detailed design. It
helps in evaluating architectural alternatives.
3. Post-Architecture Model: This is the most detailed model, used after the
system's architecture has been defined and refined. It uses KLOC or Function
Points as the size metric and incorporates a comprehensive set of 17 Cost
Drivers and 5 Scale Factors. This model provides the most accurate estimates
for detailed planning and control.

SOFTWARE PROJECT MANAGEMENT 59

• Key Differences and Enhancements from COCOMO 81:
o Size Metric Flexibility: COCOMO II supports multiple size metrics: KLOC
(for traditional development), Function Points (for functional size), and Object
Points (for rapid application development).
o Updated Cost Drivers: The set of cost drivers has been updated and expanded
to reflect modern development challenges and technologies (e.g., factors for
software reusability, platform volatility, personnel experience in specific tools).
o Scale Factors: A significant addition in COCOMO II is the introduction of 5
Scale Factors. These factors influence the exponent of the size equation,
accounting for economies or diseconomies of scale. They represent
characteristics of the overall project and organization, such as:
▪ Precedentedness (PREC): How similar the project is to previous ones.
▪ Development Flexibility (FLEX): The degree of flexibility in the
development process.
▪ Architecture/Risk Resolution (RESL): The extent to which
architectural risks have been resolved.
▪ Team Cohesion (TEAM): The level of collaboration and unity within
the team.
▪ Process Maturity (PMAT): The organization's overall process
maturity (similar to CMM levels). The formula for effort in COCOMO
II is more complex: Effort=Atimes(Size)Etimesprod_i=117EM_i,
where E=B+0.01timessum_j=15SF_j. The scale factors (SF) directly
influence the exponent E, making the relationship between size and
effort non-linear and more realistic.
o Non-linear Scaling: Unlike COCOMO 81 where the exponent B was fixed for
a mode, in COCOMO II, the exponent E is variable, influenced by the scale
factors. This allows for more realistic scaling, acknowledging that larger
projects don't always scale linearly in effort. For example, a highly flexible and
mature organization might experience greater economies of scale for larger
projects.
o Reuse and Maintenance: COCOMO II explicitly incorporates models for
software reuse and maintenance effort, which were less detailed in COCOMO
81.

SOFTWARE PROJECT MANAGEMENT 60

SLIM: A Mathematical Model
SLIM (Software Life Cycle Management) is a proprietary software estimation model
developed by Lawrence Putnam, based on the Putnam-Norden-Rayleigh (PNR) curve. The
PNR curve is a mathematical model that describes the relationship between effort, schedule,
and software size, particularly focusing on the dynamics of staffing and productivity over the
project lifecycle. It's rooted in the observation that software development effort and schedule
exhibit a specific pattern over time.
• Concept: SLIM utilizes a mathematical model to predict the effort, schedule, and
staffing levels required for a project. Its core inputs typically include the estimated
software size (often in KLOC or Function Points) and a "technology constant" (also
known as the "productivity parameter" or "process productivity"). This technology
constant represents the overall efficiency and capability of the development
environment, including factors like team experience, tools, methods, and process
maturity. A higher technology constant indicates a more efficient development
environment.
• Key Features:
o Effort-Schedule Trade-off (PNR Curve): One of SLIM's most powerful
features is its ability to illustrate the non-linear trade-off between project
duration (schedule) and the total effort required. The PNR curve demonstrates
that there's an optimal schedule duration where effort is minimized. Attempting
to compress the schedule beyond this optimal point (e.g., by adding more
people) leads to a disproportionately higher increase in total effort due to
communication overhead, integration issues, and other diseconomies of scale
(reinforcing Brooks' Law). Conversely, extending the schedule too much can
also increase effort due to prolonged overhead and potential scope creep.
▪ Conceptual Diagram (Effort vs. Schedule):
▪ Effort (Person-Months)
^
| *
| /\
| / \
| / \
|/ \

SOFTWARE PROJECT MANAGEMENT 61

 +------------------> Schedule (Time)
Optimal Schedule

o Staffing Profile (Rayleigh Curve): SLIM predicts a typical Rayleigh curve

for staffing levels over the project lifecycle. This curve shows a slow ramp-up
of personnel at the beginning of the project, followed by a peak staffing level
during the core development phase, and then a gradual ramp-down towards
project completion. This profile reflects the natural dynamics of team formation,
work distribution, and project winding down.
▪ Conceptual Diagram (Staffing over Time):
▪ Staffing Level
^
| /\
| / \
| / \
| / \
+------------------> Time

o Risk Analysis: SLIM can incorporate uncertainty in its input parameters (e.g.,
a range for size or technology constant) to provide probabilistic estimates for
effort and schedule. This allows project managers to understand the range of
potential outcomes and the associated risks.
o Resource Allocation Insights: By modeling the staffing profile, SLIM
provides insights into when resources will be needed and at what levels, aiding
in resource planning and recruitment.
• Focus: SLIM is often applied to larger, more complex software projects where
understanding the effort-schedule trade-off and optimal staffing patterns is critical. It
helps in strategic planning and provides a scientific basis for negotiation of project
constraints.
Organizational Planning
Organizational Planning within project management is the systematic process of defining the
project's structure, roles, responsibilities, reporting relationships, and overall human resource
management approach. It's a foundational activity that ensures clarity, accountability, efficient

SOFTWARE PROJECT MANAGEMENT 62

communication, and effective utilization of the project team. A well-defined organizational
plan minimizes confusion, reduces conflicts, and streamlines decision-making, contributing
significantly to project success.
• Importance:
o Clarity and Accountability: Clearly defined roles and responsibilities ensure
that every team member knows what they are expected to do and to whom they
report, preventing duplication of effort or missed tasks.
o Efficient Communication: Establishing clear reporting lines and
communication channels facilitates the smooth flow of information, reducing
misunderstandings and delays.
o Effective Resource Utilization: By understanding the required skills and roles,
resources can be acquired and deployed optimally, avoiding over-allocation or
under-utilization.
o Conflict Reduction: Ambiguity in roles is a common source of conflict. A clear
organizational structure helps mitigate these issues.
o Team Cohesion: A well-structured team with defined interactions can foster
better collaboration and morale.
• Key Activities:
o Defining Roles and Responsibilities: This involves outlining the specific
duties, authorities, and deliverables for each position within the project team.
Tools like a Responsibility Assignment Matrix (RAM), often in the form of
a RACI chart (Responsible, Accountable, Consulted, Informed), are
commonly used to clarify who does what for each task or deliverable.
o Organizational Chart Development: Creating a visual representation of the
project's reporting structure. This chart shows the hierarchy, who reports to
whom, and the various functional groups or teams involved. It provides a quick
overview of the project's command and communication lines.
o Staffing Management Plan: This document details how human resources will
be identified, acquired, developed, managed, and eventually released from the
project. It includes:
▪ Resource Requirements: The types and quantities of personnel needed.
▪ Acquisition Strategy: How team members will be obtained (e.g.,
internal staff, contractors, new hires).

SOFTWARE PROJECT MANAGEMENT 63

 ▪ Resource Calendars: Availability of specific resources, including
vacations, holidays, and training.
▪ Recognition and Rewards: How team performance will be
acknowledged.
▪ Training and Development: Plans for enhancing team skills.
▪ Release Criteria: How and when team members will transition off the
project.
o Communication Plan: Establishing how information will flow within the
project team, with stakeholders, and with external parties. This includes
defining:
▪ What information needs to be communicated.
▪ Who is responsible for communicating it.
▪ Who needs to receive it.
▪ When and how often it will be communicated (e.g., daily stand-ups,
weekly reports, monthly steering committee meetings).
▪ The communication channels and formats (e.g., email, chat, formal
documents, presentations).
o Training Needs Analysis: Identifying any skill gaps within the current or
prospective project team and planning for necessary training or development
programs to bridge these gaps. This ensures the team has the competencies
required to execute the project successfully.
o Organizational Breakdown Structure (OBS): While related to the WBS, the
OBS maps the project work packages to the organizational units or individuals
responsible for performing that work. It helps in assigning accountability and
tracking performance by organizational area.
Project Roles and Skills Needed
Successful software projects are collaborative endeavors that require a diverse set of roles, each
contributing specialized expertise and skills. Beyond technical prowess, strong soft skills are
increasingly critical for effective teamwork and stakeholder management.
• Project Manager (PM):
o Role: The central figure responsible for planning, executing, and closing the
project. The PM ensures the project meets its objectives on time, within budget,

SOFTWARE PROJECT MANAGEMENT 64

 and to the required quality standards. They are the primary point of contact for
stakeholders and the team.
o Key Responsibilities: Defining project scope, creating schedules, managing
budgets, allocating resources, identifying and mitigating risks, managing
changes, communicating progress, and resolving conflicts.
o Skills: Strong leadership (motivating and guiding the team), excellent
communication (listening, presenting, negotiating), negotiation (with
stakeholders, vendors), risk management, strategic planning, effective
problem-solving, adept stakeholder management (managing expectations,
building relationships), and decision-making.
• Software Architect:
o Role: Designs the high-level structure and overall blueprint of the software
system. They define the system's components, their interfaces, the technologies
to be used, and ensure the design meets functional and non-functional
requirements (e.g., scalability, security, performance).
o Skills: Deep technical expertise in various technologies and design patterns,
strong system design capabilities, problem-solving (especially for complex
technical challenges), and clear communication (to explain complex
architectural decisions to both technical and non-technical audiences).
• Business Analyst (BA):
o Role: Serves as the bridge between business stakeholders and the technical
development team. They gather, analyze, validate, and document user
requirements, translating business needs into clear, actionable specifications for
developers.
o Skills: Exceptional requirements elicitation (interviewing, workshops), strong
analytical skills (identifying needs, gaps, inconsistencies), precise
documentation (e.g., user stories, use cases, functional specifications),
excellent communication (facilitating discussions, clarifying ambiguities), and
relevant domain knowledge (understanding the business context).
• Software Developer/Engineer:
o Role: The core of the development team, responsible for writing, testing,
debugging, and maintaining the software code according to design
specifications.

SOFTWARE PROJECT MANAGEMENT 65

 o Skills: Proficiency in relevant programming languages (e.g., Python, Java,
JavaScript, C#), strong debugging abilities, logical and critical problem-
solving, meticulous attention to detail, and effective teamwork and
collaboration.
• Quality Assurance (QA) Engineer/Tester:
o Role: Ensures the software meets specified quality standards and requirements.
They design, execute, and automate tests to identify defects, verify
functionality, and validate performance.
o Skills: Expertise in various testing methodologies (manual, automated, black-
box, white-box), strong test case design (creating comprehensive test
scenarios), accurate defect reporting and tracking, keen attention to detail,
and analytical thinking to identify root causes of issues.
• UI/UX Designer (User Interface/User Experience Designer):
o Role: Focuses on the user's interaction with the software. UI designers craft the
visual layout and interactivity (buttons, forms, navigation), while UX designers
focus on the overall user journey, ensuring the product is intuitive, efficient, and
enjoyable to use.
o Skills: User research, wireframing, prototyping, visual design, knowledge of
usability principles, empathy for users.
• DevOps Engineer:
o Role: Manages the software development lifecycle from code commit to
deployment. They focus on automating build, test, and deployment processes,
and managing infrastructure to ensure continuous delivery and integration.
o Skills: Scripting (e.g., Bash, Python), proficiency with CI/CD tools (e.g.,
Jenkins, GitLab CI/CD, Azure Pipelines), experience with cloud platforms
(e.g., AWS, Azure, GCP), system administration fundamentals, and strong
collaboration skills to bridge development and operations teams.
• Database Administrator (DBA):
o Role: Responsible for the design, implementation, maintenance, and
performance of databases used by the software. They ensure data integrity,
security, and availability.

SOFTWARE PROJECT MANAGEMENT 66

 o Skills: Database management systems (DBMS) expertise (e.g., SQL Server,
MySQL, PostgreSQL), SQL proficiency, performance tuning, backup and
recovery, security management.
• Technical Writer:
o Role: Creates clear, concise, and accurate documentation for various audiences,
including user manuals, API documentation, system administration guides, and
online help.
o Skills: Excellent clear and concise writing, ability to understand and translate
complex technical concepts into understandable language, strong audience
awareness, and proficiency with documentation tools.
• Technical Lead/Team Lead:
o Role: A senior developer who guides and mentors a small team of developers,
provides technical oversight, reviews code, and helps resolve technical
challenges. They bridge the gap between the architect/PM and the development
team.
o Skills: Strong technical expertise, mentoring, code review, problem-solving,
communication.

SOFTWARE PROJECT MANAGEMENT 67

 QUESTION BANK
Choose the Best Answer
1. Tasks in a software project refer to:
a) High-level project goals
b) Specific activities required to achieve project objectives
c) Organizational hierarchy
d) Software architecture components
Answer: b) Specific activities required to achieve project objectives
2. Software size can be measured in:
a) LOC (Lines of Code)
b) Function points
c) Both a and b
d) Number of users
Answer: c) Both a and b
3. Software reuse helps in:
a) Reducing development time and cost
b) Increasing project risk
c) Reducing quality
d) None of the above
Answer: a) Reducing development time and cost
4. The SEI CMM is used to:
a) Measure software project cost
b) Assess software process maturity
c) Schedule tasks
d) Estimate effort
Answer: b) Assess software process maturity
5. Project risks include:
a) Technical risks
b) Schedule risks
c) Cost risks
d) All of the above
Answer: d) All of the above
6. COCOMO is a:
a) Software testing model
b) Cost estimation model
c) Process improvement model
d) Risk analysis tool
Answer: b) Cost estimation model
7. COCOMO II differs from the original COCOMO in that it:
a) Ignores software reuse
b) Supports modern software practices including reuse and incremental development
c) Only works for small projects
d) Uses only LOC as input
Answer: b) Supports modern software practices including reuse and incremental
development
8. SLIM model is primarily used for:
a) Cost estimation using regression

SOFTWARE PROJECT MANAGEMENT 68

 b) Mathematical effort estimation
c) Software testing
d) Project scheduling
Answer: b) Mathematical effort estimation
9. Effort measures in software projects are usually expressed in:
a) Lines of Code
b) Person-Months
c) Dollars
d) Hours
Answer: b) Person-Months
10. Organizational planning for a project involves:
a) Assigning roles and responsibilities
b) Selecting the project team
c) Determining skills needed
d) All of the above
Answer: d) All of the above

Important 7-Mark Questions

1. Explain the difference between Tasks and Activities in software projects.
2. Describe Software Size Estimation and the role of reuse in effort reduction.
3. Write short notes on SEI CMM levels and importance.
4. Explain Problems and Risks in software projects with examples.
5. Define Cost Estimation and Effort Measures in software engineering.
6. Write a short note on COCOMO regression model and its variants.
7. Explain the role of Organizational Planning and project roles and skills needed.

Important 10-Mark Questions

1. Explain the different methods for software size estimation (LOC, Function Points)
and the impact of reuse.
2. Discuss SEI CMM in detail and its relevance to process improvement.
3. Explain risk management in software projects: types of risks and mitigation
strategies.
4. Explain COCOMO I with example calculation and discuss its phases.
5. Discuss COCOMO II and how it incorporates modern software development
practices.
6. Explain the SLIM model and how it estimates effort mathematically.
7. Describe project organizational planning and identify key project roles and skills
needed for a software project.
8. Compare COCOMO I, COCOMO II, and SLIM models for software cost and
effort estimation.

SOFTWARE PROJECT MANAGEMENT 69

 UNIT IV
IV. Project Management Resource Activities, Organizational Form and Structure,
Software Development Dependencies, Brainstorming, Scheduling Fundamentals, PERT
and CPM, Leveling Resource Assignments, Map the Schedule to a Real Calendar,
Critical Chain Scheduling
Project Management Resource Activities
Resource Management is a core knowledge area in project management that encompasses the
entire lifecycle of identifying, acquiring, and managing all the resources needed for the
successful completion of a project. Resources are not just limited to human resources (the
project team) but also include physical resources such as equipment, materials, facilities,
infrastructure, and even software licenses. Effective resource management ensures that the
right resources are available at the right time, in the right quantity, and with the right skills,
optimizing project performance and minimizing waste.
• Key Activities within Resource Management:
1. Plan Resource Management: This initial process involves defining how to
estimate, acquire, manage, and utilize both team and physical resources
throughout the project lifecycle. It includes developing a resource
management plan which outlines roles and responsibilities, organizational
charts, and the staffing management plan. This plan sets the framework for all
subsequent resource activities.
2. Estimate Activity Resources: For each activity identified in the project
schedule, this process involves estimating the type, quantity, and characteristics
of resources required. This includes determining the skills needed for human
resources, the specifications for equipment, and the volume of materials.
Techniques like expert judgment, analogous estimating, parametric estimating,
and bottom-up estimating are used here.
3. Acquire Resources: This is the process of obtaining the necessary team
members, equipment, materials, and facilities. For human resources, this might
involve internal recruitment, external hiring, or contracting. For physical
resources, it involves procurement and logistics. The goal is to ensure that the
resources are available when needed, considering their availability, cost, and
skill sets.

SOFTWARE PROJECT MANAGEMENT 70

 4. Develop Team: This crucial activity focuses on improving the competencies of
the project team members, fostering better team member interaction, and
enhancing the overall team environment. The objective is to boost overall
project performance. Activities include training, team-building exercises,
recognition and rewards, and establishing ground rules. A cohesive and skilled
team is more productive and resilient.
5. Manage Team: This ongoing process involves tracking team member
performance, providing constructive feedback, resolving interpersonal and
performance issues, and managing changes to the team (e.g., onboarding new
members, offboarding departing ones). It also includes motivating team
members and ensuring their well-being to maintain high productivity and
morale.
6. Control Resources: This final activity involves ensuring that the physical
resources assigned and allocated to the project are available as planned and are
being utilized efficiently. It also includes monitoring the planned versus actual
utilization of both human and physical resources, taking corrective action when
deviations occur, and managing the project's physical assets. This involves
tracking resource consumption and ensuring adherence to the resource
management plan.
• Challenges in Resource Management:
o Resource Contention: Multiple projects or tasks competing for the same
limited resources.
o Skill Gaps: Difficulty in finding or developing team members with the specific
skills required for complex tasks.
o Resource Availability: Unforeseen absences, delays in hiring, or equipment
breakdowns.
o Budget Constraints: Limited funds for acquiring necessary resources.
o Geographical Dispersion: Managing distributed teams across different time
zones and cultures.
o Burnout: Over-allocating resources leading to stress and reduced productivity.
Organizational Form and Structure
The organizational structure of a company significantly influences how projects are initiated,
managed, and executed. It dictates the lines of authority, communication channels, resource

SOFTWARE PROJECT MANAGEMENT 71

allocation mechanisms, and the level of autonomy granted to project managers. Understanding
these structures is vital for project managers to navigate their roles effectively.
• Functional Organization:
o Description: In a functional organization, the company is divided into
departments based on specialized functions (ee.g., IT, Marketing, Human
Resources, Engineering, Sales). Projects are typically housed within these
existing functional departments, and project work is often integrated into the
daily operations of the functional units. Project managers in this structure
usually have limited authority and rely heavily on the functional managers for
resources and decisions. Team members report directly to their functional
manager.
o Pros:
▪ Clear Career Paths: Employees have a clear path for professional
growth within their specialized function.
▪ Easy Resource Sharing: Resources (people, equipment) are easily
shared within a department, leading to efficient utilization of specialized
skills.
▪ Specialized Expertise: Fosters deep expertise within functional areas,
as employees focus on specific domains.
▪ Strong Technical Control: Functional managers maintain strong
technical control over their teams.
o Cons:
▪ Limited Project Manager Authority: Project managers often have
little or no formal authority over project team members, leading to
potential conflicts with functional managers over priorities.
▪ Slow Decision-Making: Decisions often have to escalate up the
functional hierarchy, slowing down project progress.
▪ Poor Cross-Functional Coordination: Collaboration across different
functional departments can be challenging, leading to "silos" and lack
of integrated project focus.
▪ Weak Customer Focus: The primary loyalty of team members is to
their functional department, not necessarily to the specific project or its
external customer.

SOFTWARE PROJECT MANAGEMENT 72

 o Diagram:
o CEO
o /|\
o / | \
o / | \
o R&D Marketing IT
o | | |
o (Project A) (Project B) (Project C) <-- Projects are embedded within functional
departments

• Projectized Organization:
o Description: In a projectized organization, the entire company is structured
around projects. Project managers have high authority and full control over
project resources. Teams are often co-located and dedicated solely to a single
project. Once a project is completed, the team is disbanded, and members are
assigned to new projects or released.
o Pros:
▪ Clear Project Focus: Teams are fully dedicated to the project, leading
to strong focus and commitment.
▪ Fast Decision-Making: Project managers have high autonomy,
enabling quick decisions and rapid problem resolution.
▪ Strong Project Manager Authority: PMs have direct control over
resources and budget, leading to effective management.
▪ Team Loyalty to the Project: Team members identify strongly with
the project goals, fostering high morale and cohesion.
▪ Clear Accountability: Project success or failure is clearly attributable
to the project manager and team.
o Cons:
▪ Duplication of Resources: Specialized resources (e.g., a specific type
of tester) might be duplicated across multiple projects, leading to
inefficiency.
▪ Less Functional Expertise Development: Team members might not
have clear career paths within a functional specialty once a project ends.

SOFTWARE PROJECT MANAGEMENT 73

 ▪ Potential for Team Members to Feel "Lost": The "what next?"
problem for team members after a project completes can lead to anxiety
and loss of institutional knowledge.
▪ Inefficient Resource Utilization: Resources might be idle between
projects.
o Diagram:
o CEO
o /|\
o / | \
o / | \
o Project 1 Project 2 Project 3
o | | |
o (Team A) (Team B) (Team C) <-- Each project has its dedicated team

• Matrix Organization:
o Description: A matrix organization is a hybrid structure that attempts to
combine the advantages of both functional and projectized organizations. Team
members typically report to two managers: a functional manager (who manages
their technical skills and career path) and a project manager (who manages their
work on specific projects).
o Types:
▪ Weak Matrix: More closely resembles a functional organization. The
project manager has limited authority and acts more as a coordinator or
expediter.
▪ Balanced Matrix: The project manager and functional manager share
power more equally. This can be challenging due to potential power
struggles.
▪ Strong Matrix: Leans more towards a projectized organization. The
project manager has significant authority and a full-time administrative
staff.
o Pros:
▪ Efficient Resource Utilization: Resources can be shared across
multiple projects, optimizing their use.

SOFTWARE PROJECT MANAGEMENT 74

 ▪ Functional Expertise Available: Team members maintain their
functional home, allowing for continuous skill development and access
to specialized knowledge.
▪ Better Coordination: Facilitates cross-functional collaboration and
communication.
▪ Flexibility: Can adapt to changing project needs and priorities.
o Cons:
▪ Dual Reporting (Two Bosses): This is the most significant challenge,
as team members can experience conflicting priorities and loyalty
issues.
▪ Complex Communication: Requires more sophisticated
communication channels and careful coordination.
▪ Requires Strong Interpersonal Skills: Both project managers and
functional managers need excellent negotiation and conflict resolution
skills.
▪ Potential for Power Struggles: Conflicts over resources and priorities
between functional and project managers are common.
o Diagram (Conceptual):
o CEO
o / \
o / \
o / \
o Functional Mgrs. --- Project Mgrs.
o (e.g., Dev, QA) (e.g., Project X, Y)
o | |
o --- Team Members ---
o (Each team member reports to both their functional manager and their project
manager)

o Suitability: The choice of organizational structure depends on factors like the

size and complexity of projects, the organization's culture, strategic priorities,
and the need for resource sharing versus dedicated project focus.
Software Development Dependencies

SOFTWARE PROJECT MANAGEMENT 75

Dependencies are crucial relationships between project activities that dictate the order in which
they must be performed. Identifying and managing these dependencies correctly is fundamental
to creating a realistic and achievable project schedule. A missed or incorrectly defined
dependency can lead to significant delays and rework.
• Types of Dependencies:
o Mandatory (Hard Logic): These are inherent in the nature of the work or are
legally/contractually required. They cannot be ignored.
▪ Example: Code must be written and compiled before it can be unit
tested. A building's foundation must be poured and cured before the
walls can be constructed.
o Discretionary (Soft Logic / Preferred Logic): These dependencies are defined
by the project team based on best practices, historical knowledge, or specific
project preferences. They are not strictly mandatory but are chosen to optimize
the project.
▪ Example: It's a best practice to conduct a peer review of a design
document before proceeding to detailed coding, even though coding
could technically start without the review. Or, "We prefer to complete
all backend API development before starting frontend integration."
o External: These dependencies involve a relationship between project activities
and non-project activities or entities outside the project team's direct control.
▪ Example: Waiting for hardware delivery from a third-party vendor
before software installation can begin. Waiting for regulatory approval
before deploying a new system.
o Internal: These dependencies involve a relationship between project activities
that are within the project team's control.
▪ Example: The database schema design (internal project activity) must
be completed before the database development (another internal project
activity) can start.
• Relationship Types (Precedence Relationships): These define the precise sequence
and timing between dependent activities.
o Finish-to-Start (FS): This is the most common type of dependency. The
successor activity cannot start until the predecessor activity has completely
finished.

SOFTWARE PROJECT MANAGEMENT 76

 ▪ Example: Task A (Design UI) finishes before Task B (Develop UI)
starts.
▪ Software Context: "Requirements Gathering" (predecessor) must
finish before "System Design" (successor) can start.
o Start-to-Start (SS): The successor activity cannot start until the predecessor
activity has started. They can then proceed in parallel.
▪ Example: Task A (Start Coding Backend) starts, then Task B (Start
Coding Frontend) can start. They might run concurrently for a period.
▪ Software Context: "Start writing test cases" (successor) can start as
soon as "Start developing module X" (predecessor) begins, allowing
parallel work.
o Finish-to-Finish (FF): The successor activity cannot finish until the
predecessor activity has finished.
▪ Example: Task A (Write Test Cases) finishes, then Task B (Execute
Tests) can finish. This implies that testing cannot be fully completed
until all test cases are written.
▪ Software Context: "Debugging Phase" (successor) cannot finish until
"Integration Testing" (predecessor) finishes, as integration testing might
reveal new bugs that need debugging.
o Start-to-Finish (SF): The successor activity cannot finish until the predecessor
activity has started. This is rarely used in practice.
▪ Example: Task A (Old System Shutdown) starts, then Task B (New
System Go-Live) can finish. This implies that the new system must be
ready to go live only after the old system has begun its shutdown
process.
▪ Software Context: "User training completion" (successor) cannot
finish until "Software deployment" (predecessor) starts, ensuring users
are trained on the deployed version.
• Leads and Lags: These are modifications to dependencies to allow for overlaps or
delays.
o Lead: Allows a successor activity to start before its predecessor is complete. It
represents an overlap. A negative lag.

SOFTWARE PROJECT MANAGEMENT 77

 ▪ Example (FS with Lead): "Start writing documentation 2 days before
coding finishes." (FS -2 days).
o Lag: Imposes a delay between the completion of a predecessor and the start of
a successor. It represents waiting time. A positive lag.
▪ Example (FS with Lag): "After system design finishes, wait 3 days for
review approval before starting coding." (FS +3 days).
Brainstorming
Brainstorming is a highly effective and widely used group creativity technique designed to
generate a large number of ideas for a specific problem, topic, or challenge in a short period.
Its core principle is to foster a free-flowing environment where all ideas are encouraged,
regardless of their initial feasibility, to stimulate creative thinking and innovative solutions.
• Purpose:
o Idea Generation: To produce a wide quantity of diverse ideas.
o Problem-Solving: To explore multiple potential solutions to a defined problem.
o Creative Thinking: To encourage out-of-the-box thinking and break
conventional thought patterns.
o Team Collaboration: To foster a collaborative environment where team
members build upon each other's ideas.
o Problem Definition: Sometimes, brainstorming can help in better defining the
problem itself.
o Stakeholder Engagement: Involving diverse perspectives can lead to more
comprehensive solutions and greater buy-in.
• Rules/Guidelines for Effective Brainstorming: Adherence to these rules is crucial to
maximize the technique's effectiveness and prevent common pitfalls:
1. No Criticism or Judgment: This is the most critical rule. All ideas, no matter how
wild, impractical, or seemingly irrelevant, are welcome and should not be criticized, evaluated,
or debated during the idea generation phase. The goal is quantity over quality initially.
2. Quantity Over Quality: The focus should be on generating as many ideas as possible.
A larger pool of ideas increases the likelihood of finding truly innovative or effective solutions.
3. Wild Ideas Encouraged: Participants should be encouraged to think outside the box
and suggest unconventional, even seemingly absurd, ideas. These "wild" ideas can often spark
new and unexpected lines of thought, leading to more practical solutions later.

SOFTWARE PROJECT MANAGEMENT 78

4. Build on Others' Ideas (Piggybacking): Participants should actively listen to and
build upon ideas already suggested by others. This involves combining, refining, expanding,
or modifying existing ideas to create new ones. This collaborative synergy is a hallmark of
effective brainstorming.
• Techniques/Variations:
o Free-form Brainstorming: The most common approach, where participants
simply shout out ideas as they come to mind. A facilitator typically records all
ideas on a whiteboard or flip chart.
o Round-Robin Brainstorming: Each person takes a turn to offer one idea in
sequence. This ensures everyone participates and prevents dominant
personalities from monopolizing the session. If a person has no idea, they can
pass.
o Brainwriting: A silent brainstorming technique where participants write down
their ideas individually before sharing them with the group. This can be
particularly effective for introverted individuals or in groups where some
members might be hesitant to speak up. Ideas are often written on cards and
then circulated.
o Reverse Brainstorming: Instead of asking "How can we solve this problem?",
the question is "How could we cause this problem?" or "How could we make
this worse?". This can help identify potential failure points and then reverse
them into solutions.
o Starbursting: Focuses on generating questions rather than answers. For
example, "What questions do we need to answer about this new feature?"
• Common Pitfalls to Avoid:
o Dominant Personalities: One or two individuals monopolizing the discussion.
o Premature Judgment: Ideas being criticized or evaluated too early.
o Groupthink: Participants conforming to the opinions of the majority.
o Lack of Focus: The session veering off-topic.
o No Follow-up: Ideas are generated but never analyzed or implemented.
Scheduling Fundamentals
Project Scheduling is the art and science of listing project activities, estimating their durations,
and sequencing them to create a realistic and achievable project timeline. It's a cornerstone of
effective project management, providing a roadmap for execution, resource allocation, and

SOFTWARE PROJECT MANAGEMENT 79

progress monitoring. A well-crafted schedule helps manage stakeholder expectations, identify
potential bottlenecks, and ensure the project stays on track.
• Key Concepts:
o Activity/Task: A discrete, definable piece of work that needs to be completed
as part of the project. Each activity has a clear start and end point, and consumes
resources. (e.g., "Develop User Authentication Module," "Conduct User
Acceptance Testing," "Prepare Deployment Plan").
o Duration: The estimated amount of time required to complete an activity. This
is typically expressed in work periods (e.g., hours, days, weeks) and does not
include waiting time or non-working days. Duration estimates should be as
accurate as possible, often using techniques like three-point estimating.
o Milestone: A significant point or event in the project schedule, often
representing the completion of a major deliverable, a phase gate, or a critical
decision point. Milestones have zero duration and are used to mark progress and
provide key checkpoints. (e.g., "Requirements Approved," "Beta Release
Complete," "Go-Live Date").
o Work Breakdown Structure (WBS): A hierarchical decomposition of the
total scope of work required to be carried out by the project team to accomplish
project objectives and create the required deliverables. The WBS breaks down
the project into progressively smaller, more manageable components, with the
lowest level being the "work package" – the point at which work can be reliably
estimated and assigned. The WBS is the foundation for defining activities and
then building the schedule.
o Sequential Activities: Activities that must be performed one after another due
to dependencies. (e.g., Design must precede coding).
o Parallel Activities: Activities that can be performed simultaneously, allowing
for potential schedule compression. (e.g., Developing two independent modules
concurrently).
o Lead: As discussed in dependencies, a lead allows a successor activity to start
before its predecessor is complete, creating an overlap. This is a technique for
schedule compression.
▪ Example: "Start testing the login module 2 days before the entire UI
development is finished."

SOFTWARE PROJECT MANAGEMENT 80

 o Lag: Also discussed in dependencies, a lag imposes a waiting period between
the completion of a predecessor and the start of a successor. It represents a
required delay.
▪ Example: "After the server setup is complete, there's a 1-day lag for
network configuration before application deployment can begin."
o Scheduling Tools: Project scheduling is typically done using specialized
software tools (e.g., Microsoft Project, Jira, Asana, Primavera P6) that allow for
inputting activities, durations, dependencies, resources, and generating Gantt
charts and network diagrams.
o Baselining the Schedule: Once the schedule is finalized and approved, it
becomes the schedule baseline. This is the approved version of the project
schedule that can only be changed through formal change control procedures. It
serves as a fixed reference point against which actual project performance is
measured.
PERT and CPM
PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are
two powerful and widely used network diagramming techniques for project scheduling and
control. While they have distinct origins and primary uses, they share the common goal of
visualizing project activities and their interdependencies to determine the project's shortest
possible duration and identify critical tasks.
• Network Diagrams (Activity-on-Node - AON is common): Both PERT and CPM
rely on network diagrams to graphically represent project activities and their logical
relationships. In an Activity-on-Node (AON) diagram, each node (a box or circle)
represents an activity, and arrows connecting the nodes represent the dependencies or
precedence relationships between activities.
o Conceptual AON Diagram Structure:
o Start --> [Activity A] --> [Activity B]
o | ^
o v |
o [Activity C] --------+

• Critical Path Method (CPM):

SOFTWARE PROJECT MANAGEMENT 81

 o Purpose: CPM is a deterministic technique used when activity durations are
relatively well-known and predictable. Its primary purpose is to determine the
longest path of planned activities from the project start to the project end. This
longest path is known as the Critical Path. It also calculates the earliest and
latest that each activity can start and finish without delaying the overall project.
o Critical Path: The sequence of activities that determines the shortest possible
duration of the project. It's the path with zero total float. Any delay on an activity
on the critical path will directly delay the entire project completion date. Project
managers pay close attention to critical path activities to ensure they stay on
schedule.
o Float (Slack): Float, or slack, is the amount of time an activity can be delayed
without delaying the project end date or violating a schedule constraint.
▪ Total Float: The amount of time an activity can be delayed from its
early start date without delaying the project completion date. Activities
on the critical path have zero total float.
▪ Free Float: The amount of time an activity can be delayed without
delaying the early start of any successor activity.
o CPM Calculation Steps (Forward Pass & Backward Pass):
▪ Forward Pass: Calculates the Early Start (ES) and Early Finish (EF)
dates for each activity.
▪ ES of first activity = Project Start Date.
▪ EF = ES + Duration.
▪ ES of successor = EF of predecessor (for FS dependency). If
multiple predecessors, ES is the maximum of their EFs.
▪ Backward Pass: Calculates the Late Finish (LF) and Late Start (LS)
dates for each activity.
▪ LF of last activity = Project Completion Date (or its EF).
▪ LS = LF - Duration.
▪ LF of predecessor = LS of successor (for FS dependency). If
multiple successors, LF is the minimum of their LSs.
▪ Float Calculation: Total Float = LF - EF or LS - ES.
• PERT (Program Evaluation and Review Technique):

SOFTWARE PROJECT MANAGEMENT 82

 o Purpose: PERT is a probabilistic technique used when activity durations are
highly uncertain or difficult to estimate precisely. It addresses this uncertainty
by using a weighted average of three time estimates for each activity, providing
a more realistic expected duration and a range of possible outcomes.
o Three Time Estimates for Each Activity:
▪ Optimistic (O): The shortest possible time in which an activity can be
completed, assuming everything goes perfectly.
▪ Most Likely (M): The most realistic estimate of the time an activity will
take, under normal conditions.
▪ Pessimistic (P): The longest possible time an activity might take,
assuming unfavorable conditions or risks materialize.
o Expected Duration (E): The weighted average formula for the expected
duration is: E=(O+4M+P)/6Error! Filename not specified.
o Standard Deviation (sigma): PERT also calculates the standard deviation for
each activity's duration: sigma=(P−O)/6. This allows for calculating the
standard deviation of the entire critical path, which can then be used to
determine the probability of completing the project by a certain date (assuming
a normal distribution for the project duration, based on the Central Limit
Theorem).
• Comparison of PERT and CPM: | Feature | CPM | PERT | | :-------------- | :-----------
----------------------------- | :------------------------------------------------------ | | Duration |
Deterministic (single, known duration) | Probabilistic (three-point estimate) | |
Uncertainty | Assumes low uncertainty | Handles high uncertainty | | Focus | Schedule
compression, cost optimization | Time estimation, probability of completion | |
Application | Projects with well-defined, repeatable tasks | R&D projects, novel
projects with high uncertainty | | Origin | DuPont (for industrial projects) | US Navy
(for Polaris missile program) |
• Example (Enhanced CPM Calculation):
Task ID Description Duration (Days) Predecessor
A Requirements 5 -
B Design 8 A
C Develop Module 1 10 B
D Develop Module 2 7 B

SOFTWARE PROJECT MANAGEMENT 83

E Integrate & Test 6 C, D
• Network Diagram (Conceptual AON):
Start (Day 0)
|
v
[A:5] ES=0, EF=5, LS=0, LF=5, TF=0
|
v
[B:8] ES=5, EF=13, LS=5, LF=13, TF=0
|
+---(branch)---+
| |
v v
[C:10] ES=13, EF=23, LS=13, LF=23, TF=0 [D:7] ES=13, EF=20, LS=16, LF=23, TF=3
| |
+----(join)----+
|
v
[E:6] ES=23, EF=29, LS=23, LF=29, TF=0
|
v
End (Day 29)

• Detailed Path Analysis:

o Path 1: A -> B -> C -> E
▪ Duration = 5 (A) + 8 (B) + 10 (C) + 6 (E) = 29 Days
o Path 2: A -> B -> D -> E
▪ Duration = 5 (A) + 8 (B) + 7 (D) + 6 (E) = 26 Days
Critical Path: The longest path is A -> B -> C -> E, with a total duration of 29 Days.
This means the project's minimum duration is 29 days. All activities on this path (A, B,
C, E) have zero total float, meaning any delay in them will delay the entire project.
Float Calculation for Task D:
o Early Start (ES) of D = EF of B = 13

SOFTWARE PROJECT MANAGEMENT 84

 o Early Finish (EF) of D = ES of D + Duration of D = 13 + 7 = 20
o Late Finish (LF) of D: Task E (successor) has an Early Start of 23 (because it
depends on C, which finishes at 23). For D not to delay E, D must finish by 23.
So, LF of D = 23.
o Late Start (LS) of D = LF of D - Duration of D = 23 - 7 = 16
o Total Float for D = LF - EF = 23 - 20 = 3 Days (or LS - ES = 16 - 13 = 3 Days).
This means Task D can be delayed by up to 3 days without impacting the overall
project completion date.
o Free Float for D: Task D's early finish is 20. Its successor E can start at 23. So,
D can be delayed by 3 days without delaying the early start of E. Free Float for
D = 3 Days.
Leveling Resource Assignments
Resource Leveling is a critical technique in project scheduling used to optimize the allocation
of resources and address situations where resources are either over-allocated (required beyond
their availability) or under-allocated (idle). The primary goal is to smooth out peaks and valleys
in resource demand, ensuring a more consistent and sustainable workload for the project team
and other resources.
• Purpose:
o Avoid Over-allocation: Prevents situations where a resource (e.g., a specific
developer, a testing environment) is assigned to more work than they can
realistically complete within a given period, leading to burnout, missed
deadlines, and reduced quality.
o Avoid Under-allocation: Maximizes resource utilization by identifying and
reassigning idle resources, improving efficiency.
o Balance Resource Demand: Creates a more stable and predictable workload,
which can improve team morale and productivity.
o Optimize Schedule: While it can sometimes extend the project duration, it aims
to create a more realistic and achievable schedule given resource constraints.
• Techniques and Strategies: Resource leveling typically involves adjusting the project
schedule by shifting tasks, often utilizing the float (slack) available in non-critical
activities.
o Delaying Non-Critical Tasks: The most common technique. If a resource is
over-allocated, tasks that are not on the critical path and have available float can

SOFTWARE PROJECT MANAGEMENT 85

 be delayed until the resource becomes available, without impacting the project's
overall completion date.
o Splitting Activities: In some cases, a long activity can be temporarily
interrupted and resumed later when the required resource becomes available.
While this can help with resource allocation, it often adds complexity and
overhead due to context switching.
o Changing Activity Relationships: If feasible and logical, altering
dependencies (e.g., from FS to SS with a lag) might allow for more flexible
resource allocation, but this must be done carefully to maintain logical flow.
o Adding/Removing Resources: If budget and availability allow, adding more
resources (e.g., hiring another developer, procuring another testing machine)
can alleviate over-allocation. Conversely, if resources are consistently under-
utilized, some might be removed from the project.
o Adjusting Scope/Quality: In extreme cases, if resource constraints are severe
and cannot be resolved by other means, the project scope might need to be
reduced or quality expectations adjusted, though these are typically last resorts.
o Resource Leveling Heuristics: Project management software often uses
algorithms or heuristics to perform leveling, such as:
▪ Earliest Start: Prioritizes tasks that can start earliest.
▪ Shortest Duration: Prioritizes shorter tasks to free up resources
quickly.
▪ Lowest Total Float: Prioritizes tasks with less flexibility to avoid them
becoming critical.
• Impact: Resource leveling can have a direct impact on the project schedule. While its
primary goal is to resolve resource conflicts, it can sometimes extend the project
duration if there isn't enough float in the schedule to absorb the necessary resource
shifts. This trade-off between resource utilization and schedule duration is a key
decision point for project managers. It highlights that the critical path might change
after leveling, as new resource dependencies might create a new, longer critical chain.
Map the Schedule to a Real Calendar
Once a project schedule has been developed, including activities, durations, and dependencies,
the next crucial step is to map this schedule to a real-world calendar. This involves
converting the theoretical workdays calculated in the schedule into actual calendar dates, taking

SOFTWARE PROJECT MANAGEMENT 86

into account all non-working periods. This step is vital for creating a realistic timeline,
communicating effectively with stakeholders, and ensuring accurate resource availability.
• Considerations for Calendar Mapping:
o Working Days vs. Non-Working Days: The most fundamental consideration
is identifying which days are considered working days for the project team.
Typically, this means excluding:
▪ Weekends: Saturday and Sunday are standard non-working days in
many regions.
▪ Public Holidays: National, regional, or local holidays (e.g., Christmas,
Diwali, Eid, Independence Day) that are non-working days. These must
be accurately identified for the project's geographical location.
▪ Company Holidays/Shutdowns: Specific periods when the company
is closed for business (e.g., annual company-wide vacation, maintenance
shutdowns).
o Team Member Availability: Individual team members may have planned
absences that need to be factored in:
▪ Vacations: Pre-approved leave for team members.
▪ Training: Time allocated for professional development.
▪ Sick Leave: While unpredictable, extended absences might need
contingency planning.
▪ Part-time Work: If resources are not 100% dedicated to the project.
o Resource Calendars: In sophisticated project management software,
individual resource calendars can be created to reflect the specific working
hours, shifts, and non-working periods of each team member or resource. This
allows for highly accurate scheduling based on individual availability.
o Global Teams: For projects with distributed teams across different time zones
and countries, mapping to a real calendar becomes even more complex.
Different regions will have different public holidays and potentially different
working weeks. The schedule must account for these variations to ensure
realistic collaboration and delivery dates.
o Shift Work: If the project involves teams working in shifts (e.g., 24/7
operations or follow-the-sun development), the calendar must accurately reflect
these patterns.

SOFTWARE PROJECT MANAGEMENT 87

 • Process:
o Define Project Calendar: In project management software (like Microsoft
Project, Jira, Asana, Smartsheet), a project calendar is typically set up first. This
defines the standard working days and hours for the entire project, along with
any global holidays.
o Define Resource Calendars: For individual resources or groups, specific
calendars are created to override the project calendar where necessary (e.g., a
developer's vacation days).
o Software Automation: Modern project management software automates the
process of calculating actual dates. When you input an activity duration (e.g.,
"5 days"), the software will automatically skip weekends and holidays defined
in the calendar to determine the actual end date.
o Manual Mapping: While less common for large projects, for smaller projects,
one might manually count working days on a physical calendar, skipping non-
working days, to plot tasks and milestones.
• Importance: Accurate calendar mapping is crucial for:
o Realistic Expectations: Provides a clear and defensible completion date for
stakeholders.
o Effective Communication: Allows for precise communication of deadlines
and milestones to all involved parties.
o Resource Planning: Ensures that resources are scheduled only when they are
actually available.
o Contractual Obligations: Critical for meeting contractual delivery dates.
Critical Chain Scheduling
Critical Chain Scheduling (CCS) is an advanced project management methodology
developed by Dr. Eliyahu M. Goldratt, rooted in his Theory of Constraints (TOC). Unlike
traditional Critical Path Method (CPM) which focuses solely on logical dependencies, CCS
focuses on managing project buffers to protect the project schedule from the inherent
uncertainties and human behaviors that often cause delays. Its aim is to deliver projects faster
and more reliably by focusing management attention on the true constraints.
• Core Idea (Theory of Constraints Application): Goldratt's TOC posits that every
system has at least one constraint that limits its performance. In project management,
this constraint is often the critical chain. CCS challenges the traditional practice of

SOFTWARE PROJECT MANAGEMENT 88

 adding "safety time" to individual tasks by removing this individual padding and
aggregating it into strategically placed "buffers" at the project level. This approach aims
to counteract common human behaviors like "Parkinson's Law" (work expands to fill
the time available) and "Student Syndrome" (procrastinating until the last minute).
• Key Concepts:
o Critical Chain: This is the longest path of dependent tasks in a project,
considering both logical dependencies (e.g., Task A must finish before Task B
starts) and resource dependencies (e.g., Task X needs Resource Y, but
Resource Y is busy on Task Z). The critical chain is often shorter than the CPM
critical path because it optimizes for resource availability and removes
individual task buffers. It represents the absolute minimum time a project can
take given resource constraints.
o Project Buffer: A block of time placed at the very end of the critical chain, just
before the project completion date. Its purpose is to protect the overall project
completion date from delays that might occur on the critical chain. It's a shared
pool of safety time for the entire project.
o Feeding Buffers: Blocks of time strategically placed at the end of non-critical
paths that "feed into" or merge with the critical chain. Their purpose is to protect
the critical chain from delays that might occur on these feeding paths. If a
feeding path runs late, it consumes its feeding buffer, but ideally, it doesn't
impact the critical chain.
o Resource Buffers: These are not time buffers but rather strategic signals or
alerts. They are placed just before critical chain tasks that require a specific,
constrained resource. Their purpose is to ensure that the resource is ready and
available to start the critical chain task immediately when the predecessor task
finishes, preventing delays due to resource unavailability.
• Focus: The primary focus in CCS shifts from managing individual task durations to
managing the buffers. Project managers monitor the consumption rate of these
buffers. When a buffer starts to deplete rapidly, it signals a need for immediate attention
and intervention, indicating that the critical chain or a feeding path is falling behind
schedule. This "buffer management" provides an early warning system.
• Benefits of Critical Chain Scheduling:

SOFTWARE PROJECT MANAGEMENT 89

 o Shorter, More Reliable Schedules: By removing individual task padding and
pooling safety time into buffers, CCS often leads to overall shorter project
durations that are also more likely to be met.
o Improved Focus: Management attention is directed towards the true
constraints (the critical chain and its buffers), rather than micromanaging every
task.
o Reduced Procrastination: By removing individual safety time, team members
are encouraged to complete tasks as quickly as possible, passing work to the
next person without delay.
o Better Resource Utilization: By explicitly considering resource constraints,
CCS helps create more realistic and achievable resource loaded schedules.
o Enhanced Team Collaboration: Encourages a "get it done and pass it on"
mentality, fostering better flow and collaboration.

QUESTION BANK

Choose the Best Answer

1. Project resource activities primarily involve:
a) Hiring and allocating resources to project tasks
b) Only budgeting
c) Software coding
d) Marketing of the project
Answer: a) Hiring and allocating resources to project tasks
2. A project organizational structure defines:
a) Reporting relationships and authority
b) Task execution time
c) Software design patterns
d) Financial estimations
Answer: a) Reporting relationships and authority
3. Software development dependencies are:
a) Relationships between tasks that determine sequence of execution
b) Financial constraints
c) Hardware requirements
d) Team communication tools
Answer: a) Relationships between tasks that determine sequence of execution
4. Brainstorming in project management is used for:
a) Cost estimation
b) Idea generation and problem solving
c) Scheduling only
d) Monitoring progress
Answer: b) Idea generation and problem solving

SOFTWARE PROJECT MANAGEMENT 90

 5. Scheduling fundamentals include:
a) Task identification
b) Task sequencing
c) Estimating duration
d) All of the above
Answer: d) All of the above
6. PERT stands for:
a) Program Evaluation and Review Technique
b) Project Evaluation and Review Timeline
c) Performance Estimation Resource Tool
d) Project Execution and Resource Timing
Answer: a) Program Evaluation and Review Technique
7. CPM stands for:
a) Critical Path Method
b) Cost Planning Method
c) Coded Project Management
d) Calendar Planning Model
Answer: a) Critical Path Method
8. Resource leveling aims to:
a) Minimize resource conflicts and overallocation
b) Increase project duration
c) Reduce number of tasks
d) Skip critical tasks
Answer: a) Minimize resource conflicts and overallocation
9. Mapping a project schedule to a real calendar helps to:
a) Allocate resources effectively
b) Identify holidays, weekends, and realistic start/end dates
c) Reduce project scope
d) Improve software quality
Answer: b) Identify holidays, weekends, and realistic start/end dates
10. Critical chain scheduling focuses on:
a) Task cost optimization
b) Accounting for resource dependencies and buffer management
c) Creating a WBS
d) Estimating software size
Answer: b) Accounting for resource dependencies and buffer management

Important 7-Mark Questions

1. Explain Project Management Resource Activities with examples.
2. Describe Organizational Forms and Structure in software projects.
3. Explain Software Development Dependencies with suitable examples.
4. Write short notes on Brainstorming techniques in project planning.
5. Discuss Scheduling Fundamentals in project management.
6. Explain PERT and CPM techniques with a small example network.
7. Write notes on Resource Leveling and mapping schedules to real calendars.

SOFTWARE PROJECT MANAGEMENT 91

Important 10-Mark Questions
1. Explain in detail Project Resource Activities and their significance in software
project management.
2. Discuss the different Project Organizational Forms and Structures and their
impact on project execution.
3. Explain Software Development Dependencies and how they affect scheduling.
4. Explain PERT and CPM techniques with diagram, and calculate critical path for a
sample project.
5. Explain Resource Leveling techniques and give an example.
6. Discuss Critical Chain Scheduling and how it differs from traditional CPM.
7. Explain Mapping the Schedule to a Real Calendar with an example including
holidays and working days.
8. Compare PERT, CPM, and Critical Chain Scheduling in terms of objectives and
resource management.

SOFTWARE PROJECT MANAGEMENT 92

 UNIT-V
V. Quality: Requirements, The SEI CMM, Guidelines, Challenges, Quality Function
Deployment, Building the Software Quality Assurance Plan, Software Configuration
Management: Principles, Requirements, Planning and Organizing, Tools, Benefits, Legal
Issues in Software, Case Study
Quality: Requirements
Software Quality is a multifaceted concept that refers to the degree to which a software
system, component, or process fulfills its specified requirements and satisfies the implicit or
explicit needs and expectations of its customers or users. It's not merely about the absence of
bugs, but about the overall fitness for purpose, usability, reliability, and maintainability of the
software. High-quality software provides tangible business value and enhances user
satisfaction.
• Quality Requirements (Non-Functional Requirements - NFRs): These are specific
statements that define the quality attributes the software must possess. Unlike
functional requirements (which describe what the system does), quality requirements
describe how well the system performs its functions. They are crucial because they set
measurable criteria for testing, validation, and ultimately, user acceptance.
• Key Attributes of Quality (based on ISO/IEC 25010:2011 - Systems and software
engineering — Systems and software Quality Requirements and Evaluation
(SQuaRE) — System and software quality models):
o Functional Suitability: The degree to which a product or system provides
functions that meet stated and implied needs when used under specified
conditions.
▪ Completeness: All specified functions are implemented.
▪ Correctness: Functions produce the correct results.
▪ Appropriateness: Functions are suitable for the intended purpose.
o Performance Efficiency: The performance relative to the amount of resources
used under stated conditions.
▪ Time Behavior: Response time, throughput, and processing time. (e.g.,
"The system shall respond to user queries within 2 seconds for 95% of
requests.")

SOFTWARE PROJECT MANAGEMENT 93

 ▪ Resource Utilization: The amount and types of resources used. (e.g.,
"The application shall not consume more than 500MB of RAM during
peak usage.")
▪ Capacity: The maximum limits of the product parameter. (e.g., "The
system shall support 10,000 concurrent users.")
o Compatibility: The degree to which a product, system or component can
exchange information with other products, systems or components, and/or
perform its required functions while sharing the same hardware or software
environment.
▪ Co-existence: Ability to co-exist with other software on a shared
resource.
▪ Interoperability: Ability to interact and exchange data with other
systems. (e.g., "The e-commerce platform shall seamlessly integrate
with PayPal's API.")
o Usability: The degree to which a product or system can be used by specified
users to achieve specified goals with effectiveness, efficiency and satisfaction
in a specified context of use.
▪ Learnability: Ease with which users can learn to use the system.
▪ Operability: Ease of operating and controlling the system.
▪ User Error Protection: Protection against user mistakes. (e.g., "The
system shall prevent users from submitting incomplete forms.")
▪ User Interface Aesthetics: Attractiveness of the user interface.
▪ Accessibility: Ease of use for people with disabilities.
o Reliability: The degree to which a system, product or component performs
specified functions under specified conditions for a specified period of time.
▪ Maturity: The degree to which a system or component meets the needs
for reliability under normal operation.
▪ Availability: The degree to which a system or component is operational
and accessible when required for use. (e.g., "The system shall have
99.9% uptime.")
▪ Fault Tolerance: The degree to which a system or component can
operate correctly in the presence of hardware or software faults.

SOFTWARE PROJECT MANAGEMENT 94

 ▪ Recoverability: The degree to which, in the event of an interruption or
failure, the product or system can re-establish a specified level of
performance and recover the directly affected data. (e.g., "The system
shall fully recover from a power outage within 15 minutes with no data
loss.")
o Security: The degree to which a product or system protects information and
data so that persons or other products or systems have the degree of data access
appropriate to their types and levels of authorization.
▪ Confidentiality: Protection against unauthorized access to information.
▪ Integrity: Protection against unauthorized modification of information.
▪ Non-repudiation: Ability to prove that an action or event has occurred.
▪ Accountability: Ability to trace actions to specific entities.
▪ Authenticity: Verification of identity. (e.g., "User passwords shall be
hashed and salted.")
o Maintainability: The degree to which a product or system can be effectively
and efficiently modified by the intended maintainers.
▪ Modularity: The degree to which a system or computer program is
composed of discrete components such that a change to one component
has minimal impact on other components.
▪ Reusability: The degree to which a component can be used in more than
one system or in building other components.
▪ Analyzability: The ease with which a defect or cause of failure can be
diagnosed.
▪ Modifiability: The ease with which a product or system can be modified
without introducing defects or degrading product performance.
▪ Testability: The ease with which a product or system can be tested to
ensure it meets requirements.
o Portability: The degree to which a product or system can be effectively and
efficiently transferred from one hardware, software or other operational or
usage environment to another.
▪ Adaptability: The degree to which a product or system can be adapted
for different specified environments without needing to change the core
code.

SOFTWARE PROJECT MANAGEMENT 95

 ▪ Installability: The ease with which a product or system can be installed
in a specified environment.
▪ Replaceability: The degree to which a product can replace another
specified product for the same purpose in the same environment.
• Importance of Clear Quality Requirements: Defining quality requirements precisely
and measurably from the outset is paramount. They provide objective criteria for testing
and validation, ensuring that the developed software not only performs its intended
functions but also meets the expected levels of performance, reliability, security, and
usability. Without clear quality requirements, "quality" becomes subjective and
difficult to achieve or prove, leading to potential rework, user dissatisfaction, and
project failure.
The SEI CMM (in Quality Context)
As extensively discussed in Section III, the SEI CMM (Capability Maturity Model) is a
powerful framework for process improvement. In the specific context of software quality, the
CMM plays a pivotal role. Higher CMM maturity levels directly correlate with an
organization's ability to consistently produce higher quality software. This is because achieving
a higher maturity level signifies that an organization has:
• More Disciplined Processes: Moving from Level 1 (Initial) to Level 2 (Repeatable)
establishes basic project management and quality assurance processes, leading to more
consistent outcomes.
• Predictable Outcomes: At Level 3 (Defined), processes are standardized and
documented across the organization, making software development more predictable
in terms of quality, schedule, and cost.
• Quantitative Control: Level 4 (Managed) introduces quantitative measures for
process and product quality, allowing for statistical control and objective assessment of
quality targets. This means organizations can set measurable quality goals (e.g., "defect
density of less than 0.1 defects per KLOC") and track their progress.
• Continuous Improvement: At Level 5 (Optimizing), organizations actively seek to
continuously improve their processes based on quantitative feedback and innovative
practices, leading to sustained high levels of quality and efficiency.
In essence, the CMM provides a roadmap for building a robust quality infrastructure within an
organization. It helps embed quality into every stage of the software development lifecycle,
moving from reactive defect detection to proactive defect prevention. The successor, CMMI,

SOFTWARE PROJECT MANAGEMENT 96

further integrates quality practices across various organizational functions, reinforcing this
holistic approach to quality.
Guidelines (for Quality)
Beyond formal models like CMM, a set of general principles and practical guidelines help
promote and embed software quality throughout the entire development lifecycle. These
guidelines represent best practices that, when consistently applied, significantly enhance the
likelihood of delivering high-quality software.
• Adherence to Standards: Following established industry standards (e.g., ISO 9001 for
quality management systems, IEEE standards for documentation, coding guidelines
like MISRA C for embedded systems) ensures consistency, interoperability, and often,
higher quality. Internal organizational standards for design, coding, and testing are
equally important.
• Early Defect Detection ("Shift Left"): This is a crucial principle. The cost of fixing a
defect increases exponentially the later it is found in the development lifecycle.
Therefore, implementing quality activities as early as possible (shifting quality
activities "left" on the timeline) is paramount.
o Examples: Thorough requirements reviews, design inspections, architectural
reviews, and static code analysis tools applied during coding.
• Peer Reviews/Inspections: Formal or informal reviews of work products (code,
designs, test plans, documentation) by peers are highly effective at identifying errors
early.
o Code Reviews: Developers review each other's code for bugs, adherence to
standards, and maintainability.
o Design Reviews: Architects and senior developers review design documents
for completeness, correctness, and feasibility.
• Comprehensive Testing: Employing various levels and types of testing throughout the
development process is essential.
o Unit Testing: Testing individual components or modules in isolation.
o Integration Testing: Testing the interfaces and interactions between integrated
modules.
o System Testing: Testing the complete, integrated system against specified
requirements.

SOFTWARE PROJECT MANAGEMENT 97

 o Acceptance Testing: User Acceptance Testing (UAT) by end-users or clients
to ensure the system meets business needs.
o Non-Functional Testing: Performance testing (load, stress), security testing,
usability testing, compatibility testing, etc.
o Automated Testing: Implementing automated test suites for regression testing,
allowing for frequent and rapid verification of changes.
• Traceability: Maintaining clear, bidirectional links between requirements, design
elements, code modules, and test cases. This ensures that every requirement is
addressed in the design and code, and that every piece of code can be traced back to a
requirement, and crucially, that every requirement is tested. This helps ensure
completeness and verifies that the right system is being built.
• Continuous Improvement: Quality assurance is not a one-time activity but an ongoing
process. Regularly reviewing processes, collecting quality metrics (e.g., defect density,
test coverage, mean time to repair), analyzing root causes of defects, and implementing
process improvements based on these insights. This aligns with the "Optimizing" level
of CMM.
• Customer Focus: Understanding and prioritizing customer needs, expectations, and
feedback throughout the project lifecycle. This involves active engagement with users,
gathering feedback, and ensuring the final product truly solves their problems and
provides value.
• Static Code Analysis: Using automated tools to analyze source code without executing
it, identifying potential bugs, coding standard violations, security vulnerabilities, and
code smells.
• Continuous Integration (CI): Regularly merging code changes into a central
repository, followed by automated builds and tests. This helps detect integration issues
early and maintains a healthy codebase.
• Pair Programming: Two developers working together at one workstation, with one
writing code and the other reviewing it in real-time. This can lead to higher code quality
and knowledge transfer.
Challenges (in Quality)
Despite the best intentions and adherence to guidelines, achieving high software quality is often
fraught with challenges. These obstacles can arise from various sources, including project
dynamics, organizational culture, technical complexities, and resource limitations.

SOFTWARE PROJECT MANAGEMENT 98

• Changing and Ambiguous Requirements: This is arguably the biggest challenge.
Requirements frequently evolve throughout the project, making it difficult to stabilize
the scope, design, and test adequately. Ambiguous requirements lead to
misinterpretations and defects.
• Time and Budget Pressure: Projects are often under immense pressure to deliver
quickly and cheaply. This can lead to shortcuts in quality activities (e.g., skipping
thorough testing, neglecting code reviews, deferring defect fixes), ultimately
compromising quality for speed.
• Lack of Skilled Resources: Insufficiently trained or experienced QA personnel,
developers unfamiliar with quality practices, or a general shortage of skilled labor can
severely impact the ability to deliver high-quality software.
• Poor Communication: Misunderstandings between stakeholders, developers, testers,
and other team members are a common source of defects and quality issues. Ineffective
communication can lead to misaligned expectations and incorrect implementations.
• Complexity of Software: Modern software systems are inherently complex, involving
multiple integrated components, diverse technologies, and intricate business logic. This
complexity makes it challenging to design, develop, test comprehensively, and ensure
overall quality.
• Legacy Systems and Technical Debt: Integrating with or migrating from older, poorly
documented, or spaghetti-code legacy systems can introduce significant quality
challenges. Accumulating technical debt (choosing easy but suboptimal solutions for
short-term gains) can make future development and maintenance difficult and costly,
impacting long-term quality.
• Lack of Automation: Over-reliance on manual testing can be slow, error-prone,
expensive, and difficult to scale. Without sufficient test automation, regression testing
becomes a bottleneck, and quality assurance efforts can lag behind development.
• Insufficient Tooling and Infrastructure: A lack of appropriate tools for requirements
management, defect tracking, test automation, performance monitoring, or
configuration management can hinder quality efforts. Inadequate development and
testing environments also pose challenges.
• Lack of Quality Culture: If an organization doesn't genuinely value quality, or if
quality is seen solely as the responsibility of the QA team rather than a shared

SOFTWARE PROJECT MANAGEMENT 99

 responsibility, it becomes difficult to embed quality practices across the entire
development lifecycle.
• Security Vulnerabilities: With increasing cyber threats, ensuring software security is
a paramount and complex quality challenge, requiring specialized knowledge and
continuous vigilance.
• Performance Bottlenecks: Ensuring that the software performs efficiently under
expected load and response times can be challenging, especially for high-traffic or real-
time systems.
Quality Function Deployment (QFD)
Quality Function Deployment (QFD) is a powerful, structured methodology that
systematically translates customer requirements (often referred to as the "Voice of the
Customer") into technical requirements for every stage of product development and production.
Originating in Japan, QFD aims to ensure that customer needs are consistently understood,
prioritized, and addressed throughout the entire product lifecycle, from initial concept to final
delivery.
• Purpose: The core purpose of QFD is to bridge the gap between abstract customer
desires and concrete technical specifications. It helps teams:
o Understand Customer Needs: Deeply analyze what customers truly want and
prioritize those needs.
o Translate Needs: Convert qualitative customer desires into measurable
technical characteristics.
o Prioritize: Identify which technical characteristics are most critical to satisfy
high-priority customer needs.
o Foster Cross-Functional Collaboration: Encourage communication and
alignment between different departments (e.g., marketing, engineering,
manufacturing, quality assurance) involved in product development.
o Reduce Design Changes: By getting it right the first time, QFD helps minimize
costly rework and design iterations later in the process.
• "House of Quality": The primary tool used in QFD is the House of Quality (HoQ).
It's a series of interconnected matrices that graphically represent the relationships
between various elements of product development. It gets its name from its roof-like
shape.
o Components of the House of Quality (Conceptual and Detailed):

SOFTWARE PROJECT MANAGEMENT 100

1. Customer Requirements (WHATs): Located on the left side of the
"house." These are the voice of the customer – what the customer wants
or expects from the product/software. They are usually qualitative
statements (e.g., "easy to use," "fast response," "secure data"). These are
often weighted by their importance to the customer.
2. Technical Requirements (HOWs): Located across the top of the
"house." These are the measurable, actionable technical characteristics
or design attributes that the development team can control to satisfy the
customer's WHATs. (e.g., "average response time < 2 seconds,"
"number of clicks to complete task," "encryption algorithm strength").
3. Relationship Matrix (Central Room): This is the main body of the
house. It shows the strength of the relationship between each Customer
Requirement (WHAT) and each Technical Requirement (HOW).
Symbols (e.g., strong, medium, weak, no relationship) are used to
indicate the degree to which a technical characteristic influences a
customer need. This helps identify which technical aspects are most
critical for satisfying key customer desires.
4. Correlation Matrix (Roof): The "roof" of the house. This triangular
matrix shows the interrelationships or correlations between the
Technical Requirements (HOWs) themselves. It identifies if improving
one technical characteristic positively or negatively impacts another.
(e.g., "Increasing security measures" might have a negative correlation
with "response time" if it adds overhead). This helps identify potential
design conflicts or synergies.
5. Competitive Analysis (Right Side): This section compares the
organization's current product or proposed design (and potentially
competitors' products) against the customer requirements. It helps
identify areas where the product excels or falls short in meeting
customer needs compared to the competition.
6. Target Values/Prioritized Technical Requirements (Bottom): This
section, at the "bottom" of the house, translates the technical
requirements into specific, measurable target values. It also prioritizes
the technical requirements based on their importance to customer needs

SOFTWARE PROJECT MANAGEMENT 101

 and their relationship strengths. This guides the engineering and
development efforts.
• Benefits of QFD:
o Improved Customer Satisfaction: By systematically focusing on customer
needs, QFD helps ensure the final product truly meets expectations.
o Reduced Design Changes and Rework: Getting requirements and design right
early in the process minimizes costly changes and rework in later stages.
o Shorter Development Cycles: Reduced rework and clearer direction can lead
to faster time-to-market.
o Better Communication and Collaboration: The structured nature of QFD
forces cross-functional teams to communicate and align on priorities and
technical solutions.
o Documented Decision-Making: The House of Quality serves as a clear record
of design decisions and their rationale, linking them back to customer needs.
o Early Problem Identification: Potential conflicts between technical
requirements are identified early in the design phase.
Building the Software Quality Assurance Plan
A Software Quality Assurance (SQA) Plan is a formal document that outlines the activities,
responsibilities, and resources required to ensure that a software product meets its specified
quality requirements throughout its development lifecycle. It's a critical component of overall
project planning, providing a roadmap for embedding quality into every phase, rather than just
inspecting for it at the end.
• Purpose: The SQA Plan serves as a blueprint for how quality will be achieved and
verified. It defines the "what, who, when, and how" of quality assurance activities,
ensuring a systematic and disciplined approach to quality management. It also acts as a
communication tool for all stakeholders regarding the project's quality strategy.
• Key Components of a Comprehensive SQA Plan (often based on IEEE 730
standard):
1. Purpose and Scope: Clearly defines the objective of the SQA plan and the
specific software products or components it covers. It outlines what aspects of
quality will be addressed.
2. Reference Documents: Lists all relevant documents, standards, policies, and
procedures that the SQA plan adheres to or references (e.g., project plan,

SOFTWARE PROJECT MANAGEMENT 102

 requirements specification, design documents, organizational quality policies,
industry standards like ISO 9001, CMMI guidelines).
3. Management: Describes the organizational structure for SQA, including roles,
responsibilities, and authorities of all personnel involved in quality activities
(e.g., SQA Manager, QA Engineers, developers' quality responsibilities). It also
defines reporting lines for quality issues.
4. Documentation: Specifies the types of documents that will be produced
throughout the project (e.g., requirements, design, test plans, user manuals) and
defines their quality criteria, review processes, and approval mechanisms.
5. Standards, Practices, Conventions, and Metrics: Details the specific
standards, coding conventions, design practices, and methodologies that will be
followed to ensure quality. Crucially, it defines the quality metrics that will be
collected, analyzed, and reported (e.g., defect density, mean time to failure, test
coverage, code complexity).
6. Reviews and Audits: Outlines the schedule, scope, and procedures for various
quality reviews and audits.
▪ Technical Reviews: Peer reviews, code inspections, design reviews,
requirements reviews.
▪ Management Reviews: Progress reviews, milestone reviews.
▪ Audits: Formal checks to ensure adherence to processes and standards.
7. Test Plan: Provides an overview of the testing strategy, including:
▪ Test Levels: Unit, integration, system, acceptance testing.
▪ Test Types: Functional, performance, security, usability, regression
testing.
▪ Test Environment: Specifications for hardware and software.
▪ Test Tools: Automated testing frameworks, test management tools.
▪ Test Coverage Goals: What percentage of code or requirements should
be covered by tests.
8. Problem Reporting and Corrective Action: Defines the process for
identifying, documenting, tracking, prioritizing, and resolving defects and other
quality issues. This includes roles for problem reporting, analysis, resolution,
and verification.

SOFTWARE PROJECT MANAGEMENT 103

 9. Tools, Techniques, and Methodologies: Specifies the particular tools (e.g.,
static analysis tools, test automation tools, defect tracking systems), techniques
(e.g., root cause analysis), and methodologies (e.g., agile testing, test-driven
development) that will be employed for SQA.
10. Code Control (Configuration Management): Describes how source code and
other software artifacts will be managed, versioned, and controlled. This section
typically links directly to the Software Configuration Management (SCM) plan,
ensuring that changes are tracked and controlled to maintain quality.
11. Supplier Control: If third-party software components or services are used, this
section outlines how their quality will be ensured and monitored.
12. Training: Identifies any SQA-related training requirements for the project team
to ensure they have the necessary skills and understanding of quality processes.
13. Risk Management: Addresses how quality-related risks will be identified,
analyzed, and mitigated within the SQA context.
Software Configuration Management (SCM)
Software Configuration Management (SCM) is a disciplined and systematic approach to
controlling the evolution of complex software systems. It is the practice of tracking and
controlling changes in the software, including requirements, design, source code, test plans,
and documentation, throughout the entire software development lifecycle. SCM ensures
consistency, traceability, and integrity of the software product.
• Principles of SCM:
1. Identification: This principle involves identifying all the components that
constitute the software product, known as Configuration Items (CIs). CIs can
include source code files, build scripts, test scripts, documentation
(requirements, design, user manuals), libraries, and even development tools.
Each CI is uniquely identified and versioned.
2. Control: This is the core of SCM – managing changes to CIs through a formal,
documented change control process. This ensures that changes are authorized,
reviewed, and implemented in a controlled manner, preventing unauthorized
modifications and maintaining system integrity. A Configuration Control
Board (CCB) often oversees this process.
3. Status Accounting: This principle involves recording and reporting the status
of all CIs and changes made to them. It answers questions like: "What version

SOFTWARE PROJECT MANAGEMENT 104

 is currently deployed?", "Who made this change?", "When was this change
implemented?", and "What changes are included in the latest build?". This
provides a historical record and current snapshot of the software.
4. Audit: SCM audits are formal examinations to verify that the software product
meets its specified requirements and that the SCM process itself is being
followed correctly. This includes functional configuration audits (verifying
functionality) and physical configuration audits (verifying that the "as-built"
matches the "as-designed").
5. Version Control: This fundamental aspect of SCM involves maintaining
different versions of software components. It allows developers to track changes
over time, revert to previous stable versions if needed, and manage parallel
development efforts.
• Requirements for Effective SCM:
o Change Tracking: Ability to record every change made to every configuration
item, including who made it, when, and why.
o Concurrent Development Support: Enabling multiple developers to work on
the same codebase simultaneously without overwriting each other's work
(through branching, merging, and locking mechanisms).
o Version History and Rollback: The capability to retrieve any previous version
of a file or the entire system, and to revert to a stable baseline if problems arise.
o Branching and Merging: Support for creating separate lines of development
(branches) for new features or bug fixes, and then integrating those changes
back into the main codebase (merging).
o Traceability: Linking changes to specific requirements, defects, or tasks.
o Automated Build and Release Management: Integration with tools that can
automatically compile, test, and package the software from controlled source
code, ensuring consistent and repeatable builds.
o Baseline Management: The ability to establish baselines – formally reviewed
and agreed-upon versions of configuration items at specific points in the project
lifecycle (e.g., after requirements approval, after design completion, for a
release). Baselines serve as stable reference points.
• Planning and Organizing SCM:

SOFTWARE PROJECT MANAGEMENT 105

 o Define SCM Process: Establish clear, documented procedures for all SCM
activities, including how change requests are submitted, reviewed, approved,
implemented, and verified.
o Select SCM Tools: Choose appropriate SCM tools that align with the project's
needs, team size, and development methodology.
o Define Configuration Items: Explicitly identify what artifacts will be under
SCM control.
o Establish Baselines: Plan for when baselines will be created and what will be
included in each.
o Form a Configuration Control Board (CCB): For larger projects, a CCB
(comprising project managers, technical leads, QA, and sometimes customers)
is established to review and approve significant change requests before they are
implemented.
o Train Team: Ensure all team members are trained on the SCM tools and
processes.
• Tools for SCM:
o Version Control Systems (VCS):
▪ Git: The most popular Distributed VCS (DVCS), allowing developers
to have a full copy of the repository locally. This enables offline work,
faster operations, and robust branching/merging. Widely used with
platforms like GitHub, GitLab, Bitbucket. Common branching models
include Gitflow, GitHub Flow.
▪ SVN (Subversion): A Centralized VCS, where a single central
repository holds all versions. Developers check out files, make changes,
and commit them back.
▪ Perforce Helix Core: Another centralized VCS, often used in large
enterprises and game development due to its performance with large
binary files.
o Change Management Tools: These tools track change requests, defects, and
tasks, often integrating directly with VCS. Examples include Jira, Azure
DevOps, Bugzilla, Redmine.

SOFTWARE PROJECT MANAGEMENT 106

 o Build Automation Tools: Tools that automate the compilation, testing, and
packaging of software. Examples include Jenkins, GitLab CI/CD, Azure
Pipelines, Travis CI.
• Benefits of SCM:
o Traceability and Accountability: Provides a complete audit trail of who
changed what, when, and why, enhancing accountability.
o Reduced Errors and Conflicts: Prevents accidental overwrites, manages
concurrent changes, and reduces integration conflicts.
o Improved Collaboration: Enables multiple developers to work on the same
codebase efficiently and safely.
o Controlled and Repeatable Releases: Ensures that software releases are
consistent, reproducible, and contain only approved changes.
o Disaster Recovery: The ability to restore any previous version of the software,
providing a safety net against data loss or critical bugs.
o Enhanced Auditability: Essential for compliance with regulatory requirements
and internal quality standards.
o Better Project Visibility: Provides insights into project progress and change
activity.
Legal Issues in Software
Software development and deployment are increasingly intertwined with a complex web of
legal considerations. Ignoring these issues can lead to significant financial penalties, legal
disputes, reputational damage, and even criminal charges. Software project managers and
developers must be aware of the legal landscape impacting their work.
• Copyright:
o Protection: Copyright protects the original expression of an idea, not the idea
itself. In software, this applies to source code, object code, executable programs,
user interfaces, documentation, and even the "look and feel" of a program
(though this is more contentious).
o Automatic Protection: Copyright protection is generally automatic upon
creation of the original work; registration is not required but offers additional
legal benefits (e.g., ability to sue for infringement, statutory damages).

SOFTWARE PROJECT MANAGEMENT 107

 o Implications: Developers cannot copy, distribute, or create derivative works
from copyrighted software without permission from the copyright holder, unless
fair use or other exceptions apply.
• Patents:
o Protection: Patents protect inventions – new, useful, and non-obvious
processes, machines, manufactures, or compositions of matter. In software, this
can apply to novel algorithms, business methods implemented in software, or
specific functionalities.
o Requirement: Unlike copyright, patent protection is not automatic. It requires
a formal application process with a patent office and grants the patent holder
exclusive rights to make, use, sell, and import the invention for a limited period
(typically 20 years).
o Implications: Software developers must be careful not to infringe on existing
software patents, which can be a complex area due to the abstract nature of some
software patents.
• Trade Secrets:
o Protection: Trade secrets protect confidential business information that
provides a competitive edge to a company. This can include proprietary
algorithms, source code, customer lists, manufacturing processes, or marketing
strategies, provided they are kept secret and reasonable efforts are made to
maintain their secrecy.
o Duration: Trade secret protection lasts indefinitely as long as the information
remains secret.
o Implications: Companies must implement strict measures to protect their trade
secrets (e.g., non-disclosure agreements, access controls). Misappropriation of
trade secrets can lead to severe legal consequences.
• Licensing:
o Definition: Software licenses are legal instruments that govern the use,
distribution, and modification of software. They define the rights and
restrictions placed on the end-user or licensee by the software owner.
o Proprietary Licenses: These are typically used for commercial software and
restrict use, modification, and distribution. Users usually purchase a license to
use the software under specific terms.

SOFTWARE PROJECT MANAGEMENT 108

 o Open Source Licenses: These licenses grant users broad rights to use, modify,
and distribute the software, often with certain conditions. Common examples
include:
▪ MIT License: Very permissive, allows almost any use.
▪ GNU General Public License (GPL): A "copyleft" license, requiring
derivative works to also be open source under the GPL.
▪ Apache License: Permissive, allows proprietary derivative works.
o Implications: Developers must understand the implications of different
licenses, especially when incorporating third-party libraries or components, to
avoid license violations.
• End-User License Agreements (EULAs):
o Definition: EULAs are contracts between the software developer/publisher and
the end-user. They are typically presented during software installation and
require the user's acceptance before they can use the software.
o Content: EULAs define the terms of use, limitations of liability, warranties,
restrictions on reverse engineering, and other legal aspects.
o Implications: Users are bound by these terms, and developers rely on them to
protect their intellectual property and limit their liability.
• Data Privacy (e.g., GDPR, CCPA):
o Regulations: A growing body of laws governs the collection, storage,
processing, and sharing of personal data. Prominent examples include the
General Data Protection Regulation (GDPR) in the EU, the California
Consumer Privacy Act (CCPA) in the US, and similar laws globally.
o Implications: Software systems that handle personal data must be designed and
developed with "privacy by design" principles. Companies must ensure
compliance with these regulations regarding data consent, data security, data
subject rights (e.g., right to access, right to be forgotten), and data breach
notification. Non-compliance can result in massive fines.
• Cybersecurity Laws:
o Regulations: Laws and regulations related to protecting data and systems from
cyber threats, mandating certain security practices for software and data.

SOFTWARE PROJECT MANAGEMENT 109

 o Implications: Software must be developed with security in mind (Secure
Software Development Lifecycle - SSDLC). Companies may be legally liable
for data breaches if they fail to implement reasonable security measures.
• Accessibility Laws (e.g., ADA, WCAG):
o Regulations: Laws (like the Americans with Disabilities Act - ADA in the US)
and guidelines (like Web Content Accessibility Guidelines - WCAG) mandate
that software and web content be accessible to individuals with disabilities.
o Implications: Software must be designed and developed to be usable by people
with visual, auditory, motor, or cognitive impairments (e.g., screen reader
compatibility, keyboard navigation). Non-compliance can lead to lawsuits.
• Service Level Agreements (SLAs):
o Definition: Contracts between a service provider and a customer that define the
level of service expected. In software, this often relates to uptime, performance,
and support response times for SaaS applications or managed services.
o Implications: Failure to meet agreed-upon SLAs can result in penalties or
compensation to the customer.
• End-of-Life (EOL) Policies:
o Definition: Policies that define when a software product or version will no
longer be supported, maintained, or updated.
o Implications: Clear EOL policies are important for customer planning and
managing technical debt within the organization.
• Importance of Legal Counsel: Given the complexity and evolving nature of software
law, organizations should always consult with legal counsel specializing in intellectual
property, data privacy, and technology law to ensure compliance and mitigate risks.
Case Study
A Case Study in the context of this syllabus would involve analyzing a real-world or
hypothetical software project to illustrate the practical application of the project management,
quality assurance, and software configuration management principles discussed. It serves to
bridge the gap between theoretical knowledge and practical implementation, highlighting
successes, challenges, and lessons learned.
• Example Scenario: Development of a New Enterprise Resource Planning (ERP)
Module

SOFTWARE PROJECT MANAGEMENT 110

o Project Context: A large manufacturing company decides to develop a new
custom module for its existing ERP system to manage supply chain logistics
more efficiently. The project is complex, involves integration with various
existing systems, and has high stakes for business operations.
o Focus Areas for the Case Study:
▪ Size Estimation:
▪ Initial Phase: The project team used Function Points to
estimate the size, breaking down the module into EIs (e.g., "New
Supplier Registration Form"), EOs (e.g., "Daily Inventory
Report"), ILFs (e.g., "Supplier Database"), etc. They estimated
an initial 800 Unadjusted Function Points.
▪ Adjustment: A detailed assessment of the 14 General System
Characteristics (GSCs) resulted in a TDI of 40, leading to a VAF
of 0.65+(0.01times40)=1.05. Adjusted FP = 800times1.05=840
FP. This was then converted to estimated KLOC for COCOMO
II.
▪ Cost Estimation and Effort:
▪ The team used COCOMO II's Early Design Model based on
the Function Point estimate. They also applied expert judgment
from senior architects and used analogous estimating by
comparing it to a previous ERP module development.
▪ Contingency Reserve: Based on identified risks (e.g.,
integration complexity), a 15% contingency reserve was added
to the initial cost estimate.
▪ Organizational Structure and Roles:
▪ The project operated within a Strong Matrix Organization.
The Project Manager had significant authority, but developers
and QA engineers still reported to their respective functional
managers for career development and technical standards. This
led to initial challenges with resource contention but was
mitigated by clear RACI charts and a dedicated Project
Management Office (PMO) support.

SOFTWARE PROJECT MANAGEMENT 111

 ▪ Key roles included Project Manager, Solution Architect,
Business Analysts (dedicated to logistics domain), Senior
Developers, QA Lead, DevOps Engineer, and a Data Migration
Specialist.
▪ Software Development Dependencies and Scheduling
(PERT/CPM):
▪ The project team used a CPM approach to build the schedule.
They identified critical mandatory dependencies (e.g., "Database
Schema Finalization" (FS) "Backend API Development") and
discretionary dependencies (e.g., "Peer Review of API Design"
(FS) "API Implementation").
▪ Critical Path Identification: The critical path was identified as:
Requirements -> Architecture Design -> Database Design ->
Core Backend Development -> Integration Testing -> User
Acceptance Testing. Any delay in these tasks directly impacted
the project completion.
▪ Resource Leveling: During scheduling, they encountered over-
allocation of the "Integration Specialist" resource. They used
resource leveling by delaying some non-critical reporting
module development tasks (which had 5 days of float) to free up
the specialist, extending the overall project by 3 days but
preventing burnout.
▪ Critical Chain Scheduling Considerations: While not fully
implemented, the team considered CCS principles by identifying
potential resource bottlenecks (e.g., the ERP system's core
development team) and planning for small "feeding buffers"
before their involvement in the integration phase.
▪ Quality Assurance Plan:
▪ The SQA Plan outlined a "shift-left" strategy. Requirements
Reviews (early defect detection) were mandatory. Static Code
Analysis was integrated into the CI/CD pipeline.
▪ Testing Strategy: Unit tests were written by developers,
followed by integration tests by QA, and a dedicated

SOFTWARE PROJECT MANAGEMENT 112

 performance testing phase was included due to the module's high
transaction volume. User Acceptance Testing (UAT) was
conducted by key business users.
▪ Metrics: Defect density per module and test coverage were
tracked weekly.
▪ Software Configuration Management (SCM):
▪ Tooling: Git (with a Gitflow branching model) was used for
version control. Jira was the change management tool, integrated
with GitLab CI/CD for automated builds and deployments.
▪ Baselines: Baselines were established at the end of each major
phase (e.g., "Requirements Baseline," "Design Baseline," "Beta
Release Baseline"). A Configuration Control Board (CCB) met
bi-weekly to review and approve all significant change requests
to baselined artifacts.
▪ Benefits Realized: SCM ensured traceability of all changes,
allowed multiple teams to work concurrently on different
features, and enabled quick rollbacks to stable versions when
issues arose during integration.
▪ Legal Issues:
▪ Licensing: The team had to carefully review the licenses of
several third-party open-source libraries used for data processing
to ensure compatibility with the company's internal policies and
avoid "copyleft" obligations for the proprietary ERP module.
▪ Data Privacy: As the module handled sensitive supply chain
data, strict adherence to regional data privacy laws (e.g., GDPR-
like regulations for international suppliers) was paramount. Data
encryption at rest and in transit was a key requirement.
▪ Vendor Contracts: Legal review of contracts with external
consultants and the existing ERP vendor for integration support
was crucial.
o Challenges & Lessons Learned:
▪ Integration Complexity: Integrating with the legacy ERP system
proved more challenging than anticipated, leading to initial schedule

SOFTWARE PROJECT MANAGEMENT 113

 delays and requiring additional effort for API development and data
mapping. Lesson: Allocate more buffer for complex integrations and
conduct thorough spike solutions early.
▪ Scope Creep: Business users initially requested many "nice-to-have"
features. The formal change control process, managed by the PM and
CCB, was critical in managing this, allowing only high-priority changes
to be incorporated into the current release. Lesson: Strong change
management is vital for scope control.
▪ Performance Bottlenecks: Initial performance tests revealed
bottlenecks in the database queries for large datasets. This required
refactoring of database schema and query optimization. Lesson:
Conduct performance testing early and continuously.
▪ Team Communication: With a distributed team (some remote, some
on-site), maintaining consistent communication was a challenge.
Implementing daily stand-ups, dedicated communication channels
(Slack), and regular video conferences helped. Lesson: Invest in
communication tools and foster a culture of transparent communication.
This case study demonstrates how the various concepts from the syllabus are interconnected
and applied in a practical project, highlighting the iterative nature of project management and
the continuous effort required to manage quality, risks, and resources effectively.

SOFTWARE PROJECT MANAGEMENT 114

 QUESTION BANK
Choose the Best Answer
1. Software Quality refers to:
a) Only absence of errors
b) Degree to which software meets requirements and user needs
c) Cost of software
d) Number of features implemented
Answer: b) Degree to which software meets requirements and user needs
2. The primary objective of SEI CMM is to:
a) Reduce software cost
b) Assess and improve software process maturity
c) Increase coding speed
d) Generate user documentation
Answer: b) Assess and improve software process maturity
3. Quality Function Deployment (QFD) is used to:
a) Test software
b) Translate customer requirements into engineering specifications
c) Manage resources
d) Estimate project cost
Answer: b) Translate customer requirements into engineering specifications
4. A Software Quality Assurance Plan includes:
a) Process descriptions
b) Roles and responsibilities
c) Standards and metrics
d) All of the above
Answer: d) All of the above
5. The main principle of Software Configuration Management (SCM) is:
a) Version control and change management
b) Writing new code without documentation
c) Ignoring defects
d) Only testing software
Answer: a) Version control and change management
6. SCM tools are used for:
a) Version control
b) Change management
c) Build and release management
d) All of the above
Answer: d) All of the above
7. Benefits of SCM include:
a) Reduced errors and rework
b) Better control of changes
c) Improved team collaboration
d) All of the above
Answer: d) All of the above
8. Legal issues in software mainly involve:
a) Intellectual property rights
b) Software licensing

SOFTWARE PROJECT MANAGEMENT 115

 c) Copyright and patent issues
d) All of the above
Answer: d) All of the above
9. A challenge in software quality is:
a) Ambiguous requirements
b) Rapid technology changes
c) Limited resources
d) All of the above
Answer: d) All of the above
10. The goal of a case study in software quality is to:
a) Demonstrate practical application of SQA and SCM principles
b) Replace documentation
c) Avoid testing
d) Reduce project cost
Answer: a) Demonstrate practical application of SQA and SCM principles

Important 7-Mark Questions

1. Explain the requirements of Software Quality and their importance.
2. Discuss SEI CMM and its role in software quality improvement.
3. Explain the challenges in maintaining software quality.
4. Write short notes on Quality Function Deployment (QFD).
5. Explain the steps involved in building a Software Quality Assurance (SQA) Plan.
6. Explain the principles and requirements of Software Configuration Management
(SCM).
7. Write short notes on tools and benefits of SCM.

Important 10-Mark Questions

1. Explain in detail the requirements and guidelines for Software Quality and discuss
key challenges.
2. Explain the SEI CMM model and how it helps in improving software process and
quality.
3. Discuss Quality Function Deployment (QFD) and its role in translating customer
requirements to technical specifications.
4. Explain how to build a Software Quality Assurance (SQA) Plan with roles,
responsibilities, metrics, and standards.
5. Explain Software Configuration Management (SCM): principles, planning,
organizing, and benefits.
6. Discuss SCM tools with examples and their importance in version and change
control.
7. Explain legal issues in software development including intellectual property,
licensing, copyright, and patents.
8. Analyze a case study demonstrating SQA and SCM practices in a software project.

SOFTWARE PROJECT MANAGEMENT 116