Software Engineering Process II

INFO 637 Lecture #4 1

Software Engineering Process IIDevelopment Plan

INFO 637

Glenn Booker


Need to Plan

We need to plan our effort carefully, to help ensure that: Everyone knows what to do and when We know if we’re 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


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)


Plan Value

Each task is also assigned a Plan Value (PV), which is the percent of the project’s 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)


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


How Detailed to Plan?

Tasks should be broken down to under ten hours per person per task

For a full project, you generally don’t want to micromanage to tasks under a work-day, because then you’ll spend more time planning than working


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 M&M (Management and Miscellaneous) tasks M&M is typically 5-10% of the first cycle

Quality plans go on a SUMQ form


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)


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)



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



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



Make the quality plan, using SUMQ form (discussed later)

Copy TASK and SCHEDULE for each person Personalize these by deleting tasks others

will performDetermine PV and estimated completion

for each personal task



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


TSPi Support Tool

The TSPi Support Tool can be used to help support this process, but it doesn’t 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


Development Plan Script PLAN1

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 formProduce team’s schedule plan using

SCHEDULE form, including expected weekly hours per person

p. 75


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


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


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


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


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 phaseGenerate the SUMQ form for each

assembly, with time, size, and defect dataGenerate team level TASK & SCHEDULE,

and assembly-level SUMP and SUMQ


Tracking Work

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


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


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


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


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 > 2 for small programs, >1 if large

Review Rates and Inspection Rates measure how fast reviews and inspections are performed


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


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!

Documents

Software Engineering Process II