1

Software Project Management

Software Project Planning

2

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.

3

4

5

Identifying Needs

The project manager drives the scope of the project.The project manager should identify and

talk to the main stakeholderThe 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

6

Vision and Scope Document

A typical vision and scope document follows an outline like this one:

1. Problem Statementa) Project backgroundb) Stakeholdersc) Usersd) Riskse) Assumptions

2. Vision of the Solutiona) Vision statementb) List of featuresc) Scope of phased release (optional)d) Features that will not be developed

7

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 developedA description of each intermediate deliverable or

work product that will be built.The estimated effort involved for each work

product to be delivered

8

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

9

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.

10

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

11

Risk Plan Example

12

Stepwise Project Planning

Step 0 Select ProjectStep 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

13

Stepwise Project PlanningStep 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 activityStep 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

14

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

15

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.

16

17

Scope Management

18

Work Breakdown Structure (WBS)

WBS is deliverable oriented. Not only the customer deliverables but all

the deliverables.

19

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.

20

Project Plan Creation (mpp)

Project Plan Tutorial Sample Project Plan

21

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

22

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.

23

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.

24

Spiral ModelThe 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.

25

26

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.

27

28

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.

29

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

30

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????