Software Engineering Process II PSP Overview & TSP Introduction

Software Engineering Process IIPSP Overview & TSP Introduction INFO 637 Glenn Booker Lecture #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 Lecture #1

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

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

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

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

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

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

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? Lecture #1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Design Verification • More formal verification methods include: • Loop Verification • Proper State Machines • Symbolic Execution • Proof by Induction • Trace Tables • Execution Tables • Formal Verification Lecture #1

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

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

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

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

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

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

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

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

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

TSP Steps in each Cycle • Strategy • Plan • Requirements • Design • Implementation • Test • Postmortem Look familiar? Lecture #1

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

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

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

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

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

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

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

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

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

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

Software Engineering Process II PSP Overview & TSP Introduction