People Product Process Project Management Project and Process

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

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

1. People-aware Program Management 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 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?

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?

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"

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)

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

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"

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

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"

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?

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

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?

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

4. quantitative, metric-based project management PROJECT planning: the W 5 HH 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?

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

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

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"

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. 73 x(KLOC)1. 16 E = 5. 288 x (KLOC)1. 047 E = -13. 39 + 0. 0545 FP E = 60. 62 x 7. 728 x 10 -8 FP 3 E = 585. 7 + 15. 12 FP why are these so different?

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

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

4. quantitative, metric-based project management 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

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?

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 Incompatible software update Team can’t learn tools/lang Personnel absent (one meeting) Personnel unavailable (several meetings) Team members in conflict 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 (use categories, e. g. , low, med, high, unless you have data) Impact: e. g. , catastrophic, critical, marginal, negligible

5. risk management—identify, plan for risks 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 feat 1. htm.

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

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

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

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

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

6. accurate cost and schedule estimation 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…… Gantt or timeline chart YOU NEED THIS IN YOUR PLANNING DOCUMENT!!

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

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.

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 Subclipse (http: //subclipse. tigris. org/) which implements subversion (http: //svnbook. red-bean. com/en/1. 4/svn. intro. whatis. html) for the Eclipse IDE (can be used but not required for quarter project)

7. uniform standards CODING STANDARDS: Using standard rules for naming, documentation, etc. , will help your team and future developers understand 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

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/j 2 se/javadoc/writingdoccomments/#terminology 2. “Doxygen”: http: //www. stack. nl/~dimitri/doxygen/

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

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.

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