Software Project Management Plan (SPMP)



SOFTWARE ENGINEERING II

Software Project Management Plan

TEXT: Essentials of Software Engineering, Frank Tsui, Orlando Karam

Chapters 13.1-13.2

PROJECT WORK:

The risk management section will be created in class

PM brings in a draft PMP to discuss

The QM brings in a draft Software Configuration Plan to discuss

OBJECTIVES:

The student shall be able to:

• Define the purpose and briefly define the contents of an SPMP.

• Describe the types of decisions that are made for each area, and why each area is important

• Prepare an SPMP with aid of web page.

• Define risk, and create a Risk Table.

• Describe the four stages of risk management.

• Define risk retirement techniques and use of decision tree.

TIME ALLOCATION:

Risk ½ hour

Lab: Put together a risk mgmt. table ½ hour

SPMP 1/2 hour

Review Sample SPMP 1/2 hour

Lab: Discuss PM’s SPMP 1 hour

Total 3 hours

Software Project Management Plan (SPMP)

Software Project Planning is a Key Practice Area for SEI Level 2.

Goals include:

1.Software estimates are documented for use in planning and tracking the software project.

2.Software project activities and commitments are planned and documented.

3.Affected groups and individuals agree to their commitments related to the software project.

PMP is also an important part of the Project Mgmt Body of Knowledge (PMBoK).

SPMP Describes:

1) What you are going to do

2) How to do it

3) When to do it

4) Who will do it

5) How much will it cost. (not always performed)

SPMP is a statement of understanding with development organization and team members.

• Project manager writes the SPMP with team member input.

• SPMP may change as estimates are revised or requirements changes are necessary.

• When the SPMP changes, new agreement must be achieved and version control shall be used.

The project plan defines the work and how it will be done. It:

• Describes the milestones, their dates and deliverables.

• Provides a definition of each major task, an estimate of the time and resources required, and a framework for management review and control.

• Describes the responsibilities of the members of the project

• Describes the process and procedures to be used by the project

• Describes the software and hardware requirements to accomplish the project

• Defines the risks and assumptions of the project and how problem escalation should occur

• Defines the project tracking and communications techniques that should occur within the project, to upper management, to the customer

• For higher SEI levels: Defines the quality goals, quality expectations, and metrics to be collected.

• Is a powerful learning vehicle: a benchmark to compare with actual performance.

Our version is derived from Infosys version:

Executive Summary of Project.

• Project Overview: At a high level, what will the new software accomplish for the company?

• Project Personnel: Who is the project management from both customer and software side?

• Project Dates: When does the project start and complete?

• Project Scope: What is the purpose of the new software?

• Company Objectives: Why did the consulting company accept this project?

• Customer Commitments: List of Milestones: Date, Milestone, Deliverable

• Assumptions: What assumptions are we making that are built into our schedule?

Project Planning

• Standard Process Followed: What design technique or software methodology will be followed?

• Tailoring Notes: (For SEI Level 3 and above projects) what deviations from standard processes do we plan to follow?

• Requirements Change Management Process: How will changes to the requirements be handled?

• Estimated Size & Effort: A project estimation technique showing how the project timeline is derived.

• People: What are the skills required by the project?

• Hardware & Software Resources Required: What computer hardware and software packages are required and when are they required?

• Training Plan: What training is required for software developers/mgmt?

• Quality Plan: For SEI Level 4 and above: What quality goals does the project want to achieve? How many defects are we expecting to find? How do we expect to achieve quality?

• Reviews: Which software work products do we plan to review, and will they be group or one-person reviews?

• Risk Management Plan: List the expected risks and their probabilities, impacts, risk exposure, and a mitigation plan.

Project Tracking

• Measurement Plan: What units will we use to measure project size, effort, defects, elapsed time?

• Task Tracking: How will the project be tracked? How often will tracking methods (such as meetings) take place?

• Issues Tracking: How will customer, business manager issues be tracked and how often?

• Reporting to Senior Management: What formal communications and techniques will be used to keep Senior Management abreast? How often will the team meet with Senior Management?

• Reporting to Customer: What formal communications and techniques will be used to keep the customer informed of status? Who will be the primary interface to the customer?

• Escalation Procedures: When problems occur, how long can the problems be outstanding before escalation should occur? To whom should escalation occur?

Project Team

• Project Organization: Show organization hierarchy.

• Project Team: Who will be on the project and for which dates? What will their responsibilities be?

• Roles and Responsibilities: What are the roles that will be played, and what responsibilities are associated with each role?

References

Abbreviations

Lab: What is important for you to include in your SPMP? Who will do most of the work? Start reaching agreement on important parts of SPMP.

Risk

Risk: “A risk is something which may occur in the course of a project, and which, under the worst outcome, would affect it negatively and significantly.”

-Eric Braude, Software Engineering

Risks can be categorized as:

Project risks: Impact the project schedule or resources

• E.g. H/W not delivered in time may delay project

Product risks: Affect the quality or performance of the developed software

• E.g. Poor training on new tool.

Business risk: Affects the business organization

• E.g. Obsolescence when product delivered.

What kinds of risks are the following?

• Programmer quits

• Requirements change

• Specification delays: Details not available

• CASE tool not performing as expected

• Basic technology is changed: OS upgrade

Stages of Risk Management include:

• Qualitative Risk identification: Identify from checklists, meeting reviews, brainstorming

• Quantitative Risk analysis: Assess likelihood and consequences of risks

• Risk planning: Address how the risk can be avoided or mitigated

• Risk monitoring: Periodically review status of risk

Qualitative Risk identification:

One method:

• Each team member spends 10 minutes considering his/hers greatest fears for the project (may review SPMP)

• The member then prepares a risk analysis for each risk and sends them to team leader.

• Team leader prioritizes and integrates the results producing a single risk analysis table.

• The group reviews the table for 10 minutes, to discover additional risks.

• The group finalizes the risk table for 10 minutes.

• Responsible engineers do risk retirement work outside the meeting

• Team members review risk at weekly meetings for 10 minutes.

Risks may be related to technology, people, the organization, tools, requirements or estimation.

Risk may affect product performance, project cost/schedule, software quality/support.

Quantitative Risk Analysis:

Assign numerical rating via estimation:

* Likelihood: The probability the risk will occur: not likely (0-30%), likely (30-70%), very likely (70-100%).

* Impact: The effects of the risk: rate 1 (low) to 10 (high) or: catastrophic (10), serious (7), tolerable (4), or insignificant (1)

* Priority: Once the Likelihood & Impact are known, the priority of risks can be determined. Priority = Likelihood x Impact

* Risks can be color coded according to Priority (red>7, yellow > 4, green risk cost.

Decision Tree:

[pic]

Risk Management Table:

| | |Likeli-hood |Impact |Priority |Plan |

| | | | |(L*I) | |

|1 |Deficient database skills |High: 90% |8 - Serious |7.2 |John attends course on SQL; have unskilled people work |

| | | | | |closely with skilled people (Joe) |

|2 |Staff Illness |Low: 10% |6 – |.60 |Cross-train using inspections on all documents & code |

| | | |Serious | | |

|3 |Requirements Changes |Medium: 50% |4 -Tolerable |2.0 |Write into contract that changes |

| | | | | |must result in renegotiation of schedule |

|4 |Under-estimate Schedule |Medium: 50% |2 -Tolerable |1.0 |Implement high priority functions first. Monitor schedules|

| | | | | |on a weekly basis with meetings. |

Risk Monitoring:

Periodically assess the current status of risks: have the probabilities of risk increased or changed? Update or act on risk plan.

Allocate responsibility for risk retirement activities.

Opportunities: Risks that offer potential $ benefits can also be ranked/acted upon.

High risk/high priority: Act on first

Low risk/low priority: May ignore.

-----------------------

Lack of

Tech. expertise

Hire expert $2000

Train employee $400

Risk Contract $4000

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download