software engineering analysis and design cse3308
Download
Skip this Video
Download Presentation
Software Engineering: Analysis and Design (CSE3308)

Loading in 2 Seconds...

play fullscreen
1 / 48

Lecture 9b - PowerPoint PPT Presentation


  • 278 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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

Software Engineering: Analysis and Design (CSE3308)

Lecture 9b: Project Management in Industry

CSE3308/CSC3080/DMS/2000/24

lecture 9b project management in industry
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

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”.

Career

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

Introduction

varian osi products
SpectrAA-600/800Atomic Absorption spectrometer system.

consists of:

Microprocessor controlled instrument (near real-time control).

PC Workstation for system control and data management.

Accessories

Graphite Tube Atomizer (GTA)

Sample Preparation System (SPS)

product price

$40K to $80K

effort:

max team 15

50+ engineering years

>500K lines code

on the web:

http://www.varianinc.com/osi

Varian OSI Products

Introduction

siemens research products
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

effort:

max team 60

100+ engineering years

development budget > $20M

500K lines code

on the web

http://www.sr.com.au

Siemens Research Products

Introduction

osa products
OpenUIcross-GUI client/server UIMS

consists of:

cross GUI runtime engine

GUI Builder

integrated client / server messaging

compiler and virtual machine interpreter

effort

65 engineering years

550K lines code

on the web

http://www.osa.com.au

NetDeployInternet application deployment and version management system

consists of:

Packer

identifies component files of application

generates catalogue file

installs application files on Web Server

Launcher

checks client machine against catalogue

downloads necessary files via HTTP

effort to date:

27 engineering years

250K lines code

OSA Products

Introduction

project management
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
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
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
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
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
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

Milestone Tracking Chart (45º Chart)

milestone-3

1/1/99

1/2/99

1/3/99

1/4/99

1/5/99

milestone-2

Milestone Date

milestone-1

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

Date Charted

how is progress monitored
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
Additional Resources
  • Pressman: Software Engineering - A Practitioner’s Approach
  • Thomsett: The Busy Person’s 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
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
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 & Marketing gather, filter, 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

Sales andMarketing

ProductEngineering

ProductSpecification

Project Scoping

Scope Management

scoping in contracted projects
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
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

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

16/9

30/9

2/10

30/9

7/10

9/10

13/10

13/10

21/10

23/10

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

Use Case

drafts

Set 1:

+ 27 Features

ProductFeature List

54 Features

Use Case

(set 1.)

Use Case

(set 1.)

Feature List

(scoped)

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.

consolidate

& rank

Ranked Features

feature 1

feature 2

...

deployable system

...

feature N

development budget

feature M

Scope Management

scoping example25
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
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

Use Case

drafts

Set 1:

+ 27 Features

ProductFeature List

54 Features

Use Case

(set 1.)

Use Case

(set 1.)

Project

Feature List

(scoped)

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.

consolidate

& 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
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
Estimation
  • Estimation vs. Guesstimation
  • Best / Average / Worst
  • Estimation Example
  • Productivity
  • Scheduling
  • Additional Resources

Estimation

estimation vs guesstimation
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
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
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 example33
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 example34
Estimation Example
  • Resource Effort / Availability Estimates

Estimation

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

Estimation

scheduling
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 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

Estimation

additional resources37
Additional Resources
  • 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
Risk Management
  • Planning for risk management
  • Risk Management Example
  • Additional Resources

Risk Management

planning for 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

risk management example42
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
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
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
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
Additional Resources
  • Project Risk Assessment Form
    • http://www.ozemail.com.au/~thomsett/form/Default.htm

Risk Management

people management
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

ad