Software Engineering: Analysis and Design (CSE3308) : Lecture 9b: Project Management in Industry

Open Software Associates
Software Engineering: Analysis and

Design (CSE3308)
Lecture 9b: Project Management in

Industry
c 1998 Open Software Associates

CSE3308/CSC3080/DMS/2000/24
CSE3308: Software Engineering - Analysis and Design
An Industry Perspective
Lecture 9b: Project Management in Industry

Goal
To cover some of the key topics in Project Management, in a
practical way, using actual industry examples.
Focus
Focus on (software) product development projects.
Topics
Project Management Overview
Scope Management
Estimation
Risk Management
People Management

Introduction
Trevor Holmes
Education Varian Australia 1987-1995
Software Engineer, Software
B.Sc (Physics/Mathematics) Deakin
Marketing Manager, Project
1980
Manager, Software Quality
Dip.Eng (Digital Control) FIT 1985 Manager
M.App.Sc Monash 1993 Hewlett-Packard 1985-1996
The Intelligent Interpretation of Line Consultant (PSO)
Drawings and Text using Pattern
Siemens Research 1996-1997
Recognition Analysis.
Project Manager (SIEPLAN /
Career Capacity Integrator Project)
Olex Cables 1980-1983 Open Software Associates
Software Engineer 1998 - current
ACI Computer Services 1983 - Project Manager
1987
System Manager, Systems Engineer.

Introduction
Varian OSI Products

SpectrAA-600/800 effort:
Atomic Absorption spectrometer system. max team 15
consists of: 50+ engineering years
Microprocessor controlled >500K lines code
instrument (near real-time on the web:
control).
http://www.varianinc.com/osi
PC Workstation for system
control and data
management.
Accessories
Graphite Tube Atomizer (GTA)
Sample Preparation System
(SPS)
product price
$40K to $80K

Introduction
Siemens Research Products

Sieplan/Capacity Integrator effort:
Network planning and design tool for max team 60
Telecommunications Transmission 100+ engineering years
(SDH & PDH) Networks.
development budget >
consists of: $20M
5 to 200 GUI Clients 500K lines code
(Windows)
on the web
Unix based server (HPUX)
http://www.sr.com.au
Versant OODBMS with
databases up to 20GB.
product price
$500K to $10M

Introduction
OSA Products
OpenUI NetDeploy
cross-GUI client/server UIMS Internet application deployment and version
management system
consists of:
cross GUI runtime engine consists of:
GUI Builder Packer
identifies component files of
integrated client / server application
messaging generates catalogue file
compiler and virtual installs application files on Web
machine interpreter Server
effort Launcher
65 engineering years checks client machine against
catalogue
550K lines code
downloads necessary files via HTTP
on the web
effort to date:
http://www.osa.com.au
27 engineering years

250K lines code
Introduction
Project Management
What is a project ?
What is a successful project ?
What drives project management ?
How are projects organized ?
How is progress measured ?
How is progress monitored ?
Additional Resources

Project Management
What is a Project ?
A project is a related and interdependent set of
activities that:
are related together to meet a set of objectives
have a number of defined starts and finishes over an extended
period of time
are implemented by a team
Project work is the opposite of process work
Projects change the status quo

Project Management
What is a successful project ?

A project is successful when:
the project has a satisfied client group
the project has met its deliverable and quality objectives
the product or system is delivered on time, on budget
the project team has a sense of professional satisfaction and
accomplishment

Project Management
What drives project management ?

Each project is different.
Many factors influence how a project is conducted,
and often these factors interact.
Product functional requirements
Scope/Size,
Availability of domain expertise
Maturity of technology, development tools, and methodologies
New ?, Well understood ?, Vendor support ?
Time to Market,
Team size and experience,
Relationship with client
Product Sale vs. Contract, Joint Development ...

Prototypes, Product Trials, Acceptance arrangements ...
Project Management
How are projects organized ?

In software development: ... designers have
patterns, ... programmers have templates, and
Project Managers have Lifecycle Models.
Mature project managers and development organizations design Lifecycles
to best fit the constraints and circumstances of their projects.
Lifecycle Model types are:
Waterfall, Incremental, Iterative, Spiral ...
RAD, Component Assembly ...
Lifecycle Model Resources:
EVO (Hewlett-Packard) http://www.hp.com/hpj/aug96/augart4.htm
MeNtOR SEP (OOPL) http://www.oopl.com.au

Rational Unified Process http://www.rational.com/products/rup
Project Management
How is progress measured ?

Indicators of progress are:
the attainment of sub-goals
the completion of tasks
the completion of deliverables
Milestones
Milestones are markers, used in a project plan to track progress.
A project is said to be running to schedule if all of the
planned milestones have been passed on time
Schedule slippage is quantified by the projected delay in
passing milestones.
Project Reviews are conducted when key project milestones are

passed.
Project Management
Milestone Tracking Chart (45 Chart)
milestone-3
1/1/99
Milestone Date
1/2/99
milestone-2
1/3/99
milestone-1
1/4/99
1/5/99
1/1/99 1/2/99 1/3/99 1/4/99 1/5/99

Date Charted
How is progress monitored ?

Project Reviews
Periodic: Weekly / Monthly Progress Reviews
Milestone: End of Phase or Stage Reviews
The purpose of a review is to check that a project is on track, and
agree actions to keep, or put, it on track.
If a project is not on track, then steps must be taken to get it back
on track. For example:
change deadlines
change specifications
overtly degrade quality
partition product and add resources
use faster / better technology
work harder - in the short term.
If a project is on track, there will still be issues and risks that need

to be identified, and appropriate action plans established.
Project Management
Pressman: Software Engineering - A Practitioners Approach
Thomsett: The Busy Persons Project Management Book
http://www.ozemail.com.au/~thomsett/book/busy_book.htm
Jarvis & Crandall: Inroads to Software Quality,
Prentice Hall, ISBN 0-13-238403-5

Project Management
Scope Management
How to define the scope of a project
Project Scoping
Scoping in contracted projects
Scoping Example

Scope Management
How to define the scope of a project

Project scope is defined by the activities, responsibilities, and
deliverables required to complete the project.
In a product development project, the scope is determined by the product
features that are declared to be in, out, and undecided.
A project should proceed only when the in and out
scoping is agreed, and a process for finalizing the
undecided is agreed.
Even minor scope changes can have a major impact on a
project
may need to replan after every scope change

Scope Management
Project Scoping
Roles
Product Specification/Project
Scope developed at the intersection
of the Sales & Marketing and
Product Engineering cycles.
Sales and Product Product
Sales & Marketing gather, filter, Marketing Specification Engineering
and interpret market requirements.
Product Engineering maintains the
specification, and proposes
technologies and solutions.
Processes
Often adhoc. Can be driven by individual biases,
QFD: Quality Function Deployment (the House of Quality)

used by HP, Varian OSI
http://mijuno.larc.nasa.gov/dfc/qfd.html
Scope Management
Scoping in contracted projects

Contract Scoping
More emphasis on a negotiated
specification, delivery schedule,
acceptance criteria, and other
contract details.
Client representative propose a
Feature List and provide Domain
Expertise.
Project Team maintains the
specification, and proposes
technologies and solutions.

Scope Management
Scoping Example
Initial Brief (Enhancement Project)
A major enhancement for a large client-server product is proposed to be
released in 8 months.
The existing product specification details 54 significant features.
A new specification is to be developed in workshops with the client, and
detailed using Use Cases.
The workshops will address three distinct business areas within the
overall application domain.
Project Planning
The Project Manager develops a plan & schedule for the Use Case
workshops, and a series of scoping workshops.
The scoping workshops will be conducted through an Expert Group
drawn from (customer) domain experts, and senior project staff.

Scope Management
Scoping Example - project plan extract

Sep Oct Nov Dec
Use Case Sets 1/9 8/9 15/9 22/9 29/9 6/10 13/10 20/10 27/10 3/11 10/11 17/11 24/11 1/12 8/12 15/12 22/12
Business Sub-Domain A
Final U/C Workshop Draft 16/9
Feature Assessment 30/9
Scoping Workshop 2/10
Finalize Use Cases
Business Sub-Domain B
Scoping Workshop 9/10
Finalize Use Cases
Presentation to U/C Workshop participants 13/10
Business Sub-Domain C
+ Sub-Domain D
Scoping Workshop

23/10
Finalize Use Cases
Scope Management
Scoping Example - process
Feature List & Use Case Finalisation Process

Use Case Sets 1 - 3
Feature Assessment
Use Case
1. Complete Use Case drafts. Product Use Case
drafts
Feature List
2. Identify new Features and Issues in Use (setUse
1.) Case
Set 1: (set 1.)
Cases. 54 Features consolidate + 27 Features
& rank
3. Assess Use Case Features/Issues
4. Prepare submission to Expert Group with
indicative estimates.
Scope Verification Ranked Features
(by Expert Group)

feature 1
feature 2
... deployable system
Meetings: 2/10, 9/10, 23/10 ...
feature N Feature List
5. Resolve Issues / Clarify Requirements
development budget (scoped)
6. Consolidate and Rank Features feature M
7. Adjust list order & Identify minimum feature

set for a deployable system.

8. Management Review.
Scope Management
Scoping Example
Workshop Results
The Use Case and Scoping workshops identified and detailed:
Business Sub-Domain A: 16 Use Cases, 27 New Features
Business Sub-Domain B: 15 Use Cases, 9 New Features
Business Sub-Domain C: 25 Use Cases, No New Features

Scope Management
Scoping Example
Budgeting
Available Resource
The Project Manager has a budget of 2868 Man Days for the
development team (those project staff directly responsible for
implementing the system).
Estimates
After analyzing the results of the workshops, the development team
estimate that:
1424 Man Days will be required to re-develop system infrastructure.
1414 Man Days will be required to implement the 36 new features
The Project Manager estimates that development overheads, finals
testing, acceptance and release will require 710 Man Days.
Discretionary Capacity
After subtracting fixed costs only 734 Man Days are available to

implement the requested features.
Scope Management
Scoping Example - process
Feature List & Use Case Finalisation Process

Use Case Sets 1 - 3
Confirm Scope Use Case

Product Use Case
drafts
9. Confirm scope against Development Capacity. Feature List (setUse
1.) Case
Set 1: (set 1.)
consolidate
Use Case Detailing
54 Features + 27 Features
& rank
10. Use scoped Feature List to complete detailing of

Use Cases.
11 Confirm cost estimates for all features in scoped
system. Ranked Features
feature 1
feature 2
Development Capacity ...
...
deployable system
Discretionary Capacity feature N Project
(XX Man days) development budget Feature List
limit N features
Overheads + Release feature M (scoped)
= XX man days N Features
(710 Man days) Discretionary Capacity
XX < 734 man days costed at
< XX man days

Basic Functionality &
Note: 2868 man day budget
System Infrastructure
must be confirmed.
(1454 man days)
Scope Management
Scoping Example
Scope Finalization
Project team and Client representatives negotiate on a final set of features
that fit the development budget, while meeting the customers minimum
requirement for a deployable system.
Each feature assessed for its value to the client cf. its incremental
development cost.
A final Feature List proposed to Client Management.
Conclusion
Negotiations Failed.
Unable to derive a Feature List that met the Clients minimum
requirement.
Never commit to a fixed price (in $ or delivery date) before finalizing
scope.

Scope Management
Estimation
Estimation vs. Guesstimation
Best / Average / Worst
Estimation Example
Productivity
Scheduling

Estimation
Estimation vs. Guesstimation

A guess is a guess an estimate is an estimate
Guess: an unsupported prediction.
Guesstimate: a guess based on relevant experience, undocumented information,
or history.
Estimate: a prediction based on experience, history or information formally
recorded.
When most people say I estimate that it will take 6 days,
they are guessing or guesstimating.
Estimation requires a formal history, including predicted and
actual times for tasks, that document the organization's past
projects.
When guesstimating:
get independent guestimates from multiple sources (project team members)

document all assumptions
Estimation
Best/Average/Worst
Single figure estimates hide uncertainty
Three figure estimates capture the range of uncertainty
best: assume that things go better than expected. (10% confidence)
average: assume that things go to plan. (50% confidence)
worst: assume that things go worse than expected. (90% confidence)
If there is a wide variation between the best and worst:
allow more time for a more detailed investigation
divide the task into subtasks and estimate individually

Estimation
Estimation Example
Based on project history
Effort calibrated against size using a Class Count
Project Outline
Enhancement Project
3-tier Client-Server system (product)
Size
The new specification details functionality for 110 Business Domain
classes.
Productivity
Developer productivity has been measured and recorded for
previous releases of this product.
Productivity rates are available for new code development, code
modification, and code reuse.

Estimation
Estimation Example
Business Domain Model (BDM)
Classes Count: 110
Data & Presentation Layers
Assume 2.6 DPO classes per Business Domain class
Productivity Rates (Coding):
New: 04 Classes/person month
Modify: 06 Classes/person month
Re-Use: 10 Classes/person month
User Interface (GUI) Layer
Assume 1 GUI class per Business Domain class
Productivity Rates (Coding):
New: 04 Classes/person month
Modify: 06 Classes/person month

Re-Use: 10 Classes/person month
Estimation
Estimation Example
Resource Effort / Availability Estimates
Activity Class Productivity Effort
Count Multiplier Total Rating Man Months Man Days
DBO New 20 1.0 20 4 5.0 100
Mod 12 1.0 12 6 2.0 40
Re-use 24 1.0 24 10 2.4 48
DPO New 20 2.6 52 4 13.0 260
Mod 20 2.6 52 6 8.7 173
Re-use 14 2.6 36 10 3.6 73
Total 110 196 34.7 694
Available 829
Spare 6.7 135
Activity Class Productivity Effort

Count Multiplier Total Rating Man Months Man Days
GUI New 44 1.0 44 4 11.0 220
Mod 55 1.0 55 6 9.2 183
Re-use 11 1.0 11 10 1.1 22
Total 110 110 21.3 425
Available 585

Spare 8.0 160
Estimation
Productivity
Variation between individuals
A number of studies indicate that there is an order of magnitude
difference in productivity between the strongest and weakest team
members.
Researchers have obtained the following results for defect free, non-
commented, 3GL code:
Worst Best Case study
1 4 Barry Boehm
1 10 Capers Jones
1 16 Sackman
1 30 Putnam & Myers
Assumptions about who is to do the work and under what conditions
must be made clear when estimating and not lost when developing a team
schedule.

Estimation
Scheduling
Many other tasks need to be performed in the working
environment.
When developing a schedule, a Project Manager must take
into account time and effort expended for:
holidays and sick lease
training
reviewing other peoples work including estimates, design, code,
documentation ...
progress tracking & reporting
inter & intra-team interaction, and other team and management
communication.
Elapsed time is 2 - 3 times the estimated time

Estimation
Productivity benchmark data
International Software Benchmarking Standards Group (ISBSG)
http://www.isbsg.org.au
OSA
The sustained average coding rate at OSA is 40 lines per engineer
per day
Tools
SPR KnowledgePLAN, SPR CHECKPOINT
http://www.spr.com/html/products.htm

Estimation
Risk Management
Planning for risk management
Risk Management Example

Risk Management
Planning for risk management

Project Plan
Seek early identification of project risks, and the development of a risk
management plan with the project plan.
The table of project risks from the project plan should be regularly
updated and reviewed at Project Reviews.
Risk Table
For each identified risk, should include:
the current ranking
the probability of the risk eventuating
the severity of the risk
consequences if the risk eventuates
a mitigation strategy
a contingency plan

Risk Management

1. Risks
Table 1 summarizes the major risks for the Widgets project, as of the completion of the Product Definition Phase. A ranking is provided for the top 7 risks.
Rank Name Id Occurrence Severity Status Consequences Mitigation Strategy Contingency

Probability
(H/M/L) (H/M/L)
Overall Project Risks

1 Feedback from Widget 1.0 trials is not received 1.1 H H open No prior field experience from Make results from Incremental
in time to be incorporated in the Widget 2.0 Widget 1.0 reduces ability to Releases available to customers
product. avoid acceptance problems. for preview.
2 Customer doesnt meet delivery milestones for 1.2 M H open Schedule slippage Regular progress reviews in No delivery schedule
external dependencies. Project Management forums. commitments.
Escalate to customer sponsor
3 Key resources are diverted to Widget 1.0 support 1.3 M H open Delayed completion and release Prioritize maintenance tasks and Add extra resources for
during Widgets 2.0 development. of product. defer low priority fixes. support.
4 Insufficient resources and duration planned for 1.4 M H open Formal acceptance delayed Contract commitment from
Acceptance Testing Customer
5 New or immature business practices (eg. Red 1.5 M M open Identification of new features. Early analysis of potential for Schedule
Widget Design) in Customer lead to change Extra incremental releases process changes. implementation of
requests in Construction or Acceptance phases. delayed final release to Strict observance to Change change requests after
Customer acceptance. Management processes acceptance of baseline
Widget 2.0 system.
6 Support for Widget 1.0 sales diverts resources 1.6 L M Open Delayed completion and release Selective marketing of Widget 1.0 Cap resources allocated
from new product development. of product. prior to Widget 2.0 completion. to Sales & Marketing
Quote longer lead times in support.
delivery (post sale) to coincide
with Widget 2.0 completion
7 Integration risk with technologies new to ACME 1.7 H L Open Schedule slippage Prototype in Nov - Dec. Look at alternate
Widgets being introduced in Widget 2.0 Non-optimal design decisions. technologies.
architecture (eg. CORBA) Buy in expertise by
hire experts in
technologies.

Table 1: Major Project Risks
Risk Management
Table 2. Summarizes risks identified and managed to the acceptable outcomes in the project to date.
Rank Name Id Occurrence Severity Status Consequences Mitigation Strategy Contingency

Probability
(H/M/L) (H/M/L)
Product Definition Phase Risks

Too much parallelism in specification and 2.1 H M closed Confusion Regularly crosscheck and Pause specification
modeling tasks (inefficient and faulty Defects in specifications and models. synchronize progress through the activities until confusion
information flow between modeling teams). project's Technical Co-ordination cleared-up
Group (TCG).
Divergence in Wingdings and Widgets 2.2 L H closed Delay in achieving sign-off for Re-focus on project goals Escalate to as necessary
specifications. ACME Widgets and specifications. Regular Use Case team review of to the Widgets Expert
Customer teams disagree on what to deliver. draft specifications. Group, Widgets
Scope resolution through the Management Group, and
Expert Group. Governance Board.
Cant identify a new (viable) Architecture 2.3 L H closed Unable to meet performance and/or Involve architectural experts from Retain the existing
volume and/or usability requirements other sources to help resolve issues Widget 1.0 architecture.
Development delayed until and identify options.
architectural issues resolved
ACME Widgets and Customer disagree on 2.4 H L-M closed Customer withdraws from participation Involve Customer in scoping More focus on World
Feature Scope. in project. activities. Market to gain non-
Customer sales.
Construction Phase Risks
Acceptance Phase Risks
Table 2: Risk History

Risk Management

Risk Analysis & Planning
1. Feedback from Widget 1.0 trials is not received in time to be
incorporated in the Widget 2.0 product.
Probability: High Severity: High
Consequence: No prior field experience from Widget 1.0 reduces ability to
avoid acceptance problems.
Mitigation Strategy: Make results from Incremental Releases available to
customers for preview.
2. Customer doesnt meet delivery milestones for external
dependencies.
Probability: Medium Severity: High
Consequence: Schedule slippage.
Mitigation Strategy: a) Regular progress reviews in Project Management
forums. b) Escalate to customer sponsor.
Contingency: No delivery schedule commitments.

Risk Management

3. Key resources are diverted to Widget 1.0 support during Widgets 2.0
development.
4. Insufficient resources and duration planned for Acceptance Testing
5. New or immature business practices (eg. Red Widget Design) in
Customer lead to change requests in Construction or Acceptance
phases.
Probability: Medium Severity: Medium
Consequence: a) Identification of new features after specification sign-off. b)
Extra incremental releases delayed final release to Customer acceptance.
Mitigation Strategy: a) Early analysis of potential for process changes.
b) Strict observance to Change Management processes.
Contingency: Schedule implementation of change requests after acceptance
of baseline Widget 2.0 system.

6. Support for Widget 1.0 sales diverts resources from new product
development.
Risk Management

7. Integration risk with technologies new to ACME Widgets being
introduced in Widget 2.0 architecture (eg. CORBA).
Probability: High Severity: Low
Consequence: a) Schedule Slippage. b) Non-optimal design decisions..
Mitigation Strategy: Prototype in Nov - Dec.
Contingency: a) Look at alternate technologies. b) Buy in expertise by hire
experts in technologies.

Risk Management

Risk Analysis & Planning (managed)
1. Too much parallelism in specification and modeling tasks (inefficient
and faulty information flow between modeling teams).
2. Divergence in Wingdings and Widgets specifications. ACME Widgets
and Customer teams disagree on requirement specifications.
Probability: Low Severity: High
Consequence: Delay in achieving sign-off for specifications.
Mitigation Strategy: a) Re-focus on project goals. b) Regular Use Case
team review of draft specifications. c) Scope resolution through the Expert
Group.
Contingency: Escalate to as necessary to the Widgets Expert Group, Widgets
Management Group, and Governance Board.
3. Cant identify a new (viable) Architecture.
4. ACME Widgets and Customer disagree on Feature Scope

Risk Management
Project Risk Assessment Form
http://www.ozemail.com.au/~thomsett/form/Default.htm

Risk Management
People Management
Managers Role
ensure that a team meets its set objectives
ensure that all team members have an opportunity to contribute
help team members to achieve the goals that they set themselves
Remember
Management decisions effect people
Team members are not just resources:
they are individuals with their own ambitions and interests
they MUST be treated with respect.
Above all have fun !

People Management
Questions

Software Engineering: Analysis and Design (CSE3308) : Lecture 9b: Project Management in Industry

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Engineering: Analysis and Design (CSE3308) : Lecture 9b: Project Management in Industry

Hochgeladen von

Copyright:

Verfügbare Formate

Open Software Associates

Software Engineering: Analysis and

Lecture 9b: Project Management in

c 1998 Open Software Associates

Lecture 9b: Project Management in Industry

c 1998 Open Software Associates

c 1998 Open Software Associates

Varian OSI Products

c 1998 Open Software Associates

Siemens Research Products

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

What is a successful project ?

c 1998 Open Software Associates

What drives project management ?

c 1998 Open Software Associates

How are projects organized ?

c 1998 Open Software Associates

How is progress measured ?

c 1998 Open Software Associates

1/1/99 1/2/99 1/3/99 1/4/99 1/5/99

How is progress monitored ?

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

How to define the scope of a project

c 1998 Open Software Associates

c 1998 Open Software Associates

Scoping in contracted projects

c 1998 Open Software Associates

c 1998 Open Software Associates

Scoping Example - project plan extract

c 1998 Open Software Associates

Scoping Example - process

Feature List & Use Case Finalisation Process

Scope Verification Ranked Features

(by Expert Group)

7. Adjust list order & Identify minimum feature

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

Scoping Example - process

Feature List & Use Case Finalisation Process

Confirm Scope Use Case

10. Use scoped Feature List to complete detailing of

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

Estimation vs. Guesstimation

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

Activity Class Productivity Effort

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

c 1998 Open Software Associates

Planning for risk management

c 1998 Open Software Associates