Software engineering analysis and design cse3308
1 / 48

Lecture 9b - PowerPoint PPT Presentation

  • Uploaded on

Software Engineering: Analysis and Design (CSE3308) Lecture 9b: Project Management in Industry CSE3308/CSC3080/DMS/2000/24 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Lecture 9b' - johana

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 engineering analysis and design cse3308 l.jpg

Software Engineering: Analysis and Design (CSE3308)

Lecture 9b: Project Management in Industry


Lecture 9b project management in industry l.jpg
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


Trevor holmes l.jpg


B.Sc (Physics/Mathematics) Deakin 1980

Dip.Eng (Digital Control) FIT 1985

M.App.Sc Monash 1993“The Intelligent Interpretation of Line Drawings and Text using Pattern Recognition Analysis”.


Olex Cables 1980-1983Software Engineer

ACI Computer Services 1983 - 1987System Manager, Systems Engineer.

Varian Australia 1987-1995Software Engineer, Software Marketing Manager, Project Manager, Software Quality Manager

Hewlett-Packard 1985-1996Consultant (PSO)

Siemens Research 1996-1997Project Manager (SIEPLAN / Capacity Integrator Project)

Open Software Associates1998 - currentProject Manager

Trevor Holmes


Varian osi products l.jpg

SpectrAA-600/800Atomic Absorption spectrometer system.

consists of:

Microprocessor controlled instrument (near real-time control).

PC Workstation for system control and data management.


Graphite Tube Atomizer (GTA)

Sample Preparation System (SPS)

product price

$40K to $80K


max team 15

50+ engineering years

>500K lines code

on the web:

Varian OSI Products


Siemens research products l.jpg

Sieplan/Capacity IntegratorNetwork planning and design tool for Telecommunications Transmission(SDH & PDH) Networks.

consists of:

5 to 200 GUI Clients (Windows)

Unix based server (HPUX)

Versant OODBMS with databases up to 20GB.

product price

$500K to $10M


max team 60

100+ engineering years

development budget > $20M

500K lines code

on the web

Siemens Research Products


Osa products l.jpg

OpenUIcross-GUI client/server UIMS

consists of:

cross GUI runtime engine

GUI Builder

integrated client / server messaging

compiler and virtual machine interpreter


65 engineering years

550K lines code

on the web

NetDeployInternet application deployment and version management system

consists of:


identifies component files of application

generates catalogue file

installs application files on Web Server


checks client machine against catalogue

downloads necessary files via HTTP

effort to date:

27 engineering years

250K lines code

OSA Products


Project management l.jpg
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 l.jpg
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 l.jpg
What is a successful project ?

  • A project is successful when:

    • the project has a satisfied client group

    • the project has met it’s 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 l.jpg
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 l.jpg
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)

    • MeNtOR SEP (OOPL)

    • Rational Unified Process

Project Management

How is progress measured l.jpg
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

Slide15 l.jpg

Milestone Tracking Chart (45º Chart)








Milestone Date


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

Date Charted

How is progress monitored l.jpg
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

Additional resources l.jpg
Additional Resources

  • Pressman: Software Engineering - A Practitioner’s Approach

  • Thomsett: The Busy Person’s Project Management Book


  • Jarvis & Crandall: Inroads to Software Quality,Prentice Hall, ISBN 0-13-238403-5

Project Management

Scope management l.jpg
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 l.jpg
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 l.jpg


Product Specification/Project Scope developed at the intersection of the Sales & Marketing and Product Engineering cycles.

Sales & Marketing gather, filter, and interpret market requirements.

Product Engineering maintains the specification, and proposes technologies and solutions.


Often adhoc. Can be driven by individual biases,

QFD: Quality Function Deployment (the House of Quality)

used by HP, Varian OSI

Sales andMarketing



Project Scoping

Scope Management

Scoping in contracted projects l.jpg
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 l.jpg
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 l.jpg
































Scoping Example - project plan extract

Use Case Sets

Business Sub-Domain A

Final U/C Workshop Draft

Feature Assessment

Scoping Workshop Œ

Finalize Use Cases

Business Sub-Domain B

Final U/C Workshop Draft

Feature Assessment

Scoping Workshop 

Finalize Use Cases

Presentation to U/C Workshop participants

Business Sub-Domain C

+ Sub-Domain D

Final U/C Workshop Draft

Feature Assessment

Scoping Workshop Ž

Finalize Use Cases

Scope Management

Scoping example process l.jpg

Use Case


Set 1:

+ 27 Features

ProductFeature List

54 Features

Use Case

(set 1.)

Use Case

(set 1.)

Feature List


Scoping Example - process

Feature List & Use Case Finalisation Process

Use Case Sets 1 - 3

  • Feature Assessment

    1. Complete Use Case drafts.

    2. Identify “new” Features and Issues in Use Cases.

    3. Assess Use Case Features/Issues

    4. Prepare submission to Expert Group with indicative estimates.

  • Scope Verification(by Expert Group)

    Meetings: Œ 2/10,  9/10, Ž 23/10

    5. Resolve Issues / Clarify Requirements

    6. Consolidate and Rank Features

    7. Adjust list order & Identify minimum feature set for a “deployable system”.

    8. Management Review.


& rank

Ranked Features

feature 1

feature 2


deployable system


feature N

development budget

feature M

Scope Management

Scoping example25 l.jpg
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 example26 l.jpg
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 process27 l.jpg

Use Case


Set 1:

+ 27 Features

ProductFeature List

54 Features

Use Case

(set 1.)

Use Case

(set 1.)


Feature List


N Features

costed at

< XX man days

Scoping Example - process

Feature List & Use Case Finalisation Process

Use Case Sets 1 - 3

  • Confirm Scope

    9. Confirm scopeagainst Development Capacity.

  • Use Case Detailing

    10. Use scoped Feature List to complete detailing of Use Cases.

    11 Confirm cost estimates for all features in scoped system.


& rank

Ranked Features

feature 1

feature 2


Development Capacity

deployable system


feature N

Discretionary Capacity

(XX Man days)

development budget

limit N features

= XX man days

feature M

Overheads + Release

(710 Man days)

Discretionary Capacity

XX < 734 man days

Note: 2868 man day budget

must be confirmed.

Basic Functionality &

System Infrastructure

(1454 man days)

Scope Management

Scoping example28 l.jpg
Scoping Example

  • Scope Finalization

    • Project team and Client representatives negotiate on a final set of features that fit the development budget, while meeting the customer’s minimum requirement for a deployable system.

      • Each feature assessed for its value to the client cf. it’s incremental development cost.

      • A final Feature List proposed to Client Management.

  • Conclusion

    • Negotiations Failed.

      • Unable to derive a Feature List that met the Client’s minimum requirement.

    • Never commit to a “fixed price” (in $ or delivery date) before finalizing scope.

Scope Management

Estimation l.jpg

  • Estimation vs. Guesstimation

  • Best / Average / Worst

  • Estimation Example

  • Productivity

  • Scheduling

  • Additional Resources


Estimation vs guesstimation l.jpg
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


Best average worst l.jpg

  • 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 example l.jpg
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 example33 l.jpg
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 example34 l.jpg
Estimation Example

  • Resource Effort / Availability Estimates


Productivity l.jpg

  • 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:

      • WorstBestCase 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.


Scheduling l.jpg

  • 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 people’s 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


Additional resources37 l.jpg
Additional Resources

  • Productivity benchmark data

    • International Software Benchmarking Standards Group (ISBSG)


    • OSA

      • The sustained average coding rate at OSA is 40 lines per engineer per day

  • Tools




Risk management l.jpg
Risk Management

  • Planning for risk management

  • Risk Management Example

  • Additional Resources

Risk Management

Planning for risk management l.jpg
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

Risk management example l.jpg
Risk Management Example

Risk Management

Risk management example41 l.jpg
Risk Management Example

Risk Management

Risk management example42 l.jpg
Risk Management Example

  • 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 doesn’t 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

Risk management example43 l.jpg
Risk Management Example

  • Risk Analysis & Planning

    • 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

Risk management example44 l.jpg
Risk Management Example

  • Risk Analysis & Planning

    • 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 management example45 l.jpg
Risk Management Example

  • 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. Can’t identify a new (viable) Architecture.

    • 4. ACME Widgets and Customer disagree on Feature Scope

Risk Management

Additional resources46 l.jpg
Additional Resources

  • Project Risk Assessment Form


Risk Management

People management l.jpg
People Management

  • Manager’s 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