Computer Science and Software Engineering

University of Wisconsin - Platteville

Note 12: Project

Management

Yan ShiLecture Notes for SE 3330

UW-Platteville

Based on Pressman Chapter 21

Project Fails

2015 Chaos Manifesto, (Standish Group):

Project failure rates

— 29% of software projects are successful:

on time, on budget, with required features and functions

— 52% are "challenged“

late, over budget, and/or with less than required features

— 19% are outright failures

cancelled prior to completion

delivered and never used

Example from “The Risks Digest”

Denver baggage system

Goal: automated baggage handler, intended for use at DIA in 1995

Initial cost: $250 million Cost/schedule overruns: another $441 million 2005 result:

— United abandons the system, switching to more conventional manual system

— This will reportedly save $1 million a month in spite of having to pay $60 million/year for another 15 years!

Effective Software Project Management

Who to blame?

— Conventional view: Managers!

Effective Management focuses on 4 P’s

— People

— Product

— Process

— Project

The People Factor

Who are involved in the project:— senior managers: define business issues — project/technical managers: plan, motivate,

organize, control project — practitioners: deliver technical skills — customers, other stakeholders: people with the

business need — end-users

MOI model of leadership: motivation, organization, ideas.

Software Teams Models

Democratic Decentralized (DD): team has no permanent leader; people coordinate tasks for a time and then are replaced by others coordinating different tasks — decisions made by group consensus

Controlled Decentralized (CD): defined leader for team, secondary leaders for subtasks — problem solving done by group, implementing solution

done by subgroup

Controlled Centralized (CC): problem solving, internal team organization controlled by leader — most communication between leader and team members,

not between members

Software Teams Model Analysis

CC: faster, works better for simple problems

DD, CD: better when complex solutions needed (more communication, more ideas)

CD, CC: better for large projects

DD: improves morale when team must work together for long time

modularity: low -> DD, high -> CC or CD

The Product

The first software project management activity: Determine the Scope of the Product and the Problem to be Solved!

Software Scope: context, information objective, function and performance!

Software project scope must be unambiguous and understandable!— state quantitative data

number of simultaneous users size of mailing list maximum response time

— note constraints and/or limitations product cost restriction hardware limitations

The Process

Task: select the process model appropriate for the product to be engineered by a project team.

Starting point: choose a generic process model Example criteria:

— small project similar to previous work:— tight time constraints, well-defined problem, easy to

partition:— first release deadline "too" tight:— large project, many unknowns:

Notes: process models must be tailored!

waterfall

RAD

incremental spiral

The Project

Project Estimation

Project Scheduling

Resource management

Risk Management

Project Execution & Monitoring

Configuration Management

Project Estimation

Software size estimation

Effort estimation

Time estimation

Cost estimation

Techniques:

— Decomposition Technique: KLOC or Function Points

— Empirical Estimation Technique: COCOMO

Risk Management

What are typical risks, how to address them? — Too large a project:

— Difficult or complex functions:

— Support system problems:

— Testing time:

— Product control:

— Teamwork problems

start small and add functions in later cycles

prototype these at start of project: this gives you time to consider alternatives!

build early prototype to check development environment

test as you go!

artifact control system (aka configuration control)

discuss problems openly get help from higher ups/instructor

The Project

What can go wrong? Avoid them!

Top 10 signs indicating project in trouble:— developers don't understand customer's needs — project scope is poorly defined — changes are managed poorly — chosen technology changes — business needs change or are ill-defined — unrealistic deadlines — resistant users — lost sponsorship — team lacks people with appropriate skills — managers avoid best practices, lessons learned

product

product

process

product

process

people

people

people

people

product

process

Summary

Effective management: the 4 P‘s

— People: to organize, develop teams

— Product: determine the scope

— Process: how to get from concept to product

— Project: avoid potential issues