Download pdf - The SEI Approach

Transcript
Page 1: The SEI Approach

The SEI Approach

Modelos de Procesos y Metodologías de Ingeniería de software

Mayo de 2013

Universidad de CaldasFacultad de IngenieríasMaestría en Ingeniería Computacional

Page 2: The SEI Approach

¡Welcome!

Page 3: The SEI Approach

ContentPersonal Software Process (PSP)

Team Software Process (TSP)

PSP & TSP & CMMI

Page 4: The SEI Approach

Sources• Ron S. Kenett & Emanuel R. Baker. Process Improvement and CMMI® forSystems and Software. 2010 Taylor and Francis Group, LLC. ISBN 978-1-4200-6051-5

• James McHale and Daniel S. Wall. Mapping TSP to CMMI. TECHNICALREPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. April 2005. Available inhttp://www.sei.cmu.edu/reports/04tr014.pdf

•Hayes, W. and Over, J.W., The Personal Software ProcessSM (PSPSM): AnEmpirical Study of the Impact of PSP on Individual Engineers, (CMU/SEI-97-TR-001), Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, December 1997.

•Mukesh Jain. Delivering Successful Projects with TSPSM and Six Sigma APractical Guide to Implementing Team Software Process. AuerbachPublications, 2009. ISBN 978-1-4200-6143-7

Page 5: The SEI Approach

National Interest around CMMI,

PSP/TSP

• SENA

• MINTIChttp://programa.gobiernoenlinea.gov.co/convocatoria_TSP_PSP.shtml

• Goverment PSP, TSP, CMMI

• National Industry Scrum

Why?

Page 6: The SEI Approach

Relations between CMMI-TSP-PSP

•The CMMI constellations address issues related to howorganizations develop or acquire systems and services

•The Team Software Process (TSP) and the PersonalSoftware Process (PSP) address issues regardingdevelopment at the next lower levels of organizations: TSPat the team level and PSP at the personal level.

•Although one may look at the organization of models as a top-down architecture, in reality, the TSP extends and builds uponthe concepts contained in the PSP.

•These techniques provide detailed guidance for how toimplement individual- and team-based processes toquantitatively manage and improve software development

Page 7: The SEI Approach

Relations between CMMI-TSP-PSP

Source: http://www.gonet.us/index.asp?action=home.interior&SectId=1295&CatId=1539&ArtId=656

Page 8: The SEI Approach

CMM/CMMI - fororganizational

capability

TSP - for quality products on cost

and schedule

PSP - forindividual skill and discipline

Adapted From “Three Dimensions of Process Improvement,” Watts Humphrey, CROSSTALK, February 1998

Relations between CMMI-TSP-PSP

Source: www.enel.ucalgary.ca/People/Smith/2011webs/encm511_11/11_Lectures/11_November/ExtraTalk_4Nov2011_PSP.ppt

Page 9: The SEI Approach

Personal Software Process

(From Watts Humphrey):

“Engineers are understandably skeptical aboutchanges to their work habits; although they may bewilling to make a few minor changes, they willgenerally stick fairly closely to what has worked forthem in the past until they are convinced a newmethod will be more effective. This, however, is achicken-and-egg problem: engineers only believe newmethods work after they use them and see the results,but they will not use the methods until they believe theywork”

Page 10: The SEI Approach

Personal Software Process

(From Hayes and Over):

The PSP course incorporates what has been calleda “self-convincing” learning strategy that usesdata from the engineer’s own performance toimprove learning and motivate use. The courseintroduces the PSP practices in steps corresponding toseven PSP process levels. Each level builds on thecapabilities developed and historical data gathered inthe previous level.

Page 11: The SEI Approach

TEAM Power• The initial TSP objective is to convince management

to let your team be self directed.

• A self-directed team

• sets its own goals

• establishes its own roles

• decides on its own development strategy

• defines its own processes

• develops its own plans

• measures, manages, and controls its own work

• Self-directed teams do the best work.

• The PSP provides the knowledge and skill thatdevelopers need to work on TSP teams

Page 12: The SEI Approach

TEAM Power

• Management will agree to your managing your ownwork as long as they believe that you are doing asuperior job.

• To convince them of this, you must

• maintain precise and accurate plans

• measure and track your work

• regularly show management that you are doingsuperior work

• The PSP shows you how to do this

Page 13: The SEI Approach

PSP Principles (I)

• The quality of a software system is determined bythe quality of its worst components.

• The quality of a software component is governed bythe individual who developed it.

• The quality of a software component isgoverned by the quality of the process used todevelop it.

• The key to quality is the individual developer’s skill,commitment, and personal process discipline.

Page 14: The SEI Approach

PSP Principles (II)

• As a software professional, you are responsible foryour personal process.

• You should measure, track, and analyze your work.

• You should learn from your performance variations.

• You should incorporate lessons learned into yourpersonal practices.

Page 15: The SEI Approach

What Does a PSP Provide? (I) A stable, mature PSP allows you to

• estimate and plan your work

• meet your commitments

• resist unreasonable commitment pressures

• You will also understand your current performancebe better equipped to improve your capability

The PSP provides:

• a proven basis for developing and using anindustrial-strength personal process

• a discipline that shows you how to improve yourpersonal process

• the data to continually improve the productivity,quality, and predictability of your work

Page 16: The SEI Approach

What Does a PSP Provide? (II)

Page 17: The SEI Approach

What Does a PSP Provide? (III)

• The PSP process is designed for individual use.

• It is based on scaled-down industrial softwarepractice.

• The PSP course demonstrates the value of using adefined and measured process.

• It helps you and your organization meet theincreasing demands for high quality and timelysoftware.

Page 18: The SEI Approach

How to learn PSP?In a SEI PSP Official course, Engineers learn to use thePSP by writing ten programs, one or two at each of theseven levels, and preparing five written reports.

Engineers may use any design method or programminglanguage in which they are fluent. The programs aretypically around one hundred lines of code (LOC) andrequire a few hours on average to complete.

While writing the programs, engineers gather process datathat are summarized and analyzed during a postmortemphase. With such a short feedback loop, engineers canquickly see the effect of PSP on their own performance.They convince themselves that the PSP can help them toimprove their performance; therefore, they are motivated tobegin using the PSP after the course

Page 19: The SEI Approach

Learning the PSP• The PSP methods are organized into seven process

versions and address different aspects of how PSP isapplied.

• The process versions are labeled PSP0, PSP0.1, PSP1,PSP1.1, PSP2, PSP2.1, and PSP3.

• Each process version contains a similar set of scripts,logs, forms, and standards.

• You write one or more module-sized programs at eachstep.

• You gather and analyze data on your work.

• You use the results to improve your personalperformance

Page 20: The SEI Approach

Learning the PSP

source:SEI officialtraining slides

Page 21: The SEI Approach

The PSP Process

Page 22: The SEI Approach

Learning the PSP

• PSP0: You establish a measured performancebaseline.

• PSP1: You make size, resource, and scheduleplans.

• PSP2: You practice defect and yieldmanagement

• PSP3: You scale efficiently PSP to real lifeprojects

Page 23: The SEI Approach

PSP 0 (I)•PSP0 and PSP0.1 formulate a baseline understanding ofPSP, focusing on developing and understanding the needfor establishing an initial base of historical size, time, anddefect data.

•These process versions address issues such asunderstanding the current process in use, the need forbasic measures, the importance of measures of size(which relate to productivity), etc.

•In PSP training courses, in learning this aspect of PSP,students develop small programs, using their ownmethods but following a rigorous process. They arerequired to estimate, plan, perform, measure, compareactuals to estimates, and conduct a post-mortem whenfinished.

Page 24: The SEI Approach

PSP 0 (II)• The objective for PSP0 is to demonstrate the use ofa defined process in writing small programs

• Incorporate basic measurements in the softwaredevelopment process require minimal changes toyour personal practices.

•The PSP is not the process for writing software.

•The PSP is a process for learning about process.

•It’s the process equivalent of a code sample

•examine your PSP data

•review your experience and PIPs (ProcessImprovement Proposals)

•tailor the PSP to meet your needs

Page 25: The SEI Approach

PSP 0 (III)•Planning – produces a plan for developing theprogram defined by the requirements.

•Design – produces a design specification for theprogram defined by the requirements.

•Coding – transforms the design specification intoprogramming language statements

•Compile – translates the programming languagestatements into executable code.

•Test – verifies that the executable code satisfies therequirements.

•Postmortem – summarizes and analyzes the projectdata.

Page 26: The SEI Approach

Process Scripts•Process scripts guide you through the process.

•You should

•check the entry criteria before starting a phase

•record the phase start time

•perform the phase steps and instructions

•record defects as they are found and corrected

•check the exit criteria before ending a phase

•record the phase end time

•go to the next phase

•Force yourself to use this paradigm until it becomesa habit.

Page 27: The SEI Approach

PSP0 Measures and Forms•PSP0 measures

•Time – track time in phase

•Defects – record defects as they are found andfixed

•PSP0 has four forms

•PSP0 Project Plan Summary – summarizesplanned and actual time and defects by phase

•PSP0 Time Recording Log – used to record time

•PSP0 Defect Recording Log – used to recorddefects

•PSP0 Defect Type Standard – used to definestandard defect types

Page 28: The SEI Approach

PSP0•In using PSP0, your principal objective is to learnto gather and report accurate and complete dataon your work.

•Gather and record data on your process as you work,not afterwards. If you forget, promptly make your bestguess.

• Be precise and accurate.

• Track time in minutes.

• Count every defect.

•You will be using your own data to manage yourprocess; gather data that is worthy of your trust.

Page 29: The SEI Approach

PSP 0.1 (I)• Your principal objective is to measure and estimatethe size of the programs that you produce so that youcan effectively plan and manage your work

• The objectives of PSP0.1 are to help you tomeasure the size of the programs that youproduce, perform size accounting for theprograms that you produce make accurate andprecise size measurements

•There are two new process elements.

•process improvement proposal (PIP) form

•size counting and coding standards

Page 30: The SEI Approach

PSP 0.1 (II)• The additions to the PSP0.1 process scripts include newsteps for

•estimating and reporting software size

•distributing development time over planned project phases

•using a size counting and coding standard

•recording process problems and improvement ideas

• To improve your process, you will need to capture processproblems and propose improvements for future reference.

• You will need to know

•any problems you have encountered in using the process

•any suggestions you have for process improvements

•your observations and findings from doing the assignments

Page 31: The SEI Approach

PSP 0.1 and coding standards• Coding and size counting standards are needed towrite the PSP programs.

• These standards are tailored to your language andneeds designed to make size counting easier

• The coding standard defines quality-oriented exitcriteria for the code phase.

Page 32: The SEI Approach

PSP 0.1 size measurements•In the PSP, software size measures are used to

•relate the amount of product produced with effortexpended to project total effort

•calculate productivity

•normalize defects

•project the total defects

•Software size is measured in LOC.

•To accurately relate size to effort, the different types ofLOC in your program are counted separately

•Your principal objective is to measure and estimatethe size of the programs that you produce so that youcan effectively plan and manage your work.

Page 33: The SEI Approach

PSP and measurements•The basic PSP data are

•program size

•time spent by phase

•defects found and injected by phase

•Both actual and estimated data are gathered onevery item.

•Measures derived from these data

•support planning

•characterize process quality.

Page 34: The SEI Approach

PSP and size measurements•The goals of the PSP size measures are to

•Define a consistent size measure

•Establish a basis for normalizing time and defectdata

•Help make better size estimates

•Some of the questions these data can help to answerare

•What size program did I plan to develop?

•How good was my size estimate?

•What was the completed size of the finishedprogram?

Page 35: The SEI Approach

PSP and time measurements•The goals of the PSP time measures are to

•Determine how much time you spend in each PSPphase

•Help you to make better time estimates

•Typical questions these data can help answer are

•How much time did I spend by PSP phase?

•How much time did I plan to spend by PSPphase?

Page 36: The SEI Approach

PSP and defect measurements•The goals of the PSP defect measures are to

•provide a historical baseline of defect data

•understand the numbers and types of defectsinjected

•understand the relative costs of removing defectsin each PSP phase

•Some questions these data can help answer are

•How many defects did I make in each phase?

•How many defects did I remove in each phase?

•How much time did it take to find and fix eachdefect?

Page 37: The SEI Approach

Size Versus Development Effort•The principal requirement: If the size measure is notdirectly related to development cost, it is not worth using.

•There are many possible measures.

•database elements

•lines of code (LOC)

•function points

•pages, screens, scripts, reports

•Pages are often an acceptable measure for documentdevelopment.

•LOC is usually a good measure for developing sourceprograms like Pascal and C++.

•Other possible measures are function points, screens,modules, database elements, and maintenance fixes.

Page 38: The SEI Approach

PSP 1 and PSP 1.1• PSP1 and PSP1.1 focus on personal projectmanagement techniques, introducing size andeffort estimating, schedule planning, andschedule tracking methods.

• The objective of PSP1 is to establish an orderly andrepeatable procedure for developing software sizeestimates.

Page 39: The SEI Approach

The Project Planning Framework

Page 40: The SEI Approach

EstimatingThe advantages of using defined estimating methodsare that you

•have known practices that you can improve

•have a framework for gathering estimating data

•can consistently use historical data to producebalanced estimates

Page 41: The SEI Approach

Estimating with PROBE (I)• The PSP uses the PROBE method to estimate and

plan projects.

• PROBE stands for PROxy Based Estimating.

• PROBE uses proxies to estimate program size anddevelopment time.

• A good proxy will help you to make accurateestimates.

• The size measure should be sensitive to language,design, and development practice.

Page 42: The SEI Approach

Estimating with PROBE (II)• A good proxy should correlate closely to development

costs.

• A good proxy should be easy to visualize early indevelopment.

• It should also be a physical entity that can be measured

• The basic issue

• Good size measures are detailed.

• It is generally hard to visualize product details early in aproject.

• Alternatives

• Wait to estimate until you have the detail.

• Make your best guess.

• Identify a suitable proxy.

Page 43: The SEI Approach

Some proxies• Classes, functions, and procedures

• Product elements

• database elements

• screens, reports, scripts, files

• book chapters

• Correlation with development hours

• Numbers of classes correlates reasonably well.

• Class size correlates very closely.

• Class size can be estimated using historical data.

• The program size estimate is then calculated from thehistorical relationship between total class size and programsize.

Page 44: The SEI Approach

• With a good correlation, calculate program size from therelationship between class size and program size.

• When classes are selected as application entities, they canbe visualized early in development.

• Functions and procedures can often be estimated in thesame way.

• Classes, functions, procedures, and their sizes can beautomatically counted.

• Accurate size estimates will help you to make betterdevelopment plans.

• Estimating skill improves with practice.

• A defined and measured process provides a repeatablebasis for improvement.

• To make accurate estimates, you must use historical dataand follow sound methods.

Some proxies ideas with PROBE

Page 45: The SEI Approach

PROBE resume

Page 46: The SEI Approach

PSP 1.1• The objectives of PSP1.1 are to introduce and practice

methods for making resource and schedule plans

• tracking your performance against these plans

• judging likely project completion dates

• There are two new process elements.

• task planning template

• schedule planning template

• These are typically used for projects that take severaldays or weeks.

• The project plan summary has been expanded toinclude basic process statistics.

Page 47: The SEI Approach

PSP 2 and 2.1• PSP2 and PSP2.1 fold in methods for managing

quality.

• The notion of personal reviews for design and codeare introduced.

• The use of design notation and templates for designare also introduced.

• Importantly, the need for measures to manageprocess and product quality is also addressed

Page 48: The SEI Approach

PSP 2 and 2.1(From Hayes and Over)

“The goal of quality management in the PSP is to find

and remove all defects before the first compile. The

measure associated with this goal is yield. Yield is

defined as the percent of defects injected before

compile that were removed before compile. A yield of

100% occurs when all the defects injected before

compile are removed before compile.”

Page 49: The SEI Approach

PSP 2 and 2.1(From Hayes and Over)

“Starting with PSP2, engineers also begin using the historical

data to plan for quality and control quality during development.

Their goal is to remove all the defects they inject before the first

compile. During planning, they estimate the number of defects

that they will inject and remove in each phase. Then they use the

historical correlation between review rates and yield to plan

effective and efficient reviews. During development, they control

quality by monitoring the actual defects injected and removed

versus planned, and by comparing actual review rates to

established limits (e.g., less than 200 lines of code reviewed per

hour). With sufficient data and practice, engineers are capable of

eliminating 60% to 70% of the defects they inject before their first

compile.”

Page 50: The SEI Approach

PSP 2 (I)• The objectives of PSP2 are to introduce

• design and code reviews

• methods for evaluating and improving the quality ofyour reviews

• PSP2 adds two key capabilities to the PSP

• design and code reviews

• quality planning

• Quality planning involves

• estimating the total number of defects that will be injected

• estimating the number of defects that will be injected andremoved in each process phase

• estimating the amount of time needed for design and codereviews

• adjusting these parameters as needed to ensure a highquality result

Page 51: The SEI Approach

PSP 2 (II)• To estimate the total defects injected and removed, use the

estimated program size and to-date defect density to calculatethe estimated total defects.

• Benchmark data on code review rates can be used to estimatereview time.

• From PSP data, we know that code review rates under 200LOC/hour generally give high yield.

• Using planned added and modified LOC, code review time canbe calculated using this formula

Page 52: The SEI Approach

The PSP Quality Focus (I)• Defects are not important to users, as long as they do not

• affect operations

• cause inconvenience

• cost time or money

• cause loss of confidence in the program’s results

• The defect content of software products must be managedbefore more important quality issues can be addressed.

• Low defect content is an essential prerequisite to a qualitysoftware process.

• Since low defect content can best be achieved where thedefects are injected, engineers should

• remove their own defects

• determine the causes of their defects

• learn to prevent those defects

Page 53: The SEI Approach

The PSP Quality Focus (II)• Improve product quality and accelerate development

work by

• doing reviews and inspections to remove defectsbefore test

• using testing to check product quality, not to removevolumes of defects

• Design and code reviews

• improve the quality of your programs

• save development time

• To do effective reviews, you must

• establish review goals

• follow a disciplined review process

• measure and improve your review practices

Page 54: The SEI Approach

PSP 2.1 (I)

• The objectives of PSP2.1 are to introduce

• additional measures for managing process quality

• design templates that provide an orderlyframework and format for recording designs

• PSP2.1 adds the following process elements:

• PSP2.1 design review script

• PSP2.1 design review checklist

• operational specification template

• functional specification template

• state specification template

• logic specification template

Page 55: The SEI Approach

PSP 2.1 (II)

• Since there is no single best design method, thePSP supports multiple methods.

• The PSP focuses on what a complete design shouldcontain.

• The goal is to eliminate requirements and designdefects.

• The PSP uses design templates to provide

• criteria for design completeness

• reviewable designs

Page 56: The SEI Approach

PSP 2.1 Design Framework

Page 57: The SEI Approach

PSP 2.1 Design Framework

Page 58: The SEI Approach

PSP 2.1 Design Hierarchy

Page 59: The SEI Approach

PSP 2.1 Design

• It is important to separate two issues.

• how to do the design

• how to represent the design when it is completed

• Since the PSP can be used with any design method, itdoes not specify a specific design approach.

• However, the PSP does address design representation.

• Four design templates are used in the PSP to cover thefour design views.

• operational specification template

• functional specification template

• state specification template

• logic specification template

Page 60: The SEI Approach

PSP 3 (I)

• PSP <= 2.1 have focused on basic techniques that willimprove the engineer’s ability and skill to deliver small(up to 2000 lines of code) programs predictably (effort,schedule, and quality).

• PSP3 needs to scale the PSP2 process to deliver thesame rigor and benefits to large systems.

• The strategy here is to subdivide the big system tosmaller programs, which can be managed effectivelyby the PSP2 process. The cyclic process of PSP3works very well for programs between 2000 and20,000 lines of code .

Page 61: The SEI Approach

PSP 3 (II)

• PSP3, Cyclic Personal Process, addresses scalability.

• It is important for students who are learning PSP tobe able to scale upward efficiently from what theyhave learned in the PSP training course to larger,real-life projects, without sacrificing either quality orproductivity.

• PSP3 addresses scalability by decomposing largeprograms into smaller elements, developing them, andthen integrating them. This reduces the developmentproblem to something that is analogous to developingsoftware using methods described in PSP2.1.

Page 62: The SEI Approach

PSP Key

• One important aspect of the PSP is thatimplementing process improvement models,whether it’s the CMMI, ISO 12207, or any othermodel, enables the developers within theorganization to accept the disciplined methodologiesassociated with these standards.

• Once a developer understands the value in his/herown use of disciplined practices as a result of usingPSP, he/she will be more willing to accept thedisciplined practices associated with implementing aprocess improvement model.

Page 63: The SEI Approach

PSP & CMMI levels

Source: www.enel.ucalgary.ca/People/Smith/2011webs/encm511_11/11_Lectures/11_November/ExtraTalk_4Nov2011_PSP.ppt

Level 2Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking and oversight*Software project planning*Requirements management

*PSP key practices

Level 3Peer reviews*Intergroup coordinationSoftware product engineering*Integrated software management*Training programOrganization process definition*Organization process focus*

Level 4Quality management*Process measurement and analysis*

Level 5Process change management*Technology innovation*Defect prevention*

Level 1W. S. Humphrey,

“A Discipline for Software Engineering”, 1995

Page 64: The SEI Approach

TSP – Team Software Process

• The TSP is a framework and a process structurefor building and guiding engineering teams.

• The TSP contains

• a team-building process that builds shared goals,commitments, and cohesion

• a team-working process that guides the team’sengineering processes and practices

Page 65: The SEI Approach

What Does the TSP Do?• The TSP establishes an environment that builds,

develops, uses, and supports self-directedteamwork.

• A self-directed team

• sets its own goals

• establishes its own roles

• decides on its own development strategy

• defines its own processes

• develops its own plans

• measures, manages, and controls its own work

• Self-directed teams are jelled teams and they do thebest work.

Page 66: The SEI Approach

Management Support• Management will agree to you and your team mates

working as a self-directed team as long as you

• strive to meet their needs

• regularly report on your work

• convince them that your plans are sound

• do quality work

• respond to changing needs

• come to them for help when you need it

• While this is not hard for you to do, it takes

• skill

• disciplined work

• guidance and support

Page 67: The SEI Approach

Building Needed Skills• The PSP shows you how to

• measure and manage your personal work

• use data to make sound plans

• manage the quality of your work

• produce quality products on predictableschedules

• With the TSP, you use these skills to convincemanagement to support self-directed teamwork.

Page 68: The SEI Approach

TSP Roadmap Launch

Page 69: The SEI Approach

TSP Structure and Flow

• A TSP launch kicks off each major project phase.

• The team builds a common understanding of thework and the way to do it.

• The members produce plans to guide their work.

• Subsequent phases kick off with a TSP relaunch.

Page 70: The SEI Approach

TSP Launch• The TSP process recognizes that up-front project

planning is performed on the basis of a lot ofunknowns; consequently, the process addressesplanning at four points during the developmentcycle: at project start, at the start of architecturaldesign, at the start of implementation (e.g., coding),and at the start of integration and test.

• The initial point is referred to as the launch, andthe other three points are referred to asrelaunches.

• As with the PSP, there are a number of scripts,forms, and standards that are a part of the TSPprocess.

Page 71: The SEI Approach

TSP Launch

Page 72: The SEI Approach

TSP Launch

Page 73: The SEI Approach

TSP Launchs

• The launch, which is the team-building component ofTSP, consists of nine meetings spread over 4 days.

• It focuses on planning the team’s work and coversthe following topics: establishing product andbusiness goals, assigning roles and establishingteam goals, laying out the development strategy,building top-down and next-phase plans, developingthe quality plan, building bottom-up and consolidatedplans, conducting the risk assessment, preparing thebriefing to management and the launch report,holding a management review, and conducting thelaunch post-mortem.

Page 74: The SEI Approach

TSP Launchs

Page 75: The SEI Approach

Working on a TSP Project

• Once you have management support to launch aTSP team, you need to keep that support.

• This requires that you and your teammates do fivethings.

• Follow the process you have defined.

• Maintain the individual and team plans.

• Manage product quality.

• Regularly track and report your progress.

• Continually demonstrate high performance.

Page 76: The SEI Approach

TSP & CMMI

• TSP might be considered from some perspectivesas a micro-implementation of the CMMI

• TSP complements CMMI implementation by helpingproject and line managers implement the projectmanagement practices contained in the ProjectPlanning, Project Monitoring and Control, IntegratedProject Management, and Risk ManagementProcess Areas.

• It facilitates the team (or teams) being able to hit theground running when the project starts.

Page 77: The SEI Approach

TSP & CMMI Categories

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 78: The SEI Approach

TSP & CMMI Process Mgmnt

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 79: The SEI Approach

TSP & CMMI Project Mgmtn

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 80: The SEI Approach

TSP & CMMI Engineering

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 81: The SEI Approach

TSP & CMMI Support

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 82: The SEI Approach

TSP & CMMI ML 2

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 83: The SEI Approach

TSP & CMMI ML 3

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 84: The SEI Approach

TSP & CMMI ML 4

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 85: The SEI Approach

TSP & CMMI ML 5

Source: Mapping TSP to CMMI. TECHNICAL REPORT CMU/SEI-2004-TR-014 ESC-TR-2004-014. Available in http://www.sei.cmu.edu/reports/04tr014.pdf

Page 86: The SEI Approach

More Info

•CMMI and TSP Resources: http://cmmiinstitute.com/cmmi-getting-started/cmmi-compatibility/cmmi-and-tsp/

•PSP/TSP support tool open-source initiative: http://www.processdash.com/download

Page 87: The SEI Approach

Questions?

Thanks


Recommended