St. Petersburg, FL

September 17-20, 2012

Abstracts

Exploring TSP: An Introduction

James McHale and Mark Kasunic, Software Engineering Institute

In the current economy, organizations are looking for ways to maximize their return on investment. Capers Jones has rated TSP as one of the top methods across small, medium, and large software projects for improving cost, schedule, and quality performance in software development organizations.

Industry data has quantitatively demonstrated that using TSP significantly improves a team's overall performance. This one-day tutorial provides an overview of the core TSP concepts and principles and provides the foundation needed to begin to introduce and apply TSP in your organization.

Key topics include

  • the concepts on which the TSP is built
  • how the TSP improves software development activities and provides positive motivation for engineers and project team
  • how to use the TSP to address current and future software needs
  • how to successfully introduce and maintain TSP
  • what management must do to help their teams be successful

Navigating your Quality Journey: How to Engineer Exceptional Quality Software

Timothy Chick and Gene Miluk, Software Engineering Institute

Watts Humphrey once said, "if you don't know where you are, a map won't help." This statement describes a very frustrating situation: you know where you would like to be, however you don't know how to navigate a course to get there. This is the circumstance many individuals, teams, projects, and organizations face: they know they need better quality but don't know how to get there.

One popular approach is to just pick some quality methods and techniques and hope they lead you to the performance you need. Fortunately, there is a much better way. This tutorial will describe how the Team Software Process, a comprehensive, proven methodology, can dramatically improve your software quality capabilities.

The first step in addressing quality is to understand that it is not a destination, but a set of capabilities and stages of development. Each individual, team, and project within an organization can be operating at different stages on the path to producing high-value, high-quality products and services. By identifying on what quality level people are currently operating, and understanding the associated root cause issues, you can pick the most effective direction to take to get to the next stage and avoid costly dead-ends and wrong turns.

This tutorial will take a deeper look into the eight stages of development in the quality journey using TSP. The presenters will describe each stage, identify their differences, and discuss techniques used to improve software quality. This tutorial goes beyond a theoretical presentation; the tools and techniques presented have been rigorously field tested and validated. Data and experience will be shared from organizations who use TSP and are benefitting from these concepts.

Leading a Development Team Pilot for IT Project Management Master's Degree Students

Valentina Ivanova, New Bulgarian University (NBU)

This presentation introduces the Software Engineering Management Program (SEMP) in Bulgaria. The program is a partnership between world leaders in software engineering and technology and the leading Bulgarian universities in Informatics and Computer Science, managed by ESI Center Bulgaria and funded by the America for Bulgaria Foundation. The presentation will discuss the IT Project Management master's degree program, at New Bulgarian University (NBU) and the considerations to add SEI professional courses Leading a Development Team, PSP Fundamentals, and PSP Advanced to the academic curriculum.

The presentation will focus on the pilot course Leading a Development Team as a first step to introducing PSP to IT Project Management master's degree students, the presenter's classroom experience, and the students' professional background and expectations. The presenter will cover the topics that were most challenging to introduce and what concepts the students found difficult to understand and embrace.

The presentation will include final course feedback, conclusions about differences between academic and professional learners, and questions concerning the academic classroom experience. The goal of the presentation is to start a professional discussion in the community about improvement proposals to face academic challenges associated with TSP.

Why Does Agile Software Development Not Require the TSP Disciplines?

Yoshihiro Akiyama, Next Process Institute Ltd.

As a modern software project needs to quickly deliver a large software product of very high quality with a specified cost, the applicability of agility must be improved. The Agile Manifesto provides a full set of the statements which characterize an agile method. However, perhaps because the Manifesto's principles are at a very high level rather than operational, an agile team often finds itself in a catastrophic situation.

This presentation discusses why the TSP disciplines are necessary to make agile more operational, based on these two key principles:

  1. separation of the process of developing a solution from the process of searching or finding a solution
  2. prediction capability at any time during a project

The first principle is important for agile knowledge workers. Effective agile workers always try to separate and define the two types of processes elements. It is observed often that a team that violates this principle encounters many problems in delivery, cost, and quality management. The PSP and TSP processes always encourage separating the two types of process elements. The second principle is leading a team to the best team performance, which is determined at a project end by knowing that everything done during the project contributed to the best result. The measurement framework is necessary for this principle. In addition, the agility needs to be supported by every engineer and team lead following the two principles in their actual project or work. This presentation discusses how this support is accomplished by the TSP.

TSP as the Next Step for Scrum Teams

Noopur Davis and Darryl Davis, Davis Systems

Lately, we have been encountering the following situation: we train and coach a Scrum team, and after a few sprints, the team members start asking these types of questions:

  1. How can we improve estimation? Velocity is fine, but we want to know more about our estimation process. What types of stories are hardest to estimate? How do we know if a story estimated as a 5-point story actually turned out to be a 5-point story?
  2. We are doing unit-tests with high level of code coverage. We are statically assuring our code. We have automated functional tests and streamlined regression tests. We are happy with the progress we have made, but want to improve quality even more. What can we do?
  3. We can't always directly implement user stories: some intermediate steps could help, such as a little bit of design, or a few use cases, or some requirements specifications. How can we do this, without becoming too heavy in our processes?

When we start hearing questions like this, our first reaction is "I am so glad I know TSP!" Then, we work with the teams to slowly (and only when appropriate) start introducing some TSP practices. We have found that teams who are successful with Scrum and want to continue improvement can add these practices incrementally to their work, and seem to have much less resistance to change.

We will share our experiences introducing TSP practices to Scrum teams, and discuss adoption implications for TSP. With Scrum practices forming a basic subset of TSP practices, Scrum can serve as an incremental step toward the higher discipline of TSP.

Using the TSP at the End of the Development Cycle

Scott Van Eps and Rick Marshall, Beckman Coulter

Your project is in final test, but defect rates are not declining and the ship date remains completely uncertain. Team morale is low as it sees a death march of fix and test in its future. You have heard from other project managers how the TSP is being used on their projects and have seen early success. However, TSP principles are typically applied throughout the entire software development process, so you are uncertain of its benefits if applied at the end of a project. Running out of options, what is a project manager to do?

Faced with such a project, we contacted the SEI and developed a pilot project to incorporate the TSP during final test. We implemented various quality and management techniques along with TSP principles to plan and track progress. In the end, we were able to ship within 5% of the planned completion date over a 13 month schedule with very high quality. This is the story of our journey with the SEI, the development team and management. We will share how we were able to incorporate the TSP during final test to plan and recover a struggling project.

Combining a Formal Method and PSP for Improving Software Process: An Initial Report

Shigeru Kusakabe, Kyushu University

This presentation explores the idea that formal methods/ disciplined processes and TSP/PSP can be a powerful combination to efficiently realize high-quality software development. This combination can draw out the effectiveness of both TSP/PSP and formal methods. The presentation includes initial trial on introducing a formal method, Vienna Development Method, (VDM) into PSP.

Formal methods are effective in increasing our confidence in specifications and designs and decreasing defects in the development phases. However, formal methods are not widely used in actual projects. One of the major reasons seems to be that many managers and developers are unsure of what kind of formal methods are useful for them. Even if they select a specific method, they have no idea when and where to use the formal method, and whether it is cost-effective or not. The presenters discuss their belief that disciplined software processes like TSP/PSP can change this situation.

In the trial, students completed course material for PSP 0 and PSP 1 that was published online and wrote the interim report based on the analysis of their process data. They used the process data as a baseline and used the analysis results for the baseline as the clue to improve their process with VDM. In VDM, we use formal specification languages such as VDM++ at different abstraction levels. We can develop high-level design and detailed design in a lightweight way, without rigorous proof. We can use the VDMTools to syntax and type-check the specification. In addition, we can execute our specifications if they are written as explicit executable ones.

After planning the way to improve process with VDM, students tried PSP 2. According to the process data so far, they spent more time in design and less in test. They successfully reduced the number of defects they had focused on without decreasing their productivity. They had an impression that without a disciplined process like PSP, they could not have made a process improvement plan with formal methods. The presenters share a plan to extend their approach to TSP in future work.

Coaching a Winning Team

Dan Wall, The Wall Group

In many sports the top coaches are becoming as well-known as their players. While there is little difference in these coaches' technical knowledge of the game, the information they have access to, and the rules to which they must follow, often what differentiates the best comes down to their ability to be an effective teacher of what it takes to "move the ball" in the process of creating a winning organization.

TSP coaches play a very similar role. This session will review some of the practices and principles that top sports coaches use to teach and motivate their athletes to perform at their highest levels and explain how you can use the same techniques for your teams. TSP coaches and team leaders who adapt these ideas can improve the performance of team members and increase the team's ability to succeed.

The TSP Initiative in Colombia: Strategies for Adoption and Plans for the Future

Yuri Ontibon, SEONTI

During 2011 more than 1,000 people in Colombia were trained in the TSP/PSP practices. In 2012, a project began to start 16 TSP projects supported by TSP Certified Coaches and there are also plans to offer 1,000 PSP courses and to certify more than 500 people as PSP Developers around the country.

These efforts are part of the Colombian government policy of competitiveness based on the productive transformation of the economy. One of the goals is to position the Colombian Information and Communications Technology (ICT) industry as one of the three leading countries in Latin America by 2019.

The current projects has been supported by a number of institutions including Fedesoft (Colombian Federation of Software Companies), SENA (a government institution dedicated to promote the technical development of Colombian work force), and the Ministry of Information Technologies and Communications (MinTIC). The projects have garnereda strong and enthusiastic commitment and sponsorship from participating companies in the private sector.

The next phases of the initiative include performing more TSP pilot projects in the companies that have TSP/PSP training, as well as training PSP Instructors and TSP Coaches to support the full implementation in the companies. Future actions will also include introducing CMMI-DEV into some of those companies.

This presentation shares details of Colombian TSP Initiative, including the strategy for TSP adoption how TSP was selected as the main component of the strategy, the key members of the initiative, the current state of the effort, and the planned next steps.

Integrating Model-Driven Engineering Techniques in the Personal Software Process

João Faria, Faculty of Engineering, University of Porto

The PSP provides a set of specification templates for completely and precisely recording reviewable software designs covering important design views. On the other hand, the Unified Modeling Language (UML) is a standard visual notation for representing object-oriented software designs. Especially when enriched with contracts specified in the Object Constraint Language (OCL) and algorithms described in an action semantics compliant language, UML diagrams provide a convenient and widely accepted means for recording essentially the same information that can be recorded in the PSP design specification templates. Furthermore, the time invested in creating and updating UML models can be recovered and their quality can be objectively evaluated by employing model-driven engineering (MDE) techniques, i.e., the automatic generation of subsequent lifecycle artifacts from models. Since the level of detail of the models needed to generate complete applications is often too high or only effective for specific domains, we advocate a lightweight MDE approach that combines partial code generation from structural/static models with automatic test generation from partial behavioral/dynamic models.

To demonstrate the approach, we developed a plug-in that adds to the code generation capabilities of an existing modeling tool, the capability of generating executable unit tests from parameterized sequence diagrams acting also as test specifications. This way, test specification is effectively embedded in the design phase. The tool also checks model consistency and completeness.

In this talk, we will present the mapping of PSP specification templates to UML artifacts, the automatic generation of production code and executable tests from the UML artifacts, refinements to the PSP process scripts and some preliminary performance results.

Excellence: Methodology Assists, Discipline Delivers

David Ratnaraj, Advanced Information Services Inc.

Advanced Information Services (AIS) is a strong CMMI Maturity Level 5 company that has consistently produced high-quality results for multiple years. AIS' history shows that TSP/PSP processes integrated with CMMI produce consistent and high-quality results. These processes provide a strong platform for all new AIS development projects.

Excellence lies in consistently delivering high-quality products in a timely manner and achieving customer satisfaction. This presentation focuses on a project scaling up existing processes, integrating a large number of new team members, and the challenges and lessons learned in successfully delivering the project ahead of schedule with high quality, achieving excellence.

The team delivered the project, with more than 550 KLOC delivered into production in ~100 weeks, one week ahead of schedule with very high quality, as evidenced by zero cyber-security vulnerabilities in the code and defect density of 0.097 defects/KLOC in production usage. Customer feedback indicated that the team exceeded customer's expectations for schedule, quality, and value. The team's continued success has been primarily due to using well defined processes and a disciplined approach in following them. Large teams could quickly head towards failure if not for these two critical elements.

The presentation will conclude with recommendations for scaling up processes for larger projects and approaches to ensure discipline in work developed by new and experienced developers.

Analysis of Code Defect Injection and Removal in PSP

William Nichols, Software Engineering Institute
Diego Vallespir, Universidad de la República

Defects are the primary source of rework during software development. Late rework often consumes 40 percent or more of project duration and resources. By examining all defects injected and removed during development projects, we may learn how to prevent or remove defects at lower cost. The Personal Software Process (PSP) course provides a rich source of data describing developer effort and defects in a rigorously measured environment.

In this report, the authors examine defects injected in the coding phase and later removed by developers using the full PSP2.1 process. The authors report the frequency of defect injections by type, the removal cost by type, and the phases in which defects of a given type are removed. Because the PSP process begins at detailed design and ends at unit test, some results may not generalize to a production development environment. Nonetheless, the authors report that defects found in the unit test are seven times more expensive to remove than those found earlier in development, that approximately a quarter of all injections escape into the unit test, and that escapes are dominated by defects that may have resulted from designing during the coding phase.

Using TSP to Improve an Organization

Lana Cagle, Naval Oceanographic Office

The Systems Integration Division of the Naval Oceanographic Office (NAVOCEANO) has been using the TSP for more than a decade and it is the organization's standard approach for initiating and executing work. The TSP, or its principles, is applied to every type of work in the division, including chartering a team that manages the engineering lab, establishing teams to enhance a fleet application, developing software requirements, implementing a strategic initiative, filling an improvement gap, providing an engineering solution, or developing a strategic plan. As the division has matured, it has become more productive, less reactive, and more disciplined.

Having a common framework and language has proven useful in developing team leaders and team members, and accelerating the integration of new hires. It has helped the division align its goals and objectives so each work group is moving in the same direction. It has enabled transparency across the division and allowed the sharing of lessons learned as well as historical data.

Another indication of success is that the division is now being asked to assist in broadening the adoption of TSP to other divisions within NAVOCEANO. This presentation will discuss our journey using the TSP to change a culture within the government as well as provide an update on its transition to the larger organization. The key ingredients of success will be summarized as well as the new insights that are being applied to the larger transition the second go around. As TSP matures, we are learning how to apply the TSP principles to other forms of knowledge work throughout the organization.

Taking the "Software" Out of TSP

Jason Huibregtse, CGI Federal

It may be called the Team Software Process (TSP), but that doesn't mean that the TSP has to be limited only to software teams. It can also be a useful tool for non-software teams that support the software development process, including TSP coaches. This presentation will focus on how TSP can be successfully implemented within a software process group to support the day-to-day operations of software teams and how it can be used to plan, track, and support organizational process improvement events, such as developing, deploying, and training organizational policies; conducting performance analysis events; and piloting improvement proposals. In addition, we will discuss how our coaches plan and track their coaching activities using TSP.

The presentation will be accompanied by real data from our process group and TSP coaches and we will share the results of our process improvement events as our organization worked toward CMMI Maturity Level 3. Many questions will be answered such as "why did we chose TSP for our process group?", "what changes were made for a non-software team?", and "what lessons did we learn along the way?" In the end, we think everyone will agree: you CAN take the "Software" out of TSP.

CMMI, Security, and Architecture: Using TSP With Other Technologies

James McHale, Software Engineering Institute

TSP is often used in combination with other process-related technologies, even if those technologies don't want to admit to being process-related.This interactive session details some of the history of TSP usage with other technologies, including but not exclusively SEI technologies like CMMI, security practices, and architecture practices. Attendees at this session should gain an appreciation of some the challenges as well as the potential rewards of such combinations.

PSPDC: An Adaptation of the PSP to Incorporate Verified Design by Contract

Diego Vallespir, Universidad de la República

The Personal Software Process (PSP) applies process discipline and quantitative management to the individual work of software professionals. This process promotes improvement of the quality of the product and an increase in the individual's productivity. On the other hand, formal methods also promote quality improvement, requiring the production of clear, concise and unambiguous specifications which in turn enable the development of zero-fault implementations.

In Design by Contract (DbC), the contracts (pre and post conditions) of each method and the invariant of each class are specified in a formal specification language. In our work we want to use DbC within the framework of the PSP in order to get even better quality products. We therefore present an adaptation of the PSP that incorporates DbC. We call this new process PSPDC. The PSPDC incorporates new phases and modifies existing ones. In particular, there is a Formal Specification phase, during which the pre and post conditions of the designed methods and the invariant of each class are written using a formal language. Then there is a phase of review of the specification in order to prevent defects injected during the formal specification phase from escaping to later phases and therefore increasing the cost of their correction. Following the codification phase, we propose a compilation and proof phase which must produce a formally verified program. In this article we present the most relevant characteristics of the PSPDC: new phases of the process, new scripts, new forms, new checklists, and a classification of defects for formal specifications.

We conclude that it is possible to use DbC within the framework of the PSP, although the process has to be adjusted. We hope this adaptation will take the quality of software programs developed by an individual to new heights and that it will have a positive impact on their maintainability.

What is TSP Organizational Performance Evaluation?

William Nichols, Software Engineering Institute

This SEI interactive session will preview the TSP Organizational Performance Evaluation, a new approach to evaluating process and performance that emphasizes reliance on TSP data. This session will cover topics like

  • Why evaluate?
  • What the results look like
  • How the review is conducted
  • Howto apply
  • How to prepare

Attendees should come prepared with questions to ask and opinions to share regarding the TSP Organizational Performance Evaluation.

TSP and Deliberate Practice as Tools for Improved Capability in the Workforce

Marsha Pomeroy-Huff, Software Engineering Institute

The best practitioners in any field are those who engage in "deliberate practice," a methodology whereby individuals consistently use challenging and measurable performance objectives in combination with specific and quantifiable feedback in order to make incremental performance refinements. Individuals learn to think consciously about the tasks they perform, shifting their objective from getting the job done to doing every part of the job better. Successful implementation of deliberate practice is hard mental work that requires mindful attention to perfecting the many steps and processes of the components comprising masterful/expert performance in a chosen domain.

The specific methodologies and conceptual foundations on which Team Software Process (TSP) practices are built have much in common with the elements that researchers have identified as being the critical factors that differentiate deliberate practice from ordinary practice. The same techniques used by expert performers in chess, medicine, sports, and the arts can be employed in the workplace to produce high-quality software. When TSP practitioners internalize the skills used in producing high-quality software, they develop good work habits that, over time, become almost automatic behaviors. Individuals who have successfully integrated excellence into their everyday work are more agile, produce better results, and are generally more creative than their competent-but-ordinary peers.

This presentation will describe deliberate practice and map its elements to those of the TSP. It will examine the underlying psychological and neurochemical factors that explain how and why deliberate practice (à la TSP) enables enhanced performance capability at the individual and team levels. It will also outline the environmental and cultural changes required for successful implementation of TSP across an organization, as well as a few of the benefits realizable from consistent use of TSP in the workplace.

A Virtual Safari of Nedbank's TSP Centre-of-Excellence

John Bourhill, Nedbank
Barru Dwolatzky, Johannesburg Centre for Software Engineering

To survive, Southern Africa needs to develop and nurture professional, flexible, knowledgeable, and competent software developers. To thrive, we must systematically grow and nurture our talent and play to our strengths.

Nedbank is one of the four top banks operating in South Africa, and Nedbank Group Technology develops or acquires, maintains, and supports all the software requirements of the organization. To grow the business, we need a robust, flexible IT architecture, coupled with optimized IT spending and reduced time to market. To achieve this, we need to strengthen business collaboration, improve service delivery capacity and capability, and standardize delivery processes.

Previous attempts to formalize and standardize the software development lifecycle with CMMI were met with mixed results. However, it introduced a process culture foundation upon which we can expand. Following a successful TSP pilot, the TSP Centre-of-Excellence was formed to accelerate a TSP roll-out. Coaches have been trained and certified to support TSP fidelity and discipline within the organization.

There has been significant success in efforts to reduce production defects and, therefore, associated test and maintenance costs, and to reduce variances in schedule and budget. However, challenges remain. To address these challenges we have started our own PSP interim training and established a coach's forum to discuss common issues and concerns. Candidate coaches are being approached to expand our base. We are now considering future roll-out of the methodology to other city hubs like Durban, and also to our African neighbors.

Experience Report: Applying and Introducing TSP to Electronic Design Automation

Elias Fallon and Lee Gazlay, Cadence Design Systems

In April 2011, Cadence Design Systems officially kicked off pilot projects using the Team Software Process (TSP) in an attempt to address our challenge of continuing to deliver highly innovative new capabilities in our software with much higher quality.

Cadence is a leading company in Electronic Design Automation (EDA) which serves the semiconductor and electronics industry with software tools to enable their design and manufacturing needs. While the performance and capacity of electronics keeps doubling every 18–24 months, following Moore's Law, the number of engineers creating these designs has increased only marginally. Cadence sells software that helps chip designers estimate the yield through their manufacturing process of a given chip design, and offers suggestions on how to improve that yield.

Applying similar techniques to our own software development processes has not been our primary objective. Due to the constantly changing technology our customers are working with, we often have to develop new products and features very quickly in close partnership with our customers to enable the next generation of designs. This requires us to deliver large new functionality quickly, often at the expense of quality, and has given our industry a reputation for "ship it with bugs, since they need to use it anyway…" With TSP, we believe we can transform our company to be able to deliver that same new functionality just as fast, with true production quality and discipline and gain significant advantages for our customers.

We will present an analysis of the data collected by the TSP team in terms of what has worked well and what hasn't. We will describe the approaches taken so far as well as the challenges we've run into with them, along with the tactics we've used to try to address those challenges.

Leading GREAT Teams: Key Findings at the Intersection of Leadership, Teamwork, and the Personal Process

Alan Willett, Oxseeker, Inc.

Team leaders are the key to creating great teams that embody and live the TSP principles. This presentation covers the specific challenges team leaders face and shows how coaches and team leaders can work together to overcome them. Team leadership skills are critical in order to mold a collection of people with diverse talents and personalities and transform them into a cohesive, purpose-driven unit committed to achieving a common goal. The promise of the TSP is that by following the process, great teams will be created. However, there is no guarantee. Learn why some team leaders succeed and some have difficulty. Benefit from the knowledge gained from leading, coaching and participating in more than 200 TSP launches. The critical success factor in these experiences rests firmly in the leadership of the team.

What are the key things outstanding team leaders do to make the transformation from good teams to great teams? What happens to the team when a team leader falters in these key areas? Is it possible that team leaders can recover from the mistakes they invariably make? (We all inject defects!)

This presentation demonstrates what the author has observed and learned in exploring the answer to these questions. The presentation provides the critical few things a team leader must do and specific suggestions on how to do them. The presentation provides valuable insight on the critical intersection between the personal process and the team software process: it all rests with—wait for it—the TEAM LEADER.

tspsymposium 2012 news


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.