Presentation is loading. Please wait.

Presentation is loading. Please wait.

Www.ischool.drexel.edu INFO 636 Software Engineering Process I Prof. Glenn Booker Week 3 – Planning and Measuring 1INFO636 Week 3.

Similar presentations


Presentation on theme: "Www.ischool.drexel.edu INFO 636 Software Engineering Process I Prof. Glenn Booker Week 3 – Planning and Measuring 1INFO636 Week 3."— Presentation transcript:

1 www.ischool.drexel.edu INFO 636 Software Engineering Process I Prof. Glenn Booker Week 3 – Planning and Measuring 1INFO636 Week 3

2 www.ischool.drexel.edu INFO636 Week 32 Planning is Good Planning is the foundation for most project management approaches –Plans convey commitment to do something Here we focus on planning as a basis for –Defining the tasks needed for a project –Evaluating the accuracy of our estimates

3 www.ischool.drexel.edu INFO636 Week 33 Planning is Good On a broader level, planning is also necessary to be able to project the cost and profit of an activity, and hence decide whether it’s worth doing at all Programmers and most technical professionals are more motivated when they have a role in planning their tasks

4 www.ischool.drexel.edu INFO636 Week 34 What is a Plan? A plan defines the work to be done –Who will do it –When will it occur –How long will it take In management terms, this determines the schedule and effort (and hence cost) needed for each task

5 www.ischool.drexel.edu INFO636 Week 35 What is a Plan? The creation of a plan often becomes a contractual commitment to do the stated work Need to ensure plans cover all the needed tasks – not just design and code, but also the rest of the life cycle, and support activities (CM, QA, etc.)

6 www.ischool.drexel.edu INFO636 Week 36 Software Plan A plan to develop software is a big topic (see INFO 638) Here we are mostly concerned with –How long will the task take? –In what order will tasks be done? –How do you measure progress? –How good was the plan?

7 www.ischool.drexel.edu INFO636 Week 37 Software Plan Notice we’re following a consistent pattern for each task –Plan how to do it –Do it –Evaluate how well it was done Most quality and process methods (ISO 9000, CMM/CMMI, etc.) are based on comparing planned versus actual data!

8 www.ischool.drexel.edu INFO636 Week 38 Software Plan Your customer for a real project will often look for –What do I get for my money? –How good will the end product be? –How can I tell if there are cost, schedule, or quality problems during the project? –How will I be able to evaluate the project after it’s done?

9 www.ischool.drexel.edu INFO636 Week 39 Software Plan Hence a plan has to have certain things –Clearly defined work to be accomplished –Multiple steps to complete that work –Some way to convey progress to the customer The plan itself must generally be reviewed and approved by the customer

10 www.ischool.drexel.edu INFO636 Week 310 Planning Tools Many tools are available for planning large projects; they aren’t needed for the scope of this course –PERT charts help identify which tasks are critical to completion of the project on time –Cost models such as COCOMO and PriceS help define realistic initial estimates

11 www.ischool.drexel.edu INFO636 Week 311 Planning in PSP The tasks needed for planning are shown on page 65, and explained in detail in chapters 4 to 6 of the text The basic tasks are: –Define project requirements –Product conceptual design –Estimate product size

12 www.ischool.drexel.edu INFO636 Week 312 Planning in PSP –Estimate resources needed –Produce the schedule –Develop the product –Analyze the process to determine refinements to estimation

13 www.ischool.drexel.edu INFO636 Week 313 Planning Objectives Plans should be –Complete – make sure all needed tasks are accounted for –Accessible – make sure the plans are available to those who need to see them –Clear – the tasks and structure of the project should be easy to understand

14 www.ischool.drexel.edu INFO636 Week 314 Planning Objectives –Specific – make sure it is clear who will do what, and when –Precise – use an appropriate level of detail for recording estimates Here, minutes are fine; for a larger project, hours or weeks of effort might make sense –Accurate – make sure the data add up correctly Double or triple check your math!

15 www.ischool.drexel.edu INFO636 Week 315 Measuring Software Size The size of software is the most critical characteristic to estimate well –Many estimation methods start with size as an input, and determine the schedule (calendar months) and effort (people months) from it –Cost comes from multiplying effort by the labor rate ($/hour)

16 www.ischool.drexel.edu INFO636 Week 316 Measuring Software Size So, what’s the best size measurement for software? In spite of many elaborate measures derived over the last few decades, the most reliable measure of software size for predicting development effort is: –Lines of code

17 www.ischool.drexel.edu INFO636 Week 317 Lines of Code Lines of code (LOC) has a lot of problems as a measure There are dozens of possible differences in the way code can be counted –See the LOC handout from INFO 630 for more detailsLOC handout –The key distinction is deciding what kinds of code or other stuff “count” as LOC

18 www.ischool.drexel.edu INFO636 Week 318 Lines of Code We want to automate counting lines of code, since it’s a tedious process to do manually –IBM created a proprietary application to count code, so that all of their projects were counted in the same manner

19 www.ischool.drexel.edu INFO636 Week 319 LOC for Planning After we have tracked our performance for a while, we can use our history to predict the effort to do future assignments –And yes, we will be doing this Examples on pp. 70-71 show a roughly linear (line) relationship between effort and size of the code produced

20 www.ischool.drexel.edu INFO636 Week 320 Goodness of Fit A touch of statistics is needed now –See my statistics overview for more infostatistics overview In plotting two variables, we can determine the correlation (R) between a linear regression and the data –The coefficient of determination, R 2, is a measure of the goodness of fit –Want R 2 > 0.5 to use data for planning

21 www.ischool.drexel.edu INFO636 Week 321 Significance The statistical measure of significance of a correlation is connected to the level of confidence that the result isn’t just the result of random chance Normally want a 95% level of confidence, resulting in a desired significance of p < 0.050 (5%)

22 www.ischool.drexel.edu INFO636 Week 322 Precision versus Accuracy Precision, in connection with software measures, is the degree to which the measure is clearly defined In a single number, precision denotes how many digits are used to describe it –A LOC estimate of 625 LOC is more precise than 600

23 www.ischool.drexel.edu INFO636 Week 323 Precision versus Accuracy Accuracy is how closely the actual performance met the planned value –Like how close an arrow comes to the bull's-eye

24 www.ischool.drexel.edu INFO636 Week 324 Size Measurement Framework We want to define a consistent set of rules for measuring our work –For P track students, you’ll define a LOC counting standard –For N track students, you’ll define proxies to estimate your work This set of rules is the size measurement framework

25 www.ischool.drexel.edu INFO636 Week 325 Size Measurement Framework This allows us to make size estimates the same way throughout the project –More generally, across different projects Essentially, it doesn’t matter what rules you establish (unless they’re really weird) – it’s more important that you HAVE rules and follow them consistently

26 www.ischool.drexel.edu INFO636 Week 326 Size Measurement Framework Page 76 gives an outline of a typical framework –Examples follow p. 76 for Pascal (anyone remember that language?) and C++ –P track students will use it to define counting standards for their work –N track students will follow a parallel exercise to practice using a measurement framework

27 www.ischool.drexel.edu INFO636 Week 327 Size Measurement Framework Key choices for a framework include –Handling of comments –Handling of various types of declarations and types of statements –Handling of sparse lines, like “}” –Handling of null, empty, or blank lines –Handling of reused or legacy code –Handling code developed only for testing

28 www.ischool.drexel.edu INFO636 Week 328 Using LOC LOC is a tricky measure, since different programmers can use wildly different amounts of code to do the same thing Packaging of software can be affected by the volume of code –It’s more expensive to ship a product which requires 2 DVD’s instead of one

29 www.ischool.drexel.edu INFO636 Week 329 Using LOC Another challenge in using LOC is the sparseness of current languages –One line of Visual Basic might be the equivalent of 200 lines of assembly code –As languages get more complex Many routines could only have a few LOC, making estimation seem a little silly The exact functionality invoked gets less clear, since code calls complex packages from within the development environment

30 www.ischool.drexel.edu INFO636 Week 330 Code Development We’re concerned with several types of code changes –New – code which never existed before –Modified – changes to existing code in this program –Deleted – existing code which was removed –Reused – code which was adapted from another source

31 www.ischool.drexel.edu INFO636 Week 331 Code Quality To make comparisons meaningful across projects, consistent standards for coding, LOC counting, and defect measurement are needed The universal measure for code quality is defects per thousand source lines of code (defects/kSLOC)

32 www.ischool.drexel.edu INFO636 Week 332 Code Quality Many think that the number of problems reported with a software release is best linked to the “number of new and modified LOC” –IBM suggested that the total LOC in a release is a better measure Best advice is to try both and see which works better for your environment

33 www.ischool.drexel.edu INFO636 Week 333 Code Reuse As hinted earlier, reuse is a key issue –If only new or modified code is “counted” for productivity, it discourages reuse of code –Poorly documented ‘reusable’ code may be just as time consuming as new development

34 www.ischool.drexel.edu INFO636 Week 334 LOC Counting Each task starts with a Base amount of code in the system (zero initially) From that, code is Added, Deleted, Modified, and Reused At the end of the task, we have –Total LOC = Base + Added – Deleted + Reused –New & changed LOC = Added + Modified

35 www.ischool.drexel.edu INFO636 Week 335 Productivity Productivity is the amount of product produced, divided by the number of hours spent to do so (including the design, test, etc.) There are many ways to count how much LOC ‘should’ count for productivity

36 www.ischool.drexel.edu INFO636 Week 336 Productivity While deleting and reusing code take time, adding and modifying code generally takes much longer, hence the most common definition of LOC for productivity is (Added + Modified)

37 www.ischool.drexel.edu INFO636 Week 337 Productivity If a substantial amount of time was needed for finding code to reuse, or deciding exactly which code was to be deleted, I’d count those too (Added + Modified + Reused + Deleted) Either way, divide the number of LOC by the number of hours spent on the project

38 www.ischool.drexel.edu INFO636 Week 338 LOC Counters LOC count can be based on physical lines (as in, on a page) or logical lines (what counts as a separate statement) –A=1; B=2; C=3; Is one physical line, but three logical lines The simplest logical LOC counter in ‘C’ deletes comment lines, and counts semicolons in the rest of the document

39 www.ischool.drexel.edu INFO636 Week 339 LOC Counters More commonly, LOC is counted by considering both physical and logical lines using a counting standard –The counting standard defines whether a simple line such as “{“ or “Endif” counts as a LOC

40 www.ischool.drexel.edu INFO636 Week 340 Counting Program Changes Page 93 has a simple way to find the number of lines added or deleted between two versions of a file –Lines in the new version not in the old one count as Added LOC –Lines in the old version not in the new one count as Deleted LOC –Modified or Reused code can’t be counted this way

41 www.ischool.drexel.edu INFO636 Week 341 Reports R1 and R2 Reports R1 and R2 start on page 767 –R1 is to create a LOC counting standard template, based on the format on page 76 P track students – tailor it to meet any specific needs of your language choice –R2 is to create a coding standard, based on the template on page 670 P track students – you are expected to use your coding standard for all subsequent assignments

42 www.ischool.drexel.edu INFO636 Week 342 Reports R1 and R2 N track students will be using the existing R1 standard to count LOC for a sample piece of code provided


Download ppt "Www.ischool.drexel.edu INFO 636 Software Engineering Process I Prof. Glenn Booker Week 3 – Planning and Measuring 1INFO636 Week 3."

Similar presentations


Ads by Google