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