1 / 48

Software Engineering Process II PSP Overview & TSP Introduction

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

jean
Télécharger la présentation

Software Engineering Process II PSP Overview & TSP Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Engineering Process IIPSP Overview & TSP Introduction INFO 637 Glenn Booker Lecture #1

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

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

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

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

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

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

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

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

  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 can’t be accurate Lecture #1

  11. 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

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

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

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

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

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

  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 isn’t needed, don’t bother collecting it! • Make sure measures are clearly defined Lecture #1

  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 won’t know if the process improved or not! Lecture #1

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

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

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

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

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

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

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

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

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

  28. 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

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

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

  31. 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

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

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

  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 we’re using the TSPi, designed for a team of 4-8 people … uses the same concepts, but on a different scale Lecture #1

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

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

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

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

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

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

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

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

  43. 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

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

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

  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 – don’t panic! Lecture #1

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

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

More Related