Software Engineering Process II

1
Software Engineering Process II

• Development Plan
• INFO 637
• Glenn Booker

2
Need to Plan

• We need to plan our effort carefully, to help
  ensure that
• Everyone knows what to do and when
• We know if were going off schedule
• We can improve the accuracy of our predictions
• Detailed planning helps make some of our
  inaccuracies counterbalance each other
• Results in more accurate overall estimates

3
Plan(ned) Hours

• Each task is assigned a planned number of hours
  for its completion (Plan Hours), based on the
  estimation methods discussed in the PSP
• The sum of Plan Hours for all tasks is the total
  effort needed for the project, in staff-hours
  (Total Plan Hours)

4
Plan Value

• Each task is also assigned a Plan Value (PV),
  which is the percent of the projects value
  assigned to completing that task
• The sum of Plan Value for all tasks in the
  project is, by definition, 100
• If all tasks are equal significance by effort,
  PV (Plan Hours) 100 / (Total Plan Hours)

5
Earned Value

• As tasks are completely finished, they earn
  Earned Value (EV) in the amount of their Plan
  Value
• Hence at any time, the total EV earned is the
  sum of PV for all tasks which have been completed

6
How Detailed to Plan?

• Tasks should be broken down to under ten hours
  per person per task
• For a full project, you generally dont want to
  micromanage to tasks under a work-day, because
  then youll spend more time planning than working

7
Where Record Tasks?

• The overall project, and small programming tasks,
  can be planned on a SUMP form
• Unplanned tasks (including startup for the
  project) can be identified as MM (Management and
  Miscellaneous) tasks
• MM is typically 5-10 of the first cycle
• Quality plans go on a SUMQ form

8
Software Estimates

• Use the same techniques used for the PSP
• Sizes of parts and assemblies, ranging from
  smallest to largest, are called
• Modules (assemblies of objects)
• Components (assemblies of modules)
• Products (assemblies of components)
• System (assemblies of products)

9
TSPi Planning Process

• Conceptual design was created in the strategy
  phase
• Initial estimates of parts for each cycle were
  also developed in the strategy phase (STRAT form)

10
TSPi Planning Process

• Now use SUMS form to list the components to be
  developed in the first cycle
• Also on the SUMS form, identify test plans and
  requirements specifications which apply to these
  components

11
TSPi Planning Process

• Use TASK and SCHEDULE forms to identify how long
  each component will take to create
• Include time for individual effort each week,
  and team effort as well
• Blend to provide TASK and SCHEDULE for entire
  team
• Calculate PV and expected completion date for
  each task

12
TSPi Planning Process

• Make the quality plan, using SUMQ form (discussed
  later)
• Copy TASK and SCHEDULE for each person
• Personalize these by deleting tasks others will
  perform
• Determine PV and estimated completion for each
  personal task

13
TSPi Planning Process

• Review the TASK and SCHEDULE forms for each
  person, and balance the workload
• Adjust tasks and responsibilities as needed to
  make the schedule fair to everyone
• Use the adjusted individual plans to regenerate
  the overall team TASK and SCHEDULE, plus the SUMP
  and SUMQ
• Give these to all team members and instructor

14
TSPi Support Tool

• The TSPi Support Tool can be used to help support
  this process, but it doesnt fully automate the
  process
• If not using the Tool, most teams discuss and
  balance their workload before committing it to
  the forms, to avoid revising the individual
  plans, and then regenerating the team plans

15
Development Plan Script PLAN1
p. 75

• Based on the conceptual design
• Identify specific products to be produced, and
  estimate their sizes
• Record STRAT data in SUMS
• Produce task plan using TASK form
• Produce teams schedule plan using SCHEDULE form,
  including expected weekly hours per person

16
Development Plan Script PLAN1

• Produce the quality plan using estimated SUMP and
  SUMQ plans
• Break out individual plans based on the team TASK
  and SCHEDULE plans
• Balance workload, then reconsolidate the team
  TASK and SCHEDULE plans
• Send TASK, SCHEDULE, SUMS, SUMP, and SUMQ to team
  members and instructor

17
Tracking Work

• Record your time in the time recording log
  (LOGT)
• This helps update your personal TASK and SCHEDULE
  forms
• When a task is completed, enter the week in the
  TASK form
• This will feed the Earned Value for that week

18
Tracking Work

• At the end of each work week, generate the
  updated TASK and SCHEDULE to show the time and EV
  status of your work
• Enter these on the WEEK form, and give to your
  planning manager
• Enter defects on the defect recording log (LOGD)
• These feed the SUMP form for each assembly

19
Tracking Work

• Note that inspection defects (INS) do not
  automatically show up the product owner needs to
  enter each inspection defect on form LOGD as well
• Once a component has been developed, enter its
  size in SUMS for that part
• Includes documentation size, not just code

20
Tracking Work

• Update SUMP to track the time, size, and defect
  data for each engineer
• A separate SUMP should be maintained for each
  assembly, and each phase
• Generate the SUMQ form for each assembly, with
  time, size, and defect data
• Generate team level TASK SCHEDULE, and
  assembly-level SUMP and SUMQ

21
Tracking Work

• Each person reports to the team weekly using the
  WEEK script and the team reports to the
  instructor using the same form

22
Quality Plan

• The quality plan (SUMQ) is outlined on pages
  88-89
• It is a summary of the quality results for the
  project to date, comparing the quality goals with
  the actual results as they become available
• Description of each SUMQ section follows

23
Quality Plan

• Summary section has the overall team productivity
  (LOC/hour), and the percent of reuse and new
  reuse (if any)
• Percent Defect-Free (PDF) section describes the
  percent of components which had no defects, by
  life cycle phase
• Defects/page describes documentation quality

24
Quality Plan

• Defects/KLOC describes the total number of
  defects which were found during development
• Defect Ratios compare the defect rates for
  different activities
• Development time ratios () compare the amount of
  time spent in phases to their review activities

25
Quality Plan

• A/FR is the Appraisal to Failure Ratio the
  ratio of time spent in reviews and inspections to
  the time spent in failure detection activities
  (compile, test)
• Want A/FR gt 2 for small programs, gt1 if large
• Review Rates and Inspection Rates measure how
  fast reviews and inspections are performed

26
Quality Plan

• Defect injection and removal rates (Defects/Hr.)
  measure how quickly defects were made and
  discovered during each life cycle phase or
  inspection
• Phase Yield is the percent of defects entering
  the phase which were removed
• Process Yield is the percent of defects removed
  before entering a phase

27
Quality Plan

• The quality plan is heavily dependent on having
  sound data input
• Hence the data recorded for every task and every
  defect must be as accurate as possible, or the
  final results will quickly become gibberish!