INFO 637

Software Engineering Process II

PSP Overview & TSP Introduction Lecture #1 INFO 637 Glenn Booker 1

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 INFO 637 Lecture #1 2

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 INFO 637 Lecture #1 3

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 INFO 637 Lecture #1 4

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 INFO 637 Lecture #1 5

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 INFO 637 Lecture #1 6

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 INFO 637 Lecture #1 7

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 INFO 637 Lecture #1 8

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?

INFO 637 Lecture #1 9

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 INFO 637 Lecture #1 10

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 INFO 637 Lecture #1 11

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 INFO 637 Lecture #1 12

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 INFO 637 Lecture #1 13

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 INFO 637 Lecture #1 14

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 INFO 637 Lecture #1 15

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

INFO 637 Lecture #1 16

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 INFO 637 Lecture #1 17

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!

INFO 637 Lecture #1 18

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 INFO 637 Lecture #1 19

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!

INFO 637 Lecture #1 20

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.) INFO 637 Lecture #1 21

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 INFO 637 Lecture #1 22

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 INFO 637 Lecture #1 23

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 INFO 637 Lecture #1 24

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 INFO 637 Lecture #1 25

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 INFO 637 Lecture #1 26

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 INFO 637 Lecture #1 27

Design Verification

 More formal verification methods include:  Loop Verification  Proper State Machines  Symbolic Execution  Proof by Induction  Trace Tables  Execution Tables  Formal Verification INFO 637 Lecture #1 28

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 INFO 637 Lecture #1 29

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 INFO 637 Lecture #1 30

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 INFO 637 Lecture #1 31

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 INFO 637 Lecture #1 32

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!) INFO 637 Lecture #1 33

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 INFO 637 Lecture #1 34

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 INFO 637 Lecture #1 35

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 INFO 637 Lecture #1 36

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 INFO 637 Lecture #1 37

TSP Steps in each Cycle

 Strategy  Plan  Requirements  Design  Implementation  Test  Postmortem Look familiar?

INFO 637 Lecture #1 38

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 INFO 637 Lecture #1 39

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 INFO 637 Lecture #1 40

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 INFO 637 Lecture #1 41

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 INFO 637 Lecture #1 42

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 INFO 637 Lecture #1 43

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 INFO 637 Lecture #1 44

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) INFO 637 Lecture #1 45

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! INFO 637 Lecture #1 46

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 INFO 637 Lecture #1 47

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 INFO 637 Lecture #1 48