The role of Planning in the Software Development Process Winter 2004 SE-280 Dr. Mark L. Hornick

Q: Why bother with Planning? Winter 2004 SE-280 Dr. Mark L. Hornick

Q: Why bother with Planning? In planning, we want to know the time and resources that will be needed for a project. Winter 2004 SE-280 Dr. Mark L. Hornick

Exercise How long would it take you to write a program that prompts a user to enter the names of students in a class in any order Sorts the students alphabetically Outputs the students in alphabetical order Winter 2004 SE-280 Dr. Mark L. Hornick

Planning is an important part of software development, especially for the team doing the work. We want to make realistic commitments to management Your reputation as an engineer will depend to large extent on your ability to fulfill your commitments In order to do this, we must Identify tasks Identify resources resources=time + people Winter 2004 SE-280 Dr. Mark L. Hornick

Exercise, part 2 How long would it take you to Understand the requirements (see previous slide) Design the program Implement the code Test the program (and fix errors) Summarize your results Compare plan vs. actual (time/resources/cost) What would have been done differently Winter 2004 SE-280 Dr. Mark L. Hornick

How do we make time and resource estimates? Do we guess? When management and a team are both only guessing about the resources and schedule for a software project, management will always win the argument. Winter 2004 SE-280 Dr. Mark L. Hornick

To do better than guessing, we need defined processes and good historical data on prior executions of those processes. To gather historical data, we need to accurately track and report progress. Actual size of the task vs. planned Actual development time vs. planned Actual schedule vs. planned Winter 2004 SE-280 Dr. Mark L. Hornick

Historical data implies measurement; in the PSP, there are four basic process measures. Size Size of what?? Time Minutes by phase Quality Defects by phase Schedule Task completion date To improve performance, we must be able to measure and make comparisons. Other measures, such as productivity and defect density, are derived from the base measures.

Why do we care about Software Size? It’s a basis for better planning: Development resources #People (effort) Cost (time*effort) Defect rates As a measurement criterion, it should be: Related to development effort Precise, easily countable Suitable for early planning Winter 2004 SE-280 Dr. Mark L. Hornick

How do we measure Software Size? SE-280 2/22/2019 How do we measure Software Size? Candidate measures “Function points”: #Input interfaces #Output (reports) #Queries #Data files #Interfaces to other apps # Pages in Requirements Document # of Prototype Screens # of Prototype Reports Lines of code (LOC) Function points – page 107 Winter 2004 SE-280 Dr. Mark L. Hornick Dr. Mark L. Hornick

Is LOC a good measure? What should we count? What are the advantages? SE-280 2/22/2019 Is LOC a good measure? What should we count? Logical lines of code? Physical lines of code? What are the advantages? What are some disadvantages? Logical lines of code Count “effective” LOC Invariant to formatting Correlate well with effort Complex to count precisely Physical lines of code Not invariant or uniquely definable Easy to count Winter 2004 SE-280 Dr. Mark L. Hornick Dr. Mark L. Hornick

Estimation Process Flow SE-280 2/22/2019 Estimation Process Flow Define requirements Conceptual design Size database Estimate size Productivity database Estimate effort Resources available Produce schedule Develop product Data analysis Winter 2004 SE-280 Dr. Mark L. Hornick Dr. Mark L. Hornick

Size and Effort have been shown to be correlated: SE-280 2/22/2019 Size and Effort have been shown to be correlated: Other examples on page 39. Winter 2004 SE-280 Dr. Mark L. Hornick Dr. Mark L. Hornick

Good Planning results in An overall Project Plan Team knows what each person is to do Composed of multiple “realistic” phase plans Team knows it’s succeeding Or where it needs to focus As “quality” of each phase increases, the overall project quality increases Winter 2004 SE-280 Dr. Mark L. Hornick

Bad planning results in Cost overruns Schedule slippage Loss of credibility Low morale Winter 2004 SE-280 Dr. Mark L. Hornick