UNIT III

Task and Activities in SPM:

Software Project Management consists of many activities, that includes planning of the
project, deciding the scope of product, estimation of cost in different terms, scheduling of
tasks, etc.
The list of activities are as follows:
1. Project planning and Tracking
2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management
1. Project Planning: It is a set of multiple processes, or we can say that it a task that
performed before the construction of the product starts.
2. Scope Management: It describes the scope of the project. Scope management is important
because it clearly defines what would do and what would not. Scope Management create the
project to contain restricted and quantitative tasks, which may merely be documented and
successively avoids price and time overrun.
3. Estimation management: This is not only about cost estimation because whenever we start
to develop software, but we also figure out their size(line of code), efforts, time as well as
cost.
If we talk about the size, then Line of code depends upon user or software requirement.
If we talk about effort, we should know about the size of the software, because based on the
size we can quickly estimate how big team required to produce the software.
If we talk about time, when size and efforts are estimated, the time required to develop the
software can easily determine.
And if we talk about cost, it includes all the elements such as:
o Size of software
o Quality
o Hardware
o Communication
 o Training
o Additional Software and tools
o Skilled manpower
4. Scheduling Management: Scheduling Management in software refers to all the activities to
complete in the specified order and within time slotted to each activity. Project managers
define multiple tasks and arrange them keeping various factors in mind.
For scheduling, it is compulsory -
o Find out multiple tasks and correlate them.
o Divide time into units.
o Assign the respective number of work-units for every job.
o Calculate the total time from start to finish.
o Break down the project into modules.
5. Project Resource Management: In software Development, all the elements are referred to
as resources for the project. It can be a human resource, productive tools, and libraries.
Resource management includes:
o Create a project team and assign responsibilities to every team member
o Developing a resource plan is derived from the project plan.
o Adjustment of resources.
6. Project Risk Management: Risk management consists of all the activities like
identification, analyzing and preparing the plan for predictable and unpredictable risk in the
project.
Several points show the risks in the project:
o The Experienced team leaves the project, and the new team joins it.
o Changes in requirement.
o Change in technologies and the environment.
o Market competition.
7. Project Communication Management: Communication is an essential factor in the success
of the project. It is a bridge between client, organization, team members and as well as other
stakeholders of the project such as hardware suppliers.
From the planning to closure, communication plays a vital role. In all the phases,
communication must be clear and understood. Miscommunication can create a big blunder in
the project.
8. Project Configuration Management: Configuration management is about to control the
changes in software like requirements, design, and development of the product.
The Primary goal is to increase productivity with fewer errors.
Some reasons show the need for configuration management:
o Several people work on software that is continually update.
o Help to build coordination among suppliers.
o Changes in requirement, budget, schedule need to accommodate.
o Software should run on multiple systems.
Tasks perform in Configuration management:
o Identification
o Baseline
o Change Control
o Configuration Status Accounting
o Configuration Audits and Reviews
People involved in Configuration Management:
Project Size Estimation Techniques :
In the fast-paced world of Software Engineering, accurately estimating the size of a project is
key to its success. Understanding how big a project will be helps predict the resources, time,
and cost needed, ensuring the project starts off on the right foot.
Project Size Estimation Techniques are vital because they allow you to plan and allocate the
necessary resources effectively.
Project Size Estimation:
Project size estimation is determining the scope and resources required for the project.
1. It involves assessing the various aspects of the project to estimate the effort, time,
cost, and resources needed to complete the project.
2. Accurate project size estimation is important for effective and efficient project
planning, management, and execution.
Importance of Project Size Estimation:
Here are some of the reasons why project size estimation is critical in project management:
1. Financial Planning: Project size estimation helps in planning the financial aspects of
the project, thus helping to avoid financial shortfalls.
2. Resource Planning: It ensures the necessary resources are identified and allocated
accordingly.
3. Timeline Creation: It facilitates the development of realistic timelines and milestones
for the project.
4. Identifying Risks: It helps to identify potential risks associated with overall project
execution.
5. Detailed Planning: It helps to create a detailed plan for the project execution, ensuring
all the aspects of the project are considered.
6. Planning Quality Assurance: It helps in planning quality assurance activities and
ensuring that the project outcomes meet the required standards.
Different Methods of Project Estimation
1. Expert Judgment: In this technique, a group of experts in the relevant field estimates
the project size based on their experience and expertise. This technique is often used
when there is limited information available about the project.
2. Analogous Estimation: This technique involves estimating the project size based on
the similarities between the current project and previously completed projects. This
technique is useful when historical data is available for similar projects.
 3. Bottom-up Estimation: In this technique, the project is divided into smaller modules
or tasks, and each task is estimated separately. The estimates are then aggregated to
arrive at the overall project estimate.
4. Three-point Estimation: This technique involves estimating the project size using
three values: optimistic, pessimistic, and most likely. These values are then used to
calculate the expected project size using a formula such as the PERT formula.
5. Function Points: This technique involves estimating the project size based on the
functionality provided by the software. Function points consider factors such as
inputs, outputs, inquiries, and files to arrive at the project size estimate.
6. Use Case Points: This technique involves estimating the project size based on the
number of use cases that the software must support. Use case points consider factors
such as the complexity of each use case, the number of actors involved, and the
number of use cases.
7. Parametric Estimation: For precise size estimation, mathematical models founded on
project parameters and historical data are used.
8. COCOMO (Constructive Cost Model): It is an algorithmic model that estimates
effort, time, and cost in software development projects by taking into account several
different elements.
9. Wideband Delphi: Consensus-based estimating method for balanced size estimations
that combines expert estimates from anonymous experts with cooperative
conversations.
10. Monte Carlo Simulation: This technique, which works especially well for complicated
and unpredictable projects, estimates project size and analyses hazards using
statistical methods and random sampling.
Each of these techniques has its strengths and weaknesses, and the choice of technique
depends on various factors such as the project’s complexity, available data, and the expertise
of the team.
Estimating the Size of the Software:
Estimation of the size of the software is an essential part of Software Project Management. It
helps the project manager to further predict the effort and time that will be needed to build the
project. Here are some of the measures that are used in project size estimation:
1. Lines of Code (LOC)
As the name suggests, LOC counts the total number of lines of source code in a project. The
units of LOC are:
1. KLOC: Thousand lines of code
2. NLOC: Non-comment lines of code
3. KDSI: Thousands of delivered source instruction
  The size is estimated by comparing it with the existing systems of the same kind. The
experts use it to predict the required size of various components of software and then
add them to get the total size.
 It’s tough to estimate LOC by analyzing the problem definition. Only after the whole
code has been developed can accurate LOC be estimated. This statistic is of little
utility to project managers because project planning must be completed before
development activity can begin.
 Two separate source files having a similar number of lines may not require the same
effort. A file with complicated logic would take longer to create than one with simple
logic. Proper estimation may not be attainable based on LOC.
 The length of time it takes to solve an issue is measured in LOC. This statistic will
differ greatly from one programmer to the next. A seasoned programmer can write the
same logic in fewer lines than a newbie coder.
Advantages:
1. Universally accepted and is used in many models like COCOMO.
2. Estimation is closer to the developer’s perspective.
3. Both people throughout the world utilize and accept it.
4. At project completion, LOC is easily quantified.
5. It has a specific connection to the result.
6. Simple to use.
Disadvantages:
1. Different programming languages contain a different number of lines.
2. No proper industry standard exists for this technique.
3. It is difficult to estimate the size using this technique in the early stages of the project.
4. When platforms and languages are different, LOC cannot be used to normalize.
2. Number of Entities in ER Diagram:
ER model provides a static view of the project. It describes the entities and their
relationships. The number of entities in the ER model can be used to measure the estimation
of the size of the project. The number of entities depends on the size of the project. This is
because more entities needed more classes/structures thus leading to more coding.
Advantages:
1. Size estimation can be done during the initial stages of planning.
2. The number of entities is independent of the programming technologies used.
Disadvantages:
1. No fixed standards exist. Some entities contribute more to project size than others.
 2. Just like FPA, it is less used in the cost estimation model. Hence, it must be converted
to LOC.
3. Total Number of Processes in DFD:
Data Flow Diagram(DFD) represents the functional view of software. The model depicts the
main processes/functions involved in software and the flow of data between them. Utilization
of the number of functions in DFD to predict software size. Already existing processes of
similar type are studied and used to estimate the size of the process. The sum of the estimated
size of each process gives the final estimated size.
Advantages:
1. It is independent of the programming language.
2. Each major process can be decomposed into smaller processes. This will increase the
accuracy of the estimation.
Disadvantages:
1. Studying similar kinds of processes to estimate size takes additional time and effort.
2. All software projects are not required for the construction of DFD.
4. Function Point Analysis:
In this method, the number and type of functions supported by the software are utilized to
find FPC(function point count). The steps in function point analysis are:
1. Count the number of functions of each proposed type.
2. Compute the Unadjusted Function Points(UFP).
3. Find the Total Degree of Influence(TDI).
4. Compute Value Adjustment Factor(VAF).
5. Find the Function Point Count(FPC).
Stages of Project size Estimation:
Project size estimates must take place at multiple key points throughout the project lifecycle.
It should take place during the following stages to ensure accuracy and relevance:
1. Project Initiation: Project is assessed to determine its feasibility and scope.
2. Project Planning: Precise estimates are done to create a realistic budget and timeline.
3. Project Execution: Res-estimation when there are significant changes in scope.
4. Project Monitoring and Control: Regular reviews to make sure that the project is on
track.
5. Project Closeout: Comparing original estimates with actual outcomes and
documenting estimation accuracy.
Challenges in Project Size Estimation
Project size estimation can be challenging due to multiple factors. Here are some factors that
can affect the accuracy and reliability of estimates:
1. Unclear Requirements: Initial project requirements can be vague or subject to change,
thus making it difficult to estimate accurately.
2. Lack of Historical Data: Without access to the data of similar past projects, it becomes
difficult to make informed estimates, thus estimates becoming overly optimistic or
pessimistic and leading to inaccurate planning.
3. Interdependencies: Project with numerous interdependent tasks are harder to estimate
due to the complicated interactions between components.
4. Productivity Variability: Estimating the productivity of resources and their availability
can be challenging due to fluctuations and uncertainties.
5. Risks: Identifying and quantifying risks and uncertainties is very difficult.
Underestimating the potential risks can lead to inadequate contingency planning, thus
causing the project to go off track.
Future of Project Size Estimation
The future of project size estimation will be shaped by the advancements in technology and
methodologies. Here are some key developments that can define the future of project size
estimation:
1. Smarter Technology: Artificial intelligence (AI) could analyze past projects and code
to give more accurate forecasts, considering how complex the project features are.
2. Data-Driven Insights: Instead of just lines of code, estimates could consider factors
like the number of users, the type of software (mobile app vs. web app), and how
much data it handles.
3. Human-AI Collaboration: Combining human expertise with AI can enhance the
decision-making process in project size estimation.
4. Collaborative Platforms: Tools that facilitate collaboration among geographically
dispersed teams can help to enhance the project size estimation process.
5. Agile Methodologies: The adoption of agile methodologies can promote continuous
estimation and iterative refinement.
SOFTWARE REUSE ESTIMATION
Software reuse estimation" in Software Project Management (SPM) refers to the process of
predicting how much existing software components (like code modules, libraries, or
frameworks) can be reused in a new project, allowing for estimations of development time,
cost savings, and overall project feasibility by leveraging pre-built elements instead of
creating everything from scratch.
Key aspects of software reuse estimation:
 Identifying reusable components:
Analyzing existing software libraries, frameworks, and codebases to identify components that
could potentially be adapted for the new project.
 Assessing reusability factors:
Evaluating factors like component quality, documentation, modularity, compatibility, and
potential adaptation effort needed to integrate the reused component.
 Estimating reuse percentage:
Calculating the expected proportion of a new software system that can be built using reused
components, which impacts development time and cost.
Methods for software reuse estimation:
 Function Point Analysis (FPA):
A common method to measure software functionality based on features and complexity,
which can be used to estimate potential reuse based on similar functionalities in existing
systems.
 Object-Oriented Metrics:
Analyzing the number of classes, methods, and their relationships within a system to assess
reusability potential.
 Similarity analysis:
Using techniques like code similarity algorithms to identify code sections with high
resemblance between different projects.
 Expert judgment:
Leveraging the knowledge of experienced developers to estimate the feasibility and effort
required for reusing specific components.
Benefits of software reuse estimation:
 Reduced development time:
By utilizing existing code, developers can focus on new features rather than writing
everything from scratch.
 Cost reduction:
Lower development costs due to reduced coding effort and faster development time.
 Improved quality:
Reusing well-tested components can lead to higher quality software with fewer bugs.
 Increased consistency:
Consistent code across projects can improve maintainability and future updates.
Challenges in software reuse estimation:
 Identifying suitable components:
Finding components that are adaptable to the new project requirements while considering
potential integration complexities.
 Quality assessment:
Evaluating the quality and maintainability of existing components before incorporating them
into a new system.
 Adaptation effort:
Accurately estimating the effort needed to modify and integrate reused components into the
new project.
Software Cost Estimation:
For any new software project, it is necessary to know how much it will cost to develop and
how much development time will it take. These estimates are needed before development is
initiated, but how is this done? Several estimation procedures have been developed and are
having the following attributes in common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule
estimates.
6. Acquire one or more automated estimation tools.
Uses of Cost Estimation
1. During the planning stage, one needs to choose how many engineers are required for
the project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the project is
progressing according to the procedure and takes corrective action, if necessary.
Cost Estimation Models
A model may be static or dynamic. In a static model, a single variable is taken as a key
element for calculating cost and time. In a dynamic model, all variable are interdependent,
and there is no basic variable.
Static, Single Variable Models: When a model makes use of single variables to calculate
desired values such as cost, time, efforts, etc. is said to be a single variable model.
Static, Multivariable Models: These models are based on method (1), they depend on several
variables describing various aspects of the software development environment. In some
model, several variables are needed to describe the software development process, and
selected equation combined these variables to give the estimate of time & cost. These models
are called multivariable models.
Software development effort estimation:
Effort Estimation in Software Development:
Effort estimation is a process that forms part of the software development life cycle and is
key to the assessment of the probable number of hours that may be required for the
accomplishment of particular tasks in a software development project. In high-level
definition, effort estimation in software development is the process of quantifying the amount
of work that can be done in terms of person-hours or person-days needed to accomplish a
given task or the whole project. This involves, i.e., the whole process of the SDLC, that is,
the gathering of requirements and preparation of specifications, the design, the coding and
testing of the software, and the maintenance of the software. Effort estimation is an essential
part of project management, as it enables one to predict the amount of time necessary to
complete a project and coordinate the costs and quality of a project to meet customer
expectations.
Effort estimation is a fundamental task in software development, which is crucial in
managing and controlling the productivity process within a project as well as within the
software production organization in general.
Estimation Approaches:
Effort estimation approaches can be broadly categorized into the following:
 Expert Judgment: This approach is based on the perception of experts or some
particular teams and groups to make an estimation of the effort that will be required. It
is commonly used for the purpose of getting and consolidating the views of experts,
including the use of Delphi and Wideband Delphi.
  Analogous Estimation: This method is similar to the preceding one in that historical
data is also analyzed to establish the effort of a current project. It presumes that the
present project will go through formative processes just like past projects that were
implemented.
 Parametric Models: These models employ mathematical equations through which
effort is forecasted with the aid of project characteristics such as size, level of
difficulty, and the expertise of the staff to be enlisted. Traditional forecasting models
include COCOMO, which falls into the category of parametric models.
 Function Point Analysis (FPA): FPA has been defined to reflect the extent of
functionality that is delivered to the user, and this is the measure that FPA uses to
derive effort. Effort can be too complicated, where function points are counted,
including inputs, outputs, and/or queries, and conversion rates are used.
 Story Points and Agile Estimation: Also in Agile methodologies, activity valuation is
done in terms of story points, which is a measure of effort to implement a particular
user story. This ensures that team members attain consensus when estimating the story
points using various techniques, such as planning poker.
 Machine Learning-Based Estimation: Automated methods apply historical data from
completed projects to estimate effort using machine learning models. These models
can also be refined and modified as more ‘data‘, that is, more measuring, is carried
out.
Selection of Estimation Approaches
Choosing the right estimation approach depends on various factors, including:
 Project Size and Complexity: Larger, more complex projects may benefit from
parametric models or machine learning-based approaches, while smaller projects
might be effectively estimated using expert judgment or analogous estimation.
 Data Availability: If historical data is available, analogous estimation or machine
learning models can provide more accurate estimates. In the absence of such data,
expert judgment may be more reliable.
 Development Methodology: Agile projects often use story points and techniques like
planning poker, while traditional projects may rely more on parametric models and
function point analysis.
 Team Experience: The expertise and experience of the team can significantly
influence the accuracy of expert judgment-based estimates.
Assessing the Accuracy of Estimates
Assessing the accuracy of effort estimates involves comparing estimated effort with actual
effort after project completion. Common techniques include:
 Variance Analysis: Calculating the difference between estimated and actual effort to
identify deviations and understand their causes.
  Statistical Measures: Using metrics such as mean absolute error (MAE), mean
squared error (MSE), and mean magnitude of relative error (MMRE) to quantitatively
assess estimation accuracy.
 Post-Mortem Analysis: Conducting thorough reviews at the end of projects to
evaluate estimation performance and identify areas for improvement.
COCOMO Model:
The 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. 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.
The key parameters that define the quality of any software product, which are also an
outcome of COCOMO, are primarily effort and schedule:
1. Effort: Amount of labor that will be required to complete a task. It is measured in
person-months units.
2. Schedule: This simply means the amount of time required for the completion of the
job, which is, of course, proportional to the effort put in. It is measured in the units of
time such as weeks, and months.
Types of Projects in the 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.
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 these three types of Projects in COCOMO Model
Aspects Organic Semidetached Embedded

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

Complexity Low Medium High

Team Highly Some experienced as well Mixed experience,

Experience experienced as inexperienced staff includes experts

Flexible, fewer Somewhat flexible, Highly rigorous, strict

Environment constraints moderate constraints requirements

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

Simple payroll New system interfacing Flight control

Example system with existing systems software

Types of COCOMO Model:

There are three types of COCOMO Model:
 Basic COCOMO Model
 Intermediate COCOMO Model
 Detailed COCOMO Model
1. 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).
2. 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
3. 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.
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.
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.
COCOMO-II :
COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and
was developed at the University of Southern California. It is the model that allows one to
estimate the cost, effort, and schedule when planning a new software development activity.
Sub-Models of COCOMO Model

COCOMO Sub-models
1. End User Programming
Application generators are used in this sub-model. End user write the code by using these
application generators. For Example, Spreadsheets, report generator, etc.
2. Intermediate Sector
COCOMO Intermediate Sector
 Application Generators and Composition Aids: This category will create largely
prepackaged capabilities for user programming. Their product will have many
reusable components. Typical firms operating in this sector are Microsoft, Lotus,
Oracle, IBM, Borland, Novell.
 Application Composition Sector: This category is too diversified and to be handled by
prepackaged solutions. It includes GUI, Databases, domain specific components such
as financial, medical or industrial process control packages.
 System Integration: This category deals with large scale and highly embedded
systems.
3. Infrastructure Sector
This category provides infrastructure for the software development like Operating System,
Database Management System, User Interface Management System, Networking System, etc.
Stages of COCOMO II

Stages of COCOMO II:

1. Stage-I
It supports estimation of prototyping. For this it uses Application Composition Estimation
Model. This model is used for the prototyping stage of application generator and system
integration.
2. Stage-II
It supports estimation in the early design stage of the project, when we less know about it.
For this it uses Early Design Estimation Model. This model is used in early design stage of
application generators, infrastructure, system integration.
3. Stage-III
It supports estimation in the post architecture stage of a project. For this it uses Post
Architecture Estimation Model. This model is used after the completion of the detailed
architecture of application generator, infrastructure, system integration.
SEI CMM: Problems and Risks
The Capability Maturity Model (CMM) developed by the Software Engineering Institute
(SEI) provides a framework for improving software processes. While it offers numerous
benefits, there are challenges and risks associated with implementing and using SEI CMM.
Problems with SEI CMM
1. High Implementation Cost:
o Description: Adopting SEI CMM often requires significant financial and
resource investments.
o Impact: Smaller organizations may struggle to afford the required training,
tools, and assessments.
2. Time-Consuming Process:
o Description: Achieving higher maturity levels (e.g., Level 4 or Level 5) takes
substantial time.
o Impact: Organizations may face delays in seeing tangible benefits.
3. Overemphasis on Documentation:
o Description: SEI CMM requires extensive documentation to ensure process
standardization.
o Impact: May lead to bureaucracy and reduced flexibility, hindering innovation.
4. Resistance to Change:
o Description: Employees and management may resist process changes required
to meet CMM standards.
o Impact: Resistance can slow down or derail process improvement efforts.
5. One-Size-Fits-All Approach:
o Description: SEI CMM does not always adapt well to unique organizational
needs or non-software domains.
o Impact: Generic practices may not align with specific project requirements,
leading to inefficiencies.
6. Focus on Process Over Outcome:
 o Description: CMM emphasizes process maturity, which may not directly
correlate with project success.
o Impact: Organizations might excel in process compliance but fail to deliver
quality products.
7. Lack of ROI Clarity:
o Description: It may be difficult to quantify the return on investment (ROI)
from implementing SEI CMM.
o Impact: Organizations may abandon the model if immediate benefits are not
evident.
Risks Associated with SEI CMM:
1. Risk of Misalignment:
o Details: Processes might not align with organizational goals, leading to
inefficiencies.
o Mitigation: Regularly review and tailor processes to meet specific business
objectives.
2. Risk of Overhead:
o Details: The administrative burden of adhering to CMM practices can
overwhelm teams.
o Mitigation: Focus on practical, lean documentation and avoid unnecessary
complexity.
3. Risk of Non-Adoption:
o Details: Employees may fail to embrace new processes, resulting in poor
implementation.
o Mitigation: Engage stakeholders early and provide adequate training and
support.
4. Risk of Stagnation:
o Details: Organizations might stop evolving once they reach a certain maturity
level.
o Mitigation: Promote continuous improvement beyond achieving a specific
CMM level.
5. Risk of Dependency on Assessments:
o Details: Excessive reliance on external assessments can detract from actual
process improvements.
o Mitigation: Focus on internal evaluations and real progress rather than solely
aiming for certification.
 6. Competitive Disadvantage:
o Details: Competitors not using CMM may innovate faster due to greater
flexibility.
o Mitigation: Balance adherence to CMM with agility and adaptability.
Summary of Challenges
Problem/Risk Description Mitigation

High Implementation Financial burden on smaller Prioritize critical areas and secure
Cost organizations. funding.

Time-Consuming Long duration to achieve higher Break implementation into

Process maturity levels. manageable phases.

Overemphasis on Automate documentation and

Bureaucracy reduces flexibility.
Documentation streamline processes.

Employees resist process Foster a culture of change and

Resistance to Change
adjustments. inclusion.

Focus on Process Over Maturity does not guarantee Monitor both process and
Outcome project success. deliverable quality.
Organizational Planning in Software Project Management (SPM)
Organizational planning in SPM is the process of defining roles, responsibilities, and
relationships among project team members, as well as aligning organizational resources to
meet project goals. It ensures the smooth execution of the project by establishing clear
frameworks for communication, resource allocation, and decision-making.
Key Components of Organizational Planning
1. Defining Roles and Responsibilities:
o Establishing roles for all team members, such as project managers, developers,
testers, and analysts.
o Clearly outlining individual responsibilities to avoid duplication of effort and
confusion.
2. Organizational Structure:
o Deciding the structure to support project execution:
 Functional Structure: Resources are organized by department, and
team members report to departmental managers.
 Projectized Structure: A dedicated project team is formed, and
members report directly to the project manager.
 Matrix Structure: A hybrid structure where team members have dual
reporting lines (functional and project managers).
 3. Resource Allocation:
o Identifying the resources (human, financial, technological) needed for the
project.
o Ensuring the availability and proper utilization of these resources throughout
the project lifecycle.
4. Skill Assessment and Training:
o Assessing the skill sets of team members.
o Organizing training sessions to fill skill gaps and ensure alignment with
project requirements.
5. Team Building:
o Encouraging collaboration and effective communication among team
members.
o Promoting a positive team culture to enhance productivity and morale.
6. Communication Planning:
o Defining how project information will be shared among stakeholders and team
members.
o Identifying communication methods, such as meetings, emails, reports, and
collaboration tools.
7. Risk Management Integration:
o Identifying potential risks related to resources, structure, and relationships.
o Developing strategies to mitigate these risks through contingency planning.
8. Stakeholder Engagement:
o Ensuring all stakeholders are involved and their expectations are managed.
o Defining roles for stakeholder interaction and decision-making.
Steps in Organizational Planning
1. Identify Objectives:
o Understand the project's goals and scope.
o Align organizational resources and structures to achieve these objectives.
2. Analyze Resource Needs:
o Determine the type and quantity of resources required.
o Ensure resources are allocated based on project priorities.
3. Develop Organizational Charts:
 o Create diagrams to represent the structure and reporting lines.
o Clearly define relationships between team members and management.
4. Assign Roles and Responsibilities:
o Use tools like the RACI matrix to assign accountability:
 Responsible: Person who performs the task.
 Accountable: Person ultimately answerable for the task.
 Consulted: Person(s) consulted for input.
 Informed: Person(s) kept informed of progress.
5. Create a Staffing Plan:
o Outline recruitment, onboarding, and training processes.
o Define the timeline for when specific resources will be required.
6. Implement Monitoring Mechanisms:
o Establish performance tracking systems to ensure the team adheres to the plan.
o Use key performance indicators (KPIs) to measure effectiveness.
Benefits of Organizational Planning in SPM
 Improved Clarity: Clearly defined roles and structures prevent confusion and ensure
accountability.
 Enhanced Efficiency: Optimal resource allocation leads to better utilization and
productivity.
 Better Communication: Structured communication channels reduce
misunderstandings.
 Risk Reduction: Proactive planning mitigates risks related to organizational resources.
 Alignment with Goals: Ensures the project aligns with overall organizational
objectives.
Challenges in Organizational Planning
 Resource Constraints: Limited resources can hinder planning and execution.
 Resistance to Change: Teams may resist new roles or structures.
 Dynamic Environments: Rapid changes in project scope or organizational priorities
may disrupt planning.
 Coordination Issues: Balancing the needs of different departments or stakeholders can
be challenging.
By implementing effective organizational planning, software projects can be executed with
greater precision, efficiency, and success.
PROJECT ROLES AND SKILLS NEEDED IN SPM:
In Software Project Management (SPM), successful execution of a project requires a team
with clearly defined roles and the appropriate skills. Each role contributes to the overall
planning, execution, and delivery of the software project.
Key Project Roles and Their Responsibilities
1. Project Manager (PM):
o Responsibilities:
 Define project scope, goals, and deliverables.
 Develop project plans, schedules, and budgets.
 Monitor progress and manage risks.
 Ensure stakeholder communication and satisfaction.
o Skills Needed:
 Leadership and decision-making.
 Risk management and problem-solving.
 Communication and negotiation.
 Proficiency in project management tools (e.g., MS Project, Jira).
2. Business Analyst (BA):
o Responsibilities:
 Gather and document project requirements.
 Act as a liaison between stakeholders and the development team.
 Ensure the solution aligns with business needs.
o Skills Needed:
 Analytical thinking and requirement elicitation.
 Stakeholder management.
 Knowledge of modeling tools (e.g., UML, BPMN).
3. Technical Lead/Architect:
o Responsibilities:
 Define the technical architecture and design.
 Ensure the technical feasibility of requirements.
 Provide guidance to the development team.
o Skills Needed:
 Deep understanding of system architecture and design patterns.
 Expertise in programming languages and tools.
 Problem-solving and mentorship.
4. Developers/Programmers:
 o Responsibilities:
 Write, test, and debug code.
 Implement features and functionalities as per requirements.
 Collaborate with QA and other team members.
o Skills Needed:
 Proficiency in programming languages (e.g., Java, Python, C++).
 Understanding of software development methodologies (e.g., Agile,
Scrum).
 Version control systems (e.g., Git).
5. Quality Assurance (QA) Tester:
o Responsibilities:
 Develop and execute test cases and scripts.
 Identify and report bugs and issues.
 Ensure the software meets quality standards.
o Skills Needed:
 Knowledge of testing tools (e.g., Selenium, JIRA).
 Familiarity with automated and manual testing techniques.
 Attention to detail and analytical thinking.
6. UI/UX Designer:
o Responsibilities:
 Design user interfaces and enhance user experience.
 Create prototypes and wireframes.
 Ensure designs align with user needs and project goals.
o Skills Needed:
 Proficiency in design tools (e.g., Adobe XD, Figma, Sketch).
 Understanding of user psychology and usability principles.
 Creativity and visual design skills.
7. DevOps Engineer:
o Responsibilities:
 Automate deployment processes and maintain CI/CD pipelines.
 Manage infrastructure and application monitoring.
 Ensure smooth collaboration between development and operations
teams.
o Skills Needed:
 Knowledge of cloud platforms (e.g., AWS, Azure).
  Expertise in DevOps tools (e.g., Jenkins, Docker, Kubernetes).
 Strong scripting and automation skills.
8. Database Administrator (DBA):
o Responsibilities:
 Design and maintain the database schema.
 Ensure data security, backup, and recovery.
 Optimize database performance.
o Skills Needed:
 Proficiency in database management systems (e.g., SQL Server,
MySQL, PostgreSQL).
 Understanding of database design and optimization.
 Problem-solving and analytical skills.
9. Scrum Master (for Agile Projects):
o Responsibilities:
 Facilitate Scrum ceremonies (e.g., stand-ups, retrospectives).
 Remove impediments and ensure team alignment.
 Monitor and improve Agile processes.
o Skills Needed:
 Knowledge of Agile and Scrum frameworks.
 Strong facilitation and coaching skills.
 Conflict resolution and team-building.
10. Stakeholders:
o Responsibilities:
 Provide project requirements and approvals.
 Monitor project progress and provide feedback.
 Ensure alignment with business goals.
o Skills Needed:
 Clear communication and decision-making.
 Understanding of project goals and expectations.
Additional Skills Across Roles
 Soft Skills:
o Team collaboration and communication.
o Adaptability and time management.
o Problem-solving and critical thinking.
 Technical Skills:
 o Familiarity with software development lifecycle (SDLC).
o Knowledge of tools and platforms used in the project.
o Awareness of emerging technologies and best practices.
Summary of Roles and Skills
Role Core Skills

Project Manager Leadership, risk management, project planning tools.

Business Analyst Requirement gathering, stakeholder communication, modeling tools.

Technical Lead System architecture, coding expertise, problem-solving.

Developer Programming, version control, SDLC understanding.

QA Tester Testing techniques, tools expertise, attention to detail.

UI/UX Designer Design tools, user psychology, creativity.

DevOps Engineer Automation, cloud platforms, CI/CD knowledge.

Database Administrator Database management, optimization, data security.

Scrum Master Agile expertise, facilitation, conflict resolution.

Stakeholders Clear communication, decision-making, alignment with goals.

By assembling a team with these roles and skills, software projects can be effectively
managed and executed to meet objectives within time and budget constraints.