project planning copyright, 2002 © jerzy r. nawrocki jerzy.nawrocki@put.poznan.pl quality...

Project Project PlanningPlanning

Copyright, 2002 © Jerzy R. Nawrocki

Jerzy.Nawrocki@put.poznan.pl

www.cs.put.poznan.pl/jnawrocki/mse/quality/

Quality ManagementQuality Management

Auxilliary MaterialAuxilliary Material

Quality ManagementQuality Management

Auxilliary MaterialAuxilliary Material

J. Nawrocki, Project Planning

IntroductionIntroductionIntroductionIntroduction

CMMCMM

• Requirements management• Software project planning• Software project tracking

and oversight• Software subcontract

management• Software quality assurance• Software configuration

management

CMM Level 2 - Repeatable

J. Nawrocki, Project Planning

IntroductionIntroductionIntroductionIntroduction

Documented procedures for ..

• developing an SDP• estimating size, effort, cost, critical

computer resources, and schedule• planning SQA activities• planning SCM• . . .

J. Nawrocki, Project Planning

IntroductionIntroductionIntroductionIntroduction

Product measures

Process measures

Size

Effort

Cost (not applicable?)

(Computer) resources

Delivery date (schedule)

Measures at CMM Level 2

J. Nawrocki, Project Planning

Work productsWork productsWork productsWork products

• IPD• Concept of the system• SRS• (Intermediate) design• Implementation (a set of

modules)• Acceptance tests• Bachelor thesis

• Specification

• Implementation idea

• Code

• Test bed

• Test cases

J. Nawrocki, Project Planning

AbilitiesAbilitiesAbilitiesAbilities

Ab1. A documented and approved statement of work exists for the software project.

J. Nawrocki, Project Planning

AbilitiesAbilitiesAbilitiesAbilities

Scope of the work

Technical goals and objectives

Identification of customers & end users

Imposed standards

Assigned responsibilities

Cost and schedule constraints and goals

Statement of Work (I)

J. Nawrocki, Project Planning

AbilitiesAbilitiesAbilitiesAbilities

Dependencies between the software project and other organisations (customer, subcontractors, j.v. partners)

Resource constraints

Other constraints

Statement of Work (II)

• Statement of work is reviewed.

• It is managed and controlled.

J. Nawrocki, Project Planning

AbilitiesAbilitiesAbilitiesAbilities

Ab2. Responsibilities for developing the software development plan are assigned.

• The project manager co-ordinates the project’s planning.

• Responsibilities for the software work products and activities are partitioned and assigned to in a traceable, accountable manner.

J. Nawrocki, Project Planning

AbilitiesAbilitiesAbilitiesAbilities

Ab3. Adequate resources and funding are provided for planning the project.

Is it enough?

J. Nawrocki, Project Planning

AbilitiesAbilitiesAbilitiesAbilities

Ab4.

• The software managers,

• software engineers, and

• other individuals involved in the software project planning

are trained in the software estimating and planning procedures applicable to their areas of responsibility.

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Ac1. The software engineering group participates on the project proposal team.

The software engineering group reviews the proposed commitments.

J. Nawrocki, Project Planning

Overallplanning

ActivitiesActivitiesActivitiesActivities

Ac2. Software project planning is initiated in the early stages of, and in parallel with, the overall project planning.

Softwareplanning

At PUT:

software project = overall proj.

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Ac3. The software engineering group participates with other affected groups in the overall project planning throughout the project’s life.

The software engineering group reviews the project-level plans.

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Ac4. Software project commitments made to individuals and groups external to the organisation are reviewed with senior management (B.W. or A.W.) according to a documented procedure.

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Ac5. A software life cycle with predefined stages of manageable size is identified or defined.

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

IPD

Concept of the system (scenarios)

Soft. requirements specification

Conceptual design & detailed planning

Release 1 (from reqs to acceptance)

Release 2

Final acceptance (bachelor degree)

Software life cycle at PUT

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Ac6. The project’s software development plan is developed according to a documented procedure.How

towriteSDP

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

The SDP is based on the customer’s and project’s standards, IPD, and SRS.

Plans are negotiated with the affected groups (3rd year!). The agreements are documented.

The SDP is reviewed, and managed and controlled.

Howto

writeSDP

The planning procedure at PUT

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Howto

writeSDP

The planning procedure at PUT

• The SDP is approved by the Project Area Manager (Bartek or Adam).

• The SDP is available through the project’s web page along with all the previous versions of it. That web page is referenced in the Initial Project Description (IPD).

J. Nawrocki, Project Planning

ActivitiesActivitiesActivitiesActivities

Ac7. The plan for the software project is documented.SD P

J. Nawrocki, Project Planning

Wide-band Delphi methodWide-band Delphi methodWide-band Delphi methodWide-band Delphi method

Rand Corporation, Boehm’81

• A few experts individually produce size estimates.

• A Delphi process is used to reach a consensus.

PythiaPythia

J. Nawrocki, Project Planning

Wide-band Delphi methodWide-band Delphi methodWide-band Delphi methodWide-band Delphi method

1. Experts get the specification and an estimation form

2. They meet for discussion (project goals, assumptions, estimation issues)

3. Each expert anonymously lists the tasks and estimates the size

4. The estimates go to the estimate moderator. He tabulates the results and returns them to the experts.

The Delphi procedureThe Delphi procedure

The estimateThe estimate

moderatormoderator

J. Nawrocki, Project Planning

Wide-band Delphi methodWide-band Delphi methodWide-band Delphi methodWide-band Delphi method

Estimator: Jerzy Nawrocki Date: 22.06.1999

Project: Sorting routine

The estimates from the 1st round:

e E M e e

0 20 40 60 80 100

e - estimates, E - your estimate, M - median estimate

Your estimate for the next round: ......... LOC

A rationale for your estimate: ...........................................

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

J. Nawrocki, Project Planning

Wide-band Delphi methodWide-band Delphi methodWide-band Delphi methodWide-band Delphi method

5. The experts meet to discuss the results. They review the tasks they have defined but not their size estimates.

6. The procedure is repeated from step 3 until the estimates are acceptably near

The Delphi procedureThe Delphi procedure

The estimateThe estimate

moderatormoderator

J. Nawrocki, Project Planning

IntroductionIntroductionIntroductionIntroduction

What is a risk?

J. Nawrocki, Project Planning

IntroductionIntroductionIntroductionIntroduction

Two approaches to risk

Reactive Proactive

J. Nawrocki, Project Planning

Risk description

IntroductionIntroductionIntroductionIntroduction

ProbabilityImpact• catastrophic• critical• marginal• negligible

J. Nawrocki, Project Planning

RMMM

IntroductionIntroductionIntroductionIntroduction

RMMM = Risk Mitigation, Monitoring, and Management

Mitigation= minimising the probability

Monitoring= observing factors/indicators

Management= if it happens ..

J. Nawrocki, Project Planning

Risk analysis

IntroductionIntroductionIntroductionIntroduction

IBM: > 100 risk factors

For each risk factor an MMM plan.

Risk management becomes a project in itself!

Pareto analysis: the 80-20 principle

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

GeneralPoor planningPoor configuration controlPoor progress trackingPoor quality assurancePoor requirementsPoor development

Risk areas

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Corporate politics (at client side)Crowded office conditions (< 9 m2)Excessive paperwork (> 50 docs, > 6 pages/FP)Friction with client or senior managementLack of specialisationLow productivity (?)Low quality ( -> Poor QA)Low user satisfactionMalpractice (Management)

General

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Inaccurate sizing of software deliverablesInadequate risk analysisInadequate tools and methodsLack of reusable estimatesLack of reusable project plansMissed schedules (unrealistic schedules;

schedules not updated after changes; inadequate planning methods; lack of historical data from past projects)

Partial life-cycle definitions

Poor planning

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Inadequate configuration controlSchedules not updated after changes

Poor configuration control

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Inadequate measurementInadequate tools and methods

Poor progress tracking

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Inadequate software policies and standardsInadequate tools and methods (QA)Lack of reusable test plans and test cases

Poor quality assurance

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Creeping requirementsLack of reusable requirements

Poor requirements

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

Inadequate tools and methods (Soft.Eng., Tech. Documentation)

Lack of reusable components (architecture, code, design, doc, human interfaces)

Malpractice (technical staff)

Poor development

J. Nawrocki, Project Planning

Selected risk factorsSelected risk factorsSelected risk factorsSelected risk factors

A team member stops his studiesA team member passes his exams in AprilA team member is late is project tasks (e.g. he is

ill)Customer representative is not availableThe tools are not available or not workingThere is a computer/disk crashTeam members are not satisfied (e.g. The work

is boring)The acceptance criteria are not clear

SDS specific risks

J. Nawrocki, Project Planning

SummarySummarySummarySummary

Work products and their measures

The planning procedureWide-band Delphi MethodRisk is described by three

elements:• name,• probability,• impact.

J. Nawrocki, Project Planning

Further readingsFurther readingsFurther readingsFurther readings

[CMM] M.C. Paulk et. al.,The Capability

Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading, 1994.

[Jon] Capers Jones, Assessment and control of software risks, Prentice Hall, Englewood Cliffs, NJ, 1994.

[Pres] Roger Pressman, Software Engineering. A Practitioner’s Approach, McGraw Hill, 1997.

J. Nawrocki, Project Planning

Quality assessmentQuality assessmentQuality assessmentQuality assessment

1. What is your general impression? (1 - 6)

2. Was it too slow or too fast?

3. What important did you learn during the lecture?

4. What to improve and how?