Software Engineering Process II PSP Overview

1
Software Engineering Process II PSP Overview
TSP Introduction

• INFO 637
• Glenn Booker

2
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

3
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

4
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

5
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

6
PSP Maturity Progression

• PSP0 and 0.1 Baseline Personal Process
• PSP1 and 1.1 Personal Planning Process
• PSP2 and 2.1 Personal Quality Management
• PSP3 Cyclic Personal Process

7
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

8
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

9
Software Plan

• The software plan is key to the PSP
• Primary 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?

10
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 cant be
  accurate

11
Product Size Estimation

• Size estimates of the product need to be repeated
  during the life cycle to help ensure the product
  isnt growing forever
• Software size estimates often based on Lines of
  Code (LOC)
• Function points also used, but less reliable for
  cost and schedule estimation

12
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

13
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

14
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

15
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

16
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

17
GQM Method

• Metrics need to be traced to the questions they
  will answer, and the business goals they will
  help understand
• If the data isnt needed, dont bother collecting
  it!
• Make sure measures are clearly defined

18
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 wont know if the
  process improved or not!

19
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

20
Design and Code Reviews

• 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!

21
Design and Code Reviews

• 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.)

22
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

23
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

24
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

25
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

26
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

27
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

28
Design Verification

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

29
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

30
Defining the Software Process

• Several formats have been developed for
  representing software processes
• See 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

31
Using the PSP

• Challenges in using the PSP concepts in the Real
  World include
• Sticking to your plans and estimates when your
  boss doesnt like the numbers
• Not folding into chaos when the first crisis
  comes along
• Being flexible to accommodate changing
  requirements

32
Using the PSP

• Using the PSP alone is very difficult
• Even with organizational support, using the PSP
  can cost you
• Time to learn it
• Mental anguish to maintain your own discipline
• Risk to your ego

33
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!)

34
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 were using the TSPi,
  designed for a team of 4-8 people uses the same
  concepts, but on a different scale

35
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

36
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

37
TSP Design

• Build on the PSP
• Develop products in several cycles
• Use standard, precise measures for quality and
  performance
• Use role and team evaluations
• Require process discipline (stick to it!)
• Provide guidance on teamwork problems

38
TSP Steps in each Cycle

• Strategy
• Plan
• Requirements
• Design
• Implementation
• Test
• Postmortem

Look familiar?
39
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

40
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

41
TSP Logic

• Common teamwork problems
• Ineffective leadership
• Failure to compromise or cooperate
• Lack of participation
• Procrastination and lack of confidence
• Poor quality
• Function creep
• Ineffective peer evaluation

42
What is a Team?

• At least two people, who
• Have a common goal, where
• Each person has specific roles to perform, and
  where
• The mission is complex enough to require
  dependency among them

43
Teams

• Teams typically cant 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

44
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

45
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)

46
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 dont panic!

47
TSP Teams

• TSP teams form using a common project as the
  starting point that defines their goal
• Roles are clearly assigned
• Plans are prepared to identify how to reach the
  goal
• Meetings are required to help avoid internal
  communication problems

48
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