1. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 1 1/11/2004 Day 4, Part 1 Software Development Plans

2. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 2 1/11/2004 Outline (slide 1 of 2) The Contents of a SW Development Plan The Role of a Software Development Plan The Role of the SW Project Manager Reviewing Assumptions, Estimates & Commitments Setting Expectations Using the SEI CMM to set the stage for a Successful Software Project

3. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 3 1/11/2004 Outline (slide 2 of 2) Planning Reviews and Audits Planning Subcontractor Management Facilities and Staffing Plans Maintaining an Effective Plan Summary

4. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 4 1/11/2004 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

5. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 5 1/11/2004 Detailed Planning - Processes Estimate Size Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost Schedule OK Complete Detailed Planning Revise & Negotiate Not OK

6. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 6 1/11/2004 The Contents of a Software Development Plan

7. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 7 1/11/2004 Warning from Dilbert “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle

8. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 8 1/11/2004 Your plan consists of virtually everything you produce as a result of planning

9. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 9 1/11/2004 “software development plan” definition “The accumulation of all plans and related artifacts generated during the planning process” Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design CodeDesignTest Build DeliveryContract Prototype Final Design Build Design Prototype Final Design Build Design technical interchanges contract issues legal issues

10. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 10 1/11/2004 Your Plan is a document containing a selected group of the principal planning artifacts

11. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 11 1/11/2004 “Software Development Plan” definition “ A document describing the principal plans for developing software ”

12. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 12 1/11/2004 The Plan within a plan Software Development Plan (formal document) software development plan Software Standards and Procedures WBS Policies Facilities Estimates Staffing plan Schedule

13. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 13 1/11/2004 Why Create a Formal Software Development Plan? To help you manage the project AND To show others that you can manage the project

14. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 14 1/11/2004 To Show that You Can Manage the Project... The Plan demonstrates that sufficient planning has been done The Plan shows that you understand the project, the problem, the risks, the criteria for completion, the methods for developing software, and the customer expectations

15. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 15 1/11/2004 To Help You Manage the Project... The Plan forces you to answer questions that might otherwise be left unanswered How will we set up our software library? How will we track progress on the data base development?

16. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 16 1/11/2004 To Help You Manage... The Plan communicates your plans to concerned parties - your staff, other organizations, subcontractors It provides a common framework from which all participants can make their individual plans

17. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 17 1/11/2004 To Help You Manage... The Plan documents assumptions, contractual understandings, mutual agreements, etc. It helps you to remember what you planned It helps you manage risks by recording your rationale, backup plans, expectations, etc.

18. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 18 1/11/2004 Don’t Overdo the Formal Plan The Formal Plan should contain … … a guide to the software development approach … a guide to your management approach... information that is not likely to change frequently during the project … information that is necessary to evaluate and understand your plan

19. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 19 1/11/2004 The exact content of the formal plan will depend on specifics of your contract, organization, project size, customer, management style, etc. The Formal Plan Should Not Contain... … detailed information about the product’s technical characteristics, architecture, or design approach … detailed schedules, cost estimates, etc. … excessive detail about the process and methods you will use, especially if it is likely to change often

20. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 20 1/11/2004 The Formal Plan is like the Textbook for your Project You learn from it You use it to teach new employees all about the project You refer to it from time to time But most people do not use it on a daily basis

21. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 21 1/11/2004 The Formal Plan Should Cover... … a little about the product –A summary that shows its characteristics, components, and performance goals … more about the project –Focusing on organization, structure, and management … a lot about the process –In detail, including all aspects of how software will be developed and managed

22. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 22 1/11/2004 A Checklist for an SDP

23. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 23 1/11/2004 Where Does This Information Come From? Job Analysis Initial Planning Estimating … In other words, all of the planning activities

24. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 24 1/11/2004 A Closer Look at the Contents of a Software Development Plan

25. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 25 1/11/2004 Product Information - The Application and the System A summary description of the application and the system, such as: –Scenarios describing system use –An overview of the architecture, including the major components –Processors and their functions –Brief discussions of the technologies involved or any unusual aspects –Summary of any key performance objectives and system constraints

26. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 26 1/11/2004 Product Information - The Software For each software product –Its type and characteristics –Its function, in relation to the other software and the rest of the system –Its architecture, including the major software components and interfaces –Processor(s) and other system elements the software will use –Programming language(s) –Rough size estimate

27. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 27 1/11/2004 Metrics and threshold values are discussed in another course. Product Information - Risk Management and Metrics Key risks or performance goals For each risk or performance goal (such as speed, memory size, etc), identify –Objectives, constraints and concerns –Metrics you will use to monitor –Threshold values requiring management action

28. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 28 1/11/2004 Anything that tells you whether the product is likely to meet its performance requirements or encounter significant risks Sample Product Metrics How fast the software is expected to run Unused processing capacity Memory size I/O channel or network utilization

29. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 29 1/11/2004 Project Information - General The nature of the project –Type of contract, if any –Source of funding –Reporting structure –Interfaces with customer Logistics –Location(s) of organizations –Facilities you will use –Security considerations, if any

30. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 30 1/11/2004 Project Information - Schedule Lifecycle model, if any Integrated master plan (at a summary level - major tasks to be performed) Integrated master schedule –Major milestones and goals –Top level schedules for major tasks –Key reviews and milestones or gate points

31. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 31 1/11/2004 Project Information - Organization Organizational Breakdown Structure –Key roles and responsibilities –Reporting structures within the project –Key relationships and communication paths –Skills required for key roles Work Breakdown Structure Subcontract and Co-Contract relationships (if applicable)

32. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 32 1/11/2004 Project Information - Risk Management and Metrics Key risks and project goals should be identified For each risk or goal, indicate: –Objectives, constraints and concerns –Metrics you will use to monitor –Threshold values requiring management action

33. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 33 1/11/2004 Anything that tells you whether the project is likely to meet its cost, schedule, or other goals Sample Project Metrics What work tasks are complete (such as requirements defined, modules designed, units coded or tested) –Compare with plans Expenditures of effort or funds –Compare with budgets Unplanned turnover rates

34. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 34 1/11/2004 Process Information This forms the bulk of the content of a formal software development plan. Typical information includes: –Methods and processes for software development, evaluation and testing –Milestones and reviews –Subcontractor management methods –Tools to be used

35. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 35 1/11/2004 Additional Process Information Reuse plans and approaches Process improvement techniques Risk analysis and management techniques Structure and procedures of software development libraries Processes for support activities such as quality assurance and configuration management

36. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 36 1/11/2004 Process Information is Identified Throughout the Project Much of it can be established during planning, at least at a high level But many of the details are typically not fully worked out until the project is underway And such details are not necessary to understand your plan

37. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 37 1/11/2004 Process Information - Risk Management and Metrics Key risks and process goals should be identified For each risk or goal, indicate: –Objectives, constraints and concerns –Metrics you will use to monitor –Threshold values requiring management action Some process metrics are used to identify the causes of project and product problems

38. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 38 1/11/2004 Typical Plan Supplements Project-specific standards, detailed procedures and methods –Often found in an SSPM (software standards and procedures manual) Detailed schedules Shoploads Specific assignments of people and resources to tasks Details of SW Engineering Environment (SEE)

39. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 39 1/11/2004 Anything that tells you whether the process is being followed correctly or is achieving its objectives Sample Process Metrics How well we are finding problems during inspections and reviews Defect levels and defect correction levels Amount of rework due to errors

40. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 40 1/11/2004 The Role of the Software Project Manager

41. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 41 1/11/2004 You Have Four Customers 1) The Project Manager –Wants you to deliver a product on budget and on schedule 2) The Company –Wants you to meet corporate goals and follow company standards 3) The End User –Wants a quality product, on time, at low cost 4) The Software Development Staff –Wants a rewarding job and career

42. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 42 1/11/2004 Do what is best for the project Do what is best for the employee Do what is best for the end user Do what is best for the company You May Have Conflicts

43. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 43 1/11/2004 To Succeed, You Must... Understand what each of them expects –What they think you should do for them Understand the perspective of each –Why they want what they want Establish communication with each of them and develop mutual understanding and respect

44. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 44 1/11/2004 The Project Manager Wants... Effective management of the software project –Accurate estimates & realistic plans –Participation in project level planning –Timely reports on project status –Early warnings of problems –Effective coordination with the rest of the project Satisfied customers –Maintaining schedule and budget

45. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 45 1/11/2004 Building a Good Relationship with the Project Manager Ask what will help them the most –Information and interaction needed from you - when and in what format Learn about priorities - ask them to define success for the sw project Document commitments & agreements Support the project manager –Don’t deceive or cover up the truth –No surprises! -- Identify risks early Admit mistakes and ask for help

46. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 46 1/11/2004 The Company Wants... Accurate estimates and plans Periodic reviews of project status Maintaining schedule and budget Following company standards, processes, and procedures Timely notice of staffing and other resource needs Prudent use of resources Happy customers I’m here to help. Corporate Mandate …..

47. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 47 1/11/2004 Building a Good Relationship with the Company Follow company standards –or tailor to your needs Understand and support company goals and values Understand how the company handles finances and measures performance Use resources wisely and prudently Cooperate with company-imposed mandates

48. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 48 1/11/2004 Remember - the customer pays the bill The End User Wants... High quality products Ease of use On-time delivery Low costs Low maintenance costs Keeping commitments

49. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 49 1/11/2004 Building a Good Relationship with the End User Don’t miss milestones –Especially the early ones Don’t give excuses or act defensively if things have gone wrong –Accept responsibility Accept their suggestions and invite their participation Meet commitments and promises Explain what you can do, not what you can’t

50. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 50 1/11/2004 Good organization, effective project structure, and good management –Guidance without micro-management Good working conditions –Minimal interruptions and disruptions –Removal of barriers –Interesting work –Good facilities Career growth –Learning & Recognition The Staff Wants...

51. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 51 1/11/2004 Building a Good Relationship with the Staff Learn and apply team building skills Use consensus techniques Let the staff define processes and measurements where possible, or tailor standards in these areas Acknowledge small successes Walk the talk - be out there with them Treat each person as an individual

52. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 52 1/11/2004 When conflicts arise, you should focus on the common goals in order to achieve effective compromises Many Goals Overlap Good organization and management Avoidance of risks Profits Effective progress reports Satisfied customers

53. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 53 1/11/2004 You will make mistakes –Learn from them –Recover from them (knowledge helps) Not everyone will like you all the time –Maintain professional behavior –Deliver! But success will be rewarding –Sense of accomplishment & personal growth –Career advancement The Job is Challenging

54. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 54 1/11/2004 Learn to Balance Performance Cost Schedule

55. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 55 1/11/2004 Learn to Prioritize Covey’s Matrix for Prioritizing Your Time

56. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 56 1/11/2004 Reviewing Assumptions, Estimates and Commitments

57. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 57 1/11/2004 Initial Planning etc. initial plan Periodic Review and Update revised plan Update your Estimates and Plans The Start of Execution is an Excellent Time to Review the plans and estimates –Especially if there was a long gap between planning and execution.

58. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 58 1/11/2004 Review Commitments & Assumptions Commitments are often changed during contract negotiations –Make sure you know what they are The start of a project is often a stressful environment –It is common to overlook changes that affect your plans –Especially changes in parts of the project that are not your responsibility

59. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 59 1/11/2004 Projects that start out in trouble tend to end up in trouble. You Have the Most Leverage at the Start of the Project The most expensive problems result from mistakes made very early Beware of inconsistent system concepts that lead to incompatible interfaces –These problems might not even surface until you are near the end of the project

60. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 60 1/11/2004 Set Expectations

61. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 61 1/11/2004 Let People Know the Plan Define what will happen Document the processes Teach people Deal with their concerns Let them know how you will evaluate them and what you expect from them –And then follow through –Say what you do and do what you say

62. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 62 1/11/2004 Buy-in and Respect are Earned Show by actions that you are serious Avoid preaching Let the people who will do the work own the processes, the metrics, and the change mechanisms

63. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 63 1/11/2004 When there is Trouble, Don’t Focus on the Practitioners David, I’ll be watching you as you debug to see how well you are doing and help you improve. David is likely to: -- be more careful than usual (and therefore NOT behave as usual) -- be nervous & error prone David is likely to: -- be more careful than usual (and therefore NOT behave as usual) -- be nervous & error prone Now I’m Really Nervous!

64. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 64 1/11/2004 Don’t Punish or Blame the Practitioners David, this disaster is all your fault! I’ll show you! David is likely to be: -- defensive -- uncooperative David is likely to be: -- defensive -- uncooperative

65. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 65 1/11/2004 Focus on the Process David, our coding conventions are flawed and we need your help to improve. I had a lot of trouble with some parts, and I think I know some better rules. David will help to improve and will become a better coder as well. David will help to improve and will become a better coder as well.

66. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 66 1/11/2004 Frailey’s Maxim for Life in the Real World You must succeed with normal, average people. Unlike the university, you cannot reward the top 50% and flunk out the rest.

67. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 67 1/11/2004 The Normal Distribution Curve Mean + 1 s - 1 s + 2 s Capability Number of People with This Capability

68. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 68 1/11/2004 Using the SEI CMM to set the stage for a Successful Software Project

69. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 69 1/11/2004 Quality Management Goal: Manage the software engineering function to achieve high quality at low cost and cycle time Quality Low Cost Short Cycle Time Customer Value

70. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 70 1/11/2004 Organizational Process Maturity This is the way to achieve quality management The concept of organizational maturity began with Philip Crosby –who introduced a five level maturity level for project management Crosby found that organizational effectiveness was directly related to process maturity

71. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 71 1/11/2004 Crosby’s Model was a Model of Management Crosby believed that this could be measured by how effectively you use processes This was based on the work of Edwards Deming How Mature and Effective is Your Organization?

72. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 72 1/11/2004 Philip Crosby’s Five Patterns of Management Attitude 1) Uncertainty –Do not understand the task 2) Awakening –Understand the problems, not the solutions 3) Enlightenment –Understand HOW to solve known problems 4) Wisdom –Understand WHY the solutions work 5) Certainty –Can solve unexpected problems

73. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 73 1/11/2004 Watts Humphrey’s Model for Software Organizational Maturity Humphrey used Crosby’s concept of a five level Model to form a model of Software Process Management Maturity This eventually became the SEI CMM model, which is widely used today Regardless of whether you use the CMM model, the ideas here are worthwhile

74. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 74 1/11/2004 Humphrey’s Five Levels 1) Initial - Ad-hoc and unmanaged –Not under control –Success depends on heroes and heroic actions –Results cannot be reliably predicted 2) Repeatable - Stable –Relies on firm management and control –Results can be predicted provided you use the same people and the have the same kind of problem

75. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 75 1/11/2004 Humphrey’s Five Levels (Continued) 3) Defined –Stable due to knowledge and definition of processes. –Predictable even if entirely new people are used –Automation begins to pay off 4) Managed –Comprehensive measurement and analysis –Management by fact

76. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 76 1/11/2004 5) Optimizing –Significant improvements on a regular basis in a controlled fashion –Adapts well to new conditions and environments Humphrey’s Five Levels (Continued)

77. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 77 1/11/2004 Humphrey’s Model FocusKey Process AreasResultLevel Productivity and Quality RISK 4 Managed 3 Defined 2 Repeatable 1 Initial 5 Optimizing Project Management Engineering Process Product and Process Quality Continuous Process Improvement Heroes Process Meas/Anal Quality Management Process Focus&Def’n; Integrated SW Mgmt; Peer Reviews; Training; Intergroup Coord; SW Product Engineering Project Mgmt; Planning; Rqmts Mgmt; SQA; SCM; Subcont. Mgmt Defect Prevention Technology Innovation Process Change Mgmt

78. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 78 1/11/2004 Each Level Contains Key Process Areas (KPA) These are the things you must master to attain a given level For example, at level 2 the KPAs are: –Project Management –Planning –Requirements Management –Software Configuration Management –Software Quality Assurance –Subcontractor management

79. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 79 1/11/2004 What You Know at Each Level

80. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 80 1/11/2004 Rationale for the Five Levels Historical experience (Crosby, et. al.) with other processes A reasonable sequence of measurable and attainable improvement goals –You know what to do first Interim improvement plateaus –You don’t take on too much at a time They assist in setting priorities Each level is the foundation for the next

81. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 81 1/11/2004 CAVEAT: Do one level at a time. Skipping levels results in ultimate failure Level 5 Maturity Level 4 Maturity Level 3 Maturity Level 2 Maturity Level 1 Maturity

82. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 82 1/11/2004 Characteristics of an Immature Software Organization In an immature organization, there is no objective basis for judging product quality or for solving product or process problems Therefore, product quality is difficult to predict

83. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 83 1/11/2004 How to Spot an Immature Organization Activities intended to enhance quality, are often curtailed or eliminated when projects fall behind schedule For more information, see Paulk (references).

84. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 84 1/11/2004 Characteristics of a Mature Software Organization Possesses an organization-wide ability for managing software development and maintenance processes The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process.

85. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 85 1/11/2004 Mature Organization (continued) The processes mandated are fit for use and consistent with the way the work actually gets done These defined processes are updated when necessary, and improvements are developed through controlled pilot- tests and/or cost benefit analyses

86. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 86 1/11/2004 For more information, see Crosby, Humphrey, and Paulk (references). Mature Organization (continued) Roles and responsibilities within the defined process are clear throughout the project and across the organization.

87. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 87 1/11/2004 Attributes that Characterize a Mature Process Area These attributes, derived from the SEI CMM, indicate whether a process area is implemented & institutionalized effectively, repeatably, and in a lasting manner. These attributes are a good checklist of things to look for when preparing your program and your organization

88. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 88 1/11/2004 Commitment to Perform Ability to Perform Activities Performed Measurement and Analysis Verifying Implementation We WILL do this! The Five Attributes

89. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 89 1/11/2004 Commitment to Perform Commitment to Perform describes the actions the organization must take to ensure that the process is established and will endure –Example: establishing a policy that mandates a particular activity Commitment to Perform typically involves establishing organizational policies and demonstrating senior management sponsorship

90. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 90 1/11/2004 Boss SEPG SW Manager Ability to Perform Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently Ability to Perform typically involves resources, organizational structures, and training

91. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 91 1/11/2004 Activities Performed Activities Performed describes the roles and procedures necessary to implement a key process area Activities Performed typically involve: –Establishing plans and procedures –Performing the work –Tracking it and –Taking corrective actions as necessary

92. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 92 1/11/2004 Measurement and Analysis Measurement and Analysis describes the need to measure the process and analyze the measurements Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the activities performed.

93. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 93 1/11/2004 Verifying Implementation Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established Verification typically encompasses reviews and audits by management and software quality assurance.

94. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 94 1/11/2004 Key Practices The SEI CMM describes several key practices that suggest what should be done to master a given process area –Example: a key practice for risk management might be periodic evaluation of risks and the status of known risk mitigation activities The CMM is a good source of ideas and recommended practices –But they are NOT mandates

95. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 95 1/11/2004 Alternative Practices Alternative practices may accomplish the goals of the key process area Key practices should be evaluated to judge whether the objectives can be achieved effectively, although perhaps differently. Key Practice per CMM Example Key Practice for Our Situation

96. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 96 1/11/2004 Using a Maturity Model Effectively Know your maturity Focus on the key process areas needed to move up to the next level Maintain the good practices of your current level Use the model to improve your effectiveness, not to “keep score” –Focusing on “levels” can lead to “cosmetic” improvements rather than real ones

97. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 97 1/11/2004 Planning Reviews and Audits

98. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 98 1/11/2004 Reviews Purpose: –To learn the status of the project Performed by: –Managers or Peers Method: –Practitioners report on the status and plans of their projects, following specified formats and reporting on specific metrics

99. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 99 1/11/2004 Reviews (continued) Typical Duration: –A few hours to several days Achieves: –Uncovers problems (or, at least, symptoms) Drawbacks: –Does not always identify solutions –May motivate hiding of problems Avoid punishing the messenger if you want to get an accurate message

100. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 100 1/11/2004 Advantages of Reviews Reviews are relatively inexpensive –Standardize how they are done so people know exactly what to prepare –Make it easy to prepare for a review by making normal work products a natural part of the review Reviews tend to get everyone back on the same track

101. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 101 1/11/2004 Three Categories of Reviews 1) Phase or Milestone Reviews (Gates) –Held at major milestones –Ensures that the project is ready to move to the next phase 2) Status Reviews –Held periodically, frequency driven by risk Typically 1-week to 4-month intervals –Ensures that everyone knows current status 3) Peer Reviews and Inspections –Designed to evaluate a specific development artifact

102. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 102 1/11/2004 Phase or Milestone Reviews (Gates) Provide a forum to understand –the state of the project and product –at a point where the direction can be altered or refined A quality control checkpoint for the project team and organization Typically attended by senior management and external organizations and maybe the customer

103. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 103 1/11/2004 Topics Covered in a Phase Review Major accomplishments and plans Actions needed for phase completion Variances from estimates and plans Problems that are impacting quality, cost and the schedule High-risk areas that need attention Problems or lessons learned that could impact later phases

104. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 104 1/11/2004 Status Reviews A team progress review Provide a forum to identify and raise issues and problems (technical and schedule) as early as possible Focused on near-term issues and actions (often sensitive ones) Typically attended mostly by the people working directly on the software project

105. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 105 1/11/2004 Topics Covered in a Status Review Accomplishments since previous review The original plan vs actual performance The critical path of the project High-risk areas that need attention Problems that are impacting quality, cost and the schedule Status of action items (open & closed)

106. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 106 1/11/2004 Topics Covered in a Status Review - For the Next Period The plan –Possibly revised during the review New action items –Assignments –Dates Due –Who will track to closure

107. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 107 1/11/2004 Peer Reviews and Inspections Provide a way to evaluate specific artifacts –designs, code, test code, etc. Typically attended only by peers of the person whose work is being evaluated

108. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 108 1/11/2004 Why Only Peers? This approach is designed to foster free and open discussion –The supervisor’s presence tends to inhibit open discussion, often in ways that are not evident to participants Often a facilitator or quality assurance representative will participate –To keep everyone focused and to record findings and action items

109. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 109 1/11/2004 Issues Regarding Peer Reviews & Inspections You must foster a culture where people actively participate in the reviews and inspections of others –Include this in how you evaluate them –Include time in the schedule –Don’t count their work done until they have participated in others’ peer reviews There are many methods available –Select methods that fit your team

110. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 110 1/11/2004 Audits

111. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 111 1/11/2004 Audits Purpose: –To study a project in detail and find problems that may not be evident Performed by: –Independent technical experts, often outsiders Method: –Experts question practitioners and examine artifacts of their process to determine what is happening

112. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 112 1/11/2004 Audits (continued) Typical Duration: –Several days to several weeks Achieves: –Uncovers problems not seen by insiders –Informs staff that management cares about the results Advantages: –Tends to uncover real problems –Tends to confirm or disprove suspected problems

113. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 113 1/11/2004 You don’t trust us! Drawbacks of Audits More expensive than reviews Do not usually identify solutions May motivate hiding of problems Can generate hostility and lack of cooperation or demotivation Outsiders often do not understand –even if they do, they are not always believed

114. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 114 1/11/2004 When and How to Plan for Audits Use audits at points when verification and validation are important –Such as before shipping a product or after making substantial progress Use audits sparingly, but regularly –An audit should not be viewed as a sign that you suspect trouble –It should be treated as a normal part of doing a high quality job Like a regular medical checkup

115. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 115 1/11/2004 Get the Practitioners Involved Have the practitioners identify the right times for audits –Use them as a way to validate their work –Remind them that athletes and artists rely on coaches and critics Have practitioners participate in audits of other projects –Let periodic audits become part of the culture

116. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 116 1/11/2004 Planning Subcontractor/Supplier Management

117. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 117 1/11/2004 Typical Symptoms of Weak Software Subcontract Management They were supposed to deliver it today. They just called and told us they have a three month delay! They always delivered on time in the past!

118. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 118 1/11/2004 More Typical Symptoms We’ve been hit by a $25,000 fine because our user interface does not meet EPA standards. The subcontractor did not know about the regulations. The big cost will be the recall - about $200,000

119. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 119 1/11/2004 Further Typical Symptoms They delivered the software module, but no test cases or documentation The contract was vague on this point. They thought that was our responsibility.

120. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 120 1/11/2004 Software Subcontract Management Purpose: –To select qualified subcontractors –To manage subcontractors effectively

121. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 121 1/11/2004 How to Do Software Subcontract Management Select subcontractors based on ability to do the job Communicate effectively with subcontractors Document commitments Flow down standards, processes, etc. Track and review subcontractor performance and results

122. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 122 1/11/2004 Subcontractors May Not Like to be Reviewed and Audited Diplomacy, tact, and firm management skills are needed A cooperative approach based on mutual goals can lead to more openness and more accurate information Standards and regulations can provide leverage in negotiations –“We trust you, but ISO 9000 requires that we do an audit”

123. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 123 1/11/2004 Other Parts of Your Company are Subcontractors to You They may not require all the formality, but the principles are still the same: –Statement of work, commitment, tracking, etc. Their goals may not align with yours –Unless you make sure that they do

124. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 124 1/11/2004 Facilities and Staffing Plans

125. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 125 1/11/2004 You Must Plan Reasonable Staff Acquisition and Use Patterns

126. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 126 1/11/2004 Your job is to remove obstacles to their effectiveness... … not to have them take burdens off of you! Your job is to remove obstacles to their effectiveness... … not to have them take burdens off of you! People Cost Money -- Make Them Productive! Adequate training Adequate facilities Avoid excessive interruptions

127. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 127 1/11/2004 Make Sure the Facilities Fit the Job to be Done Enough computers, copiers, etc. Enough work space Reliable networks and utilities People who work closely together should be located closely together

128. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 128 1/11/2004 The Software Development Plan... … should describe the facilities needed and planned (at a high level) … and the overall staffing plans –Numbers –Skills required … and the plans for managing any risks related to these –Backup staffing plans –Alternate facilities options

129. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 129 1/11/2004 Maintaining an Effective Plan

130. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 130 1/11/2004 Warning from Dilbert “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle

131. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 131 1/11/2004 The Plan is Static -- Planning is Dynamic You rarely follow the plan exactly as written As you progress, you learn more Keeping the plan up to date keeps everyone synchronized and reduces the chances of miscommunication, etc. Initial Planning etc. initial plan Periodic Review and Update revised plan

132. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 132 1/11/2004 You Learn More Every Day Plans need to reflect what you know today... … not what you didn’t know when you wrote the plan. Plans need to reflect what you know today... … not what you didn’t know when you wrote the plan.

133. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 133 1/11/2004 Be Sure to Coordinate and Communicate Plan Changes Some software managers change their plans without notifying affected parties This can lead to chaos So it is worth the trouble to coordinate changes and communicate them effectively Don’t change too frequently or people will not take the time to pay attention to changes

134. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 134 1/11/2004 Beware of Bureaucrats It is a good idea to have an approval process for plan changes But some customers or managers have instituted a slow, burdensome bureaucracy for approval of plan changes that impedes effective plan updates People who must approve changes to the plan

135. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 135 1/11/2004 Dealing with the Realities of Bureaucratic Change Approvals Avoid excessive detail in the Plan –put it in a supplement Incorporate plans for changing the Plan Maintain “Duplicate” plans –Formal, approved plan (high level) –Working, dynamic plan (more specific) Establish trust with customers by keeping commitments

136. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 136 1/11/2004 Summary Software Development Plans The Software Development Plan serves many roles –Communicates your plans –Helps you plan –Shows you know how to manage the project The formal Plan is supplemented by many other plan elements

137. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 137 1/11/2004 Planning forces you to think Documenting your plan helps you avoid glossing over issues that need to be pinned down Plans must be maintained and used Plans changes must be communicated A standard plan is like a checklist to make sure you have included everything in your plan Summary Software Development Plans

138. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 138 1/11/2004 Summary Understand your role Establish good relationships with all of your “customers” Review and update assumptions, estimates and plans Set the right expectations Establish an environment for success Plan reviews, audits Plan subcontractor management

139. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 139 1/11/2004 References Covey, Stephen R. The Seven Habits of Highly Effective People. New York: Simon & Schuster, 1986. Copyright © 1989 by Stephen R. Covey. Crosby, Philip B. Quality is Free, New York, McGraw-Hill, 1979. Deming, W. Edwards, Out of the Crisis, MIT Press, 1986, ISBN: 0911379010 Deming, W. Edwards, Quality, Productivity, and Competitive Position, MIT Press, Cambridge, 1982. (out of print) Humphrey, Watts S. Managing the Software Process, Reading, Mass., Addison-Wesley, 1989. Paulk, M. C., Curtis B., Chrissis, M. B. and Weber C. V. 1993. “Capability maturity model version 1.1”, IEEE Software 10(July): 18-27.

140. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 4, Part 1, Page 140 1/11/2004 Donaldson, Scott E. and Stanley G. Siegel, Cultivating Successful Software Development, Prentice-Hall, 1997, Chapter 2. Department of Defense, Defense System Software Development, Dod-STD 2167A, 29 Feb. 1988, Department of Defense, Washington D.C., 20201. Reifer, Donald, Tutorial: Software Management, IEEE Computer Society References Software Development Plans