Software Project Management

Software Project Planning

1
Integration Management – Main Role of a
Project Manager
Team Members Role – Concentrating on completing their work
packages
Project Sponsor – Protecting the project from changes and loss of
resources
Project Manager – To put all the pieces of the project together into one
cohesive whole that gets the project done faster, cheaper and with
fewer resources while meeting the project objectives.

2
3
4
 Identifying Needs
The project manager drives the scope of
the project.
The project manager should identify and
talk to the main stakeholder
The effective way to show stakeholders that
their needs are understood and that those
specific needs will be addressed is with a
vision and scope document

5
Vision and Scope Document
A typical vision and scope document follows an
outline like this one:
1. Problem Statement
a) Project background
b) Stakeholders
c) Users
d) Risks
e) Assumptions
2. Vision of the Solution
a) Vision statement
b) List of features
c) Scope of phased release (optional)
d) Features that will not be developed

6
 Statement of Work
The statement of work (SOW) is a detailed
description of all of the work products which
will be created over the course of the project.
It includes:
A list of features that will be developed
A description of each intermediate deliverable or
work product that will be built.
The estimated effort involved for each work
product to be delivered

7
 Resource List
The project plan should contain a list of all
resources that will be used on the project.
A resource is a person, hardware, room or
anything else that is necessary for the project but
limited in its availability
The resource list should give each resource a
name, a brief one-line description, and list the
availability and cost (if applicable) of the resource

8
Estimates and Project Schedule
The project plan should also include estimates and a
project schedule:
 A work breakdown structure (WBS) is defined. This is a list
of tasks which, if performed, will generate all of the work
products needed to build the software.
 An estimate of the effort required for each task in the WBS is
generated.
 A project schedule is created by assigning resources and
determining the calendar time required for each task.

Estimates and project schedules will be discussed in

detail in later slides.

9
 Risk Plan
A risk plan is a list of all risks that threaten the
project, along with a plan to mitigate some or
all of those risks.
The project manager selects team members to
participate in a risk planning session:
• The team members brainstorm potential risks
• The probability and impact of each risk is estimated
• A risk plan is constructed

10
Risk Plan Example

11
 Stepwise Project Planning
Step 0 Select Project
Step 1 Identify Project Scope and Objectives
 Identify Objectives and measures of effectiveness in meeting them
 Establish a project authority
 Identify Stakeholders – All the participants in Escalation Procedure
 Establish methods of communications with all parties
Step 2 Identify Project Infrastructure
 Establish Project Execution Methodology
 Identify installation standards and procedures (H/w and S/w Requirements)
 Identify project team organization
Step 3 Analyze project characteristics
 Identify Project Risks
 Project Phases
 Review overall resource estimates

12
 Stepwise Project Planning
Step 4 Identify project products and activities
 Identify and describe project products (Including Quality Criteria) - Deliverables
 Acceptance/Warranty Criteria
 Configuration Management
Step 5 Estimate effort for each activity
Step 6 Identify activity risks
 Identify and quantity risks
 Plan risk reduction and contingency measures
 Adjust plans and estimates to take account of risks
Step 7 Allocate Resources
 Identify and allocate resources
 Revise plans and estimates to take account of resource constraints
Step 8 Review/Publicize plan
 Review Quality aspects of project plan
 Document plans and obtain agreement
Step 9/10 Execute plan/lower levels of planning

This may require the reiteration of the planning process at a lower level

13
 Project Management Plan
The project management plan defines the work that
will be done on the project and who will do it. It
consists of:
 A statement of work (SOW) that describes all work products
that will be produced and a list of people who will perform
that work
 A resource list that contains a list of all resources that will be
needed for the product and their availability
 A work breakdown structure and a set of estimates
 A project schedule
 A risk plan that identifies any risks that might be
encountered and indicates how those risks would be
handled should they occur

Project
Management Plan

14
 Scope Management
Scope Management means –
 Constantly checking to make sure you are completing all the work
 Not letting people randomly add to the scope of the project without a structured
change control system
 Making sure all changes fit within the project charter
 Defining and controlling what is and is not included in the project
 Preventing extra work or gold plating
Scope planning is focused on thinking ahead to determine, “How will I do this”?,
before doing the work, and turning the answer into a project scope management
plan. (SMP)
Project SMP may be unique for a particular project but may cover topics that for
the company or the type of the project may be standardized.
Once completed SMP becomes part of Project Management Plan and is used to
guide and measure the project until the closing process group.

15
16
Scope Management

17
 Work Breakdown Structure
(WBS)
WBS is deliverable oriented. Not only the customer deliverables but all
.
the deliverables

18
There are few rules for creating a WBS. WBSs created by different –people for same
projects may be different.
Following rules should be followed –
 It is created with the help of the team.
 The first level is completed before the project is over.
 Each level of the WBS is a smaller piece of the level above.
 The entire project is included in each of the highest levels of the WBS. Eventually some
levels will be broken down further.
 Includes only work needed to create deliverables
 Work not in the WBS is not part of the project.
 Continues breaking down the project until you reach what are called work packages (tasks)
–
• Can be realistically an confidently estimated
• Cannot be logically subdivided further
• Can be completed quickly
• Have a meaningful conclusion and deliverable
• Can be completed without interruption. (Without the need for more information)
MOST COMMONLY -
 The top level of the WBS is the Project Title.
 The first level is the same as Project SDLC. (Analysis, Design etc)
 The second and later level breaks the project into smaller pieces.

19
Project Plan Creation (mpp)

Project Plan Tutorial Sample Project Plan

20
 Process Models
The word “Process” is used to emphasize the idea of a system
in action.
In order to achieve an outcome, the system will have to execute
one or more activities; this is its process.
These activities can be organized in different ways and we can
call these PROCESS MODELS.
Process Models are –
 Waterfall Model
 Spiral Model
 V- Model
 Software Prototyping

21
 Waterfall Model
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential
manner.
For example, one first completes requirements specification, which are set in stone. When the
requirements are fully completed, one proceeds to design. The software in question is designed
and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for
implementing the requirements given.
When the design is fully completed, an implementation of that design is made by coders.
Towards the later stages of this implementation phase, separate software components produced
are combined to introduce new functionality and reduced risk through the removal of errors.
Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is completed and perfected. However, there are various modified waterfall models
(including Royce's final model) that may include slight or major variations upon this process.

22
 Spiral Model
The spiral model is a software development process
combining elements of both design and prototyping-
in-stages, in an effort to combine advantages of top-
down and bottom-up concepts. Also known as the
spiral lifecycle model (or spiral development), it is a
systems development method (SDM) used in
information technology (IT). This model of
development combines the features of the
prototyping model and the waterfall model. The spiral
model is intended for large, expensive and
complicated projects.

23
 Spiral Model
The steps in the spiral model iteration can be generalized as follows:
The new system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the external or internal users and
other aspects of the existing system.
A preliminary design is created for the new system. This phase is the most important part of
"Spiral Model". In this phase all possible (and available) alternatives, which can help in
developing a cost effective project are analyzed and strategies are decided to use them.
This phase has been added specially in order to identify and resolve all the possible risks in
the project development. If risks indicate any kind of uncertainty in requirements,
prototyping may be used to proceed with the available data and find out possible solution in
order to deal with the potential changes in the requirements.
A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics of
the final product.
A second prototype is evolved by a fourfold procedure:
 evaluating the first prototype in terms of its strengths, weaknesses, and risks;
 defining the requirements of the second prototype;
 planning and designing the second prototype;
 constructing and testing the second prototype.

24
25
 V Model
The V-model is a software development process which can be
presumed to be the extension of the waterfall model. Instead of moving
down in a linear way, the process steps are bent upwards after the
coding phase, to form the typical V shape. The V-Model demonstrates
the relationships between each phase of the development life cycle and
its associated phase of testing.
The V-model deploys a well-structured method in which each phase
can be implemented by the detailed documentation of the previous
phase. Testing activities like test designing start at the beginning of the
project well before coding and therefore saves a huge amount of the
project time.
The V-model consists of a number of phases. The Verification Phases
are on the left hand side of the V, the Coding Phase is at the bottom of
the V and the Validation Phases are on the right hand side of the V.

26
27
 Software Prototyping
Software prototyping, an activity during certain software development, is
the creation of prototypes, i.e., incomplete versions of the software program
being developed.
A prototype typically simulates only a few aspects of the features of the
eventual program, and may be completely different from the eventual
implementation.
The conventional purpose of a prototype is to allow users of the software to
evaluate developers' proposals for the design of the eventual product by
actually trying them out, rather than having to interpret and evaluate the
design based on descriptions.
Two Types -
 Throw-away Prototypes –
• The prototype is used to test out some ideas and is then discarded when the
true development of the operational system is commenced.
 Evolutionary Prototypes –
• The prototype is developed and modified until it is finally in a state where it
can become the operational system.

28
Software Prototyping - Benefits
Learning by doing
Improved Communication
Improved user involvement
Clarification of partially known requirements
Demonstration of the consistency and completeness of a
specification
Reduced need for documentation
Reduced maintenance cost
Feature constraint
Production of expected results

29
 Incremental Delivery Plan
This approach breaks the application down into small components which are then
implemented and delivered in a sequence. Each delivered sequence must give
some benefit to the user. (Phased Delivery)
Advantages –
 Feedback from early increments improves the later stages
 The possibility of changes in requirements is reduced because of the shorter time span
 Users gets benefits earlier than normal conventional approach.
 Early delivery of some useful components improves cash flow because you get some ROI
early.
 Smaller sub projects are easier to control.
Disadvantages –
 Later increments might require modifications in previous increments. This is known as
software breakage.
 Software developers might be more productive in large systems as compared to smaller
ones.

Selecting the most appropriate model – think????

30