Software Engineering Process I Planning and Measuring

1
Software Engineering Process IPlanning and
Measuring

• INFO 636
• Glenn Booker

2
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
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 its worth
  doing at all
• Programmers and most technical professionals are
  more motivated when they have a role in planning
  their tasks

4
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
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
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
Software Plan

• Notice were following a consistent pattern for
  each task
• Plan how to do it
• Do it
• Evaluate how well it was done

8
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
  its done?

9
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
  approved by the customer

10
Planning Tools

• Many tools are available for planning large
  projects they arent 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
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
Planning in PSP

• Estimate resources needed
• Produce the schedule
• Develop the product
• Analyze the process to determine refinements to
  estimation

13
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
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
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
Measuring Software Size

• So, whats 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 is
• Lines of code

17
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 is counted
• See the LOC handout from INFO 630 for more
  details
• The key distinction is deciding what kinds of
  code or other stuff count as LOC

18
Lines of Code

• We want to be able to automate counting code,
  since its 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
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
Goodness of Fit

• A touch of statistics is needed now
• See my statistics overview for more info
• In plotting two variables, we can determine the
  correlation (R) between a linear regression and
  the data
• The coefficient of determination, R2, is a
  measure of the goodness of fit
• Want R2 gt 0.5 to use data for planning

21
Significance

• The statistical measure of significance of a
  correlation is connected to the level of
  confidence that the result isnt just the result
  of random chance
• Normally want a 95 level of confidence,
  resulting in a desired significance of lt 0.050
  (5)

22
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
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
Size Measurement Framework

• We want to define a consistent set of rules for
  measuring our work
• For P track students, youll define a LOC
  counting standard
• For N track students, youll define proxies to
  estimate your work
• This set of rules is the size measurement
  framework

25
Size Measurement Framework

• This allows us to make size estimates the same
  way throughout the project
• More generally, across different projects
• Essentially, it doesnt matter what rules you
  establish (unless theyre really weird) its
  more important that you HAVE rules and follow
  them consistently

26
Size Measurement Framework

• Page 76 gives an outline of a typical framework
• Examples follow p. 76 for Pascal (anyone remember
  that?) 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 framework

27
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
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
• Its more expensive to ship a product which
  requires 2 CDs instead of one

29
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

30
Code Development

• Were 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
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
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
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
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
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
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
Productivity

• If a substantial amount of time was needed for
  finding code to reuse, or deciding exactly which
  code was to be deleted, Id count those too
  (Added Modified Reused Deleted)
• Either way, divide the number of LOC by the
  number of hours spent on the project

38
LOC Counters

• LOC count can be based on physical lines (as in,
  on a page) or logical lines (what counts as a
  separate statement)
• A1 B2 C3Is 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
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
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 cant be counted this way

41
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 assignments

42
Reports R1 and R2

• N track students will be using the existing R1
  standard to count LOC for a sample piece of code
  provided