1. 2 PROJECT MANAGEMENT

2. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 2 Focus Corporate practices Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Development process - when to do what phase - document: SPMP Management structure - hierarchical, peer,... Risk identification & retirement Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 2 Focus Corporate practices Development phases Schedule Cost estimate SPMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Learning Goals of This Chapter Understand the term “project management” Organize teams Specify project management plans Define and retire risks Estimate costs very early in the life cycle Create high level projects schedules Write a Software Project Management Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

5. 1. Introduction to project management

6. The Variables of Project Management Can somewhat vary the following factors. 1. The total cost of the project,  e.g., increase expenditures 2. The capabilities of the product,  e.g., subtract from a list of features..... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. The Variables of Project Management Can somewhat vary the following factors. 1. The total cost of the project,  e.g., increase expenditures 2. The capabilities of the product,  e.g., subtract from a list of features 3. The quality of the product,  e.g., increase the mean time between failure 4. The date on which the job is completed.  e.g., reduce the schedule by 20%  e.g., postpone project's completion date one month Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. Bullseye Figure for Project Variables cost capabilityduration defect density Target : $70K Target : 30 wks Target : 4 defects/Kloc Target: 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

9. Bullseye Figure for Project Variables cost capabilityduration defect density Target : $70K Actual: 100% Target : 30 wks Target : 4 defects/Kloc this project Actual: 1 defect/Kloc Actual: 20 wks Actual: $90K Target: 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

10. RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved) -- see section 3 4. Identify managerial process (responsibilities of the participants) -- see section 3 of case study 1 at end of chapter..... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved) -- see section 3 4. Identify managerial process (responsibilities of the participants) -- see section 3 of case study 1 at end of chapter 6. Develop staffing plan -- see section 3.5 of case study 1 5. Develop schedule (times at which the work portions are to be performed) -- see section 6 7. Begin risk management -- see section 4 8. Identify documents to be produced -- see SQAP 4.2 9. Begin process itself -- described in chapters 3-10 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. 2. Managing people

13. 1.* Distribute start time, end time, and agenda with approximate times (see figure tbd) –list important items first 2.* Ensure “strawman” items prepared 3. Start on time 4. Have someone record action items ‡ 5. Have someone track time & prompt members 6. Get agreement on the agenda and timing 7. Watch timing throughout, and end on time –allow exceptions for important discussion –stop excessive discussion; take off line 8. Keep discussion on the subject 9.** E-mail action items & decision summary. Plan and Execute Meetings * in advance of meeting ‡ actions members must perform ** after meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

14. Specify Agendas 1. Get agreement on agenda & time allocation 2. Get volunteers to … : … record decisions taken and action items … watch time and prompt members (see figure tbd) 3. Report progress on project schedule -- 10 mins 4. Discuss strawman artifact(s) -- x mins 5. Discuss risk retirement -- 10 mins metrics and process improvement? n. Review action items -- 5 mins Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. 3. Options for organizing personnel

16. Optimal Size for Interaction (Approximate) Number of people with whom developer must frequently interact Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. Key:= engineer 3 Effectiveness per developer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. Optimal Size for Interaction (Approximate) Number of people with whom developer must frequently interact Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. Key:= engineer Approximate optimal range 37 Effectiveness per developer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. Hierarchical Project Management Organizations Larger Projects:Smaller Projects: No separate Marketing? No separate QA organization? Subdivide QA into testing, …? Subdivide Engineering into system engineering, …? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. Horizontal Project Management Organizations Gil Warner Team leader Ian Corliss Team member Nel Tremont Team member Fran Smith Team member Team facilitator? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20. Organize a Team 1. Select team leader: responsibilities: –ensure all project aspects active –fill all gaps 3. Designate leader roles & document responsibilities team leader: proposes and maintains… SPMP configuration management leader:... SCMP quality assurance leader:... SQAP, STP requirements management leader:... SRS design leader:... SDD implementation leader:... code base 2. Leaders’ responsibilities: –propose a strawman artifact (e.g. SRS, design) –seek team enhancement & acceptance –ensure designated artifact maintained & observed –maintain corresponding metrics if applicable 4. Designate a backup for each leader as per Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

21. Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Table 2.1 Matrixed organization Project Airline reserv. project Bank accountg. project Molecular analysis project Fluid mechanics project Func- tional Unit Project manage- ment dpt Al Pruitt Full time Quinn Parker Half time Ruth Pella Full time Fred Parsons Full time Marketing dpt Oscar Mart Full time Pete Merrill Full time Sue More Half time Elton Marston Full time Engineer- ing dpt Hal Egberts...... Ben Ehrlich...... Mary Ericson..... Len Engels..... Table 2.1 Matrixed organization

23. 4. Identifying and retiring risks

24. The Four Risk Activities (1) Identification Mindset: try to continually identify risks (2) Retirement planning (3) Prioritization (4) Retirement or mitigation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

25. Risk Sources Ordered by Importance (Keil, Cule, Lyytinen, Schmidt) 1. Lack of top management commitment 2. Failure to gain user commitment 3. Misunderstanding of requirements 4. Inadequate user involvement 5. Failure to manage end-user expectations 6. Changing scope and/or objectives 7. ….

26. Project finish The Risk Management Mindset Project start IdentificationRetirement 2. “Java skills not high enough.” 1. “May not be possible to superimpose images adequately.” 1. Retirement by conquest: Demonstrate image super- imposition Risk 1 Risk 2 Risk 1 Project finish Risk 2 2. Retirement by avoidance: Use C++ Project start Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. Likelihood 1-10 1 = least likely Impact 1-10 1 = least impact Retire- ment cost 1-10 1 = lowest retirement cost Priority computation Resulting priority Lowest number handled first The highest priority risk 10 (most likely) 10 (most impact) 1 (lowest retiremen t cost) (11-10) *(11-10) *1 1 The lowest priority risk 1 (least likely) 1 (least impact) 10 (highest retiremen t cost) (11-1) *(11-1) *10 1000 Table 2.2 A way to compute risk priorities Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. # Risk title (details given above) Like- lihood 1-10 1=least likely Im- pact 1-10 1=least impact Retire- ment cost 1-10 1=lowest retirement cost Pri- ority lowest number handled first Retirement / mitigation plan Respon- sible engineer Target com- pletion date 1 Super- imposing images 31018 Experiment with Java images. P. R.2/1/99 2 Deficient Java skills 96880 H.T., K.M., V.I. and L.D. to attend training course beginning 1/5/99 at Ultra Training Corp, obtain Java level 2 certification by 3/1/99 and level 3 certification by 4/15/99 H. L.4/15/99 3 Alan Gray may be pulled off this project 379288 Susan Ferris to inspect all of Alan's work S.F. Contin- ual.... Table 2.3 Sample Risk Analysis for Encounter Case Study Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. *:in advance of first meeting M : at meeting **: between meetings Identify and Retire Risks 1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader 3.* Team leader integrates and prioritizes results 4. M Group spends 10 mins. seeking additional risks 5. M Team spends 10 mins. finalizing the risk table –Designates responsible risk retirement engineers 6.** Responsible engineers do risk retirement work 7. M Team reviews risks for 10 mins. at weekly meetings –responsible engineers report progress –team discusses newly perceived risks and adds them

30. 5. Choosing development tools and support

31. Potential CASE Tool Components To support project management –schedule –work breakdown To support configuration management For managing requirements For drawing designs –functional –object-oriented –use-case-based Tracing tools –requirements to designs –designs to code To support testing To support maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

32. Example of Build vs. Buy Decision-making: Game Graphics engine Build costBuy cost Comments (in thousands) multi-year costs not accounted for Supplies $ 0$40 Purchase Ajax engine First-person perspective $ 5$ 0 Ajax has this feature 3-D $10$ 1 Customize Ajax application Light reflection $15$10 Customize Ajax application ______ _________________ TOTALS$30$51 Build, do not buy Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

33. Factor Weight (1-10) Benefit of Language 1 1 to 10=best Benefit of Language 2 1 to 10=best Internet-friendly 382 Familiarity to development team 839 Compilation speed 528 Runtime speed on processor p 173 Score 3*8 + 8*3 + 5*2 + 1*7 = 65 3*2 + 8*9 + 5*8 + 1*3 = 121 Table 2.4 Example of method for deciding language choice Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

34. 6. Creating schedules: high level planning

35. High Level Task Chart with Fixed Delivery Date: Order of Completion Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones(1 * ) Delivery Begin system testing Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk identification & retirement (5) * Indicated the order in which the parts of this table were built SCMP complete SQAP complete SPMP rel. 1 complete (2) Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. Create an Initial Schedule 1. Indicate the milestones your must observe –usually includes delivery date 2. Back these up to introduce the milestones you need –e.g., begin system testing well before delivery 3. Designate a time at which all requirements frozen The remaining steps depend on the process used. We will assume an iterative process. 4. Show first iteration: establishes minimal capability –usually: keep it very modest, even trivial, in capability –benefit: exercises the development process itself 5. Show task of identifying & retiring risks –starting from project inception 6. Show unassigned time (e.g., week) near middle? 7. Complete the schedule Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

37. Level Labor Allocation for Fixed Labor Total Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones Release to production Complete testing Iteration 1 Iteration 2 Freeze requirements Risk ID & retire 2223223 222111 444334 444443344443344444 44444 44 4 Given team size: To be assigned 4 Hal vacation Karen vacation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

38. 7. Integrating legacy applications

39. Resulting system Legacy System Integration Legacy system New features New application Add new features (typically using same language) or Change features (e.g., port to new environment) Build new application that uses legacy system (possibly using different language) Legacy system Repairs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

40. 8. Estimating costs: early calculations

41. Range of cost estimates after conceptualization phase, based on actual cost of $1 Integration/Test Design Implementation Requirements analysis $1 25c $4 $1 Conceptual- ization phase Range of cost estimates after requirements analysis phase Range of Errors in Estimating Eventual Cost Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

42. Typical Cost Estimation Roadmap 1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code. and / or 1B. Use function point method to estimate lines of code 1B.1 Compute un-adjusted function points. 1B.2 Apply adjustment process. 2. Use lines of code estimates to compute labor and duration using COCOMO formulas. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

43. Function Point Computation for a Single Function (IFPUG) Function External Inputs (EI) External Inquiries (EIN) External Outputs (EO) file External Logical Files (ELF) file Internal Logical Files (ILF)* * Internal logical grouping of user data into files Logical group of user data Logical group of user data Logical group of user data

44. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) Ext. inputs EI  … 3 or… 4 or... 6 = ___ Ext. outputs EO  … 4 or … 5 or... 7 = ___ PARAMETER simple complex countTotal

45. Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) Ext. inputs EI  … 3 or… 4 or... 6 = ___ Ext. outputs EO  … 4 or … 5 or... 7 = ___ Ext. inquiries EIN  … 3 or … 4 or... 6 = ___ Ext. logical files ELF ... 5 or …7 or... 10 = ___ Int. logical files ILF ... 7 or …10 or... 15 = ___ PARAMETER simple complex countTotal

46. Unadjusted Function Point Computation for First Encounter Functions:“Set up Player Character” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

47. Unadjusted Function Point Computation for Second Encounter Functions: “Encounter Foreign Character” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

48. General Characteristics for FP Adjustment 1-7 1. Requires backup/recovery?0-2 2. Data communications required?0-1 3. Distributed processing functions? 0..... 0 incidental average essential 12345 Case study none moderate significant

49. General Characteristics for FP Adjustment 1-7 1. Requires backup/recovery?0-2 2. Data communications required?0-1 3. Distributed processing functions? 0 4. Performance critical?3-4 5. Run on existing heavily utilized environmt.?0-1 6. Requires on-line data entry? 5 7. Multiple screens for input?.... continued4-5 0 incidental average essential 12345 Case study none moderate significant

50. 8. Master fields updated on-line?3-4 9. Inputs, outputs, inquiries of files complex? 1-2 10. Internal processing complex?1-4.. 012345 General Characteristics for FP Adjustment 8-14 incidental average essential Case study none moderate significant

51. 8. Master fields updated on-line?3-4 9. Inputs, outputs, inquiries of files complex? 1-2 10. Internal processing complex?1-3 11. Code designed for re-use?2-4 12. Conversion and installation included?0-2 13. Multiple installation in different orgs.?1-3 14. Must facilitate change & ease-of-use by user?4-5 012345 General Characteristics for FP Adjustment 8-14 incidental average essential Case study none moderate significant

52. Computation of Adjusted Function Points (IFPUG) (Adjusted) Function points = [ Unadjusted function points ]  [ 0.65 + 0.01  ( total general characteristics ) ]

53. Unadjusted Function Point Scores for Video Store Example Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

54. 012345 FP Adjustment Factors for Video Example 1. Requires backup/recovery?………………………….4 2. Data communications required ?………...………….0 3. Distributed processing functions ?………………….0 4. Performance critical ?………………….…………….3 5. Run on existing heavily utilized environment ?…….1 6. Requires on-line data entry ?………………………..5.... none incidental moderate average significant essential

55. 012345 FP Adjustment Factors for Video Example 1. Requires backup/recovery?………………………….4 2. Data communications required ?………...………….0 3. Distributed processing functions ?………………….0 4. Performance critical ?………………….…………….3 5. Run on existing heavily utilized environment ?…….1 6. Requires on-line data entry ?………………………..5 7. Multiple screens for input ?………………………….3 8. Master fields updated on-line ?……………………..5 9. Inputs, outputs, inquiries of files complex ?………..2 10. Internal processing complex ?……………………….1 11. Code designed for re-use ?…………………………...3 12. Conversion and installation included ?……………..3 13. Multiple installation in different orgs. ?…………….3 14. Must facilitate change & ease-of-use by user ?……..2 none incidental moderate average significant essential Total 35

56. 9. Estimating effort and duration from lines of code

57. Meaning of the COCOMO Formulas (Boehm) Applies to design through integration & test. *“Effort” = total person-months required. (2) Duration for increasing Effort* ( y b 2.5x 0.35 ) (1) Effort* for increasing LOC ( y b 3x 1.12 ) exponent: < 1 > 1

58. Basic COCOMO Formulae (Boehm) Effort in Person-months = a  KLOC b Duration = c  Effort d Software Project a b c d Organic2.41.05 2.5 0.38 Semidetached3.01.12 2.5 0.35 Embedded3.61.20 2.5 0.32 Due to Boehm [Bo]

59. Computing COCOMO Case Study Models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

60. Computing COCOMO Case Study Models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

61. Estimate Cost and Duration Very Early in Project 1. Use the function point method to estimate lines of code 2. Use Boehm’s formulas to estimate labor required 3. Use the labor estimate and Boehm’s formula to estimate duration Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

62. 10. The Team Software Process

63. TSP Launch Issues to Settle (Humphrey) Graphics reproduced with permission from Corel. Process to be used Quality goals Manner of tracking quality goals How team will make decisions What to do if quality goals not attained –fallback positions What to do if plan not approved –fallback positions Define team roles Assign team roles

64. To Be Produced at Launches (Humphrey) 1. Written team goals 2. Defined team roles 3. Process development plan 4. Quality plan 5. Project’s support plan computers, software, personnel etc. 6. Overall development plan and schedule 7. Detailed plans for each engineer 8. Project risk assessment 9. Project status report

65. TSPi Cycle Structure (Humphrey) 123456789012345 1. strategy 2. plan 3. requirements 4. design 5. implementation 6. test 7. postmortem Milestones Delivery 1. strat. Iteration 1 Iteration 2 1. strategy…. Cycle 1 launch Week 1 Cycle 2 launch Cycle 3 launch 11111 Iteration 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

66. 11. The Software Project Management Plan

67. IEEE 1058.1-1987 SPMP Table of Contents 1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities..

68. IEEE 1058.1-1987 SPMP Table of Contents 1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities 3.2 Assumptions, dependencies & constraints 3.3 Risk management 3.4 Monitoring & controlling mechanisms 3.5 Staffing plan 4. Technical process 4.1 Methods, tools & techniques 4.2 Software documentation 4.3 Project support functions 5. Work packages, schedule & budget 5.1 Work packages 5.2 Dependencies 5.3 Resource requirements 5.4 Budget & resource allocation 5.5 Schedule

69. 12. Quality in project management

70. Defects detected per...... 100 requirements, or... design diagram, or... KLOC This project / norm Phase in which defects detected Detailed require- ments DesignImplemen- tation Phase containing defects Detailed requirements 2 / 50.5 / 1.50.1 / 0.3 Design 3 / 11 / 3 Implementa- tion 2 / 2 Table 2.5 Defects by Phase Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

71. Five Process Metric Examples 1.Number of defects per KLOC detected within x weeks of delivery 2.Variance in schedule on each phase actual duration - projected duration projected duration 3.Variance in cost actual cost - projected cost projected cost 4.Total design time / total programming time should be at least 50% (Humphry) 5.Defect injection and detection rates per phase e.g. “1 defect per class in detailed design phase” Compare each of the following with company norms averaged over similar processes. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

72. IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2 7. Test -- can reference Software Test Documentation 8. Problem reporting & corrective action 9. Tools, techniques and methodologies -- can reference SPMP 10. Code control -- reference SCMP 11. Media control 12. Supplier control 13. Records collection, maintenance & retention 14. Training 15. Risk Management -- can reference SPMP

73. Gather Process Metrics 1. Identify & define metrics team will use by phase; include... time spent on 1. research, 2. execution, 3. review … size (e.g. lines of code) … # defects detected per unit (e.g., lines of code) include source … quality self-assessment of each on scale of 1-10 maintain bell-shaped distribution 2. Document these in the SQAP 3. Accumulate historical data by phase 4. Decide where the metric data will be placed –as the project progresses SQAP? SPMP? Appendix? 5. Designate engineers to manage collection by phase –QA leader or phase leaders (e.g., design leader) 6. Schedule reviews of data for lessons learned –Specify when and how to feed back improvement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

74. Requirements Document: 200 detailed requirements MeetingResearchExecution Personal Review Inspection Hours spent0.5 x 44536 % of total time10%20%25%15%30% % of total time: norm for the organization 15% 30%15%25% Self-assessed quality 1-1028546 Defects per 100N/A 56 Defects per 100: organization norm N/A 34 Hours spent per detailed requirement 0.010.020.0250.0150.03 Hours spent per detailed requirement: organization norm 0.02 0.040.010.03 Process improvement Improve strawman brought to meeting Spend 10% more time executing Summary Productivity: 200/22 = 9.9 detailed requirements per hour Probable remaining defect rate: 6/4  [ organizational norm of 0.8 per hundred] = 1.2 per 100 Table 2.6 Project Metric Collection for phases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

75. 13. Process improvement and the Capability Maturity Model

76. Motor control applications Process WaterfallSpiral, 2-4 iterations Spiral, 5-10 iterations Company average -- Defects per thousand source lines of code at delivery time injected at...... requirements time4.23.22.4... architecture time3.12.53.7... detailed design time1.1 2.2... implementation time1.02.13.5 TOTAL9.48.911.8 Table 2.7 Example of Process Comparison Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

77. Feed Back Process/Project Improvement 1. Decompose the process or sub-process being measured into Preparation, Execution and Review –include Research if learning about the procedure 2. Note time taken, assess degree of quality for each part on a 1-10 scale, count defects –try to enforce a curve 3. Compute quality / (percent time taken) 4. Compare team’s performance against existing data, if available 5. Use data to improve next sub-process –note poorest values first e.g., low quality/(percent time) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

78. For each part... PreparationExecutionReview % time 453025 Quality (0 to 10)* If low, investigate 6 2 investigate 6 Quality/(% time) If low, investigate 0.13 investigate 0.07 investigate 0.24 Typical? No Joe lost specs Yes Action Schedule 20% more time for execution, taken equally from other phases Table 2.8 Measuring Team Phase Performance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

79. 14. Miscellaneous tools and techniques for project management Model

80. Remote Team Options Same office area + ideal for group communication - labor rates sub-optimal Same city, different offices communication fair Same country, different cities - communication difficult + common culture Multi-country - communication most difficult - culture issues problematical + labor rates optimal Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

81. Non-Extreme vs Extreme Programming Limited customer contact Central up-front design Build for the future too Complex implementation Tasks assigned Developers in isolation Infrequent integration Limited communication Customer on team Open evolving design Evolve; just in time Radical simplicity Tasks self-chosen Pair programming Continuous integration Continual communication Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998

82. Triage in Project Management Among top items in importance? –if so, place it in do at once category otherwise Could we ignore without substantially affecting project? –if so, place it in last to do category otherwise …… Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

83. Triage in Project Management Among top items in importance? –if so, place it in do at once category otherwise Could we ignore without substantially affecting project? –if so, place it in last to do category otherwise (do not spend decision time on this) –place in middle category Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

84. 16. Summary of the project management process

85. Summary Project management: “silver bullet”? “People” aspects co-equal technical Specify SPMP Define and retire risks Estimate costs with several methods –expect to revisit and refine –use ranges at this stage Schedule project with appropriate detail Maintain a balance among cost, schedule, quality and functionality Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.Graphics reproduced with permission from Corel.

86. SPMP for the Encounter video game

87. Gaming Industries Consolidated President VP EngineeringVP Marketing... IV&V EncounterGame 123... SQA Game Lab... Software Engineering Labs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

88. Member Team leader CM Leader QA leader Require- ments manageme nt leader Design leader Implementati on Leader Liaison Respon- sibility VP Engineer ing Marketing Software engineeri ng lab Docume nt Responsi -bility SPMPSCMP SQAP STP SRSSDDCode base Table 2.9 Encounter Project Responsibilties Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

89. Program Monitoring & Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

90. Name Team Leader CM Leader. QA Leader Requ. Mngmnt Leader Design Leader Implemen- tation Leader Ed BraunX X Al Pruitt X Fern Tryfill X Hal Furnass X Karen Peters X Liaison withVP Eng. Marketing Soft. Eng. Lab Table 2.11 Encounter Staffing Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

91. Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones Delivery Complete testing Iteration 1 Iteration 2 Freeze requirements Risk I&R SCMP SQAP SPMP rel. 1 E. Braude 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J. Pruitt 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Tryfill 1 1 1 1 1 1 1 1 1 1 1 1 1 H. Furnass 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 K. Peters 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Tasks Work Breakdown Structure Excluding Secretarial TOTAL 5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5 F. Smith (tech support).5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5.5 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

92. Method* Mini- mum Maxi- mum Comment (1)7.5**170 (2)4.2300 (3)11.446 1.9-2.3 for two identified functions  6-20 times as many in complete application Most conservative 11.4300 Maximum of minimums and maximum of maximums. Least conservative 4.246 Minimum of minimums and minimum of maximums. Widest range 4.2300 Minimum of minimums and maximum of maximums. Narrowest range 11.446 Maximum of minimums and minimum of maximums. Table 2.12 Very Rough Estimate of Application Size Prior to Requirements Analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

93. High Level Task Chart with Fixed Delivery Date: Order of Completion Month 1 1234 Month 2 1234 Month 3 1234 Month 4 1234 Month 5 1234 Milestones(1 * ) Delivery Begin system testing Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk identification & retirement (5) * Indicated the order in which the parts of this table were built SCMP complete SQAP complete SPMP rel. 1 complete (2) Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

94. Software quality assurance plan Part 2 of 2

95. 1. Defect Number: 2. Proposer: 3. Documents / sections affected:__________ Source code affected*: 4. package(s)_______ 5. class(es) ____6. method(s) ______ 7.Severity: ____8. Type: _____ 9. Phase injected**: Req Arch Dtld.Dsg Code Int 10. Detailed description: ___________________ 11. Resolution: ____ 12. Status closed / open:__ Sign-off: 13. Description and plan inspected: __ 14. Resolution code and test plan inspected: ___ 15. Change approved for incorporation: ______ Problem Reporting Form * for source code defects **earliest phase with the defect Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.