BE (CS)

Fall 2022 Semester

CS-435: Software Project Management

Lectures 5 & 6
Project Planning

Dr Syed Zaffar Qasim

Assistant Professor (CIS)

Project Planning
Identifying the activities, resources required, milestones and
deliverables produced by a project.
 Project planning takes place at three stages in a
project life cycle:
1. Proposal stage
o Planning at this stage is inevitably speculative
being based on a high-level description of the
software functionality.
o Plan needed here to decide about
the resources to complete the work and
to work out the price that should be quoted to a
customer.

SPM (CS-435) 1
 Project Planning
2. Project startup phase
o At this stage, more information about the
requirements are available.
o The aim here is to create a project plan with enough
detail to help make decisions about
Breaking the project into subactivities
resource allocation,
project staffing and
budgeting.
o It helps to decide if you need to hire new staff.

Project Planning
3. Development phase (cont’d)
o The project plan always evolves during the
development because of requirements changes,
technology issues, and development problems.
o More information available about the capabilities of
your development team.
o Therefore, the schedule, cost estimate, and risks all
have to be revised as the software is developed.
o This information allows you to make more accurate
estimates of how long the work will take.

SPM (CS-435) 2
 Task Set for Project Planning

1.Establish project scope

2.Determine feasibility
3.Analyze risks
4.Define required resources.
a)human resources.
b)reusable software resources.
c)environmental resources.

Task Set for Project Planning

5.Estimate cost and effort.
a)Decompose the problem.
b)Develop two or more estimates using size,
function points, process tasks, or use cases.
c)Reconcile the estimates.
6.Develop a project schedule
a)Establish a meaningful task set.
b)Define a task network.
c)Use scheduling tools to develop a time-line
chart.
d)Define schedule tracking mechanisms.

SPM (CS-435) 3
 Software Scope
 Software scope describes
o the functions to be delivered to end users;
o the data that are input and output;
o the “content” that is presented to users as a
consequence of using the software;
o and the performance, constraints, interfaces, and
reliability that bound the system.
 Scope is defined using one of two techniques:
1. A narrative description of software scope is
developed after communication with all
stakeholders.
2. A set of use cases is developed by end users.
7

Software Scope

 Because both cost and schedule estimates are

functionally oriented, some degree of decomposition
is often useful.
 Performance considerations encompass processing
and response time requirements.
 Constraints identify limits placed on the software by
external hardware, available memory, or other
existing systems.

SPM (CS-435) 4
 Feasibility
 Once scope has been identified, it is reasonable to ask:
Can we build software to meet this scope?
 Four solid dimensions of software feasibility
1. Technology — i.e. technically feasibility
o Is it within the state of the art?
o Can defects be reduced to a level matching the
application’s needs?
2. Finance—Is it financially feasible?
o Can development be completed at a cost the software
organization, its client, or the market can afford?
3. Time – Will the project’s time-to-market beat the
competition?
4. Resources – Does the organization have the resources
needed to succeed? 9

Identify required resources

 Figure 1 depicts the three major categories of
software engineering resources –
1. people,
2. reusable software components, and
3. the development environment (hardware and software
tools).

Fig 1: project resources

10

SPM (CS-435) 5
 Identify required resources
 Each resource is specified with four characteristics:
o description of the resource,
o a statement of availability,
o time when the resource will be required, and
o duration of time that the resource will be applied.
1. Human Resources
o The number of people required can be determined
only after an estimate of development effort (e.g.,
person-months) is made.
o For relatively small projects (a few person-months),
a single individual may perform all software
engineering tasks, consulting with specialists as
required. 11

Identify required resources

1. Human Resources (cont’d)
o For larger projects, the software team may be
geographically dispersed across a number of
different locations. Hence, the location of each
human resource is specified.
2. Reusable Software Resources
o Off-the-shelf components.
Ready for use components acquired from a third
party or from a past project.
COTS (commercial off-the-shelf) components are
purchased from a third party.

12

SPM (CS-435) 6
 Identify required resources
o Full-experience components.
Existing components developed for past projects,
similar to the software to be built.
Members of the current software team have had
full experience in the application area
represented by these components.
Therefore, modifications required for these
components will be relatively low risk.

13

Identify required resources

o Partial-experience components.
Existing components developed for past projects
that require substantial modification.
Members of the current software team have only
limited experience in the application area
represented by these components.
Therefore, modifications required for partial-
experience components have a fair degree of risk.

14

SPM (CS-435) 7
 Identify required resources
o New components.
Software components must be built by the
software team specifically for the needs of the
current project.
Ironically, reusable software components are
often neglected during planning.
It is better to specify software resource
requirements early.
In this way technical evaluation of the
alternatives can be conducted and timely
acquisition can occur.

15

Identify required resources

3. Environmental Resources (hardware and software)
o Hardware provides a platform that supports the tools
(software) required to produce the work products.
o When a computer-based system is to be engineered, the
software team may require access to hardware elements
being developed by other engineering teams.
o For example, software for a robotic device may require
a specific robot (e.g., a robotic welder) as part of the
validation test step;
o a software project for advanced page layout may need a
high-speed digital printing system during
development.
o Each hardware element must be specified as part of
planning.
16

SPM (CS-435) 8
 Project planning process

17

Milestones and deliverables

 Milestones: a recognisable end-point of a software

process activity.
o At each milestone, there should be a formal output,
such as a report, that can be presented to
management.
o Indefinite milestones such as Coding 80% complete
that can't be checked
are useless for project management
because the amount of code that still has to be
developed is uncertain.

18

SPM (CS-435) 9
 Milestones and deliverables
 Deliverable: a project result that is delivered to the
customer.
o It is usually delivered at the end of some major
project phase such as specification or design.
 Deliverables are usually milestones, but milestones
need not be deliverables.
 Milestones may be internal project results to check
project progress but which are not delivered to the
customer.

19

Milestones and deliverables

 For example, Fig 2 below shows possible activities
involved in requirements specification when
prototyping is used to help validate requirements.

Fig 2: Milestones in the requirements process

 The milestones in this case are the completion of the
outputs for each activity.
 The project deliverables, which are delivered to the
customer, are the requirements definition and the
requirements specification. 20

SPM (CS-435) 10