A quick reference note on Software Project Management

RCS7D001 Software Project Management L-T-P 3-0-0 3 CREDITS

Unit 1
Introduction to Software Project Management – Software Projects – ways of categorizing software projects
– problems with software projects – Project Life Cycle – Management – Setting objectives – Stakeholders –
Project Team – Step Wise: An overview of project planning – Project evaluation – Selection of appropriate
project approach. S/W size estimation, estimation of effort & duration. COCOMO models, Putnam’s work,
Jensen’s model, Halstead’s software Science.
Unit 2
Activity planning - project schedules - sequencing and scheduling projects - Network planning models -
AON and AOA - identifying critical activities - crashing and fast tracking, Risk management: Categories, Risk
planning, management and control - Evaluating risks to the schedule, PERT. Resource allocation - identifying
resource requirements - scheduling resources - creating critical paths - publishing schedule - cost schedules
- sequence schedule. CPM, Gantt chart, staffing, organizing a software engineering project
Unit 3
Monitoring and control – Visualizing progress, Earned value analysis – Managing people and organizing
teams – organizational structures - Planning for small projects. Case Studies, Agile Development.
Unit 4
Software quality- quality engineering, defining quality requirements, quality standards, practices &
conventions, ISO 9000, ISO 9001, Software quality matrices, managerial and organization issues, defect
prevention, reviews & audits, SEI capability maturity model, PSP, six sigma.
BOOKS:
1. B. Hughes, M. Cotterell, Rajib Mall, Software Project Management, McGraw Hill , 2015
2. R. Walker, Software Project Management, Pearson , 2003
3. R. H. Thayer, Software Engineering Project management, IEEE CS Press , 1988
4. R. Pressman, Software Engineering: A Practitioner’s approach, McGraw Hill , 2005

Digital Learning Resources: Course Name: Software Project Management Course Link:
[Link]
Course Instructor: By Prof. Rajib Mall & Prof. Durga Prasad Mohapatra

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

UNIT-I
Introduction to Software Project Management – Software Projects – ways of categorizing software projects
– problems with software projects – Project Life Cycle – Management – Setting objectives – Stakeholders –
Project Team – Step Wise: An overview of project planning – Project evaluation – Selection of appropriate
project approach. S/W size estimation, estimation of effort & duration. COCOMO models, Putnam’s work,
Jensen’s model, Halstead’s software Science.

Introduction
Software project management (SPM) is a specialized discipline within the broader field of project
management, focusing specifically on overseeing the process of developing and delivering software
solutions.
What is SPM?
SPM involves applying knowledge, skills, tools, and techniques to define, plan, execute, monitor, control,
and close out software development projects. The primary objective is to deliver high-quality software that
meets the needs and expectations of the users, on time and within budget constraints.
Key aspects of SPM
 Planning: This involves defining the project scope, goals, and requirements; estimating resources
(people, budget, time, technology); scheduling tasks and setting milestones; and developing
strategies.
 Execution: Carrying out the planned activities, coordinating teams, and managing resources
effectively.
 Monitoring and Control: Tracking progress against the plan, identifying and addressing deviations,
managing changes to the project scope and requirements, and mitigating risks.
 Risk Management: Identifying, assessing, and developing strategies to handle potential risks that
could impact the project's success.
 Quality Management: Implementing quality assurance and testing processes to ensure the software
meets defined standards and user requirements.
 Communication Management: Facilitating clear and consistent communication among team
members, stakeholders, and clients.
 Maintenance: Providing ongoing support, updates, and bug fixes after the software's initial release.

Why is SPM important?

Software development projects can be complex and involve numerous stakeholders, technologies, and
evolving requirements. Effective SPM is crucial for:
 Ensuring timely and cost-effective delivery of high-quality software.
 Managing resources efficiently.
 Enhancing collaboration and communication within the team and with stakeholders.
 Mitigating risks and addressing challenges proactively.
 Improving client satisfaction and building trust.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Software Projects
A software project is an undertaking focused on developing, maintaining, or enhancing software
applications. It involves activities such as gathering requirements, designing architecture, implementation,
and maintenance, often taking place in dispersed environments.
Here are some key characteristics and aspects of software projects:
Characteristics
 Logic and Logical Works: Software projects heavily rely on logical thought processes and structured
programming to function correctly.
 Complexity: The complexity of a software project might not be fully understood at the outset,
according to [Link]. This often requires iterative development and adjustments throughout the
project lifecycle.
 Progress Visibility: Progress might not be readily apparent until at least one module of the project is
completed, says [Link].
 Flexibility: Software projects are generally more adaptable to changes compared to other types of
projects, especially with methodologies like Agile.
 Resource Requirements and Cost: Compared to other project types, software projects might require
fewer resources and have lower associated costs.
Types of software projects
Software projects can be broadly categorized into:
 Systems Software Development: Focuses on creating software that manages and controls computer
hardware, such as operating systems, device drivers, and utilities.
 Web Development: Involves building web applications and websites, including both the front-end
(user interface) and back-end (server-side logic and databases).
 Mobile App Development: Dedicated to creating applications for mobile devices like smartphones
and tablets.
 Game Development: Focuses on creating interactive and engaging games for various platforms.
 Embedded Systems Development: Involves developing software that's integrated into hardware
devices to control their functions, such as in smart devices or medical equipment.
 API Development: Creating Application Programming Interfaces to facilitate communication
between different software applications or components.
 Data Science Projects: Utilize programming and data analysis techniques to extract insights from
data, build predictive models, and support data-driven decision making.
Challenges in software projects
Software projects face several common challenges, including:
 Unclear or Changing Requirements: Poorly defined or evolving requirements can lead to rework,
delays, and dissatisfied clients.
 Scope Creep: Uncontrolled expansion of project requirements beyond the initial plan can strain
resources and delay delivery.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Poor Communication: Lack of clear communication between teams, stakeholders, and clients can
lead to misunderstandings, missed deadlines, and quality issues.
 Risk Management: Failing to identify and mitigate risks proactively can cause significant setbacks
and impact project success.
 Inadequate Resource Allocation: Improperly managed resources can lead to delays, reduced quality,
and team burnout.
 Unrealistic Timelines: Setting unachievable deadlines can pressure teams and negatively impact the
project's quality and timeline.
 Difficulty Adapting to Change: Resistance to new processes, technologies, or directions can hinder
progress and adaptability.
 Lack of Post-Launch Support: Neglecting ongoing maintenance and support can lead to user
dissatisfaction and hurt long-term product success.
 Technical Debt: Taking shortcuts or using sub-optimal solutions can create long-term problems,
making future development and maintenance more difficult.
Importance of software projects
Software projects are crucial for:
 Developing innovative solutions to address user needs and business challenges.
 Improving efficiency and productivity in various sectors.
 Creating applications that enable automation, enhance communication, and streamline workflows.
 Driving digital transformation across industries.
 Fostering economic growth and creating new employment opportunities.
Project life cycle
The project life cycle is a structured framework that guides a project from its inception to closure. It
typically comprises five phases: initiation, planning, execution, monitoring & control, and closure. Each
phase has distinct objectives, tasks, and deliverables, ensuring a systematic and organized approach to
project management.
Phases of the project life cycle
 Initiation: This phase defines the project's purpose, scope, and objectives. It involves identifying
stakeholders, assessing project feasibility, and creating a project charter to formalize the project's
existence.
 Planning: During this phase, a detailed roadmap is created, outlining tasks, timelines, resources, and
budget. It includes developing a work breakdown structure (WBS), defining milestones, planning for
risk mitigation, and establishing communication channels.
 Execution: This phase involves carrying out the project plan, assigning tasks to team members,
managing resources, and tracking progress. It emphasizes efficient execution and adherence to the
project schedule.
 Monitoring and controlling: This phase run concurrently with the execution phase and focuses on
tracking the project's performance, identifying deviations from the plan, and making necessary
adjustments. It includes monitoring progress, managing changes, controlling risks, and reporting on
project performance.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Closure: The final phase involves concluding project activities, delivering the final product or service,
and assessing project success. It includes obtaining final acceptance from stakeholders,
documenting lessons learned, and archiving project records.
To manage and streamline software development, organizations often use structured frameworks known as
SDLC models. These models define phases and approaches to plan, design, develop, test, and deploy
software effectively. Common SDLC models include:
 Waterfall Model: A traditional, sequential model where each phase is completed before the next
one begins.
 V-shaped Model: An extension of the Waterfall model that emphasizes verification and validation at
each development stage.
 Iterative Model: Focuses on building and refining the software through repeated cycles or iterations.
 Spiral Model: Combines iterative development with systematic risk analysis and management.
 Agile Model: Emphasizes flexibility, collaboration, customer feedback, and rapid, incremental
delivery of software.
 DevOps Model: Integrates development and operations teams and practices to achieve continuous
integration and delivery.
Management
Software project management is the application of management principles to software engineering
activities. It involves planning, organizing, leading, and controlling software projects to ensure successful
delivery within defined constraints.
Key aspects of software project management
 Planning: Developing a comprehensive project plan that outlines objectives, scope, schedule,
budget, resources, and risks.
 Leading: Assembling and motivating a skilled development team, facilitating communication, and
fostering collaboration.
 Execution: Overseeing and managing the execution of project tasks, ensuring adherence to the plan
and timely completion of deliverables.
 Time management: Keeping the project on schedule, managing deadlines, and adjusting timelines
as needed.
 Budgeting: Creating and adhering to the project budget, allocating funds effectively, and monitoring
spending.
 Risk management: Identifying, analysing, and mitigating potential risks that could impact project
objectives.
 Quality assurance: Ensuring the delivered software meets quality standards through testing,
reviews, and continuous improvement.
Setting objectives
Clearly defined objectives are fundamental to successful software projects. They provide direction, align
efforts, and enable effective performance measurement.
Best practices for setting objectives
 SMART goals: Objectives should be Specific, Measurable, Achievable, Relevant, and Time-bound.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 OKR goals: Utilizing Objectives and Key Results framework helps align goals with organizational
vision and mission, measuring progress through quantifiable metrics.
 Agile goals: Embracing agile principles focuses on delivering value, adapting to change, and
incorporating customer feedback.
 Involve the team: Engaging team members in the goal-setting process fosters buy-in and ownership.
 Align with vision: Ensuring goals are aligned with the overall organizational vision and customer
needs.
 Break down goals: Decomposing large goals into smaller, manageable tasks for better tracking and
execution.
 Regular review: Regularly reviewing and updating goals to reflect changing priorities or
circumstances.
Stakeholders
Stakeholders are individuals or groups who have a vested interest in the software project and can influence
or be affected by its outcomes. Identifying and managing stakeholder expectations and needs are crucial
for project success.
Key stakeholders in software projects
 Customers: End-users who will interact directly with the software and whose needs it aims to
address.
 Users: Individuals who will directly use the software and rely on its functionalities.
 Project Sponsor: A senior-level individual who champions the project, provides resources, and offers
strategic guidance.
 Project Manager: Responsible for planning, executing, monitoring, and closing the project.
 Development Team: Comprises developers, testers, designers, and other technical roles responsible
for building the software.
 Vendors/Suppliers: External organizations that provide hardware, software components, or services
needed for the project.
 Regulatory Bodies: Government agencies or organizations that impose legal or industry regulations
on the software.
 Investors/Shareholders: Individuals or entities who have a financial interest in the project and its
success.
 Company Executives/Management: Internal stakeholders responsible for aligning the project with
organizational strategy and goals.
Stakeholder management strategies
 Identify and classify stakeholders: Understanding their roles, responsibilities, and interests.
 Define and communicate the scope: Clearly articulating the project boundaries and deliverables.
 Involve and update stakeholders: Seeking their input, providing regular updates, and incorporating
feedback.
 Manage and resolve conflicts: Addressing disagreements or conflicting priorities constructively.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Recognize and reward stakeholders: Acknowledging their contributions and fostering their
continued engagement.
 Learn and improve from stakeholders: Utilizing their feedback to enhance project processes and
outcomes.
Project team
Building a skilled and dedicated project team is paramount for successful software development. The
team's structure, dynamics, and individual member skills significantly impact the project's progress and
quality.
Key roles and responsibilities
 Project Manager: Responsible for overall project management, including planning, execution,
monitoring, and closure.
 Business Analyst (BA): Acts as a liaison between stakeholders and the technical team, gathering and
documenting requirements.
 Team Lead: Provides technical guidance and support to the development team, ensuring adherence
to coding standards and best practices.
 Developers: Design, code, and deploy software features.
 UI/UX Designer: Creates intuitive user interfaces and experiences.
 Quality Assurance (QA) Engineer: Tests the software to ensure quality, identify defects, and verify
functionality.
 DevOps Engineer: Manages and automates the software delivery process, improving deployment
speed and quality.
 Subject Matter Experts (SMEs): Provide expertise in specific domains or technical areas.
Building a successful team
 Define project needs and team structure: Consider project scope, complexity, and technology
requirements to determine the optimal team structure (generalist, specialist, or hybrid).
 Hiring the right talent: Focus on relevant experience, technical skills, and cultural fit.
 Foster continuous learning: Encourage skill development and knowledge sharing within the team.
 Provide tools and support: Ensure the team has the necessary tools, resources, and an enriching
work environment.
 Encourage proactive communication: Establish clear communication channels and promote open
feedback and collaboration.
An overview of project planning
The Step Wise planning process is a systematic approach to project planning, offering a structured
framework for managing the various stages of software development.
Steps involved in Step Wise planning
1. Identify project scope and objectives: Clearly define the project's boundaries, goals, and desired
outcomes.
2. Identify project infrastructure: Establish the organizational structure, standards, and procedures for
the project.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

3. Analyse project characteristics: Evaluate the project's type, size, complexity, and other defining
attributes.
4. Identify project products and activities: Determine the deliverables and tasks required to achieve
project objectives.
5. Estimate effort for each activity: Estimate the time, resources, and cost needed for each activity.
6. Identify activity risks: Identify potential risks associated with each activity and plan for mitigation
and contingencies.
7. Allocate resources: Assign appropriate personnel, equipment, and other resources to tasks.
8. Review and publicize the plan: Review the plan for quality and completeness, and share it with
stakeholders for feedback and agreement.
9. Execute the plan: Implement the planned activities and manage the project as it progresses.
10. Conduct lower-level planning: Refine plans as more details emerge during execution, adapting to
new information and challenges.
Project evaluation
Project evaluation is the systematic assessment of a project's performance, processes, and outcomes. It
helps measure success, identify areas for improvement, and inform future decision-making.
Methods of project evaluation
 Pre-project evaluation: Assess project proposals during intake, considering factors like feasibility,
cost analysis, risk assessment, and resource availability.
 Ongoing evaluation: Monitor project progress, efficiency, and challenges during execution, checking
KPIs, budget, and timeframe.
 Post-project evaluation: Analyse project outcomes and impacts after completion, assessing
performance, quality, and effectiveness in meeting objectives and needs.
 Self-evaluation: Individuals reflect on their work, contributions, and impact on project goals.
 External evaluation: Engaging independent organizations to provide an objective assessment of the
project.
Selection of an appropriate project approach
Choosing the right software development methodology is critical for aligning development processes with
project needs and minimizing risks.
Factors influencing methodology selection
 Project requirements and complexity: Well-defined and stable requirements may suit traditional
methods like Waterfall, while complex projects with evolving requirements benefit from Agile
methodologies.
 Team size and experience: Larger teams might find traditional methodologies with clearly defined
roles more effective, while smaller teams may thrive with Agile's collaborative approach.
 Customer involvement and feedback: Agile methodologies emphasize continuous customer
engagement and feedback, which is crucial for projects with evolving requirements.
 Time constraints and deadlines: Projects with fixed scopes and strict deadlines may align better with
traditional methods, while Agile offers flexibility for uncertain timelines.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Risk tolerance: Traditional methodologies often involve thorough planning and risk analysis upfront,
while Agile allows for incremental risk mitigation.
 Client preferences and team expertise: Considering the client's preferred methodology and the
team's familiarity with specific approaches can enhance collaboration and productivity.
 Collaboration type: Different collaboration models, such as fixed-price, dedicated team, or time and
materials, may be better suited for specific methodologies. For instance, fixed-price models align
well with Waterfall, while Agile is flexible for time and materials contracts.
 Combining methodologies (Hybrid approach): In some cases, a blend of methodologies, such as
Scrum and Waterfall, can offer a balance of structure and flexibility for projects with diverse needs.
Software project estimation: size, effort, and duration
Accurate estimation of software size, the effort required to develop it, and the project's duration are critical
for effective software project management. These estimations impact resource allocation, budgeting,
scheduling, and overall project success.
Software size estimation
Software size estimation aims to quantify the scope and complexity of the software product to be
developed. This initial estimation provides a foundation for subsequent effort and duration estimations.
Common techniques for software size estimation
 Lines of Code (LOC): This technique estimates size by counting the number of source instructions in
the code, excluding comments and header lines.
o Advantages: Relatively simple to measure, can be used for comparing projects with similar
structures.
o Disadvantages: Dependent on programming language and style, difficult to estimate
accurately at the early stages.
 Function Points (FP): This technique measures the functionality delivered by a software application
from a user perspective, considering factors like inputs, outputs, inquiries, files, and interfaces.
o Advantages: Language-independent, can be used for estimation in the early phases, more
reliable for comparative analysis.
o Disadvantages: Requires experience to apply, calculation can be subjective, does not account
for non-functional aspects like performance or maintenance.
 Feature Points: An extension of function points that also considers algorithmic complexity.
 Use Case Points (UCP): Based on the number and complexity of use cases that the software must
support.
 Story Points (SPs): A relative sizing technique used in Agile development, where teams assign points
to user stories based on their perceived effort and complexity.
Effort estimation
Effort estimation predicts the amount of work required to develop the software, usually expressed in
person-hours, person-days, or person-months.
Key aspects of effort estimation

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Relationship to Size: Effort is closely related to software size, where larger projects generally require
more effort.
 Influence of Other Factors: Effort is also influenced by other factors such as the complexity of the
project, the team's experience and skill level, the development environment, and project-specific
risks.
 Importance of Accuracy: Accurate effort estimation is essential for budgeting, resource allocation,
and project scheduling.
Common techniques for effort estimation
 Expert Judgment: Relies on the experience and expertise of seasoned professionals in the project
area.
 Analogous Estimation: Compares the current project to similar past projects to derive effort
estimates.
 Parametric Estimation: Uses mathematical models and historical data to estimate effort based on
specific project parameters like software size.
 Three-Point Estimation (PERT): Uses optimistic, pessimistic, and most likely scenarios to create a
range of effort estimates, helping to account for uncertainty and variability.
 COCOMO (Constructive Cost Model): An algorithmic model that estimates effort, cost, and schedule
based on project size (often LOC or FP) and a variety of cost drivers.
o Types: Basic, Intermediate, and Detailed COCOMO, offering progressively more refinement
and accuracy.
 Delphi Technique: A structured group estimation method where experts independently estimate
and then discuss their estimates until a consensus is reached.
Duration estimation
Duration estimation predicts the total time required to complete the software project, from initiation to
closure.
Factors influencing duration
 Software Size and Effort: Larger projects generally require longer durations.
 Team Size and Productivity: Team size can influence duration, but adding more team members
doesn't always proportionally reduce project duration due to factors like increased communication
overhead.
 Technical Complexity: Projects with higher technical complexity can require longer durations for
development and testing.
 Requirements Clarity and Stability: Unclear or changing requirements can lead to delays and
extended durations.
 Risk Management: Unforeseen risks and issues can significantly impact project timelines.
 Development Methodology: Agile methodologies, with their iterative nature, may influence how
durations are planned and managed compared to traditional methodologies like Waterfall.
Techniques for duration estimation
 Analogous Estimation: Using historical data from similar projects to predict duration.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Parametric Estimation: Employing mathematical models to estimate duration based on project

parameters and historical data.
 Three-Point Estimation: Incorporating optimistic, pessimistic, and most likely scenarios to define a
range of potential durations.
 Work Breakdown Structure (WBS): Decomposing the project into smaller tasks and estimating the
duration for each, then aggregating to determine the total project duration.
 Gantt Charts and Project Scheduling Software: Tools like Jira, Trello, and Microsoft Project assist in
creating detailed schedules and visualizing timelines and dependencies.
Importance of accurate estimation
Accurate software estimation is crucial for:
 Effective Project Planning and Scheduling: Creating realistic project plans, assigning resources, and
establishing achievable timelines.
 Resource Allocation and Budget Management: Ensuring that adequate resources are available when
needed and controlling project costs.
 Client Satisfaction: Setting clear expectations with stakeholders and building trust.
 Risk Management: Identifying and mitigating potential risks and uncertainties early in the project
lifecycle.
By diligently applying these estimation techniques and considering the influencing factors, project
managers can significantly improve the accuracy of their software size, effort, and duration estimations,
leading to more successful project outcomes.
COCOMO Model
The Constructive Cost Model (COCOMO) It was proposed by Barry Boehm in 1981 and is based on the
study of 63 projects, which makes it one of the best-documented models.
It is a Software Cost Estimation Model that helps predict the effort, cost, and schedule required for a
software development project.
COCOMO Model is a procedural cost estimate model for Software Projects and is often used as a process
of reliably predicting the various parameters associated with making a project such as size, effort, cost,
time, and quality.
The key parameters that define the quality of any Software Product, which are also an outcome of
COCOMO, are primarily effort and schedule.

Types of Projects in COCOMO Model

In the COCOMO model, software projects are categorized into three types based on their complexity, size,
and the development environment. These types are:
1. Organic
A software project is said to be an organic type if the team size required is adequately small, the problem is
well understood and has been solved in the past and also the team members have a nominal experience
regarding the problem.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

2. Semi-detached
A software project is said to be a Semi-detached type if the vital characteristics such as team size,
experience, and knowledge of the various programming environments lie in between organic and
embedded.
The projects classified as Semi-Detached are comparatively less familiar and difficult to develop compared
to the organic ones and require more experience better guidance and creativity. Eg: Compilers or different
Embedded Systems can be considered Semi-Detached types.
3. Embedded
A software project requiring the highest level of complexity, creativity, and experience requirement falls
under this category. Such software requires a larger team size than the other two models and also the
developers need to be sufficiently experienced and creative to develop such complex models.
Comparison of Types of Projects in COCOMO Model
Here is the Comparison in detail where the project types of COCOMO Model

Aspects Organic Semidetached Embedded

Project Size 2 to 50 KLOC 50-300 KLOC 300 and above KLOC

Complexity Low Medium High

Team Some experienced as well as Mixed experience,

Highly experienced
Experience inexperienced staff includes experts

Flexible, fewer Somewhat flexible, moderate Highly rigorous, strict

Environment constraints constraints requirements

Effort Equation E = 2.4(400)1.05 E = 3.0(400)1.12 E = 3.6(400)1.20

Simple payroll New system interfacing with

Flight control software
Example system existing systems

Structure of COCOMO Model

Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the
cost driver's impact on each step of the Software Engineering Process.
In detailed COCOMO, the whole software is divided into different modules and then we apply COCOMO in
different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

1. Planning and requirements: This initial phase involves defining the scope, objectives, and
constraints of the project. It includes developing a project plan that outlines the schedule,
resources, and milestones
2. System design: : In this phase, the high-level architecture of the software system is created. This
includes defining the system’s overall structure, including major components, their interactions, and
the data flow between them.
3. Detailed design: This phase involves creating detailed specifications for each component of the
system. It breaks down the system design into detailed descriptions of each module, including data
structures, algorithms, and interfaces.
4. Module code and test: This involves writing the actual source code for each module or component
as defined in the detailed design. It includes coding the functionalities, implementing algorithms,
and developing interfaces.
5. Integration and test: This phase involves combining individual modules into a complete system and
ensuring that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used method for
estimating the cost and effort required for software development projects.
Different models of COCOMO have been proposed to predict the cost estimation at different levels, based
on the amount of accuracy and correctness required. All of these models can be applied to a variety of
projects, whose characteristics determine the value of the constant to be used in subsequent calculations.
Importance of the COCOMO Model
1. Cost Estimation: To help with resource planning and project budgeting, COCOMO offers a
methodical approach to software development cost estimation.
2. Resource Management: By taking team experience, project size, and complexity into account, the
model helps with efficient resource allocation.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

3. Project Planning: COCOMO assists in developing practical project plans that include attainable
objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO assists in identifying and mitigating
potential hazards by including risk elements.
5. Support for Decisions: During project planning, the model provides a quantitative foundation for
choices about scope, priorities, and resource allocation.
6. Benchmarking: To compare and assess various software development projects to industry
standards, COCOMO offers a benchmark.
7. Resource Optimization: The model helps to maximize the use of resources, which raises
productivity and lowers costs.

Types of COCOMO Model

There are three types of COCOMO Model:
Basic COCOMO Model
The Basic COCOMO model is a straightforward way to estimate the effort needed for a software
development project. It uses a simple mathematical formula to predict how many person-months of
work are required based on the size of the project, measured in thousands of lines of code (KLOC).
It estimates effort and time required for development using the following expression:
E = a*(KLOC)b PM
Tdev = c*(E)d
Person required = Effort/ Time
Where,
E is effort applied in Person-Months
KLOC is the estimated size of the software product indicate in Kilo Lines of Code
Tdev is the development time in months
a, b, c are constants determined by the category of software project given in below table.
The above formula is used for the cost estimation of the basic COCOMO model and also is used in the
subsequent models. The constant values a, b, c, and d for the Basic Model for the different categories of
the software projects are:
Software Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

1. The effort is measured in Person-Months and as evident from the formula is dependent on Kilo-
Lines of code. The development time is measured in months.
2. These formulas are used as such in the Basic Model calculations, as not much consideration of
different factors such as reliability, and expertise is taken into account, henceforth the estimate is
rough.
Example of Basic COCOMO Model:
Suppose that a Basic project was estimated to be 400 KLOC (kilo lines of code). Calculate effort and time
for each of the three modes of development. All the constants value provided in the following table:
Solution: From the above table we take the value of constant a,b,c and d.
1. For organic mode,

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 effort = 2.4 × (400)1.05 ≈ 1295 person-month.

 dev. time = 2.5 × (1295)0.38 ≈ 38 months.
2. For semi-detach mode,
 effort = 3 × (400)1.12 ≈ 2462 person-month.
 dev. time = 2.5 × (2462)0.35 ≈ 38 months.
3. For Embedded mode,
 effort = 3.6 × (400)1.20 ≈ 4772 person-month.
 dev. time = 2.5 × (4772)0.32 ≈ 38 months.
Intermediate COCOMO Model
The basic COCOMO model assumes that the effort is only a function of the number of lines of code and
some constants evaluated according to the different software systems. However, in reality, no system's
effort and schedule can be solely calculated based on Lines of Code. For that, various other factors such
as reliability, experience, and Capability. These factors are known as Cost Drivers (multipliers) and the
Intermediate Model utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their Attributes:
The cost drivers are divided into four categories
Product attributes:
 Required Software Reliability extent
 Size of the application database
 The complexity of the product
Hardware attributes:
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
Personal attributes:
 Analyst capability
 Software engineering capability
 Application experience
 Virtual machine experience
 Programming language experience
Project attributes:
 Use of Software Tools.
 Application of Software Engineering Methods.
 Required development schedule.
Each of the 15 such attributes can be rated on a six-point scale ranging from "very low" to "extra high" in
their relative order of importance. Each attribute has an effort multiplier fixed as per the rating. Table
give below represents Cost Drivers and their respective rating:
The Effort Adjustment Factor (EAF) is determined by multiplying the effort multipliers associated with
each of the 15 attributes.
The Effort Adjustment Factor (EAF) is employed to enhance the estimates generated by the basic
COCOMO model in the following expression:
Intermediate COCOMO Model equation:
E = a*(KLOC)b * EAF PM
Tdev = c*(E)d
Where,
 E is effort applied in Person-Months
 KLOC is the estimated size of the software product indicate in Kilo Lines of Code
 EAF is the Effort Adjustment Factor (EAF) is a multiplier used to refine the effort estimate obtained
from the basic COCOMO model.
 Tdev is the development time in months

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 a, b, c are constants determined by the category of software project given in below table.
The constant values a, b, c, and d for the Basic Model for the different categories of the software
projects are:
Software Projects a b c d

Organic 3.2 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

Detailed COCOMO Model

Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving deeper into project-specific
factors. It considers a wider range of parameters, like team experience, development practices, and
software complexity. By analyzing these factors in more detail, Detailed COCOMO provides a highly
accurate estimation of effort, time, and cost for software projects. It's like zooming in on a project's
unique characteristics to get a clearer picture of what it will take to complete it successfully.

CASE Studies and Examples

1. NASA Space Shuttle Software Development: NASA estimated the time and money needed to build
the software for the Space Shuttle program using the COCOMO model. NASA was able to make well-
informed decisions on resource allocation and project scheduling by taking into account variables
including project size, complexity, and team experience.
2. Big Business Software Development: The COCOMO model has been widely used by big businesses
to project the time and money needed to construct intricate business software systems. These
organizations were able to better plan and allocate resources for their software projects by using
COCOMO's estimation methodology.
3. Commercial Software goods: The COCOMO methodology has proven advantageous for software
firms that create commercial goods as well. These businesses were able to decide on pricing, time-
to-market, and resource allocation by precisely calculating the time and expense of building new
software products or features.
4. Academic Research Initiatives: To estimate the time and expense required to create software
prototypes or carry out experimental studies, academic research initiatives have employed
COCOMO. Researchers were able to better plan their projects and allocate resources by using
COCOMO's estimate approaches.
Advantages of the COCOMO Model
1. Systematic cost estimation: Provides a systematic way to estimate the cost and effort of a software
project.
2. Helps to estimate cost and effort: This can be used to estimate the cost and effort of a software
project at different stages of the development process.
3. Helps in high-impact factors: Helps in identifying the factors that have the greatest impact on the
cost and effort of a software project.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

4. Helps to evaluate the feasibility of a project: This can be used to evaluate the feasibility of a
software project by estimating the cost and effort required to complete it.
Disadvantages of the COCOMO Model
1. Assumes project size as the main factor: Assumes that the size of the software is the main factor
that determines the cost and effort of a software project, which may not always be the case.
2. Does not count development team-specific characteristics: Does not take into account the specific
characteristics of the development team, which can have a significant impact on the cost and effort
of a software project.
3. Not enough precise cost and effort estimate: This does not provide a precise estimate of the cost
and effort of a software project, as it is based on assumptions and averages.
Best Practices for Using COCOMO Model
1. Recognize the Assumptions Underpinning the Model: Become acquainted with the COCOMO
model's underlying assumptions, which include its emphasis on team experience, size, and
complexity. Understand that although COCOMO offers useful approximations, project results cannot
be predicted with accuracy.
2. Customize the Model: Adapt COCOMO's inputs and parameters to your project's unique
requirements, including organizational capacity, development processes, and industry standards. By
doing this, you can be confident that the estimations produced by COCOMO are more precise and
appropriate for your situation.
3. Utilize Historical Data: To verify COCOMO inputs and improve estimating parameters, collect and
examine historical data from previous projects. Because real-world data takes project-specific
aspects and lessons learned into account, COCOMO projections become more accurate and reliable.
4. Verify and validate: Compare COCOMO estimates with actual project results, and make necessary
adjustments to estimation procedures in light of feedback and lessons discovered. Review
completed projects to find errors and enhance future project estimation accuracy.
5. Combine with Other Techniques: To reduce biases or inaccuracies in any one method and to
triangulate results, add COCOMO estimates to other estimation techniques including expert
judgment, similar estimation, and bottom-up estimation.
Putnam's work: SLIM model and the Rayleigh curve
Lawrence Putnam introduced the SLIM (Software Lifecycle Management) model, an empirical software
effort estimation model based on observations that software staffing profiles often follow the Rayleigh
distribution.
 Rayleigh Curve: This curve depicts the distribution of effort (manpower) over time, showing a
gradual increase to a peak and then a gradual decrease towards project completion. It suggests an
optimal staff buildup during a project, with fewer engineers needed at the beginning and end
compared to the peak during the detailed work phase.
 Software Equation: Putnam derived the software equation relating delivered lines of code (L) to
effort (E), a productivity parameter (P), and project duration (t): L = P x E^1/3 * t^4/3.
 Key Insight: Putnam's model suggests a trade-off between project duration and effort: shorter
project durations can lead to a disproportionate increase in required effort and cost. Conversely,
extending the schedule can potentially reduce the overall effort needed.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Jensen's model
Jensen's model is a refinement of Putnam's work, aiming to soften the effect of schedule compression on
effort, making it more applicable to small and medium-sized projects.
 Similar to Putnam: Jensen's model shares similarities with Putnam's model, particularly regarding
the relationship between effort and schedule compression.
 Focus on Compression: Jensen's model suggests that when project duration is compressed, the
increase in effort (and cost) is proportional to the square of the degree of compression.
 Enhanced Equation: Jensen proposed an equation for estimating size as a function of effort and
schedule, incorporating parameters like a productivity parameter and a special skills factor to tune
the model to specific organizations and application types.
Halstead's software science
Maurice Halstead's Software Science focuses on measuring the complexity of software directly from the
source code, rather than primarily on effort estimation like Putnam's model. It uses four basic metrics
derived from the source code:
 Distinct Operators (n1): The number of unique symbols or reserved words representing operations
in the code.
 Distinct Operands (n2): The number of unique variables or constants used in the program.
 Total Operators (N1): The total occurrences of all operators.
 Total Operands (N2): The total occurrences of all operands.
From these basic metrics, other important measures are derived:
 Program Length (N): The total count of operators and operands (N1 + N2).
 Vocabulary Size (n): The total number of distinct operators and operands (n1 + n2).
 Program Volume (V): Represents the size of the program in bits, based on the program length and
vocabulary size.
 Program Difficulty (D): Reflects the complexity or error-proneness of the code.
 Effort to Implement (E): The mental effort required to develop or understand the program.
 Time to Implement (T): The estimated time needed to implement the program, derived from the
effort.
Halstead's metrics offer a quantitative approach to evaluating code complexity, aiding in understanding the
structure, size, and potential maintainability of software. However, it's important to remember that these
metrics have limitations, such as the assumption of equal importance for all operators and operands and
the potential for limited accuracy in certain situations.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

UNIT-II
Activity planning - project schedules - sequencing and scheduling projects - Network planning models -
AON and AOA - identifying critical activities - crashing and fast tracking, Risk management: Categories, Risk
planning, management and control - Evaluating risks to the schedule, PERT. Resource allocation - identifying
resource requirements - scheduling resources - creating critical paths - publishing schedule - cost schedules
- sequence schedule. CPM, Gantt chart, staffing, organizing a software engineering project
Activity Planning
Definition:
Activity planning is the process of identifying and organizing the tasks required to complete a project.
It ensures that the right activities are done in the right order and within the right time frame.
Objectives:
 Identify all project activities.
 Establish logical sequence.
 Allocate time and resources.
 Identify dependencies and critical tasks.
 Provide a basis for monitoring progress.
Steps in Activity Planning
Activity planning in software projects follows a systematic sequence to ensure that tasks are identified,
organized, and scheduled properly.
1. Identify Activities
 Break the project into manageable tasks.
 Use a Work Breakdown Structure (WBS) to decompose the project into smaller work packages.
 Each activity should have a clear objective and deliverable.
Example: In a software project, activities could be “Requirement Analysis,” “Database Design,” “Coding
Module A,” “Testing Module A.”
2. Determine Activity Dependencies
 Identify logical relationships between activities.
 Decide which tasks must be completed before others can start.
 Classify dependencies:
o Finish-to-Start (FS) – Task B starts after Task A finishes (most common).
o Start-to-Start (SS) – Tasks start together.
o Finish-to-Finish (FF) – Tasks finish together.
3. Estimate Activity Durations
 Use expert judgment, historical data, or estimation models (like COCOMO, function points).
 Consider complexity, resources, technology, and risks.
 Use techniques like:
o Three-point estimation (Optimistic, Most Likely, Pessimistic)
o Analogous estimation (based on past projects)

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

4. Sequence Activities
 Arrange activities in logical order according to dependencies.
 Use:
o Activity on Node (AON) diagrams (nodes = activities, arrows = dependencies)
o Activity on Arrow (AOA) diagrams (arrows = activities, nodes = events)
5. Develop the Schedule
 Assign start and end dates to each activity.
 Allocate resources (people, tools, budget).
 Represent schedule using different tools like Gantt Charts, Network Diagrams, PERT Charts
 Identify the Critical Path (longest duration path in the project network).
6. Review and Optimize
 Check for resource overloading or unrealistic timelines.
 Optimize by:
o Crashing (adding resources to critical tasks to shorten duration)
o Fast Tracking (doing activities in parallel instead of sequentially)
Project Schedules
o A project schedule is a time-based plan showing when tasks should start and finish.
o Project scheduling is the process of organizing and sequencing project activities, considering
constraints like resources and task dependencies.
o It provides a roadmap for project execution, showing what needs to be done, when, and by whom.
o Scheduling helps in time management, resource allocation, risk management, and overall project
success.
The project schedule is represented as set of charts in which work-breakdown structure and dependencies
within various activities are represented. To accomplish and complete project within a given schedule,
required resources must be available when they are needed. Therefore, resource estimation should be
done before starting development.
Resources required for Development of Project:
 Human effort
 Sufficient disk space on server
 Specialized hardware
 Software technology
 Travel allowance required by project staff, etc.
Advantages of Project Scheduling: There are several advantages provided by project schedule in our
project management:
 It simply ensures that everyone remains on same page as far as tasks get completed, dependencies,
and deadlines.
 It helps in identifying issues early and concerns such as lack or unavailability of resources.
 It also helps to identify relationships and to monitor process.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 It provides effective budget management and risk mitigation.

Steps in Creating a Project Schedule:
 Define Tasks: Break down the project into smaller, manageable tasks.
 Estimate Durations: Determine the time required for each task.
 Determine Dependencies: Identify relationships between tasks.
 Sequence Tasks: Arrange tasks in a logical order.
 Assign Resources: Allocate resources to tasks.
 Set Timelines: Establish start and end dates for tasks and the project.
 Monitor and Adjust: Track progress, identify issues, and adjust the schedule as needed.
Techniques and Tools:
 Gantt Charts:
A common visual representation of the project schedule, showing tasks, durations, and dependencies.
 PERT(program evaluation and review techniques) Charts:
Useful for visualizing and analyzing project timelines, especially in complex projects.
 Critical Path Method (CPM):
Identifies the longest sequence of dependent tasks, determining the minimum project duration.
Sequencing and Scheduling Projects
 Sequencing: Determining the logical order of tasks (which comes first, what can run in parallel).
It ensures that tasks are completed in a logical and efficient order, often prioritizing foundational
work before dependent tasks. For example, in software development, designing the database
schema would likely be sequenced before building the user interface that relies on that schema.
 Scheduling: Assigning start and end dates to tasks based on sequencing and available resources.
Key Elements of a Project Schedule:
o Tasks: Individual units of work that need to be completed.
o Milestones: Key checkpoints indicating significant progress or completion of a phase.
o Dependencies: Relationships between tasks where one task's completion is required before another
can begin.
o Resource Allocation: Assigning individuals or teams to specific tasks.
o Timeline: Defines start and end dates for each task and the overall project.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Network Planning Models

Used to represent project activities and dependencies graphically for better scheduling and control.
Two Main Models:
1. Activity on Node (AON)

2. Activity on Arrow (AOA)

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

AON AOA
1 Each activity is placed within a node, and the 1 Each arrow in the diagram represents an
node can also contain information about the activity.
activity like duration, resources, etc.
2 Arrows connect the nodes and indicate the 2 Each arrow in the diagram represents an
logical relationships between activities (e.g., activity.
which activities must be completed before
another can start).
3 AON diagrams can easily show finish-to-start, 3 AOA diagrams primarily use finish-to-start
start-to-start, finish-to-finish, and start-to- relationships between activities. For more
finish relationships between activities. complex relationships, dummy activities may
be needed.
4 Generally, fewer dummy activities are needed 4 AOA diagrams can become complex and
in AON diagrams compared to AOA diagrams. difficult to visualize when dealing with many
activities and dependencies, especially with
the need for dummy activities.
5 AON is generally considered more intuitive and 5 AOA can be useful for specific analytical
easier to understand, especially for complex techniques in project management,
projects with various dependencies. particularly when dealing with mathematical
formulations.

Identifying Critical Activities

Critical Path = In project management, a critical path is the sequence of dependent tasks that form the
longest duration, allowing you to determine the most efficient timeline possible to complete a project.
 Critical activities: Tasks on the critical path (zero slack/float).
 Slack (Float): Extra time an activity can take without delaying the project.
Activities on the critical path cannot be delayed, or the whole project will be delayed, unless the loss of
time can be offset somewhere else on the critical path. To find the critical path, add up the duration of the
activities for each possible path through the network, to determine which has the longest total duration.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Crashing
 Reducing project duration by adding resources to critical activities.
 Example: Assign extra developers to complete coding faster.
 Trade-off: Increases cost, may reduce quality.
Fast Tracking
 Performing activities in parallel that were originally planned in sequence.
 Example: Start testing while coding of some modules is still in progress.
 Trade-off: Increases risk of rework if earlier tasks change.

Risk Management in Software Project Management

Risk management is the process of identifying, analyzing, and responding to risks throughout the life of a
project to minimize negative impacts and maximize opportunities.
Categories of Risks
Software projects face different categories of risks, broadly classified into:
1. Project Risks
o Risks affecting the project plan and schedule.
o Examples: unrealistic deadlines, cost overruns, inadequate resources.
2. Technical Risks
o Risks related to technology, tools, or technical complexity.
o Examples: new/unproven technology, integration issues, design flaws.
3. Business Risks
o Risks affecting business value or objectives.
o Examples: changing customer needs, market competition, funding issues.
4. Operational Risks
o Risks during project execution and operations.
o Examples: staff turnover, poor communication, mismanagement.
5. External Risks
o Risks beyond the project’s control.
o Examples: government regulations, vendor dependency, natural disasters.

Risk Planning, Management, and Control

a) Risk Planning
 Define risk management strategy (how risks will be identified, analyzed, tracked).
 Identify potential risks.
 Assess probability (likelihood) and impact (consequence).
 Prepare a risk register documenting all risks.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

b) Risk Management
 Develop risk mitigation strategies (reduce likelihood/impact).
 Prepare contingency plans (backup strategies if risk occurs).
 Allocate responsibilities for risk handling.
c) Risk Control
 Continuous monitoring of identified risks.
 Identify new risks during execution.
 Track mitigation actions.
 Use tools like risk audit reports and risk status meetings.
Evaluating Risks to the Schedule
Schedule risks are among the most critical in software projects.
Common Schedule Risks
 Underestimating task durations.
 Dependency delays (waiting for another task).
 Critical resource unavailability.
 Scope creep (adding extra requirements).
 Rework due to quality issues.
Evaluation Techniques
1. Critical Path Method (CPM)
o Identifies the sequence of tasks that determine project duration.
o Delay in critical path tasks → delays overall project.
2. Program Evaluation and Review Technique (PERT)
o PERT is a project management tool used to plan, schedule, and control projects.
o Considers uncertainty in time estimates and uses probabilistic time estimates (instead of just
fixed times)
o Each task has 3 estimates:
 Optimistic time (O)
 Most likely time (M)
 Pessimistic time (P)
o Expected time (TE):

o Variance of task (σ²):

Helps in evaluating probability of completing project within deadline.

Example: Using PERT for Schedule Risk
Suppose a project task has:

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Optimistic (O) = 4 weeks

 Most Likely (M) = 6 weeks
 Pessimistic (P) = 10 weeks
Expected time (TE):

Variance:
Steps in PERT Analysis
1. Identify project activities and dependencies.
2. Estimate time for each activity (O, M, P).
3. Calculate Expected time (TE) and Variance.
4. Draw a PERT network diagram.
5. Find the Critical Path (longest path through the network).
6. Use probability analysis (Z-score) to determine chance of meeting deadlines.

Example: Let’s say a project has the following tasks:

Task Optimistic (O) Most Likely (M) Pessimistic (P) TE (Expected Time)
A (Requirement) 2 4 6 (2+4*4+6)/6 = 4.0
B (Design) 3 5 7 (3+4*5+7)/6 = 5.0
C (Coding) 2 3 4 (2+4*3+4)/6 = 3.0
D (Testing) 4 6 10 (4+4*6+10)/6 = 6.3
E (Deployment) 1 2 3 (1+4*2+3)/6 = 2.0
Dependencies
 A→B→C→D→E
Critical Path
 Total expected duration = 4 + 5 + 3 + 6.3 + 2 = 20.3 weeks
So, the expected project duration is ≈ 20 weeks.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Resource Allocation in Project Management

1. Identifying Resource Requirements
 Resources can include:
o Human resources (developers, testers, designers, managers).
o Hardware/software tools (servers, licenses, development tools).
o Financial resources (budget for salaries, vendors, training).
o Time (availability of team members).
Steps:
1. Break project into tasks (Work Breakdown Structure – WBS).
2. Assign skills/tools needed per task.
3. Estimate resource quantity and duration of need.
Example:
 Task: Coding module X → Needs 2 developers (4 weeks), 1 testing environment.
2. Scheduling Resources
 Assign resources to tasks while considering availability & constraints.
 Tools: Resource histogram, RACI matrix, Gantt chart.
 Avoid:
o Overallocation (one resource given too many tasks).
o Underutilization (resource is idle).
3. Creating Critical Paths
 Critical Path Method (CPM):
o Identify the longest sequence of dependent tasks.
o Determines minimum project completion time.
o Any delay in critical tasks → delays project.
Steps to create Critical Path:
1. List activities with durations.
2. Define dependencies.
3. Draw network diagram.
4. Calculate Earliest Start (ES), Latest Finish (LF).
5. Path with zero slack = Critical Path.
4. Publishing the Schedule
 Prepare a project schedule document.
 Share using:
o Gantt charts (timeline view).
o PERT/CPM charts (network view).
o Milestone charts (high-level checkpoints).

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Purpose:
 Keeps stakeholders informed.
 Sets expectations on deadlines.
5. Cost Schedules
 Combine resource costs with schedule → Cost Baseline.
 Estimate:
o Direct costs (salaries, equipment).
o Indirect costs (overheads, utilities).
 Use S-curves or Earned Value Analysis (EVA) to track planned vs actual spending.
Example:
 Developer @ ₹50,000/month × 2 months = ₹100,000.
 Testing tools = ₹20,000.
 Total cost for phase = ₹120,000.
6. Sequence Scheduling
 Arrange tasks in logical order to optimize efficiency.
 Dependencies:
o Finish-to-Start (FS): Task B starts after A finishes.
o Start-to-Start (SS): Task B starts when A starts.
o Finish-to-Finish (FF): Task B finishes when A finishes.
o Start-to-Finish (SF): Rare case.
Helps avoid idle time & bottlenecks.
Summary Workflow
1. Identify resources (people, tools, budget).
2. Schedule them (who does what, when).
3. Create critical path (determine project length).
4. Publish schedule (share Gantt/PERT with team).
5. Estimate costs (resource usage × time).
6. Sequence tasks (define dependencies clearly).
Critical Path Method (CPM)
 Definition:
CPM is a project scheduling technique used to determine the longest path of dependent activities
in a project. This path defines the shortest possible project duration.
 Steps in CPM:
1. Identify all project activities.
2. Define dependencies (which tasks depend on others).
3. Estimate duration for each activity.
4. Construct a network diagram.
5. Calculate:

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Earliest Start (ES), Earliest Finish (EF)

 Latest Start (LS), Latest Finish (LF)
 Slack/Float = LS – ES = LF – EF
6. Activities with zero slack form the Critical Path.
 Benefit:
Helps project managers focus on tasks that directly affect project completion.
CPM example with a small software project:
Activities & durations (weeks)
 A Requirements (3) → predecessors: —
 B Design (4) → after A
 C Infra Setup (2) → after A
 D Implementation (6) → after B and C
 E Testing (3) → after D
 F Deployment (2) → after E
Results (computed by forward/backward pass):
 Project duration (critical path length): 18 weeks
 Critical path: A → B → D → E → F (all zero-slack)

Gantt Chart
 Definition:
A Gantt chart is a bar chart showing project tasks against time.
 Features:
o Each bar = task duration.
o Dependencies shown with arrows.
o Milestones highlighted.
 Uses in Software Projects:
o Track progress visually.
o Show overlapping tasks (parallel development).
o Communicate deadlines to stakeholders.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Staffing in Software Projects

Staffing means assigning people with the right skills to the right tasks.
 Staffing Plan:
1. Skill Identification – match project needs (e.g., UI/UX, Backend, QA).
2. Staffing Levels Across Life Cycle –
 Early phase: Few people (analysts, architects).
 Middle phase: Peak (developers, testers).
 End phase: Reduced staff (maintenance, support).
3. Resource Histogram – graph showing staff required per week.
 Principles:
o Avoid overallocation (burnout).
o Avoid underutilization (wasted cost).
o Balance junior & senior staff.
Organizing a Software Engineering Project
Project organization defines roles, responsibilities, and reporting structures.
Common Structures
1. Hierarchical (Functional Organization):
o Clear roles by department (e.g., Analysts, Developers, Testers).
o Good for large projects.
2. Project-Based Team:
o Dedicated cross-functional team.
o Best for focused software development.
3. Matrix Organization:
o Combines both: staff report to both functional manager and project manager.
o Good for multi-project environments.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Typical Roles in Software Projects

 Project Manager (PM): Planning, risk management, reporting.
 System Analyst: Requirement gathering & specification.
 Software Architect: High-level design decisions.
 Developers (Frontend, Backend, Full-stack): Implementation.
 Testers / QA: Verification and validation.
 DevOps Engineer: Deployment and maintenance.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

UNIT-III
Monitoring and control – Visualizing progress, Earned value analysis – Managing people and organizing
teams – organizational structures - Planning for small projects. Case Studies, Agile Development.
Monitoring and Control in Software Project Management
1. Visualizing Progress
Monitoring requires tracking whether the project is on time, within budget, and aligned with scope.
Visualization tools help managers compare planned vs. actual progress:
 Gantt Charts → Show planned vs. actual timelines.
 Milestone Charts → Track achievement of key deliverables.
 Network Diagrams (PERT/CPM) → Compare planned critical path vs. actual progress.
 Burn-down & Burn-up Charts (Agile) → Show remaining work vs. time.
 Dashboards → Use KPIs like % completion, cost spent, defect density.
Example: A Gantt chart showing that Module A is delayed by 5 days alerts the manager to reallocate
resources.
2. Earned Value Analysis (EVA)
EVA is a powerful method to measure project performance by integrating scope, time, and cost.
Key Terms:
 Planned Value (PV) → Budgeted cost of work planned.
 Earned Value (EV) → Budgeted cost of work actually completed.
 Actual Cost (AC) → Actual expenditure incurred.
Performance Indicators:
 Cost Variance (CV) = EV – AC (Positive = under budget, Negative = over budget)
 Schedule Variance (SV) = EV – PV (Positive = ahead of schedule, Negative = behind schedule)
 Cost Performance Index (CPI) = EV / AC
 Schedule Performance Index (SPI) = EV / PV
Example:
 PV = ₹1,00,000; EV = ₹80,000; AC = ₹90,000
 CV = –₹10,000 (Over budget)
 SV = –₹20,000 (Behind schedule)
 CPI = 0.89 (inefficient cost use)
 SPI = 0.80 (progress slower than planned)

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Earned Value Analysis (EVA) graph showing Planned Value (PV), Earned Value (EV), and Actual Cost (AC).
At Week 6, EV < PV (behind schedule) and EV < AC (over budget).
3. Managing People and Organizing Teams
Since software projects are human-intensive, managing people is crucial.
Roles in a Software Team:
 Project Manager (PM) – Planning, monitoring, control.
 Developers – Coding and implementation.
 Testers – Quality assurance.
 Analysts/Architects – Design and requirements.
People Management Approaches:
 Motivation & Leadership (Maslow’s hierarchy, Herzberg’s theory).
 Conflict Management – Negotiation, collaboration.
 Communication Plans – Daily stand-ups, status meetings.
 Delegation & Empowerment – Encouraging accountability.
4. Organizational Structures
The structure impacts how teams are managed:
1. Functional Structure – Staff grouped by function (e.g., dev, test, design).
o Pros: Expertise, clear roles.
o Cons: Weak project focus, communication issues.
2. Projectized Structure – Team dedicated to one project.
o Pros: Strong project ownership.
o Cons: Costly, resource duplication.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

3. Matrix Structure – Hybrid (resources report to both functional & project managers).
o Pros: Balanced, resource sharing.
o Cons: Dual authority, possible conflicts.
Example: In a matrix structure, a developer may report to both the software engineering head (functional)
and project manager (project).
5. Planning for Small Projects
Small projects have limited resources, tight deadlines, and smaller teams.
Key Aspects:
 Simplified Planning (lightweight Gantt or Kanban board).
 Minimal Documentation (focus on essentials like requirements list).
 Rapid Prototyping for quick validation.
 Agile/Iterative Approaches preferred over heavy formal models.
 Close Team Collaboration (daily stand-ups, quick feedback).
Example: A mobile app development project with 5 people uses Trello (Kanban), weekly milestones, and
rapid releases.
6. Case Studies
Case Study 1: Large Software Project (Banking System)
 Problem: Project delayed by 4 months, budget overruns.
 Monitoring tool: Earned Value Analysis showed SPI = 0.75, CPI = 0.80.
 Action: Re-prioritized modules, added resources temporarily, improved communication.
 Outcome: Delivered with partial scope reduction but met critical deadlines.
Case Study 2: Small Project (E-commerce Website for Local Business)
 Problem: 4-member team, 3-month deadline.
 Approach: Used Agile sprints, burn-down charts, weekly demos.
 Result: On-time delivery with client satisfaction, despite scope changes.
Case Study 3: Matrix Structure (ERP System in Manufacturing)
 Issue: Conflicts between functional managers and project manager over resource allocation.
 Resolution: Weekly coordination meetings, clarified dual reporting lines.
 Result: Improved collaboration and balanced workloads.
In summary, monitoring and control ensures that software projects remain on track through visualization,
EVA, and effective team management. The choice of organizational structure and scaled planning is crucial
for project size. Case studies show how these principles are applied in practice.
Agile Model in Software Development
Agile is an iterative and incremental software development approach that emphasizes:
 Customer collaboration over contract negotiation.
 Responding to change over following a strict plan.
 Working software over heavy documentation.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Individuals and interactions over rigid processes.

It was formalized in the Agile Manifesto (2001).
Working of Agile Model
Agile divides the project into small iterations (sprints), usually 2–4 weeks long.
Each sprint delivers a working piece of the product.
Steps:
1. Requirement Gathering (User Stories):
Requirements are captured as user stories in the product backlog.
Example: “As a user, I want to log in using Google so that I can access my account quickly.”
2. Sprint Planning:
The team selects a set of user stories for the next sprint (based on priority and capacity).
3. Design & Development:
The selected features are designed, coded, and integrated in that sprint.
4. Testing:
Each sprint includes unit testing, integration testing, and user acceptance testing.
5. Review / Demonstration:
At the end of the sprint, the team demonstrates the working software to the client.
6. Retrospective:
The team discusses what went well and what to improve in the next sprint.
7. Next Iteration:
The cycle repeats until the final product is delivered.
Key Features
 Iterative progress (short cycles).
 Continuous client feedback.
 Adaptability to changing requirements.
 Team collaboration and self-organization.
 Frequent delivery of working software.
Example Agile Models
1. Scrum
 Most popular Agile framework.
 Project is divided into sprints (2–4 weeks).
 Roles:
o Product Owner → manages backlog.
o Scrum Master → facilitates the process.
o Development Team → builds the product.
 Events: Sprint planning, Daily stand-ups, Sprint review, Sprint retrospective.
Example: Building an E-commerce Website:
 Sprint 1 → User registration & login.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Sprint 2 → Product catalog.

 Sprint 3 → Shopping cart & checkout.
 Sprint 4 → Payment integration.

Scrum Agile Model cycle diagram showing the iterative flow from Product Backlog → Sprint Planning →
Sprint → Working Product → Review & Retrospective.
2. Kanban
 Visual workflow management using a Kanban board (To Do → In Progress → Done).
 No fixed iterations, tasks flow continuously.
 Focus: Limiting Work in Progress (WIP) to avoid bottlenecks.
Example: A mobile app bug-fix team uses Kanban with sticky notes/cards to track defects from reporting →
fixing → testing → deployment.

To Do → Upcoming tasks (e.g., Login

Page, Payment Gateway).
In Progress → Currently being worked
on (e.g., Shopping Cart).
Done → Completed tasks (e.g., User
Registration).

3. Extreme Programming (XP)

Extreme Programming (XP) is an Agile software development methodology that emphasizes customer
satisfaction, teamwork, and high-quality code through frequent releases and strong engineering
practices.
Key Practices of XP:
1. Pair Programming → Two developers work together on the same code (driver & navigator).

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

2. Test-Driven Development (TDD) → Write tests before writing code.

3. Continuous Integration (CI) → Integrate and test code frequently (multiple times a day).
4. Simple Design → Build the simplest solution that works.
5. Refactoring → Continuously improve code without changing functionality.
6. Collective Code Ownership → Anyone can improve any part of the code.
7. Sustainable Pace → Avoid overtime; promote balanced workload.
8. Customer Involvement → Customer is part of the team, providing constant feedback.
Advantages:
 High-quality, reliable software.
 Rapid response to changing requirements.
 Strong customer involvement.
 Encourages teamwork and communication.
Limitations:
 Requires high customer availability.
 May be difficult in large or distributed teams.
 High discipline needed to follow practices consistently.
Example: In a real-time trading software, XP ensures reliability using automated testing and continuous
integration.
4. Lean Software Development
 Derived from Lean manufacturing (Toyota).
 Principles: Eliminate waste, Build quality in, Deliver fast, Empower teams.
Example: A startup MVP (Minimum Viable Product) approach to quickly validate product ideas with
minimal resources.
5. Crystal Methodology
 Emphasizes people and interactions rather than processes and tools.
 Lightweight and flexible.
 Different “colors” of Crystal (Clear, Yellow, Orange) are used depending on project size and criticality.

Comparison of Agile Models

Feature / Extreme Programming (XP)
Scrum 🌀 Kanban 📊
Aspect 💻

Iterative with strong

Approach Iterative, sprint-based Continuous flow
engineering practices

Iteration No fixed time-box, continuous

Fixed (2–4 weeks sprints) 1–2 weeks (short cycles)
Length delivery

Work Sprint backlog planned at User stories planned per

Work pulled as capacity allows
Planning start of sprint iteration

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Feature / Extreme Programming (XP)

Scrum 🌀 Kanban 📊
Aspect 💻

Product Owner, Scrum Programmer, Customer,

Roles No defined roles (team-driven)
Master, Dev Team Tester, Tracker, Coach

Deliver sprint goal Limit Work in Progress (WIP),

Focus Code quality, fast feedback
increment optimize flow

Sprint backlog, Burndown Kanban board (To Do → In Story cards, automated tests,
Board/Tool
chart Progress → Done) CI tools

Less flexible (scope frozen Highly flexible (tasks added Moderate, but changes
Flexibility
during sprint) anytime) allowed per iteration

Predictability, structure, Simplicity, flexibility, High-quality code, best

Strengths
clear roles continuous delivery practices enforced

Best Suited Medium to large teams, Support/maintenance, continuous High-risk projects needing
For complex projects flow projects quality & adaptability

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

UNIT-IV
Software quality- quality engineering, defining quality requirements, quality standards, practices &
conventions, ISO 9000, ISO 9001, Software quality matrices, managerial and organization issues, defect
prevention, reviews & audits, SEI capability maturity model, PSP, six sigma.
Software Quality
Software quality is the degree to which a software product meets customer requirements,
expectations, and industry standards. It involves delivering reliable, efficient, maintainable, and usable
software.
Quality Engineering
Quality Engineering (QE) is the systematic approach to ensure software quality throughout the
development life cycle (SDLC), not just at the testing phase.
It emphasizes prevention of defects rather than just detection.
Key Aspects of Quality Engineering
1. Process-Oriented
o Integrates quality practices into requirements, design, coding, testing, and maintenance.
o Uses frameworks like CMMI, ISO 9001, ISO/IEC 25010.
2. Shift-Left Approach
o Focuses on early defect prevention by involving quality activities at the beginning
(requirement & design stages).
3. Automation & Tools
o Automated testing, CI/CD pipelines, static code analysis.
o Tools: Selenium, JUnit, Jenkins, SonarQube.
4. Metrics-Driven
o Collects data to measure quality and improve processes.
o Examples: defect density, test coverage, reliability index.
5. Continuous Improvement
o Feedback loops from testing, customer reviews, and production are used to enhance quality.
o Supports Agile, DevOps, and TDD practices.
Activities in Quality Engineering
 Requirement Validation → Check clarity & completeness.
 Design Reviews & Inspections → Ensure standards are followed.
 Code Quality Assurance → Static analysis, code reviews.
 Testing Strategy → Automated unit, integration, system, regression tests.
 Risk Management → Identifying and mitigating risks early.
 Quality Audits & Compliance → Adhering to standards (ISO, IEEE).
Benefits
 Reduced cost of fixing defects (early detection).
 Higher customer satisfaction.
 Improved reliability, performance, and security.
 Faster delivery with better quality (Agile + DevOps).

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Defining Quality Requirements

Quality requirements are non-functional requirements (NFRs) that describe how well a software
system should perform, rather than what it should do.
They ensure the system is reliable, usable, secure, efficient, and maintainable in real-world use.
Steps in Defining Quality Requirements
1. Identify Stakeholders
o End-users, developers, testers, managers, clients.
o Each may have different expectations (e.g., users want usability, business wants reliability).
2. Use Quality Models
o Common reference: ISO/IEC 25010 Software Quality Model.
o Main characteristics:
 Functionality
 Reliability
 Usability
 Efficiency/Performance
 Maintainability
 Portability
 Security
 Compatibility
3. Translate into Measurable Metrics
o Requirements must be quantifiable (SMART: Specific, Measurable, Achievable, Relevant,
Time-bound).
o Examples:
 Performance: Response time ≤ 2 seconds for 95% of transactions.
 Reliability: 99.95% uptime per month.
 Security: Must comply with ISO 27001.
 Usability: New user should complete a task within 3 minutes.
4. Document Quality Attributes
o Use Software Requirements Specification (SRS).
o Include acceptance criteria for each attribute.
5. Validate & Prioritize
o Check feasibility (can it be measured/tested?).
o Prioritize based on business value & risk.
Examples of Quality Requirements
 Reliability: “System shall recover from crashes within 30 seconds.”
 Performance: “System shall support 1000 concurrent users.”
 Usability: “Interface shall comply with WCAG accessibility standards.”
 Security: “All sensitive data shall be encrypted using AES-256.”
 Maintainability: “System modules shall be independent with ≤ 20% coupling.”
 Portability: “Software shall run on Windows, Linux, and macOS without modification.”

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Benefits of Defining Quality Requirements

 Provides clear expectations between customer & developer.
 Enables objective testing and validation.
 Reduces risk of project failure.
 Improves customer satisfaction and system acceptance.
Defining quality requirements means specifying measurable, testable non-functional requirements (like
performance, reliability, usability, security, maintainability) using standards such as ISO/IEC 25010, and
documenting them in the SRS to guide development and testing.
Quality Standards
Quality standards are formal guidelines and frameworks that define how software processes and products
should meet quality expectations.
Key Standards
 ISO 9001 → Quality Management System (general).
 ISO/IEC 25010 → Defines software product quality model (reliability, usability, security, etc.).
 ISO/IEC 12207 → Software life cycle processes.
 CMMI (Capability Maturity Model Integration) → Process maturity levels (from initial →
optimized).
 IEEE Standards →
o IEEE 730 – Software Quality Assurance Plan.
o IEEE 829 – Software Test Documentation.
o IEEE 830 – Software Requirement Specification.
Purpose: Provide benchmarks, ensure consistency, improve trust, and support compliance.
Quality Practices
Quality practices are the activities and methods applied during development to achieve and maintain
quality.
Key Practices
 Software Reviews & Inspections
o Peer reviews, walkthroughs, code inspections.
 Testing Practices
o Unit, integration, system, regression, acceptance testing.
o Automated testing (Selenium, JUnit).
 Configuration Management
o Version control (Git, SVN), change management.
 Defect Prevention
o Root cause analysis, checklists.
 Agile/DevOps Practices
o Test-driven development (TDD), Continuous Integration/Continuous Testing, Pair
programming.
 Metrics & Measurement
o Defect density, code coverage, MTBF (Mean Time Between Failures).
Purpose: Embed quality throughout SDLC, not only in testing.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Quality Conventions
Conventions are agreed-upon rules and guidelines followed by developers and teams to ensure
consistency and maintainability.
Examples
 Coding Conventions
o Naming: camelCase (variables), PascalCase (classes).
o Proper indentation & spacing.
o Meaningful comments & documentation.
o Error handling guidelines.
 Documentation Conventions
o Standard templates for SRS, design docs, test cases.
o Use of UML diagrams for design.
 Process Conventions
o Commit message rules (e.g., “feat: add login API”).
o Pull request review checklist.
o Issue tracking formats.
Purpose: Improves readability, collaboration, and maintainability.
Summary
 Standards → Formal frameworks (ISO, IEEE, CMMI) to benchmark quality.
 Practices → Activities (reviews, testing, metrics, CI/CD) to achieve quality.
 Conventions → Team-agreed coding, documentation, and process rules to maintain consistency.

Aspect Quality Standards Quality Practices Quality Conventions

Formal frameworks & Methods & activities followed to Agreed rules &
Definition
guidelines for quality ensure quality coding/documentation guidelines

Organization-wide /
Scope Project & process level Team / Developer level
Industry level

ISO 9001, ISO/IEC 25010, Reviews, testing, CI/CD, defect Coding style, naming rules,
Examples
CMMI, IEEE 730 prevention, metrics documentation templates

Provide benchmarks & Achieve and maintain software Ensure consistency, readability,
Purpose
compliance quality during SDLC maintainability

What quality should be How to achieve quality How to work consistently

Focus
(standards/criteria) (methods/techniques) (rules/guidelines)

Trust, credibility, Better defect prevention, Easier collaboration, reduced

Benefit
standardization reliable software ambiguity

ISO 9000
 Definition:
ISO 9000 is a family of international standards for quality management systems (QMS), created by
the International Organization for Standardization (ISO).

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Purpose:
o Provides the fundamental concepts, principles, and vocabulary of quality management.
o Acts as the foundation for the ISO 9001 standard.
 Scope:
o Introduces terms, definitions, and concepts related to quality (customer focus, leadership,
continual improvement, process approach, evidence-based decision making).
Think of ISO 9000 as the “theory” or guideline.

ISO 9001
 Definition:
ISO 9001 is the standard within the ISO 9000 family that specifies the requirements for a quality
management system (QMS).
 Purpose:
o Used for certification (organizations can be officially ISO 9001 certified).
o Ensures organizations can consistently deliver products/services that meet customer and
regulatory requirements.
 Scope:
o Defines requirements for processes like documentation, quality policy, planning, risk
management, monitoring, audits, corrective actions, continual improvement.
 Latest Version: ISO 9001:2015.

Think of ISO 9001 as the “practical implementation” that companies get certified in.

Key Difference

Aspect ISO 9000 ISO 9001

Type Guidelines (concepts, vocabulary) Requirements (certifiable standard)

Purpose Foundation for quality management Implementation of quality management system

Certification Not certifiable Certifiable

Use Reference for understanding QMS Proof of quality compliance in organizations

Example
 A software company studies ISO 9000 to understand quality principles.
 Then, it implements ISO 9001 to establish processes (e.g., requirement management, testing,
audits) and gets certified to assure clients of quality.

Software quality matrices

Software quality metrics are quantifiable measurements used to assess various aspects of software quality
throughout its development lifecycle. They provide data-driven insights into how well a software product
performs, how reliable it is, how easy it is to use, and how maintainable it is. These metrics are crucial for
identifying areas of improvement, tracking progress, and ensuring that the software meets specified quality
standards.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Categories of Software Quality Metrics:

 Product Metrics:
These metrics focus on the quality characteristics of the software itself, such as reliability, performance,
security, and usability. Examples include defect density, code coverage, mean time to failure (MTTF), and
user satisfaction.
 Process Metrics:
These metrics assess the effectiveness and efficiency of the software development process, including
testing and maintenance. Examples include defect resolution rate, lead time for changes, and test
automation coverage.
 Project Metrics:
These metrics focus on the overall health of the software development project, such as release frequency
and customer-reported defects.
Examples of Specific Software Quality Metrics:
 Defect Density: The number of defects found per unit of code (e.g., per thousand lines of code).
 Code Coverage: The percentage of code that is executed by automated tests.
 Mean Time To Failure (MTTF): The average time a software system operates without failure.
 Mean Time To Resolution (MTTR): The average time it takes to resolve a bug or issue.
 Customer Satisfaction: Measured through surveys or feedback mechanisms to gauge user
satisfaction with the software.
 Release Frequency: The rate at which new versions of the software are released.
 Code Churn: Measures the amount of code that is changed or modified within a specific period.
 Test Automation Coverage: The proportion of testing activities that are automated.
 Change Failure Rate: The percentage of software deployments that result in failures.
Benefits of Using Software Quality Metrics:
 Improved Software Quality:
Metrics help identify and address quality issues early in the development process, leading to a more robust
and reliable product.
 Increased Efficiency:
By tracking process metrics, teams can identify bottlenecks and inefficiencies in their workflows, leading to
improved productivity.
 Reduced Costs:
Early defect detection and efficient processes can significantly reduce the cost of fixing bugs later in the
development lifecycle or after release.
 Better Decision Making:
Metrics provide objective data that can be used to make informed decisions about resource allocation,
testing strategies, and overall software development priorities.
 Enhanced Communication:
Metrics provide a common language for teams and stakeholders to discuss software quality and progress.
Managerial and Organization issues
Managerial and organizational issues in software project management stem from challenges like scope
creep, poor communication, unrealistic deadlines, resource constraints, lack of accountability, and
inadequate stakeholder engagement. These issues are often compounded by the complex, dynamic nature

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

of software development, making it difficult to accurately estimate time and costs and manage
dependencies. Addressing these problems requires strong leadership, clear communication, effective risk
management, and a flexible organizational culture that supports agile methodologies.
Key Managerial Issues
 Scope Creep:
Uncontrolled changes or additions to a project's scope after it has begun, leading to delays and increased
costs.
 Poor Communication:
Misunderstandings between team members, stakeholders, and clients can lead to unmet expectations and
project misalignment.
 Unrealistic Deadlines:
Setting project timelines without consulting all teams or considering technical complexities can lead to
rushed work and poor quality.
 Limited Resources:
A lack of sufficient budget, personnel, or the right tools can significantly hinder project progress and
quality.
 Lack of Accountability:
Without clear roles and responsibilities, it's difficult to ensure tasks are completed and milestones are met,
hindering project success.
 Poor Risk Management:
Failure to identify and plan for potential roadblocks or hazards can derail projects unexpectedly.
Key Organizational Issues
 Lack of Stakeholder Engagement:
Insufficient involvement from key stakeholders and users can result in software that doesn't meet their
needs.
 Mismatched Team Skills:
A lack of necessary expertise within the team can lead to inefficiency and technical challenges.
 Inflexible Culture:
Resistance to agile methodologies or established processes can prevent organizations from adapting to the
dynamic needs of software development.
 Integration Complexity:
Challenges in getting different software components to work together seamlessly can create significant
technical hurdles and delays.
 Project Management Structure:
An overly complex or inappropriate organizational structure can create communication bottlenecks and
hinder workflow.
Solutions to Consider
 Establish Clear Goals:
Define and communicate clear project goals and objectives from the outset.
 Implement Agile Methodologies:
Foster an agile culture and use appropriate tools and systems to improve collaboration and adapt to
changes.
 Invest in Communication:

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Establish robust communication channels and ensure regular, transparent updates to all stakeholders.
 Perform Thorough Risk Assessment:
Proactively identify, assess, and plan for potential project risks to mitigate their impact.
 Ensure Proper Resource Allocation:
Carefully plan and allocate the necessary budget, skilled personnel, and tools for the project.
 Promote Accountability:
Clearly define roles and responsibilities to ensure team members are accountable for their tasks.
 Encourage Stakeholder Involvement:
Engage users and stakeholders early and continuously throughout the development process.
Defect prevention
Defect prevention in software project management is a strategy to proactively identify and eliminate the
root causes of defects to stop them from recurring in future projects. It involves analysing past defects to
understand their origins, implementing preventive actions, and sharing "lessons learned" across the
organization to improve the software development process, increase quality, reduce costs, and boost
productivity. Key activities include understanding requirements, performing code reviews, implementing
coding standards, and conducting root cause analysis of any defects found.
The Defect Prevention Process
A typical defect prevention process follows these steps:
1. 1. Analyse Defects and Identify Root Causes:
After defects are detected, analyse them to pinpoint the underlying reasons for their occurrence.
2. 2. Suggest Preventive Actions:
Based on the root cause analysis, suggest concrete actions and process changes to prevent similar defects
from happening again.
3. 3. Implement and Share Lessons Learned:
Put the preventive actions into practice and document them as lessons learned to be shared with all teams
and projects.
Key Activities and Techniques
 Requirement Analysis:
Thoroughly understand customer requirements to ensure they are correctly translated into product
specifications without introducing errors.
 Code Reviews and Inspections:
Conduct structured reviews of code and designs to find defects early.
 Coding Standards and Checklists:
Establish and follow coding standards and use self-review checklists to maintain code quality and
consistency.
 Root Cause Analysis (RCA):
A structured methodology to find the fundamental reasons behind defects, allowing for targeted
prevention.
 Knowledge Sharing:
Propagate "lessons learned" from past projects to prevent similar issues in the future.
 Team Collaboration:
Foster collaboration between developers and testers to quickly resolve issues and make informed
decisions.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Benefits of Defect Prevention

 Improved Quality: Leads to higher-quality, "bug-free" software.
 Reduced Costs: Minimizes the significant expenses associated with fixing defects discovered later in
the development cycle.
 Increased Productivity: By preventing errors, less time is spent on fixing them, freeing up resources
and improving overall output.
 Enhanced Process Maturity: Indicates a high level of process maturity within an organization.
Reviews & Audits
In software project management, reviews are informal or formal evaluations by team members to find
defects early, while audits are independent, comprehensive compliance checks by external or internal
experts to assess adherence to standards and regulations. Both aim to improve quality and mitigate risks,
but reviews are focused on technical content and early issue detection, whereas audits provide formal
compliance reports and verify adherence to established criteria.
Software Reviews
 Purpose:
To gather feedback, identify and correct defects, and ensure quality during the Software Development Life
Cycle (SDLC).
 Participants:
Typically conducted by members of the development team or other technical personnel.
 Scope:
Focuses on technical content, quality, and identifies issues within work products like code or design
documents.
 Outcome:
Results in documented findings, action items, and recommendations for improvement.
 Examples:
Walk-throughs, formal reviews, and inspections are common types of software reviews.
Software Audits
 Purpose:
To comprehensively assess a software product or process's health, quality, progress, and compliance with
specifications, standards, and regulations.
 Participants:
Conducted by independent auditors, either internal or external, who are not part of the development
team.
 Scope:
A broader, compliance-focused evaluation to check adherence to policies, standards, contracts, and best
practices.
 Outcome:
A formal, comprehensive audit report detailing findings and providing high-level overviews and suggestions
for improvements.
 Benefits:
Early risk identification, verification of licensing compliance, and ensuring adherence to industry standards
and legal requirements.
Key Differences

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Independence:
Audits are independent assessments, whereas reviews can involve internal team members.
 Focus:
Reviews focus on the technical content and quality, while audits emphasize compliance and adherence to
standards.
 Formality:
Audits are more formal and result in a comprehensive report, while reviews are often simpler assessments.
SEI capability maturity model

The Software Engineering Institute's (SEI) Capability Maturity Model (CMM) is a framework that assesses
and improves software development processes. It defines five maturity levels, from Initial to Optimizing,
guiding organizations in systematically enhancing their software development practices according to the
SEI. CMM aims to move organizations from ad-hoc, chaotic processes to mature, disciplined ones, resulting
in higher quality software and more efficient project management.

Levels of CMM

 Level One: Initial - The software process is characterized as inconsistent, and occasionally even
chaotic. Defined processes and standard practices that exist are abandoned during a crisis. Success
of the organization majorly depends on an individual effort, talent, and heroics. The heroes
eventually move on to other organizations taking their wealth of knowledge or lessons learnt with
them.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

 Level Two: Repeatable - This level of Software Development Organization has a basic and consistent
project management processes to track cost, schedule, and functionality. The process is in place to
repeat the earlier successes on projects with similar applications. Program management is a key
characteristic of a level two organization.
 Level Three: Defined - The software process for both management and engineering activities are
documented, standardized, and integrated into a standard software process for the entire
organization and all projects across the organization use an approved, tailored version of the
organization's standard software process for developing, testing and maintaining the application.
 Level Four: Managed - Management can effectively control the software development effort using
precise measurements. At this level, organization set a quantitative quality goal for both software
process and software maintenance. At this maturity level, the performance of processes is
controlled using statistical and other quantitative techniques, and is quantitatively predictable.
 Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving
process performance through both incremental and innovative technological improvements. At this
level, changes to the process are to improve the process performance and at the same time
maintaining statistical probability to achieve the established quantitative process-improvement
objectives.
Personal Software Process (PSP)
The Personal Software Process (PSP) is a structured software development methodology aimed at helping
individual software engineers improve their skills, productivity, and quality of work.
Key aspects of PSP
 Focus on the individual: Unlike team-oriented processes, PSP emphasizes self-improvement and
developing disciplined work habits at a personal level.
 Metrics-driven approach: PSP relies heavily on collecting and analyzing personal data like time spent
on tasks, defects injected and removed, and lines of code (LOC) developed.
 Iterative learning: Engineers progress through different PSP levels (PSP0, PSP1, PSP2), introducing
increasing levels of discipline and process maturity.
 Improved quality and estimation: By tracking and analyzing data, engineers can identify their
strengths and weaknesses, improve estimation accuracy, and ultimately reduce defects in their
code.
PSP's goals and benefits
PSP aims to provide software engineers with disciplined methods to improve their personal software
development processes, specifically to improve estimation and planning, manage project quality through
defect prevention, and reduce defects.
PSP's structure
PSP training advances through levels:
 PSP0: Establishes a baseline by measuring time, defects, and program size.
 PSP1: Introduces techniques for estimating size, effort, and scheduling.
 PSP2: Focuses on defect prevention and removal using design and code reviews.
 PSP3: Engineers personalize and optimize their processes using data for improvement.

PSP activities
PSP involves activities including planning, high-level design and review, development (coding, reviewing,
compiling, testing), and a postmortem analysis.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

Importance of data in PSP-

Data is crucial for understanding and improving process performance in PSP. This data is collected using
scripts, measures, standards, and forms. Core measures include size (LOC), effort (time), quality (defects),
and schedule. Derived measures can calculate estimation accuracy, productivity, defect density, and review
rates.
PSP and its relation to TSP-
PSP is a foundation for the Team Software Process (TSP) (TSP). PSP-trained developers often form TSP
teams, using their personal data to plan and manage team projects.
PSP and other methodologies-
PSP can be adapted to various methodologies, including Agile. While PSP is predictive and Agile is adaptive,
both emphasize team organization and member responsibility. PSP differs from some Agile approaches by
focusing on detailed process documentation and data for predicting schedules.
Six Sigma
Six Sigma, a data-driven quality management methodology originating in manufacturing, has been
increasingly adopted in software project management to enhance efficiency, reduce defects, and improve
overall software quality and customer satisfaction.
Key concepts
 Focus on the Customer: Prioritizing and delivering software solutions that meet user needs and
expectations.
 Data-Driven Decision Making: Relying on metrics and data analysis to identify problems, analyze
root causes, and evaluate improvement initiatives.
 Process Optimization: Streamlining software development processes, including planning, design,
implementation, testing, and deployment, to enhance efficiency and quality.
 Defect Elimination: Identifying and eliminating the root causes of software defects and errors using
tools like Root Cause Analysis (RCA) and Failure Mode and Effects Analysis (FMEA).
 Variation Reduction: Minimizing inconsistencies in software development processes to ensure
consistent quality and predictable outcomes.
 Continuous Improvement: Fostering a culture of ongoing enhancement, iterative refinement, and
learning within the software development lifecycle.
Methodologies
Six Sigma utilizes two primary methodologies in software projects:
I. DMAIC (Define, Measure, Analyze, Improve, Control): This approach focuses on improving existing
software development processes.
1. Define: Identify the problem or improvement opportunity, establish project goals and customer
requirements, and define the scope of the project.
2. Measure: Collect data on the current performance of the software development process, using
metrics like defect rates and cycle time, and establish a baseline.
3. Analyze: Analyze the collected data to identify the root causes of defects or inefficiencies and
understand the relationship between inputs and outputs.
4. Improve: Develop and implement solutions to address the root causes, refine coding practices,
enhance testing strategies, and automate tasks.
5. Control: Establish controls and monitoring mechanisms to sustain the improvements, document
new processes, and provide ongoing training.
II. DMADV (Define, Measure, Analyze, Design, Verify): This methodology is used for designing new
software products or processes or when a complete overhaul of an existing process is required.

NIT, Chandaka, Bhubaneswar

 A quick reference note on Software Project Management

1. Define: Identify customer needs and requirements, and establish the project objectives for the new
software or process.
2. Measure: Capture the Voice of the Customer (VOC) to evaluate design parameters and feasibility.
3. Analyze: Explore different solutions and technical frameworks for the new software or process
design.
4. Design: Develop a detailed blueprint or architecture for the new software solution.
5. Verify: Test and validate the final product or process against customer requirements and
specifications to ensure it meets the desired quality standards.
Benefits
Applying Six Sigma in software project management offers several advantages:
 Improved Software Quality and Reliability: By systematically identifying and eliminating defects, Six
Sigma enhances the reliability and stability of software products.
 Increased Efficiency and Productivity: Optimizing development processes and reducing waste
through Lean principles leads to faster delivery times and more efficient resource utilization.
 Reduced Costs: Preventing defects and minimizing rework significantly lowers development and
maintenance costs.
 Enhanced Customer Satisfaction: Delivering higher quality software that consistently meets
customer needs and expectations translates into greater customer satisfaction and retention.
 Better Collaboration and Communication: Six Sigma encourages a collaborative and data-driven
approach, fostering better communication among team members and stakeholders.
 Alignment with Strategic Goals: By focusing on measurable results and customer needs, Six Sigma
helps align software development efforts with overall business objectives.
Challenges and solutions
 Resistance to Change: Employees may be reluctant to adopt new methodologies. To overcome this,
it's essential to communicate the benefits of Six Sigma clearly, provide adequate training and
support, and involve employees in the process from the beginning.
 Inadequate Training and Education: Six Sigma requires specialized knowledge and skills in statistical
analysis and data-driven decision-making. Providing comprehensive training and education to team
members is crucial for successful implementation.
 Lack of Management Support: Without strong leadership commitment and backing, Six Sigma
initiatives may struggle to gain traction and secure necessary resources. Organizations need to
actively involve senior management and demonstrate the potential benefits of the methodology to
gain their support.
 Defining Clear Goals and Metrics: Setting SMART (Specific, Measurable, Achievable, Relevant, Time-
bound) goals and tracking key performance indicators (KPIs) is essential to measure progress and
demonstrate the impact of Six Sigma initiatives.
 Data Quality and Availability: Six Sigma relies heavily on accurate data. Challenges may arise from
poor data quality or limited access to relevant data. Establishing robust data collection methods,
verifying data sources, and ensuring data quality are crucial for effective implementation.
Six Sigma, when effectively implemented, can significantly benefit software project management by driving
continuous process improvement, reducing defects, and delivering high-quality software solutions that
meet customer expectations and organizational goals.

NIT, Chandaka, Bhubaneswar