any necessary refinements. The next iteration will begin, then the team will continue cycling though iterations until the initial design has been completely implemented.
RAD's main advantages stem from its insistence on a design phase. Because developers and customers agree on a design before implementation begins, developers are aware of the "big picture" while they are coding. They know how different units will work together, which in turn allows them to implement the product more elegantly and logically, as well as avoid a lot of the rewriting eventually required with XP.
Having a design phase also helps the team estimate project deadlines and budgets. With RAD, the team always knows what the project will involve and what milestones must be met before the project is considered complete. With XP and other processes that lack a design phase, the best you can do is make short-term stimates at the beginning of each iteration.
RAD's main weakness is its lack of built-in error prevention practices, but this is not a true problem as long as you recognize this and compensate appropriately. A RAD process could potentially prevent errors as well as-or even better than-an XP process, but the error prevention must be consciously integrated into the RAD process, whereas it is innate in the XP process. If you fail to intentionally weave error prevention strategies such as unit testing, coding reviews, and coding standards into the development cycle, the lengthy and costly debugging process that will be required at the end of the project will negate the advantages gained by having a design phase.
In addition, if you use RAD for a project that is very dynamic or whose scope is difficult to imagine upfront, you are likely to encounter problems because RAD is not designed to accommodate the degree of change your project will probably require. The original features can be refined during the iterations, but RAD leaves little room for adding new features that do not fit into the original design. If your original design does not account for all necessary features, you either need to delay the implementation of these new features or start a new cycle. On the flip side, if you design and implement more (or different) features than you really need, you'll have done a lot of unnecessary design and implementation work.
Personal Software Process (PSP)
PSP is not a software development process. Rather, it is a software process improvement methodology, developed by Watts Humphrey in 1989, that helps an individual developer write better code and plan projects more accurately. Matrices form the foundation for PSP. Developers take it upon themselves to track defects, code complexity, code size, progress towards project milestones, and other quantifiable metrics in matrices. As data accumulates, they analyze it to increase their awareness of their personal trends, then use it to develop customized checklists and other tools that help them improve their coding practices and better estimate project durations. For example, if a developer finds that 20 percent of his defects stem from errors within a particular type of coding construct, he could add to a code review checklist an item that reminded him to find and review all instances of this construct.
Typically, the developer creates a personal project plan and engages in design reviews during the design phase, tracks metrics, and performs code inspections throughout the implementation phase, then compares the actual results to the plan after the project is completed.
The primary benefit of PSP is that it improves product quality and process efficiency. The custom reviews required at every point in the process ensure