Team software process

Last updated

In combination with the personal software process (PSP), the team software process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software for products that range in size from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code. The TSP is intended to improve the levels of quality and productivity of a team's software development project, in order to help them better meet the cost and schedule commitments of developing a software system. [1] [2] [3] [4]

Contents

The initial version of the TSP was developed and piloted by Watts Humphrey in the late 1990s [5] and the Technical Report [6] for TSP sponsored by the U.S. Department of Defense was published in November 2000. The book by Watts Humphrey, [7] Introduction to the Team Software Process, presents a view of the TSP intended for use in academic settings, that focuses on the process of building a software production team, establishing team goals, distributing team roles, and other teamwork-related activities.

Introduction to TSP

The primary goal of TSP is to create a team environment for establishing and maintaining a self-directed team, and supporting disciplined individual work as a base of PSP framework. Self-directed team means that the team manages itself, plans and tracks their work, manages the quality of their work, and works proactively to meet team goals. TSP has two principal components: team-building and team-working. Team-building is a process that defines roles for each team member and sets up teamwork through TSP launch and periodical relaunch. Team-working is a process that deals with engineering processes and practices utilized by the team. TSP, in short, provides engineers and managers with a way that establishes and manages their team to produce the high-quality software on schedule and budget.

How TSP works

Before engineers can participate in the TSP, it is required that they have already learned about the PSP, so that the TSP can work effectively. Training is also required for other team members, the team lead and management. The TSP software development cycle begins with a planning process called the launch, led by a coach who has been specially trained, and is either certified or provisional. [8] [9] The launch is designed to begin the team building process, and during this time teams and managers establish goals, define team roles, assess risks, estimate effort, allocate tasks, and produce a team plan. During an execution phase, developers track planned and actual effort, schedule, and defects meeting regularly (usually weekly) to report status and revise plans. A development cycle ends with a Post Mortem to assess performance, revise planning parameters, and capture lessons learned for process improvement.

The coach role focuses on supporting the team and the individuals on the team as the process expert while being independent of direct project management responsibility. [10] [11] The team leader role is different from the coach role in that, team leaders are responsible to management for products and project outcomes while the coach is responsible for developing individual and team performance. [12] [13]

Latest developments

TSP has been adapted to work with other types of knowledge work, including systems engineering [14] and services. [15] [16]

Mapping TSP to Capability Maturity Model Integrated (CMMI) practices was documented in 2010, [17] and piloted as an alternative path to implement CMMI process improvement. [18] [19] A body of knowledge (BOK) was issued in 2010. [20] The coach mentor program guidebook was released in 2010. [21]

According to a study by Capers Jones TSP is one of the most successful development methodologies regarding schedule, quality and budget (TCO) [22]

Publications

See also

Related Research Articles

The Capability Maturity Model (CMM) is a development model created in 1986 after a study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.

<span class="mw-page-title-main">Software Engineering Institute</span> Federally funded research center in Pittsburgh, Pennsylvania, United States

Software Engineering Institute (SEI) is a federally funded research and development center in Pittsburgh, Pennsylvania, United States. Founded in 1984, the institute is now sponsored by the United States Department of Defense and the Office of the Under Secretary of Defense for Research and Engineering, and administrated by Carnegie Mellon University. The activities of the institute cover cybersecurity, software assurance, software engineering and acquisition, and component capabilities critical to the United States Department of Defense.

The following outline is provided as an overview of and topical guide to software engineering:

Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the code's author. The persons performing the checking, excluding the author, are called "reviewers".

Watts S. Humphrey was an American pioneer in software engineering who was called the "father of software quality."

In software development, agile practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), adaptive planning, evolutionary development, early delivery, continual improvement, and flexible responses to changes in requirements, capacity, and understanding of the problems to be solved. Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

The Personal Software Process (PSP) is a structured software development process that is designed to help software engineers better understand and improve their performance by bringing discipline to the way they develop software and tracking their predicted and actual development of the code. It clearly shows developers how to manage the quality of their products, how to make a sound plan, and how to make commitments. It also offers them the data to justify their plans. They can evaluate their work and suggest improvement direction by analyzing and reviewing development time, defects, and size data. The PSP was created by Watts Humphrey to apply the underlying principles of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) to the software development practices of a single developer. It claims to give software engineers the process skills necessary to work on a team software process (TSP) team.

Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. Version 2.0 was published in 2018. CMMI is registered in the U.S. Patent and Trademark Office by CMU.

Quality management ensures that an organization, product or service consistently functions well. It has four main components: quality planning, quality assurance, quality control and quality improvement. Quality management is focused not only on product and service quality, but also on the means to achieve it. Quality management, therefore, uses quality assurance and control of processes as well as products to achieve more consistent quality. Quality control is also part of quality management. What a customer wants and is willing to pay for it, determines quality. It is a written or unwritten commitment to a known or unknown consumer in the market. Quality can be defined as how well the product performs its intended function.

A subject-matter expert (SME) is a person who has accumulated great knowledge in a particular field or topic and this level of knowledge is demonstrated by the person's degree, licensure, and/or through years of professional experience with the subject, i.e. a PhD in chemistry could be easily declared as a SME in chemistry, or a person with a Second Class Radio Telegraph License issued by the national licensing body could be considered a SME in radio telegraph. A person with a master's degree in electronic engineering could be considered a subject-matter expert in electronics, or a person with many years of experience in machining could be considered a SME in machining.

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome should conform.

Richard Turner is a distinguished service professor in the School of Systems and Enterprises of Stevens Institute of Technology in Hoboken, New Jersey.

The cleanroom software engineering process is a software development process intended to produce software with a certifiable level of reliability. The central principles are software development based on formal methods, incremental implementation under statistical quality control, and statistically sound testing.

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the official Software Engineering Institute (SEI) method to provide benchmark-quality ratings relative to Capability Maturity Model Integration (CMMI) models. SCAMPI appraisals are used to identify strengths and weaknesses of current processes, reveal development/acquisition risks, and determine capability and maturity level ratings. They are mostly used either as part of a process improvement program or for rating prospective suppliers. The method defines the appraisal process as consisting of preparation; on-site activities; preliminary observations, findings, and ratings; final reporting; and follow-on activities.

Software quality management (SQM) is a management process that aims to develop and manage the quality of software in such a way so as to best ensure that the product meets the quality standards expected by the customer while also meeting any necessary regulatory and developer requirements, if any. Software quality managers require software to be tested before it is released to the market, and they do this using a cyclical process-based quality assessment in order to reveal and fix bugs before release. Their job is not only to ensure their software is in good shape for the consumer but also to encourage a culture of quality throughout the enterprise.

LeanCMMI is an approach to software engineering process improvement that integrates agile computing methods with process design and deployment for organization's wishing to improve software engineering capability and achieve a maturity level two or three rating based upon the Software Engineering Institute's Capability Maturity Model Integration (CMMI).

Proxy-Based Estimating (PROBE) is an estimating process used in the Personal Software Process (PSP) to estimate size and effort.

Bill Curtis is a software engineer best known for leading the development of the Capability Maturity Model and the People CMM in the Software Engineering Institute at Carnegie Mellon University, and for championing the spread of software process improvement and software measurement globally. In 2007 he was elected a Fellow of the Institute of Electrical and Electronics Engineers (IEEE) for his contributions to software process improvement and measurement. He was named to the 2022 class of ACM Fellows, "for contributions to software process, software measurement, and human factors in software engineering".

References

  1. ↑ Jones, Capers (2009). Software Engineering Best Practices. McGraw-Hill. p. 11. ISBN   9780071621618.
  2. ↑ Kindler, Nosh B; Krishnakanthan, Vasantha; Tinaikar, Ranjit. Applying Lean to Application Development. McKinsey Quarterly, May 2007
  3. ↑ "Agile Capital Consulting". Archived from the original on February 3, 2018. Retrieved July 3, 2017.
  4. ↑ Ker, J. I., Wang, Y., Hajli, M. N., Song, J., & Ker, C. W. (2014). "Deploying lean in healthcare: Evaluating information technology effectiveness in US hospital pharmacies". International Journal of Information Management, 34(4), 556–560.
  5. ↑ McAndrews, Donald (1998). "The Team Software ProcessSM (TSPSM): An Overview and Preliminary Results of Using Disciplined Practices".{{cite journal}}: Cite journal requires |journal= (help)
  6. ↑ Humphrey, Watts. "The Team Software Process" (PDF). Software Engineering Institute.
  7. ↑ Humphrey, Watts (1999). Introduction to the Team Software Process. Addison Wesley.
  8. ↑ Humphrey, Watts (2018). "The Team Software Process Body of Knowledge". Software Engineering Institute. doi:10.1184/R1/6584825.v1.{{cite journal}}: Cite journal requires |journal= (help)
  9. ↑ Chick, Timothy (2010). "Team Software Process (TSP) Coach Mentoring Program Guidebook Version 1.1". Software Engineering Institute. doi:10.1184/R1/6584810.v1.{{cite journal}}: Cite journal requires |journal= (help)
  10. ↑ Humphrey, Watts (2018). "The Team Software Process Body of Knowledge". Software Engineering Institute. doi:10.1184/R1/6584825.v1.{{cite journal}}: Cite journal requires |journal= (help)
  11. ↑ Humphrey, Watts (2005). TSP: Coaching Development Teams. Addison Wesley.
  12. ↑ Humphrey, Watts (2018). "The Team Software Process Body of Knowledge". Software Engineering Institute. doi:10.1184/R1/6584825.v1.{{cite journal}}: Cite journal requires |journal= (help)
  13. ↑ Humphrey, Watts (2005). TSP: Coaching Development Teams. Addison Wesley.
  14. ↑ Carleton, Anita. "Extending Team Software Process (TSP) to Systems Engineering: A NAVAIR Experience Report" (PDF). Software Engineering Institute.
  15. ↑ Battle, Ed. "Leading & Learning – Using TSP at the MSG Level" (PDF). Naval Oceanographic Office.
  16. ↑ "Software consulting: How to make sure the software consulting company you are looking for is reliable" . Retrieved 23 April 2019.
  17. ↑ James McHale; Timothy A. Chick; Eugene Miluk (December 2010). "Implementation Guidance for the Accelerated Improvement Method (AIM)" (PDF). Software Engineering Institute. Retrieved October 11, 2016.
  18. ↑ Webb, David (April 2007). "CMMI Level 5 and the Team Software Process" (PDF). Cross Talk. Archived from the original on October 9, 2012.
  19. ↑ Mondragon, Oscar. "AIM Case Study" (PDF). Software Engineering Excellence Center.
  20. ↑ Humphrey, Watts (2018). "The Team Software Process Body of Knowledge". Software Engineering Institute. doi:10.1184/R1/6584825.v1.{{cite journal}}: Cite journal requires |journal= (help)
  21. ↑ Chick, Timothy (2010). "Team Software Process (TSP) Coach Mentoring Program Guidebook Version 1.1". Software Engineering Institute. doi:10.1184/R1/6584810.v1.{{cite journal}}: Cite journal requires |journal= (help)
  22. ↑ Jones, Capers (2013). "Evaluating ten software development methodologies". Archived from the original on 29 June 2013.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.