Software Project Management

Mr. Awadhesh Dixit

Assistant Professor,
Dept. of CSE,
SRM AP
Contents
Project Scheduling
Scheduling
Earned Value Analysis

Project Planning
Project Plan
Planning Process
 Why Are Projects
Late?
An unrealistic deadline established by someone outside
the software development group
Changing customer requirements that are not reflected
in schedule changes;
An honest underestimate of the amount of effort and/or
the number of resources that will be required to do the
job;
Predictable and/or unpredictable risks that were not
considered when the project commenced;
Technical difficulties that could not have been foreseen
in advance;
Human difficulties that could not have been foreseen in
advance;
Miscommunication among project staff that results in
delays; 3
Project Scheduling
Software project scheduling is an action that
distributes estimated effort across the planned
project duration by allocating the effort to specific
software engineering tasks.
Early stages of project planning- Macroscopic
schedule is developed. This type of schedule
identifies all major process framework activities and
the product functions to which they are applied.
As the project gets under way- Detailed schedule.
Here, specific software actions and tasks (required
to accomplish an activity) are identified and
scheduled.
 Scheduling
Principles
Compartmentalization
 The project must be compartmentalized into a number of manageable
activities, actions, and tasks; both the product and the process are
decomposed
Interdependency
 The interdependency of each compartmentalized activity, action, or task
must be determined
 Some tasks must occur in sequence while others can occur in parallel
 Some actions or activities cannot commence until the work product
produced by another is available
Effort validation
 Every project has a defined number of people on the team
 As time allocation occurs, the project manager must ensure that no more
5
than the allocated number of people have been scheduled at any given time
 Scheduling
Principles
Defined responsibilities
 Every task that is scheduled should be assigned to a specific
team member
Defined outcomes
 Every task that is scheduled should have a defined outcome for
software projects such as a work product or part of a work
product
 Work products are often combined in deliverables
Defined milestones
 Every task or group of tasks should be associated with a
project milestone
 A milestone is accomplished when one or more work products
has been reviewed for quality and has been approved
6
Effort Allocation
 “front end” activities
 customer
40-50% communication
 analysis
 design
 review and
modification
 construction activities
15-20%
 coding or code
generation
 testing and installation
 unit, integration
 white-box, black box
30-40%  regression

7
 40-20-40 Distribution of Effort
A recommended distribution of effort across the software
process is 40% (analysis and design), 20% (coding), and 40%
(testing)
Work expended on project planning rarely accounts for more
than 2 - 3% of the total effort
Requirements analysis may comprise 10 - 25%
 Effort spent on prototyping and project complexity may
increase this
Software design normally needs 20 – 25%
Coding should need only 15 - 20% based on the effort
applied to software design
Testing and subsequent debugging can account for 30 - 40%
 Safety or security-related software requires more time for
testing 8
Defining Task
Sets
Determine type of project
Assess the degree of rigor required
Identify adaptation criteria
Select appropriate software engineering
tasks

9
 Task Set
Refinement
1.1 Concept scoping determines the
overall scope of the project.
Task definition: Task 1.1 Concept Scoping
1.1.1 Identify need, benefits and potential customers;
1.1.2 Define desired output/control and input events that drive the application;
Begin Task 1.1.2
1.1.2.1 FTR: Review written description of need
FTR indicates that a formal technical review (Chapter 26) is to be conducted.
1.1.2.2 Derive a list of customer visible outputs/inputs
1.1.2.3 FTR: Review outputs/inputs with customer and revise as
required;
endtask Task 1.1.2
1.1.3 Define the functionality/behavior for each major function;
Begin Task 1.1.3
1.1.3.1 FTR: Review output and input data objects derived in task
1.1.2;
1.1.3.2 Derive a model of functions/behaviors;
1.1.3.3 FTR: Review functions/behaviors with customer and revise as

is refined to required;
endtask Task 1.1.3
1.1.4 Isolate those elements of the technology to be implemented in software;
1.1.5 Research availability of existing software;
1.1.6 Define technical feasibility;
1.1.7 Make quick estimate of size;
1.1.8 Create a Scope Definition;
endTask definition: Task 1.1
10
 Purpose of a Task Network
Also called an activity network
It is a graphic representation of the task flow for a
project
It depicts task length, sequence, concurrency, and
dependency
Points out inter-task dependencies to help the
manager ensure continuous progress toward project
completion
The critical path
 A single path leading from start to finish in a task
network
 It contains the sequence of tasks that must be
11
Example Task Network
Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12

13
Use Automated Tools to Derive a Timeline Chart

These slides are designed to accompany

Software Engineering: A Practitioner’s
Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman. 14
Schedule Tracking
Conduct periodic project status meetings in which each
team member reports progress and problems.
Evaluate the results of all reviews conducted throughout
the software engineering process.
Determine whether formal project milestones (the
diamonds shown in Figure) have been accomplished by
the scheduled date.
Compare actual start-date to planned start-date for each
project task listed in the resource table (Figure ).
Meet informally with practitioners to obtain their
subjective assessment of progress to date and problems
on the horizon.
Use earned value analysis to assess progress
 Earned Value Analysis (EVA)
Earned value
is a measure of progress

enables us to assess the “percent of

completeness” of a project using quantitative
analysis rather than rely on a gut feeling
 “provides accurate and reliable readings of
performance from as early as 15 percent into the
project.” [Fle98]

17
 Computing Earned Value-I
The Budgeted Cost of Work Scheduled (BCWS) is
determined for each work task represented in the
schedule.
 BCWSi is the effort planned for work task i.

 To determine progress at a given point along the

project schedule, the value of BCWS is the sum of the
BCWSi values for all work tasks that should have been
completed by that point in time on the project
schedule.

The BCWS values for all work tasks are summed to

derive the Budget At Completion, (BAC). Hence,

BAC = ∑ (BCWSk) for all tasks k

 Computing Earned Value-II
Next, the value for Budgeted Cost of Work Performed (BCWP)
is computed.
 The value for BCWP is the sum of the BCWS values for all work tasks
that have actually been completed by a point in time on the project
schedule.

 “The distinction between the BCWS and the BCWP is that the
former represents the budget of the activities that were
planned to be completed and the latter represents the budget
of the activities that actually were completed.” [Wil99]
Given values for BCWS, BAC, and BCWP, important progress
indicators can be computed:

 Schedule performance index, SPI = BCWP/BCWS

 Schedule variance, SV = BCWP – BCWS

 SPI is an indication of the efficiency with which the project

Computing Earned Value-III
Percent scheduled for completion = BCWS/BAC

 provides an indication of the percentage of work that

should have been completed by time t.
Percent complete = BCWP/BAC

 provides a quantitative indication of the percent of

completeness of the project at a given point in time, t.
Actual cost of work performed, ACWP, is the sum
of the effort actually expended on work tasks that
have been completed by a point in time on the
project schedule. It is then possible to compute
 Cost performance index, CPI = BCWP/ACWP

 Cost variance, CV = BCWP – ACWP

Software Project Planning
The overall goal of project planning is to
establish a pragmatic strategy for
controlling, tracking, and monitoring a
complex technical project.

Why?

So the end result gets done on time, with

quality!

The objective of software project planning is to

provide a framework that enables the manager to
make reasonable estimates of resources, cost, and
schedule. 21
 Project Planning Process
Task sets for Project planning
Establish project scope

Determine feasibility

Analyze risks

Define required resources

Determine required human resources

Define reusable software resources

Identify environmental resources

22
 Project Planning Process
Estimate cost and effort
 Decompose the problem

 Develop two or more estimates using size, function

points, process tasks or use-cases
 Reconcile the estimates

Develop a project schedule

 Establish a meaningful task set

 Define a task network

 Use scheduling tools to develop a timeline chart

 Define schedule tracking mechanisms

23
 What is Scope?
Software scope describes
 The functions and features that are to be delivered to
end-users
 The data that are input and output
 The “content” that is presented to users as a
consequence of using the software
 The performance, constraints, interfaces, and reliability
that bound the system.
Scope is defined using one of two techniques:
 A narrative description of software scope is developed
after communication with all stakeholders.
 A set of use-cases is developed by end-users.
24
Feasibility
Once scope has been identified (with the
concurrence of the customer), it is reasonable
to ask:
 Can we build software to meet this scope?
 Is the project feasible?”

Once scope is understood, the software team

and others must work to determine if it can
be done within the dimensions just noted.
 Resource Estimation
Three major categories of software engineering
resources
 People
 Development environment
 Reusable software components
 Often neglected during planning but become a paramount
concern during the construction phase of the software process
Each resource is specified with
 A description of the resource
 A statement of availability
Time window
 The time when the resource will be required
 The duration of time that the resource will be applied

26
Categories of Resources
People Development Environment
- Number required - Software tools
- Skills required - Computer hardware
- Geographical location - Network resources

The
Project

Reusable Software Components

- Off-the-shelf components
- Full-experience components
- Partial-experience components
- New components

27
 Human Resources
Planners need to select the number and the kind
of people skills needed to complete the project
They need to specify the organizational position
and job specialty for each person
Small projects of a few person-months may only
need one individual
Large projects spanning many person-months or
years require the location of the person to be
specified also
The number of people required can be
determined only after an estimate of the
development effort
28
Development Environment Resources
A software engineering environment (SEE)
incorporates hardware, software, and network
resources that provide platforms and tools to
develop and test software work products
Most software organizations have many projects
that require access to the SEE provided by the
organization
Planners must identify the time window required
for hardware and software and verify that these
resources will be available

29
 Reusable Software Resources
Off-the-shelf components
 Components are from a third party or were
developed for a previous project
 Ready to use; fully validated and documented;
virtually no risk
Full-experience components
 Components are similar to the software that needs
to be built
 Software team has full experience in the
application area of these components
 Modification of components will incur relatively low
risk
30
Estimating Cost and Effort
Project scope must be explicitly defined. If not, the
project may be infeasible.
Task and/or functional decomposition is necessary.
Historical measures (metrics) are very helpful.
Triangulation: At least two different techniques
should be used.
Remember that uncertainty is inherent in early
estimates.
Techniques:
1. Delay estimation until late in the project (not advisable)
2. Base estimates on similar projects that have already been
completed.
3. Use relatively simple decomposition techniques (LOC or FP) .
4. Use one or more empirical models for software cost.
Estimation Techniques
• Past (similar) project experience
• Conventional estimation techniques
– task breakdown and effort
estimates
– size (e.g., FP) estimates
• Empirical models
• Automated tools

33