info 637lecture #101 software engineering process ii review info 637 glenn booker

INFO 637 Lecture #10 1

Software Engineering Process IIReview

INFO 637

Glenn Booker


TSP Overview

The TSP is designed for teams of up to 20 people Here we used TSPi, which uses the same

concepts, but designed for a team of 4-8 people

TSPi is based on a waterfall-like life cycle model, adapted for cyclical development Features are developed in cycles, which each

build on previous cycles


TSP Steps Within Each Cycle

StrategyPlanRequirementsDesignImplementationTestPostmortem


TSP Structure

The structure of the TSP is designed to avoid most common problems associated with team formation and lack of peer review Everyone is assumed to be a software

developer (Development Engineer), and also take on an additional role


TSP is Implementation-Independent

TSP doesn’t assume any type of development methodology Object oriented Procedural development

Any kind of analysis techniques or models could be used Use cases, formal specification, ERD, DFD,

class diagram, interaction diagrams, etc.


TSP Roles

Team LeaderDevelopment ManagerPlanning ManagerQuality and Process Manager

May be two separate roles

Support Manager


TSP Activities

The management of activities is similar to version 2.0 of the PSP Time is logged for all activities Defects are logged Tasks are planned, and actual times recorded Size of work products is estimated, and

compared to actuals Risks and issues are identified and tracked


TSP Activities

TSP also introduces a peer review process, which allows estimation of defects missed during inspection

A change control process is added to prevent conflicting changes to the same artifact (code, documentation, etc.)


Typical Scripts for one Cycle

We used the scripts for one project cycle Launch & Development Strategy Development Plan SRS and System Test Plan Design and Integration Test Plan Implementation Script Test Script (conduct integration & system test) Post Mortem


Launch Script

The launch script includes: Course overview Assigning roles Describing the objectives of your product

How will you know if it’s been created correctly? Hold the first team meeting Review of data reporting requirements


Development Strategy Script

Key steps in this phase are: Create Conceptual Design of the product Define Development Strategy

What features go into each cycle? Estimate Product size and development effort Assess Risks Document the Development Strategy Define Configuration Management Plan


Development Plan Script

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


Development Plan Script

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


SRS Script

The development script for creating the SRS includes: Reviewing and clarifying the system needs Allocating parts of the SRS to be done by

each team member Developing the system test plan Inspecting the SRS and test plan Refining the SRS and test plan


Design Scripts

Conduct high level design to identify and name the major components Capture the design using one or more methods

mentioned earlier

Define design standards (like in the PSP)Allocate design tasks to team members


Design Scripts

Prepare parts of the SDS separatelyPrepare the integration test plan Inspect the draft design document and

test planUpdate and agree upon the final SDS,

and prove that it is traceable to the SRS


Implementation Script

Plan implementation tasks using SUMP and SUMQ

Allocate tasks to team membersConduct detailed design

Do design review using LOGD and LOGT

Create unit test plan, test cases, procedures, and test data



Inspect the detailed design for each component using INS and LOGD

Create the code, and review it using code checklist Record defects using LOGD and LOGT

Do formal code inspection using INS and LOGD



Have quality manager verify every component

Release accepted componentsHence the outputs from this script are:

Completed code Forms INS, SUMP, SUMQ, LOGD, and LOGT Test plans and materials (test cases, etc.) Updated project notebook


Test Scripts

Test script includes: Develop build, integration test, and system

test procedures Determine size, time, and materials needed

for each test Build the product Conduct integration testing Conduct system testing


Test Scripts

Produce user documentation, review and fix it

Outputs include An integrated and tested product for this cycle Completed LOGD and LOGTEST forms for

all tests Completed user documentation Time, size, and defect data in TSP system


Post Mortem Scripts

The post mortem is started when the team has completed, tested, and documented this cycle’s product

Review the SUMP and SUMQ forms from this cycle Which processes worked, and which didn’t? How did product quality compare to

previous cycles (if any) or expectations?


Post Mortem Scripts

Did process efficiency change much (e.g. the productivity measures)?

Were the roles successfully executed? Were there any problems with any roles?

Look for improvement ideas, and submit them on PIP forms

Prepare a cycle report


Cycle Report

Each team member writes a description of What did you produce? What processes did you use? What roles did you perform? What worked, and what didn’t? How well did your role work with the team? How were you as a developer?


Waterfall Similarities

Notice that the combination of test planning with development phases is straight from classic waterfall structure The system test plan is written with the system

requirements The integration test plan is written with the high

level design The unit test plan is written with detailed design

(in the implementation phase)


Continuous Evaluation and Improvement

As each cycle progresses, earned value is tracked, and measures of quality, productivity, and defect removal effectiveness are made

This forms, over many cycles, an objective basis for predicting future development efforts and truly understanding the caliber of work produced by your team


That’s it!

And that is the Team Software Process

info 637lecture #101 software engineering process ii review info 637 glenn booker

Documents