INFO 637Lecture #11 Software Engineering Process II PSP Overview & TSP Introduction INFO 637 Glenn Booker

INFO 637 Lecture #1 1

Software Engineering Process II

PSP Overview & TSP Introduction

INFO 637

Glenn Booker


Introduction

This course expands on the Personal Software Process (PSP) to apply the same concepts to a small, highly focused team of people

Should only be used with organizations which meet Capability Maturity Model (CMM) Level 2 or higher


CMM Levels

CMM Levels are cumulative – to achieve each higher level, all of the previous requirements still apply Level 0 means that some or all key

activities are not being performed Level 1 means that key activities are

being performed, but in a chaotic or uncontrolled manner


CMM Levels

Level 2 means that key activities are planned and controlled for at least a single project

Level 3 means that key activities are planned and controlled for an entire organization (multiple projects)

Level 4 means that activities are so well predicted, they are statistically controlled

Level 5 means that you keep reaching for new and better ways of improving your activities


Personal Software Process (PSP)

The PSP: Takes those large scale project methods and

practices which can be used by individuals, Structures them so that they can be introduced

gradually, and Provides a framework for teaching them


PSP Maturity Progression

PSP0 and 0.1 Baseline Personal ProcessPSP1 and 1.1 Personal Planning ProcessPSP2 and 2.1 Personal Quality

ManagementPSP3 Cyclic Personal Process


PSP0 Baseline Personal Process

The Baseline Personal Process uses scripts and logs to measure the normal software development life cycle (design, code, compile, test)

All programs written with the PSP start with a plan, then create the program, then have a post mortem to evaluate the results


PSP0 Baseline Personal Process

Forms are used to ensure a consistent and complete reporting of needed information

Basic measurements include the time for each phase, and the defects found and removed

The net result, other than the actual software, is a Plan Summary which compares the planned effort to the actual effort, and contains defect data


Software Plan

The software plan is key to the PSPPrimary contents of a software plan

include Job size – size of the product, and time to

create it Job structure – how will work be done? In

what order? Job status – is the project on time and

on schedule?


Software Plan

Assessment – how good was the plan? What lessons can be learned for next time?

Commitment – what will be delivered, when, and for how much money?

What will the product quality be? Will it meet the needs of the customer?

Scope of the plan must be clear, or it can’t be accurate


Product Size Estimation

Size estimates of the product need to be repeated during the life cycle to help ensure the product isn’t growing forever

Software size estimates often based on Lines of Code (LOC)

Function points also used, but less reliable for cost and schedule estimation


LOC Accounting

LOC of actual program changes during development

Need to record amount of LOC which were added, deleted, modified, or reused

Productivity is then the number of LOC divided by the number of hours needed to produce it


Estimating Methods

The size of code produced for a given purpose is best predicted by past experience with similar projects

Barring that, other analytical methods can be used, such as expert estimates, function points, etc.

Object-oriented methods are evolving


Resource and Schedule Estimates

Number of resources (e.g. people) needed for development need to be derived from the size estimates

Many analytical methods are also available here

Schedule estimate also falls out from the size estimate


Earned Value

Earned value methods can help track progress, to balance The amount of work accomplished

(the amount of value earned) The effort used (labor hours) The cost expended ($)

The accuracy of successive estimates can be plotted to determine the trend, or examine special cases


Measurements

Measurements focus on four major nouns Product (size, complexity, quality, etc.) Process (task duration, completion) Resources (people hours) Tools (development environment)

Resources use tools in accordance with some process to produce a product


GQM Method

Metrics need to be traced to the questions they will answer, and the business goals they will help understand

If the data isn’t needed, don’t bother collecting it!

Make sure measures are clearly defined


Baseline

Data on product size, development effort, cost, and defects need to be collected in some sort of database

This establishes the baseline of how well (speed, cost, quality) you currently develop software Have to know this, or we won’t know if the

process improved or not!


Design and Code Reviews

Reviews are needed to help find and eliminate defects before those mistakes get passed on to the rest of the life cycle

Consists of: Preparation for the review Inspection meeting (the review itself) Repair and report



Reviews are much more cost effective at finding defects than testing

After defects are found, they can often be fixed immediately

Need to remember to verify that the fixes worked, or else additional defects may be introduced!



Reviews can be measured to determine their efficiency What percent of the defects were found during

the review? Answer is the percent Yield

In addition to the phase when found and created, defects may be categorized by type (documentation, syntax, assignment, etc.)


Software Quality

The data collected about defects allows a great deal of understanding of the quality of the product

More elaborate defect measures, by the life cycle phase where they were found, include: Time to identify defects Average cost per defect


Software Design

Design is often iterative, among these steps: Identify user and system requirements Analyze and clarify requirements Propose high level design Validate design against requirements Document the design Expand high level design into low level design


Software Design

Designs can be expressed in math-like logical languages, visual models, and/or in plain text

Specific templates for object oriented design are included in the PSP


Scaling up the PSP

Large systems can be broken down into smaller logically separate parts, where the interaction among the parts is knowable

This can be repeated until the smaller parts are small enough to apply the PSP

Strategies for large scale system development are a.k.a. life cycle models


Scaling up the PSP

Products can be sized by five categories Stage 0 – an element of a single module Stage 1 – one module or unit of code Stage 2 – components of several related

Stage 1 modules Stage 3 – an entire system Stage 4 – a group of interrelated systems


Design Verification

Designs are verified by several common methods, including review, compilation, test, and analysis

Need to balance the cost of extensive verification against value of defects it finds

Analytical verification focuses on code execution, so need to ensure code scope is correct


Design Verification

More formal verification methods include: Loop Verification Proper State Machines Symbolic Execution Proof by Induction Trace Tables Execution Tables Formal Verification


Defining the Software Process

Since most projects will not just use the PSP scripts, need to define new processes

Each process needs to identify Objectives Goals Quality criteria Scripts and Forms


Defining the Software Process

Several formats have been developed for representing software processesSee also “Process Definition Overview”

Need to define the existing process (if any), the new ideal process, and then how to get from the existing to the ideal


Using the PSP

Challenges in using the PSP concepts in the Real World include Sticking to your plans and estimates when

your boss doesn’t like the numbers Not folding into chaos when the first crisis

comes along Being flexible to accommodate

changing requirements


Using the PSP

Using the PSP alone is very difficultEven with organizational support, using

the PSP can cost you Time to learn it Mental anguish to maintain your own discipline Risk to your ego


Using the PSP

But in return for using the PSP, you get Insight into your true abilities Ideas for improvement Control over your work Pride and personal accomplishment The foundation for successful teamwork

(the TSP!)


Team Software Process

The Team Software Process (TSP) takes the concept of the PSP and expands it to a group of people who are working together on the same project Note: the true TSP is designed for up to 20

people; technically we’re using the TSPi, designed for a team of 4-8 people … uses the same concepts, but on a different scale


Why need a TSP?

The TSP is needed because most groups of engineers waste a lot of time on team formation and managing team dynamics

The TSP provides a framework to help avoid that waste


TSP Principles

Learning is most effective by following a defined process with rapid feedback

Teamwork needs goals, a supportive environment, coaching, and leadership

Solving actual problems helps you appreciate the soundness of the TSP

Good instruction builds on prior knowledge


TSP Design

Build on the PSPDevelop products in several cyclesUse standard, precise measures for

quality and performanceUse role and team evaluationsRequire process discipline (stick to it!)Provide guidance on teamwork problems


TSP Steps in each Cycle

StrategyPlanRequirementsDesignImplementationTestPostmortem

Look familiar?


TSP Structure

The TSP is cyclical in nature (even though we only have time for one cycle)

Start with the smallest viable version of the final product

Each cycle produces a testable subset of the final product

Cycle products combine to form the final product


TSP Logic

TSP is designed to address the most common causes of project failures The teamwork aspect most often causes

trouble, not technical issues Projects often fail due to handling pressure

badly, particularly from self and managers


TSP Logic

Common teamwork problemsIneffective leadership Failure to compromise or cooperateLack of participationProcrastination and lack of confidencePoor qualityFunction creepIneffective peer evaluation


What is a Team?

At least two people, whoHave a common goal, whereEach person has specific roles to perform,

and whereThe mission is complex enough to require

dependency among them


Teams

Teams typically can’t be above 20 people, because group dynamics get too messy From 4-12 people is better

A team has “jelled” when it functions better than just the sum of its parts – when synergy has occurred


Teamwork

Teamwork also requires that Tasks are clear, distinct, and meaningful The team is clearly identifiable The team has control over its tasks and how

to get the work done


Effective Teams

Effective teams also need Cohesion, so that team members are

comfortable working with each other Challenging, plausible goals Feedback, such as tracking to reach goals A common working framework (the team

members need to understand how the goals will be met)


Team Formation

Teams generally form around the common product or goal

While the means to achieve it may not be obvious, the team can often agree on the constraints it must fulfill

Conflict, confusion, and disagreement are common during this phase – don’t panic!


TSP Teams

TSP teams form using a common project as the starting point – that defines their goal

Roles are clearly assignedPlans are prepared to identify how to

reach the goalMeetings are required to help avoid

internal communication problems


TSP Teams

And finally, external communication is needed Teams often flounder (or halibut) when they fail

to communicate to their manager The TSP requires weekly feedback to the

instructor to avoid this problem

Documents

INFO 637Lecture #11 Software Engineering Process II PSP Overview & TSP Introduction INFO 637 Glenn Booker