Software project management
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

Software Project Management PowerPoint PPT Presentation


  • 65 Views
  • Uploaded on
  • Presentation posted in: General

Manage Unavoidable Complexity. Avoid Unmanageable Complexity. Software Project Management. Project Management: Some Statements. If you fail to plan, you plan to fail Planning seems to increase luck Planning and estimating is a key competence for all software engineers

Download Presentation

Software Project Management

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software project management

Manage Unavoidable Complexity

Avoid Unmanageable Complexity

Software Project Management


Project management some statements

Project Management: Some Statements

If you fail to plan, you plan to fail

Planning seems to increase luck

Planning and estimating is a key competence for all software engineers

If you don’t ask for risk information, you are asking for trouble

Uncertainty must certainly not be stated in uncertain terms

If you don’t actively attack risks, they will actively attack you

Insanity: doing the same thing over and over again and expecting a different result

The most important customer of the project plan is the project team itself


Content

Content

  • Project Management Basics

  • Requirements Management

  • Estimation

  • Risk Management

  • Project Tracking

    • Milestone Trend Analysis

    • Earned Value Chart

  • Intergroup Co-ordination

  • Peer Reviews

  • Problem Report Tracking


Project management basics

Performance

- specifications

- derivatives

- quality

- etc.

If they are all fixed

- Don’t appoint a project manager

- Keep your fingers crossed

If they can be adjusted

- Appoint a project manager

- Set priorities

Cost

- human resources

- equipment

- etc.

Schedule

- lead time

- process

- planning

Project Management Basics


Project management processes

Project Management Processes

Control

Project Data

Readjustment

Deviations

Project Data

Schedule

Cost

Monitor

Plan

Plan

Plan

Performance

Measured Data

Project Management

Project Implementation

Product

Project

Technology Skills Resources


Two main phases in a software project

Functional Requirements Spec.

Architecture / Top-Level Design

Software Development Plan

Commercial

Req. Spec.

CD

CR

CS

Concept Confirmation

Product Implementation

Two main phases in a software project

CS: Concept Start

CD: Commitment Date (commitment to cost, schedule, performance)

CR: Commercial Release


Content of a software development plan

Content of a Software Development Plan

  • Objectives, Scope (with reference to specification/architecture)

  • Deliverables

  • Activities (work breakdown structure with activities of max. 2 - 3 weeks)

  • Assumptions, Dependencies, Constraints (e.g., required hardware models, intergroup dependencies)

  • Estimates (size, effort, schedule, computer resources, + justification)

  • Project Organization and Resource Allocation

  • Schedule of Activities (including project milestones)

  • Risk Management (identification, resolution, monitoring of risks)

  • If applicable, Subcontract Management Plan(s)

  • Progress reporting and communication structure

  • Software Development Environment (methods/tools/standards)

  • Project Quality Plan (inc. (intermediate) release acceptance criteria)

  • Software Configuration Management Plan


Requirements management

Requirements Management

  • At the beginning of the project:

    • Collect commercial requirements as input

    • Write Requirements Specification

    • Review with all stakeholders

    • Formally approve the specification and use it as baseline for the project activities

  • What goes wrong?

    • Stakeholders don’t know what they want

    • Not all stakeholders identified (e.g., service, factory)

    • Many change requests during the project

  • Possible solutions:

    • Work on requirements in a pre-project phase

    • Rapid prototyping / incremental deliveries

    • Formal change control


Estimation

Estimation

  • The only unforgivable failure is to not learn from past failures

  • Project failures are mostly caused by inflated and unreasonable expectations

  • Definitions of Estimate:

    Default

    Prediction that meets the enforced deadline

    Alternative

    Most optimistic prediction that has a non-zero probability of coming true

    Proposed

    Equally likely to be above or below actual result


Causes of inaccurate estimates

Causes of inaccurate estimates

From:

Nine Management Guidelines for Better Cost Estimating

Albert L. Lederer and Jayesh Prasad

Communications of the ACM, Vol. 35, Nr. 2, Febr. 1992

  • Frequent requests for changes

  • Overlooked tasks

  • User’s lack of understanding of their own requirements

  • Insufficient communication and understanding between users and analysts

  • Poor or imprecise problem definition

  • Insufficient analysis when developing estimate

  • Lack of co-ordination between involved disciplines

  • Lack of an adequate methodology or guidelines for estimating (lack of historical data)


How to develop estimates 1

How to develop estimates? - 1

  • Immature (lack of) process: estimated date = target date

  • First improvement step: Size/effort estimates are made based on expert opinions and the project team’s own historical data using Wide Band Delphi techniques

  • Wide Band Delphi:

    • A facilitator is assigned, who organises an estimation meeting and presents each expert with an estimation form.

    • The participants discuss estimation issues using their knowledge of the requirements and the software architecture.

    • Each participant fills out the estimation form anonymously and hands it over to the facilitator. The participants should not share their estimates.

    • The facilitator prepares and distributes a summary of the estimates with the averages and standard deviations of all estimates.

    • The facilitator initiates a discussion between the experts focussing on those points where their estimates varied widely.

    • After the discussion, the experts fill out the estimation forms, again anonymously, and hand them over to the facilitator.

      The last 3 steps are repeated until consensus is reached.


How to develop estimates 2

How to develop estimates? - 2

  • What can go wrong with Wide Band Delphi?

    • No consensus has been reached when the plan must be presented to management

    • Average of the individual estimates is taken as the final estimate

    • But: when the deviation remains high, you only know that you have insufficient insight

  • Next improvement step: Size/effort estimates are made using historical data from the Organization’s Software Process Database (with an explicit effort to use data from “similar” projects)

    • Use expert opinion to determine the “project type”

    • Use historical data from the same type of projects for productivity figures (from “size” to “effort”)


Project type classification

Project type classification

From: Software Project Management

by Walker Royce, Addison-Wesley,

1998, ISBN 81-7808-013-3


Risk management

Risk Management

  • List top-x of risks

  • Add actions to prevent the risk from occurring

  • Add contingency plans (what to do when the risk materializes)

  • Plan capacity for a certain percentage of the total effort required for contingency plans


Project tracking

Project Tracking

Dilbert by Scott Adams


Content of a software progress report 1

Content of a Software Progress Report - 1

  • Management Summary and Attention Points

    • short status overview

    • issues requiring immediate management action

  • Project Dashboard

    • Milestone Trend Analysis

    • Earned Value Chart

  • Project Status

    • major results achieved during the reporting period

    • major expectations for the coming period

    • complete list of deliverables/results

    • project definition changes (planned vs. actual number of change requests)

    • main problems and issues

  • Risk Management

    • identification of risks + probability + effects + seriousness

    • actions + action holders + action status


Content of a software progress report 2

Content of a Software Progress Report - 2

  • Project Staffing

    • planned versus actual staffing

  • Budget

    • budgeted versus actual costs

  • Problem Reports

    • % of test cases passed / failed / not yet executed

    • expected versus actual numbers

    • status of CR/PRs (entered, analyzed, solved, tested, closed, rejected)

  • Performance Tracking

    • actual size figures (versus estimates)

    • actual usage of critical computer resources (versus estimates)

  • Inter-group Deliverables and Issues

    • identification of all inter-group deliverables and issues

    • actions + action holders + action status

  • Other Issues


Milestone trend analysis

Milestone Trend Analysis


Example milestone trend analysis

dec

dec

nov

nov

oct

oct

sep

sep

aug

aug

july

july

june

june

may

may

apr

apr

Commercial Release

Commercial Release

Design Release

Design Release

mar

mar

Product Range Start

Product Range Start

feb

feb

jan

jan

june

june

jan

feb

mar

apr

may

july

aug

sep

oct

nov

dec

jan

feb

mar

apr

may

july

aug

sep

oct

nov

dec

Actual time

Actual time

Example Milestone Trend Analysis

What can you learn of these MTA’s?


Simple wbs example

Simple WBS Example


Schedule example

Schedule Example


Earned value chart incomplete

Earned Value Chart (incomplete)

Planned Effort and Value


Schedule example1

Schedule Example


Earned value

Tangible Deliverables - Earned Value

Time Cards - Effort Spent

Planned Effort and Value

Earned Value


Earned value chart

Planned Effort and Value

Effort Spent

Earned Value

Earned Value Chart

Schedule:

Budget:

Analysis:

Mitigation:

Slip of 3 weeks, 50% delay

20 % under budget, 50 % effort overrun

Carol still at other project, lower productivity than estimated

Depending on priority setting: less functionality and/or more budget and/or delayed release


Maturity of project tracking process

Maturity of project tracking process

  • Lack of process: Constant crisis and re-actions

  • First improvement: Corrective actions are taken when the actual results deviate significantly (based on team judgment) from the plan

  • Next improvement: Corrective actions when the actual results deviate significantly (more than pre-defined thresholds (based on experience)) from the plan

  • Final improvement: Corrective actions when the actual results deviate significantly (i.e. outside the Upper and Lower Control Limits (obtained from Statistical Process Control)) from the plan


Inter group co ordination

Inter-group co-ordination

  • Required deliverables from other groups (internal and/or external) are listed under “Dependencies” in the project plan: it is assumed that these deliveries will be on time and with the right quality

  • Improvement step: all (intermediate) deliverables from/to other groups are explicitly listed with delivery date and person responsible, and quality criteria are defined and agreed upon for all deliverables from/to other groups

  • Next improvement step:

    • pro-active checking of the status of the expected deliverables

    • in case of problems, a joint effort is started to solve the issue

    • in case of disagreement, the issue is escalated via pre-defined and agreed upon channels


Peer reviews

Peer Reviews

  • 2 types of review:

    • To improve quality through detection of defects by peers as early as possible

    • To formally approve a deliverable by e.g., project leader, system architect, management

  • Lack of process: document quickly read by reviewers

  • First improvements (to establish stable process):

    • Review meetings and preparation time planned

    • Checklists (per type of documented) used and maintained

    • Metrics collected (preparation time, review meeting time, number of major/minor defects found, etc.)

  • Next improvements (to improve yield):

    • Ensure right persons are involved in review

    • Measure and ensure effectiveness of reviews


Problem report handling maturity grid

Severity of problem:

S: Safety, the product causes a dangerous situation

A: Product cannot be shipped, most customers will return it

Errors in basic functionality

Major errors in advanced functions

Non-compliance to standards

Errors that are irritating for every customer

B: Product can be sold, but critical customers will return it

Minor errors in the basic functions

Major errors in the functions difficult to reach (>2 levels deep in the menus)

Major errors in stress tests

C: Customers tolerate the defect or do not see it

Minor errors in the functions difficult to reach

Minor errors in stress tests

D: The defect is accepted for the product

Evolution of problem

4: Problem entered, cause not yet known

3: Problem analyzed, cause known, problem assigned to engineer

2: Solution implemented and tested by engineer

1: Solution tested by tester, included in formal release, and declared solved

0: Solution verified by submitter and declared closed

Problem Report Handling: Maturity Grid


Problem report handling example maturity grid

Problem Report Handling: Example Maturity Grid


Problem report handling

Problem Report Handling

  • All tests done and Maturity Grid shows:

  • Can we start releasing the product?

  • It depends !


Final project stage pr curve

Final Project Stage - PR Curve

Asymptotic


The asymptotic period

The Asymptotic Period

How to limit the “asymptotic” period for maturing the software?

Find as many defects as possible as early as possible!

Measures to be taken:

  • Ensure (plan + track) that all required testing is done on time

    • Integration, functional, system, electrical, torture room, field, factory, service, conformance, stress/stability

  • Ensure multiple rounds of testing are done on time

    • After fixing an “A” problem (e.g. certain functionality does not work at all) found in the first round, multiple “B” and “C” problems will probably be found in the next round

  • Prioritize PRs and ensure PRs are closed when they have been solved

    Longer term improvements:

  • Reuse test cases (increasing test coverage)

    • Random testing often results in PRs and should result in new test cases

    • Measure test coverage, track % of test cases executed and passed


  • Login