Team Software Process (TSP) Body Of Knowledge (BOK)

1 IntroductionAs the character of engineering technology has changed in the post-industrial revolution, anincreasing proportion of engineered products are actually components of entire systems ofproducts that directly support end-use applications such as driving, flying, or medical diagnosesand treatments. These products and systems must meet critical performance, safety, security,survivability, and usability requirements. Not only must these modern engineering products be ofthe highest possible quality, but they also must meet business-critical schedule and budgetconstraints.Modern engineering work requires teams for work products that are too large or too complex tobe completed by a single engineer. Furthermore, the modern engineering workforce must work inclose cooperation with people who have the variety of domain skills required for the system’sdesign and implementation. This requires a work environment in which people with vastlydifferent skills can work together to produce quality products that meet their functional,architectural, and property requirements. The Personal Software ProcessSM (PSPSM) and TeamSoftware ProcessSM (TSPSM) technologies provide such an environment by proving individualsand teams with a framework for creating or tailoring processes that all members can follow, forcommunicating in a common vocabulary, and for planning and tracking their work using acommonly accepted set of measurements and standards.The PSP is a disciplined and structured approach to developing software that was developed in1993 by Watts S. Humphrey [Humphrey 1995]. By using the PSP concepts and methods in theirwork, individuals in almost any technical field can improve their estimating and planning skills,make commitments that they can meet, manage the quality of their work, and reduce the numberof defects in their products. The TSP was introduced in 1998, and builds upon the foundation ofPSP to enable engineering teams to build software-intensive products more predictably andeffectively [McAndrews 2000].The PSP and TSP technologies are based on the premise that a defined and structured process canimprove individual work quality and efficiency. A process that requires professionals to define,measure, and track their work can help them to better understand what they do, and provide themwith the necessary information to evaluate and learn from their experiences. By developing theirown defined processes within the PSP framework, professionals gain the knowledge andexperience needed to select the methods and practices that are best suited to their particular tasksand abilities. Similarly, the TSP provides teams who are building software-intensive products orsystems with a framework in which individuals can combine their personal process disciplineskills with proven process management techniques that enable them to do high-quality work. Theuse of agreed-upon, well-defined processes also provides teams with a foundation for effectivecollaboration and an environment that facilitates creative and productive work.Implementation of the TSP begins with a launch process in which a coach guides the team andtheir managers through the steps of establishing goals, defining team roles, producing a team plan,assessing risks and devising possible mitigations, and obtaining management approval for the1 CMU/SEI-2010-TR-020

project plan. Following the launch, the team uses the TSP process framework for managing,tracking, and reporting the team's progress against its cost, schedule, and product quality goals.The concepts and methodologies of the PSP and TSP technologies have reached a level ofmaturity sufficient to warrant the development of professional competency measures to assessboth the level of knowledge acquisition and the level of skill in applying that knowledge. At thecore of the process of maturing a profession is the establishment of a body of knowledge (BOK).A body of knowledge is a document generated by master practitioners in a particular profession toidentify and delineate the concepts, facts, and skills that competent professionals in that field areexpected to have mastered. The Institute of Electrical and Electronics Engineers (IEEE) ComputerSociety has established a body of knowledge for the software engineering profession as a whole[IEEE 2004]. The TSP BOK document is meant to complement and build upon that work andupon the PSP BOK [Pomeroy-Huff 2009] by describing the essential skills and knowledgespecific to the TSP methodology for software process improvement.1.1Purpose for the TSP BOKThe TSP BOK was drafted to define the fundamental knowledge and skills that set TSP-trainedindividuals apart from other software professionals. It helps individual practitioners to assess andimprove their own skills, provides employers with an objective baseline for assessing the processimprovement skills and capabilities of their development team members, and guides academicinstitutions that want to incorporate TSP into their software and other engineering courses orcurricula. The TSP BOK also facilitates the development of TSP certification programs that arebased on a well-established standard set of knowledge and skills.The TSP BOK is intended to provide a high-level comprehensive overview of the competenciesthat compose the essential knowledge and skills required for the competent implementation of theTSP as a team member, team leader, coach, or manager of a TSP team. This document is notmeant to provide detailed descriptions or in-depth explanations of the concepts, practices, andprocedures of every component in the TSP. Rather, the purpose of this document is to provide anoverview of the competencies, knowledge areas, and key concepts and skills that constitute theessential knowledge, skills, and abilities of competent TSP practitioners. The main purposes ofthis document are as follows.1. Define the essential knowledge and skills that TSP-trained professionals are expected tomaster2. Characterize the standard practices of TSP-trained professionals3. Delineate the knowledge and skills that set TSP practitioners apart from ordinaryengineering professionals4. Establish a baseline for developing, assessing, and accrediting TSP courses and curriculathroughout academia5. Facilitate the establishment of TSP certification programs that are based on an establishedand agreed-upon standard knowledge and skills set6. Provide employers with a baseline for assessing the skills and capabilities of their productdevelopment team members to identify those areas in which additional training might berequired7. Characterize the disciplined practices used by self-directed TSP team members2 CMU/SEI-2010-TR-020

Another purpose of this document is to define and delineate the baseline knowledge and skill setupon which the Carnegie Mellon Software Engineering Institute (SEI) certification program forthe SEI-Certified TSP Coach is based.Although the TSP BOK is meant to guide the design, development, implementation, andassessment of courses and curricula based in part or in whole on the knowledge and skillsdelineated in it, the TSP BOK is not intended to be a guide for curriculum or course development.Such activities require pedagogical knowledge and expertise outside the domain of this body ofknowledge; therefore, this document is meant to guide only the content – not the methodology –of TSP instruction and training.1.2Sources and InfluencesIn preparing this document, the authors examined a number of reports delineating bodies ofknowledge from other professional disciplines. Of these, three body of knowledge guidebooksprovided guidance and inspiration in terms of structuring the document and depicting thearchitectural hierarchy used to describe the TSP BOK. These guides were IEEE Computer Society’s Guide to the Software Engineering Body of Knowledge(SWEBOK), 2004 Version Project Management Institute’s A Guide to the Project Management Body of Knowledge(PMBOK Guide), Fourth Edition SEI’s Personal Software Process Body of Knowledge (PSP BOK), Version 2.0 (CMU/SEI2009-SR-018)The IEEE SWEBOK 2004 Version and PMBOK Guide were influential in determining thedocument flow and delineation of components used in the description of the TSP BOK. The PSPBOK defines the foundational set of prerequisites, on which rest the additional knowledge andskills needed for effective practice of the TSP methodologies.1.3Document OrganizationThis document is composed of six major sections.1. Section 1 (this portion of the TSP BOK) provides background information, an overview ofthe intended purposes of and audience for this body of knowledge, and the sources andinfluences that affected its development.2. Section 2 summarizes the structure of the hierarchy used to describe the content of the bodyof knowledge and provides operational definitions of terms used in the document.3. Section 3 outlines the competency and knowledge areas that make up the body ofknowledge and delineates the key concepts and skills that make up each knowledge area.4. The fourth portion of the document contains appendices which provide guidelines andsuggestions to TSP team members, project managers, coaches, and team leaders.5. The fifth section provides a list of acronyms commonly used in TSP (and PSP).6. The last section contains complete citations for works referenced in this document. Carnegie Mellon is registered in the U.S. Patent and Trademark Office by Carnegie MellonUniversity.3 CMU/SEI-2010-TR-020

4 CMU/SEI-2010-TR-020

2 TSP BOK Structure and Terminology2.1Structure of the BOKAs with other professional body of knowledge documents, the information contained in the TSPBOK is organized into competency areas, each of which is composed of a group of interrelatedknowledge areas. The knowledge areas, in turn, are composed of concepts and skills, which arethe smallest units of information contained in the body of knowledge. For the purpose of thismodel, the term concept is used to describe the intellectual aspects of the TSP content; that is, theinformation, facts, terminology, and philosophical components of the technology. The term skillrefers to the ability of an individual to interpret and apply one or more concepts to theperformance of a task. In this document, it is assumed that if individuals understand a concept,then they also have the ability to perform the skills related to or founded upon that concept.Competency AreasKnowledge AreasConcepts and SkillsFigure 1: Architectural Hierarchy of the TSP BOK Components2.2Operational Definition of TermsThe TSP BOK uses the following terms to describe the categories of principles and processes itcontains.Competency areaA group of closely-related knowledge areas that a practitioner is wellqualified to perform intellectually or physicallyKnowledge areaThe sum or range of specific understanding and ability gained throughstudy of a set of concepts or through experience with a set of skillsConceptAn explanatory principle applicable to a specific instance or occurrencewithin a particular knowledge areaSkillProficiency, facility, or dexterity of performance that is acquired ordeveloped through training or experience in a particular knowledge are5 CMU/SEI-2010-TR-020

Engineering terms used in the TSP BOK are operationally defined as follows.DesignThe specification and plan for the subsequent implementation ormanufacture of some itemDesign processA standardized set of actions required to produce a designDeveloperA person who designs software and writes the programs; or, anorganization that designs software and produces code as its primarybusiness functionDevelopmentThe process of elaborating a design into a sufficiently detailed form so thatit can be used to produce a quality product that conforms to the intent ofthe designers, as well as the creation of the designed product or system.Software development includes the design of the user interface and theprogram architecture, as well as programming the source code.[http://www.pcmag.com/encyclopedia]EngineerA person who has been trained for and is engaged in professionalengineering workEngineeringThe application of scientific and mathematical principles and methods tothe design, manufacture, operation, and support of structures, machines,products, and systemsPlanning horizonThe portion of the project for which a detailed plan exists. (In this context,“detailed plan” means that the project work has been broken into a logicalsequence of tasks or sub-tasks, with each task or sub-task requiring nomore than 8 to 10 hours for completion.) The length of a planning horizonvaries according to the size of the project: for small or short-term projects,the planning horizon could include the entire scope of the work, whereasthe planning horizon of large or long-term projects covers only the portionof the work that will be completed in the several weeks following a launchor relaunch, or during a particular project phase or cycle.ProfessionalA person who is engaged in an occupation or is a member of a vocationthat requires specialized education and/or training. Professionals areexpected to conform to the technical and ethical standards of the disciplinein which they have attained professional status.QualityThe measurement of the degree or level of excellence of a engineeredsystem, product, or service6 CMU/SEI-2010-TR-020

3 The TSP Body of KnowledgeThe TSP BOK is composed of six competency areas, each with several knowledge areas.Competency Area 1: TSP Foundations and Fundamentals1.1 Knowledge Work1.2 TSP Prerequisite Knowledge1.3 TSP Principles1.4 TSP Process Elements and Measures1.5 TSP Quality PracticesCompetency Area 2: Team Foundations2.1 Teams and Teambuilding2.2 Team Types, Styles, and Dynamics2.3 Team Formation and Membership2.4 Team Member Responsibilities2.5 Team Member Roles2.6 Team Leader Role2.7 Coach RoleCompetency Area 3: Project Planning with TSP3.1 Change Management Fundamentals3.2 Piloting TSP in an Organization3.3 Preparing Management and Teams for TSP Implementation3.4 The TSP Launch Meetings3.5 The TSP RelaunchCompetency Area 4: Project Implementation and Tracking with TSP4.1 Weekly Meetings4.2 Checkpoints4.3 Communicating with Stakeholders4.4 Replanning4.5 Phase, Cycle, and Project PostmortemsCompetency Area 5: Gathering and Using TSP Data5.1 Data Recording5.2 Gathering and using Size Data5.3 Gathering and Using Schedule Data5.4 Gathering and Using Quality Data5.5 Gathering and Analyzing Postmortem DataCompetency Area 6: Scaling Up the TSP6.1 Organizational Implementation6.2 TSP Process Variations6.3 Large-scale TSP Teams7 CMU/SEI-2010-TR-020

The remainder of this section contains a description of each competency area, its supportingknowledge areas, and the key concepts composing each knowledge area. This information is notmeant to provide detailed descriptions of every concept, element, or practice that makes up theTeam Software Process methodology; rather, this BOK is meant to provide a high-leveloverview of the areas in which a competent practitioner of the TSP is expected to be proficient.8 CMU/SEI-2010-TR-020

Competency Area 1: TSP Foundations and FundamentalsThis competency area outlines the foundational knowledge on which TSP is built and describesthe fundamental concepts that a TSP practitioner must understand in order to successfullyimplement and practice the TSP methodology. The knowledge areas composing the TSPFoundations and Fundamentals competency area are as follows.1.1 Knowledge Work – PSP and TSP are practices designed to facilitate and improve both theprocess and the outputs of knowledge work, which is the interpretation, development, andimplementation of information by skilled professionals within a specific subject area. Thisknowledge area discusses the nature of knowledge work and the team and workplacecharacteristics required for such work.1.2 TSP Prerequisite Knowledge – This knowledge area outlines the fundamental concepts andskills that individuals must master before implementing the TSP methodology as a memberof a TSP team. Although this area calls out some of the specific Knowledge Areas of thePSP BOK, the PSP BOK in its entirety is considered to be prerequisite knowledge forimplementing the TSP in practice.1.3 TSP Principles – This knowledge area outlines the basic principles underlying theTeam Software Process. The key concepts identify the elements that are common to andrequired for successful outcomes of work done by teams to produce software productsand/or software-intensive systems.1.4 TSP Process Elements and Measures – This knowledge area describes the processelements and measures that are used in the TSP. (Where applicable, overlaps with ordifferences from PSP process elements and measures are noted.)1.5 TSP Quality Practices – This knowledge area describes the specific quality practices addedin the TSP to build on the individual quality practices used by PSP practitioners.References: The material covered in this competency area is detailed in these primary sources.[Humphrey 1995, Chapters 1, 11, Appendix A, Appendix C][Humphrey 1999, Chapters 1 and 6][Humphrey 2005, Chapters 2, 6, 13][Pomeroy-Huff 2009, in its entirety]Knowledge Area 1.1: Knowledge WorkPSP and TSP are practices designed to facilitate and improve both the process and the outputs ofknowledge work, which is the interpretation, development, and implementation of information byskilled professionals within a specific subject area [Drucker 1999]. This knowledge area discussesthe nature of knowledge work and the team and workplace characteristics required for such work.1.1.1 Characteristics of knowledge workSoftware and systems engineering work is considered to be knowledge work because the nature ofthe tasks required to create the final products is largely intellectual. Knowledge work differs fromtraditional product development work in the following ways.9 CMU/SEI-2010-TR-020

The quality, cost, and schedule performance of such work is largely determined by themotivation, skill, and discipline of the workers, rather than the cost of the raw materials andlabor or the efficiency of manual work processes. Knowledge work consists largely of converting information from one form to another;therefore, the results of a knowledge work process are frequently intangible and maytherefore be hard to measure or assess [Kidd 1994]. The suitability of knowledge workers’ products generally cannot be determined exceptthrough extensive final use or by rigorous examination by other adept and knowledgeableknowledge workers.1.1.2 Characteristics of knowledge workersThe fundamental characteristic that sets knowledge workers apart from other types of productionworkers is ownership: in traditional manufacturing, the employer (or organization) owns both theassets required to produce the end product and the product itself; in knowledge work, the workersown the assets and retain at least partial ownership of the end product, even if the product isconsidered the “intellectual property” of the employer [Drucker 1999].Other characteristics unique to knowledge workers are as follows. All knowledge workers (even those in the same field) are different from one another, so nosingle generic process can be developed to manage all knowledg

3 The TSP Body of Knowledge 7 Competency Area 1: TSP Foundations and Fundamentals 9 Knowledge Area 1.1: Knowledge Work 9 Knowledge Area 1.2: TSP Prerequisite Knowledge 12 Knowledge Area 1.3: TSP Principles 14 Knowledge Area 1.4: TSP Process Elements and Measures 15 Knowledge Area 1.5: TSP Quality Practices 17