1 / 48

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 Goal To cover some of the key topics in Project Management, in a practical way, using actual industry examples. Focus

johana
Download Presentation

Software Engineering: Analysis and Design (CSE3308)

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering: Analysis and Design (CSE3308) Lecture 9b: Project Management in Industry CSE3308/CSC3080/DMS/2000/24

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  27. Estimation • Estimation vs. Guesstimation • Best / Average / Worst • Estimation Example • Productivity • Scheduling • Additional Resources Estimation

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

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

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

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

  32. Estimation Example • Resource Effort / Availability Estimates Estimation

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

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

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

  36. Risk Management • Planning for risk management • Risk Management Example • Additional Resources Risk Management

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

  38. Risk Management Example Risk Management

  39. Risk Management Example Risk Management

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

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

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

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

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

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

  46. Questions

More Related