Content deleted Content added
m Space |
m clean up, typo(s) fixed: Therefore → Therefore, using AWB |
||
Line 78:
==Planning and tracking==
Logging time, defect, and size data is an essential part of planning and tracking PSP projects, as historical data is used to improve estimating accuracy.
The PSP uses the [[Proxy-based estimating|PROxy-Based Estimation]] (PROBE) method to improve a developer's estimating skills for more accurate project planning. For project tracking, the PSP uses the [[earned value]] method.
Line 90:
In practice, PSP skills are used in a TSP team environment. TSP teams consist of PSP-trained developers who volunteer for areas of project responsibility, so the project is managed by the team itself. Using personal data gathered using their PSP skills; the team makes the plans, the estimates, and controls the quality.
Using PSP process methods can help TSP teams to meet their schedule commitments and produce high quality software. For example, according to research by Watts Humphrey, a third of all software projects fail,<ref>Humphrey, Watts S. "Why Big Software Projects Fail: The 12 Key Questions." CrossTalk Mar. 2005 http://www.crosstalkonline.org/storage/issue-archives/2005/200503/200503-Humphrey.pdf</ref> but an SEI study on 20 TSP projects in 13 different organizations found that TSP teams missed their target schedules by an average of only six percent.<ref>Davis, Noopur, and Julia Mullaney. The Team Software Process SM (TSP SM) in Practice: A Summary of Recent Results. Pittsburgh, PA: Software Engineering Institute, Sept. 2003.</ref>
Successfully meeting schedule commitments can be attributed to using historical data to make more accurate estimates, so projects are based on realistic plans – and by using PSP quality methods, they produce low-defect software, which reduces time spent on removing defects in later phases, such as integration and acceptance testing.
Line 107:
===Quality===
High-quality software is the goal of the PSP, and quality is measured in terms of defects. For the PSP, a quality process should produce low-defect software that meets the user needs.
The PSP phase structure enables PSP developers to catch defects early. By catching defects early, the PSP can reduce the amount of time spent in later phases, such as Test.
The PSP theory is that it is more economical and effective to remove defects as close as possible to where and when they were injected, so software engineers are encouraged to conduct personal reviews for each phase of development. Therefore, the PSP phase structure includes two review phases:
* Design Review
* Code Review
To do an effective review, you need to follow a structured review process. The PSP recommends using checklists to help developers to consistently follow an orderly procedure.
The PSP follows the premise that when people make mistakes, their errors are usually predictable, so PSP developers can personalize their checklists to target their own common errors. Software engineers are also expected to complete process improvement proposals, to identify areas of weakness in their current performance that they should target for improvement. Historical project data, which exposes where time is spent and defects introduced, help developers to identify areas to improve.
Line 148:
==External links==
* [http://www.processdash.com/ Software Process Dashboard], Open-source ([[GPL3]]) PSP and TSP tool; offered both without and with proprietary SEI scripts, latter requiring free SEI registration.
[[Category:Software development process]]
| |||