Download
software project management n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Project Management PowerPoint Presentation
Download Presentation
Software Project Management

Software Project Management

263 Vues Download Presentation
Télécharger la présentation

Software Project Management

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Project Management Dr. Nguyen Hai Quan Email: Quan_nh@yahoo.com Phone: 0934221978

  2. Agenda • Software Project Planning • Software Project Estimation • Software Project Scheduling

  3. Agenda • Software Project Planning • Software Project Estimation • Software Project Scheduling

  4. Planning, Estimating, Scheduling • What’s the difference? • Plan: Identify activities. No specific start and end dates. • Estimating: Determining the size & duration of activities. • Schedule: Adds specific start and end dates, relationships, and resources.

  5. Planning • Preliminary planning starts on day one • Even in the pre-project phase • Should not be conducted “in secret” • Need buy-in and approval • Very important step • Both from above and below

  6. Planning FAQ • How much will it cost? • How long will it take? • How many people will it take? • What might go wrong?

  7. Planning • Scoping • Estimation • Risk • Schedule • Control Strategy

  8. Project Planning: A 12 Step Program • Set goal and scope • Select lifecycle • Set org./team form • Start team selection • Determine risks • Create WBS • Identify tasks • Estimate size • Estimate effort • Identify task dependencies • Assign resources • Schedule work

  9. Your PM Process • Why • Deliverable: ROI • What • SOW, Requirements • How • Design Specification, SDP, Lifecycle • Do • Execution • Done • PPR Futrell, Shafer, Shafer, “Quality Software Project Management”

  10. Primary Planning Steps • Identify project scope and objectives • Identify project organizational environment • Analyze project characteristics • Identify project products and activities • Estimate effort for each activity • Identify risk • Allocate resources • Review and communicate plan Planning Document Product Document

  11. Planning Documents • Software Development Plan (SDP) • Software Quality Assurance Plan (SQAP) • Software Configuration Management Plan (SCMP) • Risk Management Plan • Software Process Improvement Plan • Communications Management Plan • Migration Plan • Operations Plan

  12. Planning Documents (cont.) • You (the PM) need to choose which documents are appropriate • Docs do not have to be lengthy • Small Set: • Software Development Plan • Risk Management Plan • Software Quality Assurance Plan • Software Configuration Management Plan

  13. Planning Documents (cont.) • Project ROI Analysis • Statement of Work (SOW) • Project Charter • Software Project Management Plan (SPMP) • Budget • Responsibility Assignment Matrix (RAM) • Risk Management Plan

  14. Product Documents • Statement of Need • System Interface Specification • Software Requirements Specification • Software Design Specification • Software Validation & Verification Plan • User Documentation Support Plan Maintenance Documentation

  15. Software Development Plan • Software Project Management Plan (SPMP) • Some consider it the most important document in the project (along with SRS) • Can be seen as an aggregation of other core documents • Evolves over time as pieces come together

  16. Plans Evolve Over Time NASA’s “Manager’s Handbook for Software Development”

  17. SDP / SPMP • Fundamental Sections • Project overview • Deliverables • Project organization • Managerial processes • Technical processes • Budget • Schedule • Example: ACID project

  18. Process Planning

  19. Risk Management Plan • Brainstorm potential risks • Estimate the impact of each risk • a rough estimate of the probability that the risk will occur • the potential impact of that risk on the project if it does eventually materialize • Make a mitigation plan • Alter the project plan • Add additional tasks • Plan for risks

  20. Communications Management Plan • Often a section of SPMP • Describes information flow to all parties • Gathering and distributing information • Status meetings • Monthly, Weekly, Daily? • Status reports are vital

  21. How To Schedule • 1. Identify “what” needs to be done • Work Breakdown Structure (WBS) • 2. Identify “how much” (the size) • Size estimation techniques • 3. Identify the dependency between tasks • Dependency graph, network diagram • 4. Estimate total duration of the work to be done • The actual schedule

  22. WBS & Estimation • How did you feel when I asked • “How long will your project take?” • Not an easy answer to give right? • At least not if I were are real customer on a real project • How can you manage that issue?

  23. Partitioning Your Project • You need to decompose your project into manageable chunks • ALL projects need this step • Divide & Conquer • Two main causes of project failure • Forgetting something critical • Ballpark estimates become targets • How does partitioning help this?

  24. Project Elements • A Project: functions, activities, tasks

  25. Work Breakdown Structure: WBS • Hierarchical list of project’s work activities • 2 Formats • Outline (indented format) • Graphical Tree (Organizational Chart) • Uses a decimal numbering system • Ex: 3.1.5 • 0 is typically top level • Includes • Development, Mgmt., and project support tasks • Shows “is contained in” relationships • Does not show dependencies or durations

  26. WBS • Contract WBS (CWBS) • First 2 or 3 levels • High-level tracking • Project WBS (PWBS) • Defined by PM and team members • Tasks tied to deliverables • Lowest level tracking

  27. A Full WBS Structure • Up to six levels (3-6 usually) such as • Upper 3 can be used by customer for reporting (if part of RFP/RFQ) • Different level can be applied to different uses • Ex: Level 1: authorizations; 2: budgets; 3: schedules

  28. WBS Chart Example

  29. WBS Outline Example 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production

  30. WBS Types • Process WBS • a.k.a Activity-oriented • Ex: Requirements, Analysis, Design, Testing • Typically used by PM • Product WBS • a.k.a. Entity-oriented • Ex: Financial engine, Interface system, DB • Typically used by engineering manager • Hybrid WBS: both above • This is not unusual • Ex: Lifecycle phases at high level with component or feature-specifics within phases • Rationale: processes produce products

  31. WBS Types (cont.) • Less frequently used alternatives • Organizational WBS • Research, Product Design, Engineering, Operations • Can be useful for highly cross-functional projects • Geographical WBS • Can be useful with distributed teams • NYC team, San Jose team, Off-shore team

  32. Product WBS

  33. Process WBS

  34. Outline WBS w/Gantt

  35. Work Packages • Generic term for discrete tasks with definable end results • Typically the “leaves” on the tree • The “one-to-two” rule • Often at: 1 or 2 persons for 1 or 2 weeks • Basis for monitoring and reporting progress • Can be tied to budget items (charge numbers) • Resources (personnel) assigned • Ideally shorter rather than longer • Longer makes in-progress estimates needed • These are more subjective than “done” • 2-3 weeks maximum for software projects • 1 day minimum (occasionally a half day) • Not so small as to micro-manage

  36. WBS & Methodology • PM must map activities to chosen lifecycle • Each lifecycle has different sets of activities • Integral process activities occur for all • Planning, configuration, testing • Operations and maintenance phases are not normally in plan (considered post-project) • Some models are “straightened” for WBS • Spiral and other iterative models • Linear sequence several times • Deliverables of tasks vary by methodology

  37. WBS Techniques • Top-Down • Bottom-Up • Analogy • Rolling Wave • 1st pass: go 1-3 levels deep • Gather more requirements or data • Add more detail later • Post-its on a wall

  38. WBS Techniques • Top-down • Start at highest level • Systematically develop increasing level of detail • Best if • The problem is well understood • Technology and methodology are not new • This is similar to an earlier project or problem • But is also applied in majority of situations

  39. WBS Techniques • Bottom-up • Start at lowest level tasks • Aggregate into summaries and higher levels • Cons • Time consuming • Needs more requirements complete • Pros • Detailed

  40. WBS Techniques • Analogy • Base WBS upon that of a “similar” project • Use a template • Analogy also can be estimation basis • Pros • Based on past actual experience • Cons • Needs comparable project

  41. WBS Techniques • Brainstorming • Generate all activities you can think of that need to be done • Group them into categories • Both Top-down and Brainstorming can be used on the same WBS • Remember to get the people who will be doing the work involved (buy-in matters!)

  42. WBS – Basis of Many Things • Network scheduling • Costing • Risk analysis • Organizational structure • Control • Measurement

  43. WBS Guidelines Part 1 • Should be easy to understand • Some companies have corporate standards for these schemes • Some top-level items, like Project Mgmt. are in WBS for each project • Others vary by project • What often hurts most is what’s missing • Break down until you can generate accurate time & cost estimates • Ensure each element corresponds to a deliverable

  44. WBS Guidelines Part 2 • How detailed should it be? • Not as detailed as the final MS-Project plan • Each level should have no more than 7 items • It can evolve over time • What tool should you use? • Excel, Word, Project • Org chart diagramming tool (Visio, etc) • Specialized commercial apps • Re-use a “template” if you have one

  45. Agenda • Software Project Planning • Software Project Estimation • Software Project Scheduling

  46. Estimations • Very difficult to do, but needed often • Created, used or refined during • Strategic planning • Feasibility study and/or SOW • Proposals • Vendor and sub-contractor evaluation • Project planning (iteratively) • Basic process • Estimate the size of the product • Estimate the effort (man-months) • Estimate the schedule • NOTE: Not all of these steps are always explicitly performed

  47. Estimations • Remember, an “exact estimate” is an oxymoron • Estimate how long will it take you to get home from class tonight • On what basis did you do that? • Experience right? • Likely as an “average” probability • For most software projects there is no such ‘average’ • Most software estimations are off by 25-100%

  48. Estimation • Target vs. Committed Dates • Target: Proposed by business or marketing • Do not commit to this too soon! • Committed: Team agrees to this • After you’ve developed a schedule

  49. Cone of Uncertainty

  50. Estimation • Size: • Small projects (10-99 FPs), variance of 7% from post-requirements estimates • Medium (100-999 FPs), 22% variance • Large (1000-9999 FPs) 38% variance • Very large (> 10K FPs) 51% variance