Software Engineering Process I Planning and Measuring - PowerPoint PPT Presentation

1 / 42
About This Presentation
Title:

Software Engineering Process I Planning and Measuring

Description:

Accessible make sure the plans are available to those who need to see them ... P track students tailor it to meet any. specific needs of your language choice ... – PowerPoint PPT presentation

Number of Views:74
Avg rating:3.0/5.0
Slides: 43
Provided by: users3
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com