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

2. INFO 637Lecture #12 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. INFO 637Lecture #13 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. INFO 637Lecture #14 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. INFO 637Lecture #15 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. INFO 637Lecture #16 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. INFO 637Lecture #17 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. INFO 637Lecture #18 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. INFO 637Lecture #19 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. INFO 637Lecture #110 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

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

12. INFO 637Lecture #112 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. INFO 637Lecture #113 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. INFO 637Lecture #114 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. INFO 637Lecture #115 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. INFO 637Lecture #116 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. INFO 637Lecture #117 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

18. INFO 637Lecture #118 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!

19. INFO 637Lecture #119 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. INFO 637Lecture #120 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. INFO 637Lecture #121 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. INFO 637Lecture #122 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. INFO 637Lecture #123 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. INFO 637Lecture #124 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. INFO 637Lecture #125 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. INFO 637Lecture #126 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. INFO 637Lecture #127 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. INFO 637Lecture #128 Design Verification More formal verification methods include:  Loop Verification  Proper State Machines  Symbolic Execution  Proof by Induction  Trace Tables  Execution Tables  Formal Verification

29. INFO 637Lecture #129 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. INFO 637Lecture #130 Defining the Software Process Several formats have been developed for representing software processes  See also “Process Definition Overview”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. INFO 637Lecture #131 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

32. INFO 637Lecture #132 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. INFO 637Lecture #133 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. INFO 637Lecture #134 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

35. INFO 637Lecture #135 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. INFO 637Lecture #136 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. INFO 637Lecture #137 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. INFO 637Lecture #138 TSP Steps in each Cycle Strategy Plan Requirements Design Implementation Test Postmortem Look familiar?

39. INFO 637Lecture #139 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. INFO 637Lecture #140 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. INFO 637Lecture #141 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. INFO 637Lecture #142 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. INFO 637Lecture #143 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

44. INFO 637Lecture #144 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. INFO 637Lecture #145 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. INFO 637Lecture #146 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!

47. INFO 637Lecture #147 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. INFO 637Lecture #148 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