The best software process is personal and team process model one that is close to the people who will be doing the work. Watts Humphrey proposed two process models. Models “Personal Software Process (PSP)” and “Team Software Process (TSP).” Both require hard work, training, and coordination, but both are achievable.
Personal Software Process (PSP)
The Personal Software Process (PSP) emphasizes personal measurement of both the work product that is produced and the resultant quality of the work product.
In addition PSP makes the practitioner responsible for project planning and empowers the practitioner to control the quality of all software work products that are developed. The PSP model defines five framework activities:
- Planning. This activity isolates requirements and develops both size and resource estimates. In addition, defects estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.
- High level design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.
- High level design review. Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.
- Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
- Postmortem. Using the measures and metrics collected, the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.
PSP stresses the need to identify errors early and, just as important, to understand the types of errors that you are likely to make. PSP represents a disciplined, metrics based approach to software engineering that may lead to culture shock for many practitioners.
Team Software Process (TSP)
Watts Humphrey extended the lessons learned from the introduction of PSP and proposed a Team Software Process (TSP). The goal of TSP is to build a “self directed” project team that organizes itself to produce high quality software.
Humphrey defines the following objectives for TSP:
- Build self directed teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPTs) of 3 to about 20 engineers.
- Show managers how to coach and motivate their teams and how to help them sustain peak performance
- Accelerate software process improvement by making CMM23 Level 5 behavior normal and expected.
- Provide improvement guidance to high-maturity organizations.
- Facilitate university teaching of industrial-grade team skills.
A self directed team has a consistent understanding of its overall goals and objectives; defines roles and responsibilities for each team member; tracks quantitative project data (about productivity and quality); identifies a team process that is appropriate for the project and a strategy for implementing the process; defines local standards that are applicable to the team’s software engineering work; continually assesses risk and reacts to it; and tracks, manages, and reports project status.
TSP defines the following framework activities: project launch, high level design, implementation, personal and team process model, integration and test, and postmortem.
TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team members in their work. “Scripts” define specific process activities (project launch, design, implementation, integration and system testing, postmortem) and other more detailed work functions (development planning, requirements development, software configuration management, unit test) that are part of the team process.
| Read More Topics |
| The unified process in software |
| Software quality assurance |
| Mechatronics Engineering |
| Transport layer in reference model |
| Mechatronic system design |
