1.

Introduction to Software Project

Management
●​ Goal: To ensure a team of developers can work effectively to complete a project.
●​ Challenges in Software Projects:
○​ Invisibility: Unlike physical projects, progress in software development is hard to
measure.
○​ Changeability: Software requirements often change, making management
complex.
○​ Complexity: Software involves millions of interconnected components (functions,
data, files).
○​ Uniqueness: Each project has unique challenges, requiring a fresh approach.
○​ Team-oriented and intellect intensive work.

2. Responsibilities of a Software Project

Manager
A Software Project Manager (SPM) is responsible for:

1.​ Project Planning

○​ Estimating cost, duration, and effort.
○​ Scheduling manpower and resources.
○​ Risk management (identifying & mitigating risks).
○​ Quality assurance and configuration management.
2.​ Project Monitoring
○​ Ensuring the project stays on track, within budget, and meets deadlines.
○​ Managing changes in project scope.

Essential Skills for a Project Manager

●​ Knowledge of project management techniques.

●​ Decision-making capabilities.
●​ Previous experience in managing similar projects.
3. Project Planning
Once a project is found to be feasible, software project managers undertake project planning. It
happens before any development activities.

Key Aspects of Planning:

1.​ Estimation (Cost, Duration, Effort) ~ The effectiveness of all later planning activities
such as scheduling and staffing are dependent on the accuracy with which these three
estimations have been made.
2.​ Scheduling (Work Breakdown, Timelines)
3.​ Staffing (Organizing project team)
4.​ Risk Management (Identifying and reducing risks)
5.​ Quality Assurance & Configuration Management (Miscellaneous)

Sliding Window Planning

●​ Why? Large projects are hard to plan accurately from the start. During the span of the
project, the project parameters, scope of the project, project staff, etc., often change
drastically resulting in the initial plans going haywire.
●​ Solution: Plan in stages, update as the project progresses.
●​ Benefit: Reduces uncertainty, improves decision-making. Protects managers from
making big commitments at the start of the project..

The project parameters are re-estimated periodically as understanding grows and also
non-periodically as project parameters change.

By taking these developments into account, the project manager can plan the subsequent
activities more accurately and with increasing levels of confidence.
4. Project Size Estimation
Metrics for Estimating Project Size

1.​ Lines of Code (LOC)

○​ Counts the total lines of source code. The project manager divides the problem
into modules, and each module into sub-modules and so on, until the LOC of the
leaf-level modules are small enough to be predicted.
○​ Limitations:
■​ Only measures coding effort.
■​ Depends on the choice of specific instructions.
■​ Correlates poorly with the quality and efficiency of the code.
■​ Ignores design & documentation effort.
■​ Penalizes use of high-level programming languages.
■​ Difficult to accurately estimate LOC of final program from problem.
2.​ Function Point (FP)
○​ Proposed by Albrecht and Gaffney (1983).
○​ Can be computed from the problem specification itself.
○​ Measures software complexity based on the number of input/output
functions (high level functions), files, and interfaces.

○​ Compute the using a heuristic expression. Unadjusted function point (UFP).

Refine UFP to reflect the actual complexities of the different parameters used in
UFP computation. Compute FP by further refining UFP to account for the specific
characteristics of the project that can influence the entire development effort.
 ○​ Advantages:
■​ Independent of programming language.
■​ Can be computed from requirements (SRS).

5. Project Estimation Techniques

Three Main Approaches:

1.​ Empirical Estimation (Expert Judgement, Delphi Method)- essentially based on making
a guess of the project parameters. While using this technique, prior experience with
development of similar products is helpful. based on common sense and subjective
decisions, over the years.
2.​ Heuristic Estimation (COCOMO Model)- assume that the relationships that exist
among the different project parameters can be satisfactorily modelled using suitable
mathematical expressions.
3.​ Analytical Estimation (Halstead’s Software Science)- have certain scientific basis.

6. COCOMO (Constructive Cost Estimation

Model)
Developed by Barry Boehm (1981), it estimates effort, time, and cost based on project size
(LOC). In the first stage, an initial estimate is arrived at. Over the next two stages, the initial
estimate is refined to arrive at a more accurate estimate.
COCOMO Model Types
●​ Basic COCOMO
○​ Quick and rough estimation.
○​ Effort formula:

○​ Constants (a, b) depend on project type or project class:

■​ Organic: Small, well-understood projects, and the team members are
experienced in developing similar types of projects.
■​ Semi-Detached: Medium complexity, the development team consists of a
mixture of experienced and inexperienced staff. Team members may
have limited experience on related systems but may be unfamiliar with
some aspects of the system being developed.
■​ Embedded: Highly complex, hardware-integrated or stringent regulations
on the operational procedures exist. Team members may have limited
experience on related systems but may be unfamiliar with some aspects
of the system being developed.
Person-month (PM) is considered to be an appropriate unit for measuring effort, because
developers are typically assigned to a project for a certain number of months.

The effort required to develop a product increases rapidly with project size.

The development time is a sublinear function of the size of the product.

A project would also incur several other types of costs other than the calculated cost which we
refer to as the overhead costs.

Completing a project in a shorter period of time will increase the cost drastically. But completing
it over a longer period of time shows almost no decrease in the estimated cost value.

●​ Intermediate COCOMO
○​ The effort to develop a product would vary depending upon the sophistication of
the development environment. Adjusts effort using an Effort Adjustment Factor
(EAF).

The EAF is calculated by multiplying the parameter values of different cost driver
attributes. Ideally, the value is 1.

○​ Uses a set of 15 cost drivers (multipliers) that are determined based on various
attributes of software development.
■​ Product attributes

The product attributes are as follows:

1)​ Required software reliability extent

2)​ Size of the application database
3)​ The complexity of the product

■​ Computer attributes

The hardware attributes are as follows:

1)​ Run time performance constraints

 2)​ Memory constraints
3)​ The volatility of the virtual machine environment
4)​ Required turnabout time

■​ Personal attributes

The personal attributes are as follows:

1)​ Analyst capabilities

2)​ Software engineering capabilities
3)​ Applications experience
4)​ Virtual machine experience
5)​ Programming language experience

■​ Development Environment attributes

The project attributes are as follows:

1)​ Use of software tools

 2)​ Application of software engineering methods
3)​ Required development schedule

●​ Detailed COCOMO
○​ Combination of both the basic model and the intermediate model.
○​ Breaks project into subsystems.
○​ Estimates cost for each subsystem separately.
○​ The six stages of the detailed model are as follows:
■​ Planning and requirements
■​ System design
■​ Detailed design
■​ Module code and test
■​ Integration and test
■​ Cost constructive model

COCOMO II
●​ Modern extension of COCOMO (supports GUI & component-based software).
●​ Three models to be applied at the different stages of the same project:
1.​ Application Composition Model (Prototype Cost Estimation).
2.​ Early Design Model (Architecture Design Phase).
3.​ Post-Architecture Model (Final Development Stage).

7. Halstead’s Software Science

●​ Mathematical model for size, effort & cost estimation.
●​ Uses parameters:
○​ Operators (η1)
○​ Operands (η2)
○​ Total Operators (N1)
 ○​ Total Operands (N2)
●​ Computes:

Effort and Time: E=V/L ​ Length Estimation:_________________

8. Staffing Level Estimation

The staffing requirement for the project can be determined by:
●​ Norden’s Work

This model assumes that staffing follows a Rayleigh distribution curve:

●​ Staffing level gradually increases as the project progresses.

●​ Peak staffing happens near the middle of development.
●​ Declines in the later phases (maintenance needs fewer people).

where,

❖​ E is the effort required at time t.

❖​ E is an indication of the number of developers
❖​ K is the area under the curve, and
❖​ td is the time at which the curve attains its maximum value.

●​ Putnam’s Work

Only a small number of developers are needed at the beginning of a project to carry out
the planning and specification tasks. As the project progresses and more detailed work
is performed, the number of developers increases and reaches a peak during product
testing. After implementation and unit testing, the number of project staff falls.

where
❖​ K is the total effort expended (in PM) in the product development and
❖​ L is the product size in KLOC
❖​ td corresponds to the time of system and integration and testing. Therefore, td
can be approximately considered as the time required to develop the software.
❖​ Ck is the state of technology constant and reflects constraints that impede the
progress of the programmer.

typical values of
❖​ Ck = 2 for poor development environment (no methodology, poor documentation,
and review, etc.),
 ❖​ Ck = 8 for good software development environment (software engineering
principles are adhered to),
❖​ Ck = 11 for an excellent environment (in addition to following software
engineering principles, automated tools and techniques are used).

●​ Jansen’s Model

Similar to Putnam Model. Attempts to soften the effect of schedule compression on effort
to make it applicable to smaller and medium sized projects.

where,
❖​ Cte is the effective technology constant,
❖​ td is the time to develop the software, and
❖​ K is the effort needed to develop the software.

8. Scheduling Techniques
Steps for Scheduling a Software Project

1.​ Identify major activities.

2.​ Break down into tasks.
3.​ Define dependencies between tasks.
4.​ Estimate time required for each task.
5.​ Create an activity network (CPM/PERT charts).
6.​ Determine the Critical Path.
7.​ Allocate resources.

Work Breakdown Structure (WBS)

 ●​ Breaks project into smaller tasks.
●​ Each task is assigned to individual developers.

Activity Networks
Shows the different activities making up a project, their estimated durations, and their
interdependencies.

Two equivalent representations for activity networks are possible and are in use:
●​ Activity on Node (AoN): In this representation, each activity is represented by a
rectangular (some use circular) node and the duration of the activity is shown alongside
each task in the node. The inter-task dependencies are shown using directional edges
●​ Activity on Edge (AoE): In this representation tasks are associated with the edges. The
edges are also annotated with the task duration. The nodes in the graph represent
project milestones.
Critical Path Method (CPM)
●​ Identifies the longest sequence of dependent tasks (critical path).
●​ Critical task is the one with zero slack time.
●​ Determines earliest & latest start/finish times.
●​ Helps in resource optimization.

PERT (Project Evaluation & Review Technique)

●​ Estimates uncertain task durations using:

ET = (O + 4M + W ) / 6​

○​ Optimistic (O), Most Likely (M), Worst Case (W).

●​ Computes variance to assess project risks.

Gantt Charts
●​ Visual timeline representation of project tasks. A form of bar chart where each bar
represents an activity.
●​ Indicates task duration & dependencies.
9. Risk Management
A risk is any anticipated unfavourable event or circumstance that can occur while a project is
underway. Risk management aims at reducing the chances of a risk becoming real as well as
reducing the impact of a risk that becomes real.

Three essential activities: Identification, Assessment and Mitigation.

Reactive and Proactive approaches.

Types of Risks- Identification

1.​ Project Risks (Budget, Schedule, Staffing)

2.​ Technical Risks (Design, Implementation, Testing)
3.​ Business Risks (Market Demand, Financial Loss)

Risk Assessment
For risk assessment, first each risk should be rated in two ways:
●​ The likelihood of a risk becoming real (r).
●​ The consequence of the problems associated with that risk (s).

Based on these two factors, the priority of each risk can be computed as follows: p = r × s

Risk Management Strategies

1.​ Avoid Risk (Modify constraints).

2.​ Transfer Risk (Outsource work, Insurance).
3.​ Reduce Risk (Plan mitigation strategies- plan the ways to contain the risk).