1. 6/05/2007SE 652 - TSP Strat/Launch/Plan1 Team Software Project Concept / Launch Phase topics Planning Phase

2. 6/05/2007SE 652 - TSP Strat/Launch/Plan2 Due Today Project Plan –Draft, baseline post class (COB Wednesday – June 7) Presentation –Functionality –Development approach, estimates, etc. Weekly Meeting kick-off –First weekly minutes including WEEK form

3. 6/05/2007SE 652 - TSP Strat/Launch/Plan3 Deliverables Course deliverables include everything – not just the final program (e.g. SRS, User Documentation, CM Plan) Deliverables should demonstrate team collaboration –Clarity in presentation, to the point –Review/inspect all team deliverables –Ensure quality records created & maintained

4. 6/05/2007SE 652 - TSP Strat/Launch/Plan4 Team Meeting Meeting Objective Synchronize on upcoming activities, assess status, raise issues, assign action items, discuss resolutions Gather & analyze the team’s data for prior week and to date Change Control Board, but may need additional reviews during some phases Interval Once a week (for formal meeting) Follow WEEK script (modified) Capture Discussions Decisions Action Items Issues Risks Data (ala WEEK form) Output Weekly minutes document TASK & SCHEDULE forms (when applicable) Updated Project Notebook

5. 6/05/2007SE 652 - TSP Strat/Launch/Plan5 Launching a Project – Goals Typical Project Goals Customer Needs Target Market Date Functionality Goal Setting Unrealistic Goals = demotivator Aggressive but realistic = ideal Cisco Strategy “Under-commit, exceed customer expectations” But, A reputation for “sandbagging” can be very dangerous

6. 6/05/2007SE 652 - TSP Strat/Launch/Plan6 Goal Setting Use a confidence level to set goals (e.g. 90%) SMART Goals Specific Measurable Actionable Realistic Timely

7. 6/05/2007SE 652 - TSP Strat/Launch/Plan7 Project Team Goals Produce a quality product Example metrics: Defect density Customer satisfaction Run a productive & well managed product Example metrics: Estimates vs. Actual Quality Records Morale Finish on Time: Example metrics: Schedule variation

8. 6/05/2007SE 652 - TSP Strat/Launch/Plan8 Commitment What is it? A promise! Commitment pitfalls Frequently implied (assumed commitment) Frequently given even though intent is not a commitment

9. 6/05/2007SE 652 - TSP Strat/Launch/Plan9 TSPi Tool

10. 6/05/2007SE 652 - TSP Strat/Launch/Plan10 TSP Development Phase Preliminary Plan Documentation: Conceptual Design (in Project Plan) STRAT form (in Project Plan) ITL log (Risks & Issues – extended version)

11. 6/05/2007SE 652 - TSP Strat/Launch/Plan11 Development Strategy Why Plan? Common understanding of objective & work required Basis for tracking work completion Provides assessment of effort required & if objectives are achievable

12. 6/05/2007SE 652 - TSP Strat/Launch/Plan12 Development Approach Waterfall Iterative Build one, throw it away Rapid Application Design (RAD) Extreme Programming (XP)

13. 6/05/2007SE 652 - TSP Strat/Launch/Plan13 Strategy Assessment Development Approach / Conceptual Design High Level System Architecture (components) Size estimate (LOC, FP) Effort (staff hours, days, weeks) Time (calendar time) Functionality Risks Configuration Management Process

14. Project Plan Presentations

15. 6/05/2007SE 652 - TSP Strat/Launch/Plan15 Project Plan Drafts Discussion Overall... Fluff (from a previous class) Background “The developers at XYZ Labs have been expending a large amount of resources manually counting LOC. It has come to the attention of management that it would be a cost effective solution …. There are no commercially available off the shelf solutions ….. The customer has provided a need statement, …” “This system is intended to be a deliverable for our software quality management class. Our objectives are to deliver a quality product on schedule, have fun, and learn while we’re at it.” Users “There will be a hierarchy of users of the system. The top level will be the primary customer…” “A user of this system consists of any individual who wishes to obtain LOC metrics and track various software version changes.”

16. 6/05/2007SE 652 - TSP Strat/Launch/Plan16 Other Project Plan Notes Roles – document team assignments including summary of deliverables by person Update & Maintain risk section Break out detailed schedule to MS Project

17. 6/05/2007SE 652 - TSP Strat/Launch/Plan17 Feature List Summary A-Team – used variant of STRAT form Broke out features, but would be useful to include estimates (though template didn’t help here) Trinity Provided a little more detail, but no reference to target cycle Recommendation: use STRAT form

18. 6/05/2007SE 652 - TSP Strat/Launch/Plan18 2007 SE652 High Level Development Schedule DateMilestoneEntryExit June 05C1 Launch, Strategy & Plan Project Plan June 12C1 RequirementsProject PlanBaselined C1 Requirements June 19C1 DesignBaselined RequirementsBaselined C1 High Level Design June 26C1 ImplementationBaselined High Level Design Unit & Integration Tested Code July 3*C1 System TestOther team’s integration passed application Zero Defect application July 10C1 Post Mortem C2 Launch & Plan Completed C1 developmentUpdated C2 Project Plan July 17C2 RequirementsBaselined C2 Project PlanBaselined C2 Requirements July 24C2 Design & Implementation Baselined C2 RequirementsBaselined C2 High Level Design Unit & Integration Tested Code July 31C2 System TestOther team’s integration passed application Zero Defect application August 7C2 Post MortemCompleted C2 developmentFinal, etc.

19. 6/05/2007SE 652 - TSP Strat/Launch/Plan19 Strategy Forms – Requirements & Coding Estimates Estimates: TeamSteveGregRon Metric Document (Pages) Code (LOC) Document (Pages) Code (LOC) Document (Pages) Code (LOC) Units / Hour Total Phase1 units Total Phase2 units

20. 6/05/2007SE 652 - TSP Strat/Launch/Plan20 Other Suggested Improvements

21. 6/05/2007SE 652 - TSP Strat/Launch/Plan21 What is a risk? Examples from prior Project Plans “Use of java as a programming language” “Smaller group size” “Team members drop out of class” “Requirements must be dropped in Cycle 2, due to compressed…” “Hourly slip in schedule in Cycle 2…”

22. 6/05/2007SE 652 - TSP Strat/Launch/Plan22 Risks Defined: Issues – will happen Risks – are potential problems probability of an undesirable event occurring and impact/consequences 3 Risk Components –Event –Probability of occurrence –Impact Risk Management Objectives Take proactive steps to minimize the probability & consequences of adverse events

23. 6/05/2007SE 652 - TSP Strat/Launch/Plan23 What is a risk? Examples from prior Project Plans “Use of java as a programming language” “Smaller group size” “Team members drop out of class” “Requirements must be dropped in Cycle 2, due to compressed…” “Hourly slip in schedule in Cycle 2…”

24. 6/05/2007SE 652 - TSP Strat/Launch/Plan24 Risk Management Strategy Identify e.g. brainstorming, “moose on the table” Assess risk exposure –Plan determine which risks to manage/mitigate Track – build tripwires into project plan Mitigate Communicate

25. 6/05/2007SE 652 - TSP Strat/Launch/Plan25 Risk Mitigation Avoidance – eliminate the risk Transference– shift consequence of risk to another party Mitigation – reduce the probability &/or consequence Acceptance – conscious decision to not change plan Risk reduction – e.g. avoidance/mitigation strategy shifting to a lower risk choice

26. 6/05/2007SE 652 - TSP Strat/Launch/Plan26 Risk Details from Project Plan “Team Members may drop out during the course, leaving the remaining team members with extra unscheduled & unfamiliar work. To prevent this, the importance of all present team members will be heavily stressed. However if a team member does drop the course, there is no other choice but to redistribute the responsibilities.” “Mitigated by the similarities between Java and other languages. Accepted due to the expected increase in productivity of primary developer.”

27. 6/05/2007SE 652 - TSP Strat/Launch/Plan27 Risk from Previous Offering Project Plan Description: Situation arises where the schedule documented in the project plan is unrealistic or is unachievable, resulting in the product not being able to be delivered on time with desired functionality and quality given the level of staff and project resources. Probability: 30% Impact (1 to 10 scale, 10 high impact/loss): 10 Risk Exposure: 3 First Indicator: Delivery of first draft of requirements document falls behind schedule. Mitigation Approaches –Allow certain amount of slack or buffer time in schedule for delays. –Analyze time necessary to deliver proposed functionality per iteration to determine if there is necessary time to deliver product on scheduled delivery date and use this information to generate schedule. –Agree to less functionality in first iteration in order to better estimate schedule for second iteration of development. –Allow for one member of the team at any given time to be in a Waiting state, where they do not have a specified task to complete and are available for performing delayed task. Owner: Mark Current Status: Risk Control Contingency Plan: Utilize slack time in schedule to minimize effect of delay and utilize free team member to quicken task delivery pace until project is on schedule. Trigger for Contingency Plan: Milestone in project is not met on time.

28. 6/05/2007SE 652 - TSP Strat/Launch/Plan28 Indirect Risk Mitigation Risk: All functionality may not be ready to go at the start of the new fiscal year Mitigation:Build “bridge code” between old system and new, using sub- systems 3 & 4 of old until all is ready Probability: 50% Tripwire: If all DDRs are not passed by 12/21/1997, we build bridge Cost: “Al” + 2 contractors = 6 work months = $200K

29. 6/05/2007SE 652 - TSP Strat/Launch/Plan29 Ring Software, Ltd. Risk Identification

30. 6/05/2007SE 652 - TSP Strat/Launch/Plan30 Some Risk Mitigation Strategies PersonnelTraining Team building Communication (e.g. team meetings) Reassignment Budget & ScheduleDesign to budget Reduce feature commitment Renegotiate schedule Developing wrong productPrototyping User surveys Too large or ambitious projectRequirements scrubbing Cyclic software development Too many unknownsPrototyping, Cyclic Development Excessive changesControl adders (cost/benefit) Real-time performanceSimulation, prototyping RiskMitigation Strategy

31. 6/05/2007SE 652 - TSP Strat/Launch/Plan31 Configuration Management Process Three aspects: Change Tracking Version Control Library Objectives: Product content known & available at all times Product configuration is documented & provides known basis for changes Products labeled & correlated w/ associated requirements, design & product info Product functions traceable from requirements to delivery All product contents properly controlled & protected Proposed changes identified & evaluated for impact prior to go/no go decisions

32. 6/05/2007SE 652 - TSP Strat/Launch/Plan32 Configuration Management Types of product elements Maintained (e.g. software) Baselined & Maintained (e.g. SRS) Quality Records (e.g. meeting notes, action item list) Key Functions Latest Version of each product element (software, documents, quality records) Copies of prior versions of each product element Who changed from previous version When changed What changed Why changed

33. 6/05/2007SE 652 - TSP Strat/Launch/Plan33 Configuration Management Plan Configuration identification Name Configuration items Owner Storage location Configuration control procedure Process for making changes, lock-out procedures (e.g. check-out, check-in procedures) Configuration control board (CCB) Reviews all change requests Determine if change is appropriate, well understood & resources available Approvals, commitments ? Defects: holding for CCB vs. urgency of change ? Configuration change request form (CCR, aka CR) Baseline Process (see page 326) Backup procedures & facilities Configuration status reports (CSR) Software Change Management status reports @ weekly meeting

34. 6/05/2007SE 652 - TSP Strat/Launch/Plan34 Baseline Considerations Criteria –Defined in Configuration Management Plan –Review / inspection completed & stakeholders recommend approve for baseline –All major and blocking issues should be resolved –CRs tracking any remaining (and unresolved) issues Actions –Update version # to reflect baselined document (e.g. 1.0) –Place under change control Project “Baseline” – snapshot of CIs, baselined & current versions

35. 6/05/2007SE 652 - TSP Strat/Launch/Plan35 Automated Configuration Mgmt Lucent: Sablime / SBCS & SCCS Rational: DDTS / ClearCase Perforce Software: Perforce Microsoft: Visual SourceSafe MKS

36. 6/05/2007SE 652 - TSP Strat/Launch/Plan36 Change Workflow New / Proposed Assigned Resolved Study Integrated Delivered Verified NoChange Deferred Declined

37. 6/05/2007SE 652 - TSP Strat/Launch/Plan37 Due Next Week Requirements (SRS) draft for inspection Draft to Quality Manager & instructor by COB Friday Configuration Management Plan (draft) Planning Baselines Updated & Baselined Project Plan MS Project schedule (replaces Task & Schedule forms) SUMP Heads Up: System Test Planning, Quality/Measurement Plan Standard Forms (i.e. Weekly meeting minutes, WEEK form)

38. Backup Slides

39. 6/05/2007SE 652 - TSP Strat/Launch/Plan39 Team Project Reference: Introduction to Team Software Process text Completed Launch & Strategy Phases Development teams formed & roles assigned (team web pages)team web pages Project Notebook started Product objectives defined (TSPi Appendix A – Change Counter) Cycle 1 goals, meeting logistics & weekly data agreed/started Student Information Student Information forms received– missing … Development Strategy completed (STRAT form)STRAT Initial Risks & Issues identified (ITL log)ITL Project Plan completed Initial Week form completedWeek

40. 6/05/2007SE 652 - TSP Strat/Launch/Plan40 TSP Development Plan Purpose: Basic structure of work Scheduling the tasks Balancing the workload Progress Tracking Planning & Tracking: Time Estimates => Earned Values => Progress Tracking Plan Contents Component list Task list & their allocation to team members Team schedule & team member schedules Team quality plan

41. 6/05/2007SE 652 - TSP Strat/Launch/Plan41 Planning Process System – component – module – object Higher level product assembly of lower level parts Planning starts from the bottom: –Size estimate of lower level => time estimates for higher level Component size estimates => time estimates per task

42. 6/05/2007SE 652 - TSP Strat/Launch/Plan42 TSP Development Plan Script Input: Development Strategy Conceptual Design Output: Task & Schedule Forms SUMP, SUMQ & SUMS Forms

43. 6/05/2007SE 652 - TSP Strat/Launch/Plan43 TSPi Support Tool Input: logs, forms & templates Planning output: Team & team member task plans Team & team member schedules Project Quality Plan Tracking output: Project status information Completed tasks, time & defects But, a tool is just a tool: It only accepts & calculates data, Responsibility for planning belongs to the team

44. 6/05/2007SE 652 - TSP Strat/Launch/Plan44 TSP Task & Size Summary TSPi Tool Setup: Enter Project Information (Team Leader) Enter Team Members & Roles (Team Leader) Size Estimates Populate TASK form (generate task list button) Enter product & process deliverables (TASK) into SUMS Estimate & enter size information Enter software component names & sizes Tool Notes: Highest Level “part of” = SYSTEM Valid size measures: Text pages, Req pages, HLD pages, DLD pages, LOC

45. 6/05/2007SE 652 - TSP Strat/Launch/Plan45 TSP Task List & Schedule Plan TSPi Tool: Use previously generated task list Add in additional tasks identified Enter time estimates for each role (note: if > 10 hours, consider splitting task into smaller components) If not entered from SUMS, enter: Size estimates Measurement unit Rate / hour Rollup # hours / week for all team members and add to SCHED form Verify total planned hours from SCHED form supports estimates Note: SUMP Size & Time data should be automatically populated

46. 6/05/2007SE 652 - TSP Strat/Launch/Plan46 Quality Plan TSPi Tool: Estimate defects injected in each phase note: tool uses defects injected / hour (even for LOC) Estimate defect removal yield for each defect removal phase (see table 5.8) Compare SUMQ results with table 5.8 How to interpret: Compare table 5.8 percent defect free (PDF) / phase with SUMQ Process Yields Adjustments to improve PDF: Lower defect injection rates Increase time in defect removal activities to improve yields

47. 6/05/2007SE 652 - TSP Strat/Launch/Plan47 Final Planning Steps Individual Engineer Plans Assign tasks to each engineer based on available hours / week Generate individual copies of TASK & SCHDULE forms Delete task hours assigned to other engineers Add in individual tasks Balance Team Workload (TASK form) Produce Consolidated Team Plan (SUMP, SUMQ, TASK, SCHED)

48. 6/05/2007SE 652 - TSP Strat/Launch/Plan48 Quality Plan Measures Summary Rates Productivity (LOC / hour) Reuse percentages TSP Defect Definition Requirements, Design or implementation issue which could cause improper design, implementation, test, use or maintenance of the product. Major – modifies executable Minor – does not impact executable (e.g. comments, formatting) Percent Defect Free (PDF) % of components with no defects in a phase Objective: steadily increasing PDF for each successive phase Analysis hint: look at high defect parts, likely to be the source of future problem

49. 6/05/2007SE 652 - TSP Strat/Launch/Plan49 Defect Metrics Provide targets for the following measures in your Quality Plan: Defects/Page (e.g. requirements, HLD) Defects/KLOC Graph by phase – should show decreasing #’s Graph by module – shows potential problem sources Defect Ratios Code review / compile Design review / unit test higher #’s indicate better up front defect removal Defect-Injection Rates # of defects injected per unit (e.g. hours) Defect-Removal Rates # of defects removed per unit (e.g. hours)

50. 6/05/2007SE 652 - TSP Strat/Launch/Plan50 Additional Metrics Development Ratios Design Review Time / Total Design Time Requirements Inspection Time / Total Requirements Time Appraisal / Failure Ratio Review & Inspection Rates (TSPi p103 for guidelines) e.g. # pages / hour, # LOC / hour Phase Yield % defects removed in a given phase Actual yield #’s decline as defects found in later phases (note: phase intro very important data to capture) Process Yield % defects removed prior to entering a given phase

51. 6/05/2007SE 652 - TSP Strat/Launch/Plan51 Quality Plan Summary Only requires tracking a few items: Time Unit measures (e.g. LOC) Defects Phase Introduced Phase Detected In-Process Status Look for quality trends (e.g. decreasing find rates) Investigate high defect objects Scan ratios focusing on prevention activities (e.g. reviews) But, GIGO rule applies!