Project Management for Successful People, Product, and Process

1. People, Product, Process --> Project • Project Management • Project and Process Metrics Recall: overall project components: project people product process successful management plan must deal effectively with all three components

2. Project--Critical Practices • CRITICAL PRACTICES: • people-aware program management • well-defined product goals • well-defined process • quantitative, metric-based project management • risk management—identify, plan for risks • accurate cost and schedule estimation • uniform standards • tracking defects against quality definitions

3. PEOPLE ISSUES ("HUMAN FACTORS"): • what are goals / functions of each set of stakeholders? • GOAL FUNCTION • senior managers • tech managers • "practitioners" • (engineers,programmers) • customers • end-users • where do goals conflict? 1. People-aware Program Management

4. 1. People-aware Program Management team leaders need good MANAGEMENT SKILLS to: provide motivation maintain organization encourage creativity reward good work support positive work environment training in management skills is necessary; learning them on the job is not acceptable or efficient How can engineers learn these skills during their college years?

5. 1. People-aware Program Management TEAM ORGANIZATION-CHOICES: democratic / controlled centralized / decentralized there is no “best” organization for all tasks some factors to consider: ----problem difficulty ----problem size ----team lifetime ----how much modularity is possible ----quality requirements of finished product ----time constraints ----communication needs How does this decision correlate with the process model you choose?

6. 1. People-aware Program Management GOOD COMMUNICATION AND COORDINATION are an absolute MUST Two kinds of communication channels must be set up: formal communication: documents, memos, milestones, schedules, etc. quality assurance--"reviews" informal communication: group meetings, problem solving sessions, "collocation"

7. 2. Well-defined Product Goals PRODUCT: product is the overall "goal" it must be WELL-DEFINED customer input is essential: requirements intermediate reviews on-site customer (extreme programming)

8. 3. Well-defined Process • PROCESS: • many models available, as we have discussed • PROCESS MODEL MUST MATCH: • ----product • ----available resources

9. 4. quantitative, metric-based project management PROJECT *start out right *maintain momentum *track progress *"make smart decisions" *conduct "postmortem" *watch for Pressman’s "10 signs of trouble"

10. 4. quantitative, metric-based project management "10 signs of trouble" : 1. developers don't understand customer needs 2. product scope poorly defined 3. changes poorly managed 4. chosen technology changes 5. business needs change or are ill-defined 6. deadlines unrealistic 7. users resistant 8. sponsorship lost 9. project team members lack appropriate skills 10. team does not use best practices/lessons learned

11. 4. quantitative, metric-based project management Planning for a successful project: Resources: --We need ways to estimate the resources it will take to complete the project --We need to plan how to arrange the project so that sufficient resources will be available Risks: --We need to plan for "risks"--essentially, "what can go wrong"

12. 4. quantitative, metric-based project management --how can we get data to measure? * data from previous projects * "benchmarks”--e.g., industry standards * theoretical models --what quantities do we need to estimate at the planning stage? --how can we quantify qualitative questions, e.g., how “difficult” are the programming tasks?

13. 4. quantitative, metric-based project management • Things we want to measure: • software • size • difficulty • quality • the process itself • productivity • cost • Things we can measure: • software • LOC, #classes • #I/O, # functions, #objects • #bugs found • the process itself • person-hours • salaries, equipment, space

14. 4. quantitative, metric-based project management PROCESS metrics (“strategic”): factors we measure to improve the process; usually indirect Examples: --"product defects“--what are they? where did they originate? how can similar defects be prevented in future? --products delivered --person-hours --calendar time used --was the schedule met?

15. 4. quantitative, metric-based project management PROJECT metrics:"tactical" manager and team may need to adapt their procedures if project metrics are not satisfactory example: number of bugs uncovered should decrease as the software is tested

16. 4. quantitative, metric-based project management PROJECT planning: the W5HH principle (Boehm 1996): Why is the system being developed? (“business purpose”) What will be done? (task set) When will it be done? (schedule) Who is responsible for a function? (team member roles) Where are they organizationally located? (e.g., customer) How will the job be done technically and managerially? How much of each resource is needed?

17. 4. quantitative, metric-based project management • SOFTWARE metrics—can quantify product and project • Parameters need to be defined by the organization, based on experience and historical data • Example: KLOC: a simple concept • size (KLOC) • “quality”--defects per KLOC • cost per KLOC • Example: function points or object points: a higher-level concept

18. 4. quantitative, metric-based project management Example of “function points” Component type # X (simple,average,complex) = External inputs 2,1,1 3 4 6 16 External outputs 3,1,1 4 5 7 22 External inquiries 1,1,1 3 4 6 13 Internal logical files 5,1,1 7 10 15 60 External interface files 0,2,0 5 7 10 14 Total: 125 Pressman: Comparison of LOC / function point for a language? Avg. Median Low High Assembler 337 315 91 694 C 162 109 33 704 C++ 66 53 29 178 Java 63 53 --- ----- Perl 60 --- --- ----- Visual Basic 47 42 16 158

19. 4. quantitative, metric-based project management Empirical estimation models: "experimental approach" uses data from a set of (completed) projects to try to predict effort required for future projects basic method: regression analysis ("curve fitting"--statistics): independent variables can be KLOC, # objects, etc. dependent variables can be person-hours, cost, etc.--”effort"

20. 4. quantitative, metric-based project management basic formula for these models: E = A + B x (ev)C E: effort (person-months) ev: estimation variable (KLOC or weighted # of objects, e.g.) A,B,C empirical examples: E = 5.5 + 0.73x(KLOC)1.16 E = 5.288 x (KLOC)1.047 E = -13.39 + 0.0545 FP E = 60.62x7.728 x 10-8FP3 E = 585.7 + 15.12FP why are these so different?

21. 4. quantitative, metric-based project management one specific example: COCOMO model (COnstructive COst MOdel) derived by Boehm (81), refined to COCOMO II (99,00) actually a hierarchy of models:  application composition stage:for early use (p. 660, Pressman) estimated effort = (new object pts)/productivity ---weights "object pts", i.e., screens, reports, components; ---factors in reuse ("new") ---productivity based on developer skills, environment  early design stage: use after requirements set and basic architecture determined  post-architecture stage:use during software construction

22. 4. quantitative, metric-based project management software quality is harder to measure for example, is software: correct? maintainable? usable? robust?

23. what can you measure in this quarter's project? process: time (each team member) resources process "defects" product: lines of code number of classes (weighted?) number of I/O options and interclass links number of errors found / corrected at a given time Challenges (for quarter project planning): --choose good “weighting” factors for classes, code (requirements, specifications, functionality, etc.) --include time to integrate modules --must also quantify work done on “design” phase 4. quantitative, metric-based project management

24. 5. risk management—identify, plan for risks Risk analysis: managing uncertainty GOAL: be prepared for whatever happens during project example: your senior project is due next week and -the system is down -your disk crashes -your car breaks down -you get the flu -your partner disappears What could you have done during the planning stage to allow for each of these “risks”? How likely (what is the probability) that each one will occur? How likely (what is the probability) that more than one will occur?

25. 5. risk management—identify, plan for risks YOU NEED THIS IN YOUR PLANNING DOCUMENT!! During planning, a Risk Table is generated: Risks Type* Probability Impact Management Plan (Pointer) System not available Hardware failure Color printer unavailable Personnel absent (one meeting) Personnel unavailable (several meetings) Personnel have left project *Type: Performance (product won’t meet requirements); Cost (budget overruns); Support (project can’t be maintained as planned); Schedule (project will fall behind) Probability: of this risk occurring Impact: e.g., catastrophic, critical, marginal, negligible

26. Then table is sorted by probability and impact and a “cutoff line” is defined. Everything above this line must be managed (with a management plan pointed to in the last column). what risks will there be in your quarter project? how will you manage risk? Useful reference: Embedded Syst. Prog. Nov. 00--examples: http://www.embedded.com/2000/0011/0011feat1.htm . 5. risk management—identify, plan for risks

27. professionalrisk analysis is proactive, not reactive 5. risk management—identify, plan for risks

28. 6. accurate cost and schedule estimation • Scheduling and Tracking • why is software late? • unrealistic deadline • changing requirements • honest underestimate of resources/time • risks not considered • unforeseen technical difficulties • unforeseen human difficulties • miscommunication • management failure to recognize/react to delay

29. 6. accurate cost and schedule estimation • scheduling guidelines: • compartmentalize: product & process • determine interdependency: • (sequential/parallel tasks) ("Gantt” or timeline chart) • allocate time: "units" + start, stop dates • do not overallocate resources • define responsibilities • define outcomes • define milestones

30. 6. accurate cost and schedule estimation • Scheduling Aids: • task network--determine interdependencies • Gantt chart or timeline chart--schedule • project table--track • initial planning + modifications documented

31. Design Module A Project defn. Project Modulari- zation Integrate Designs for A,B Project Review Design Module B 6. accurate cost and schedule estimation Task network--interdependencies: YOU NEED THIS IN YOUR IMPLEMENTATION PLAN!

32. Work Tasks Week 1 Week 2 Week 3 Week 4 Week 5 1 Define Requirements Define customer needs Define available resources Determine skill levels Create Req. Document, Use Cases Milestone: Requirements Defined 2 Create UML description Create ER diagram Create CRC cards Create object message diagrams Create state diagrams Create sequence diagrams, tests Revise UML, complete test cases Milestone: UML Description Done 3 etc…… 6. accurate cost and schedule estimation Gantt or timeline chart YOU NEED THIS IN YOUR PLANNING DOCUMENT!!

33. 6. accurate cost and schedule estimation Work Tasks Planned Actual Planned Actual Assigned Effort Notes Start Start Complete Complete Person Alloc. 1 Define Requirements Define customer needs wk1,d1 wk1,d1 wk1,d3 wk1,d5 CP,JS 1.5 p-d cust. Define available resources wk1,d2 wk1,d2 wk1,d3 wk1,d3 DK,EL 1.5 p-d req. Determine skill levels wk1,d3 wk1,d4 wk1,d4 wk1,d5 JS 1 p-d more Create Req. Doc., Use Cases wk1,d2 wk1,d3 wk1,d4 wk1,d5 all 2.5 p-d time Milestone: Requirements Definedwk1,d4 wk1,d5 wk1,d4 wk1,d5 2 Create UML description Create ER diagram wk1,d5 wk2,d4 wk2,d4 all 8 p-d Create CRC cards wk2,d1 wk2,d4 wk2,d4 CP,JS 6 p-d Create obj. mess. diagrams wk2,d2 wk2,d4 wk3,d2 DK 2 p-d Create state diagrams wk2,d5 wk3,d2 wk3,d3 EL 3 p-d Create sequence diag., tests wk2,d5 wk2,d5 wk3,d5 CP,JS 6 p-d Revise UML, compl. test cases wk2,d1 wk4,d1 all 2 p-d Milestone: UML Description Donewk4,d1 wk4,d1 3 etc…… Project table--tracking YOU NEED THIS IN YOUR PLANNING DOCUMENT!!

34. 6. accurate cost and schedule estimation Quarter project: Initial schedule: major tasks for each week This can be determined from the 495 lab page Examples? As project progresses, details will need to be added to the schedule.

35. 7. uniform standards • CONFIGURATION MANAGEMENT: • changing software is easy, managing change is therefore difficult • configuration management guidelines: • identify objects • establish baselines • implement version control • maintain coordination: software and documentation note: one system for configuration management is CVS (Concurrent Versions System), http://www.cvshome.org/ (can be used but is not required for quarter project)

36. 7. uniform standards • CODING STANDARDS: • Using standard rules for naming, documentation, etc., will help your team and future developers understand and improve your code • Example: an example set of Java coding standards can be found at • http://developer.netscape.com/docs/technote/java/codestyle.html • The coding standards given at this website cover: • general coding rules, including naming conventions and documentation rules, which everyone working on the related project MUST follow • general coding guidelines, including source code style and naming guidelines, source code layout, and documentation for methods and functions, which everyone working on the related project is STRONGLY ENCOURAGED to follow

37. 7. uniform standards • DOCUMENTATION: good documentation requires you to: • document sufficiently • use “self-documentation (e.g., identifier names) • maintain coordination: software and documentation • use consistent standards for documentation • possible tools to help with documentation: • 1. "javadoc"; (Knuth) • javadoc website: • http://java.sun.com/j2se/javadoc/writingdoccomments/#terminology • 2. “Doxygen”: • http://www.stack.nl/~dimitri/doxygen/

38. 8. tracking defects against quality definitions SOFTWARE QUALITY ASSURANCE: SQA we must define what "quality" means we must take steps to achieve this quality what do we measure? defects customer satisfaction reliability performance

39. 8. tracking defects against quality definitions • what approach do we use to determine quality? • formal methods • statistical methods-- • including user surveys • whose responsibility is "quality"? (answer: "everyone's") • are there standards? • ISO 9001 (ISO 9000-3) • ISO registration--required to develop software for • government, medical devices, telecommunications, etc.

40. 8. tracking defects against quality definitions • What is an appropriate definition of “quality” and how can this level of quality be achieved in the quarter project? • “quality” will be part of requirements • quality factors will be included in specification • this implies there must be quality “use cases” • some possible quality factors: • --bug-free • --ease of use • --user friendliness • --completeness and usability of documentation • --help provided to user • --attractiveness of display • --response time • --???? • Measuring: bug counts, user surveys