Digital Intelligence & Forensics
Measurement & Analysis
Performance & Dependability
Process & Performance Improvement
Security & Survivability
Does the TSP allow for variations in environments, styles, languages, and tools?
Yes, the TSP is language and environment independent. The TSP is being used by teams in different organizations with widely varying environments and tools. The PSP course provides training on how to adapt TSP/PSP processes and measures to any structured task.
Does the TSP integrate the customer into the process?
The TSP supports customer needs through the requirements elicitation and review process, prototyping and iterative development, and regular customer status meetings. Also, in the TSP, one team member takes on the role of customer interface manager and is responsible for maintaining a focus on the customer’s needs.
Does the PSP facilitate component-based development and reuse?
In the PSP, planning begins by producing a conceptual design and identifying the opportunities for using or building reusable components. Estimating includes an estimate of the reusable components and the components that will be built to be reused. Two measures are included for tracking reuse: %Reuse (percentage of code that was reused) and %NewReuse (percentage of code that was built to be reused).
Does the TSP provide or facilitate the development of processes where there are none?
First, both PSP and TSP provide processes to guide development that teams often choose to use. Further, PSP/TSP have a defined approach for process development and enhancement. Team members record their process improvement proposals on a form (form PIP). During specific steps in the PSP and/or TSP process such as the launch or postmortem, individuals/teams review the PIPs and identify processes that need to be developed or improved. This work is then planned and executed by the team or is handed off to the SEPG or similar group. More important than mechanics of process development, the PSP/TSP create an environment where processes are routinely developed and used.
Does the PSP/TSP facilitate the discovery and dissemination of best practices? Does it integrate PDCA (Plan-Do-Check-Act) or other process improvement models? Does it integrate just-in-time training or event-driven learning?
The PSP's emphasis on the collection and analysis of data is the basis for the answer for all of these questions. How do you know something is a best practice? Data. What does “Check” mean in PDCA? Analyze the data. How do you know you’re really learning and improving? Data. Also, with the PSP, data-driven feedback and learning are occurring daily or weekly. The principles outlined for PSP also scale up to the team level with TSP.
Is the TSP evolving? What improvements are being made to the model?
New process extensions and updates to the existing processes, courses, and other materials are ongoing. Extensions and updates include TSP version 4.0 (update to the TSP), TSP Secure, and TSP COTS. The SEI is also doing research in TSP extensions for software security and for software acquisition.
Isn't the TSP a heavy DoD methodology?
This is a common misconception. TSP has been presented at key “agile” conferences such as Agile Universe, SD West, SD East, and the USC agile symposium. At each conference, key proponents of agile methods declared TSP to be an agile methodology.
Is TSP adaptable? Will it work in our fast-paced, ever-changing environment?
On their second TSP project, EBS changed nearly everything: platform (from DEC to PC), operating system (from VMS to Windows), language (from C to Java), and design methodology (from functional specification to OO using UML). The system was delivered in three iterations of about one year each. Acceptance test and installation in a world-wide 24/7 trading network was trouble-free.
How much of this is just academic? Are any real companies using the TSP?
TSP was designed for industrial use, tested in industry settings, and is in use in a growing number government and industry organizations. The academic version, TSPi, was developed after TSP. The principal investigator and the development team are all from industry, and each had from 10 to 20 years of industry experience before joining the SEI.
Organizations that use the TSP include Microsoft, Intuit, The Boeing Company, Allied Signal, Lockheed Martin, NAVAIR, and SAIC.
Don’t you have to have a mature organization to use TSP?
No, both low and high maturity organizations have been successful with PSP/TSP. Introducing change in low maturity organizations is always risky, but there is no alternative. Unless they change they won’t improve. Some low maturity organizations have succeeded with PSP/TSP when nothing else worked.
Don’t you have to have a large organization, team, or project to benefit from TSP?
No. The TSP scales well, by design, from very small to very large organizations. Organizations with as few as 30 developers have benefited from TSP. Teams with as few as two developers have benefited from TSP. Projects as short as 6 weeks have benefited from TSP. TSP has also been used on large projects, multiple team projects, geographically distributed projects, projects involving more than one organization, and projects with a few hundred developers.
Does TSP support risk management?
TSP teams practice continuous risk management. Risk identification, analysis, mitigation planning, and weekly tracking are built in. Also, TSP virtually eliminates the two top risks to every software project: being over cost and being over schedule.
How will TSP help us execute our other improvement priorities?
One of the most significant barriers to improvement or to achieving high organizational maturity is experience. Too few people have had the opportunity to either work in a high maturity setting, or to implement successful change. TSP has helped several organizations gain the experience they need, both the understanding of what a high maturity process is like, and the experience of implementing successful change. This kind of experience generally breeds more success.
Can the PSP and TSP work with iterative development processes and prototyping? I have seen several references to “waterfall,” but when I look at the model, it seems that it could be adaptable and work well with iterative development. Does it have to conform to any specific life-cycle model? Or by waterfall, are you just meaning the TSP processes are waterfall?
TSP specifically calls for the project team to use a life-cycle model appropriate to the task at hand. We have teams that have used both waterfall and iterative approaches.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.