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

Software Engineering: Analysis and Design (CSE3308)

Lecture 9b: Project Management in Industry

CSE3308/CSC3080/DMS/2000/24


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

Introduction


Trevor holmes l.jpg

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

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

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

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

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

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

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

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

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

  • Estimation vs. Guesstimation

  • Best / Average / Worst

  • Estimation Example

  • Productivity

  • Scheduling

  • Additional Resources

Estimation


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

Estimation


Best average worst l.jpg
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 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


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


Estimation example34 l.jpg
Estimation Example

  • Resource Effort / Availability Estimates

Estimation


Productivity l.jpg
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 l.jpg
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 l.jpg
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 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

    • http://www.ozemail.com.au/~thomsett/form/Default.htm

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



ad