Lecture 9b
Upcoming SlideShare
Loading in...5
×
 

Lecture 9b

on

  • 340 views

 

Statistics

Views

Total Views
340
Views on SlideShare
340
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • OpenUI 201K OPL + 333K C++ NetDeploy team size 3 -> 10
  • Commentary : A project is a related and interdependent set of activities that: Project work is the opposite of process work Process : ongoing, general objectives, and maybe no deliverables; about the way things are done. Project : planned end, specific objectives & deliverables; about the things (products) themselves. Projects change the status quo significant functional and/or quality improvement improve the product’s competitive position to open new market opportunities to satisfy particular customer requirements
  • Commentary : If the first three points are not achieved, then the project team won’t be given many more projects … If the last point is not achieved, then the project team won’t want to do many more projects ...

Lecture 9b Lecture 9b Presentation Transcript

  • 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
      • Focus on (software) product development projects.
    • Topics
      • Project Management Overview
      • Scope Management
      • Estimation
      • Risk Management
      • People Management
  • 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-1983 Software Engineer
      • ACI Computer Services 1983 - 1987 System Manager, Systems Engineer.
      • Varian Australia 1987-1995 Software Engineer, Software Marketing Manager, Project Manager, Software Quality Manager
      • Hewlett-Packard 1985-1996 Consultant (PSO)
      • Siemens Research 1996-1997 Project Manager (SIEPLAN / Capacity Integrator Project)
      • Open Software Associates 1998 - current Project Manager
  • Varian OSI Products
    • SpectrAA-600/800 Atomic 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
  • Siemens Research Products
    • Sieplan/Capacity Integrator Network 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
  • OSA Products
    • OpenUI cross-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
    • NetDeploy Internet 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
  • 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
  • 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
  • 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
  • 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 ...
  • 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
  •  
  •  
  • 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.
  • Milestone Tracking Chart (45º Chart) Date Charted 1/1/99 1/2/99 1/3/99 1/4/99 1/5/99 Milestone Date 1/1/99 1/2/99 1/3/99 1/4/99 1/5/99              milestone-2 milestone-1 milestone-3
  • 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.
  • 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
  • Scope Management
    • How to define the scope of a project
    • Project Scoping
    • Scoping in contracted projects
    • Scoping Example
  • 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
  • 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 and Marketing Product Engineering Product Specification
  • 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.
  • 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.
  • 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 Sep Oct 15/12 8/12 1/12 24/11 17/11 10/11 3/11 27/10 20/10 13/10 6/10 22/9 29/9 15/9 8/9 22/12 1/9 Nov Dec 7/10 30/9 9/10 16/9 2/10 30/9 21/10 13/10 23/10 13/10
  • Scoping Example - process feature 1 feature 2 ... … feature M consolidate & rank Use Case Sets 1 - 3 Ranked Features ... feature N deployable system development budget
    • 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.
    Feature List & Use Case Finalisation Process Use Case (set 1.) Use Case (set 1.) Product Feature List 54 Features Use Case drafts Set 1: + 27 Features Feature List (scoped)
  • 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
  • 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.
  • Scoping Example - process feature 1 feature 2 ... … feature M consolidate & rank Use Case Sets 1 - 3 Ranked Features ... feature N deployable system development budget limit N features = XX man days Basic Functionality & System Infrastructure (1454 man days) Discretionary Capacity (XX Man days) Development Capacity Discretionary Capacity XX < 734 man days Note: 2868 man day budget must be confirmed.
    • Confirm Scope
      • 9. Confirm scope against 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.
    Feature List & Use Case Finalisation Process Overheads + Release (710 Man days) Use Case (set 1.) Use Case (set 1.) Product Feature List 54 Features Use Case drafts Set 1: + 27 Features Project Feature List (scoped) N Features costed at < XX man days
  • 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.
  • Estimation
    • Estimation vs. Guesstimation
    • Best / Average / Worst
    • Estimation Example
    • Productivity
    • Scheduling
    • Additional Resources
  • 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
    • 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
    • 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 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 Example
    • Resource Effort / Availability Estimates
  • 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.
  • 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
  • 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
  • Risk Management
    • Planning for risk management
    • Risk Management Example
    • Additional Resources
  • 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 Example
  • Risk Management Example
  • 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 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 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 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
  • Additional Resources
    • Project Risk Assessment Form
      • http://www.ozemail.com.au/~thomsett/form/Default.htm
  • 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 !
  • Questions