The Personal Software Process (PSP) provides engineers with a disciplined personal
framework for doing software work. The PSP process consists of a set of methods, forms, and
scripts that show software engineers how to plan, measure, and manage their work.
Software engineers develop their personal practices when they first learn to write programs.
Since they are given little or no professional guidance on how to do the work,
most engineers start off with exceedingly poor personal practices
when a group of engineers starts a project, they get little or no guidance on how to proceed. If they are
lucky, their manager or one or two of the experienced engineers will have worked on well-run teams
and have some ideas on how to proceed. In most cases, however, the teams have to muddle through a
host of issues on their own. Following are some of the questions every software team must address:
What are our goals?
What are the team roles and who will fill them?
What are the responsibilities of these roles?
How will the team make decisions and settle issues?
What standards and procedures does the team need and how do we establish them?
What are our quality objectives?
How will we track quality performance, and what should we do if it falls short?
What processes should we use to develop the product?
What should be our development strategy?
How should we produce the design?
How should we integrate and test the product?
How do we produce our development plan?
How can we minimize the development schedule?
What do we do if our plan does not meet management’s objectives?
How do we assess, track, and manage project risks?
How can we determine project status?
How do we report status to management and the customer?
Most teams waste a great deal of time and creative energy struggling with these questions. This is unfortunate, since none of these questions is new and there are known and proven answers for every one.
The team software process(TSP)
The TSP provides team projects with explicit guidance on how to accomplish their objectives. As shown in Figure 1, the TSP guides teams through the four typical phases of a project. These projects may start or end on any phase, or they can run from beginning to end. Before each phase, the team goes through a complete launch or relaunch, where they plan and organize their work. Generally, once team members are PSP trained, a four-day launch workshop provides enough guidance for the team to complete a full project phase. Teams then need a two-day relaunch workshop to kick off the second and
each subsequent phase. These launches are not training; they are part of the project.
The TSP launch process
To start a TSP project, the launch process script leads teams through the following steps:
Review project objectives with management.
Establish team roles.
Agree on and document the team’s goals.
Produce an overall development strategy.
Define the team’s development process.
Plan for the needed support facilities.
Make a development plan for the entire project.
Make a quality plan and set quality targets.
Make detailed plans for each engineer for the next phase.
Merge the individual plans into a team plan.
Re balance team workload to achieve a minimum overall schedule.
Assess project risks and assign tracking responsibility for each key risk.
Hold a launch postmortem.
-In the final launch step, the team reviews its plans and the project’s key risks with management. Once
the project starts, the team conducts weekly team meetings and periodically reports its status to
management and to the customer. In the four-day launch workshop, TSP teams produce
written team goals
defined team roles
a process development plan
the team quality plan
the project’s support plan
an overall development plan and schedule
detailed next-phase plans for each engineer
a project risk assessment
a project status report
It’s not the end, you can search for (PSP/TSP) ,it is somewhat new and far from us.