The prototyping approach favors extensive communication with the client, using prototypes as a tool to establish and evolve requirements. Prototypes can be concept, and model the GUI or demonstrate a function, to be used as a tool, or be early iterations of the final project to be cyclically evaluated and redeveloped until requirements are met and the project is finalised. Prototyping is suitable for small projects, where requirements yet to be fully defined and/or understood.

The software is developed by the end user, through use of wizards, automated code or standard software packages. This method can mean sacrificing functionality, efficiency and performance however it has the advantage of full understanding of requirements, and no need for documentation. It is suitable for very small, low/no budget, and short time frame projects.

Examples include a small business owner creating their own reports in Microsoft Acceess using wizards, or a spreadsheet coded to give financial inputs and outputs for a business owner who will use this information to quote jobs for customers.

Combinations of development approaches can be the most suitable way to develop software, taking the positive attributes of multiple approaches, or minimising the consequences of approaches.

Prototyping specifically, can be used in conjunction with other approaches, as a communication tool.

The old system is dropped, and the new system installed simultaneously. As the old system becomes unavailable, it is crucial that the new one must be fully functional and reliable. Before installation data must be converted and imported, and users must be trained with the new system.

This is a fast way to convert, though may have serious repercussions should there prove to be a problem with the new system.

This method is the least expensive of the four but has the highest risk of data loss. The reason for this being that if something fails, the company can not revert back to the old system as a backup.

This method best suits companies with low budgets with a short time period.

The old system and new system operate together for a period before the old system is dropped.

If problems are encountered with the new system, they can be addressed without the loss of data or operation, and users can familiarise themselves with the new system until it is found to be meeting requirements and the old one is dropped. While this method is suitable for crucial software it can be tedious as all functions must be performed on both systems.

Although this method is the safest, it would not be suited for companies with less than expensive budgets and a medium amount of time.

The gradual introduction of a new system, while the old system is gradually discarded.

This method is often used when software is released as it is developed, in modules which replace previous ones, for faster roll out.

Phased is also suitable for large companies for manageable conversion, modules are systematically introduced across sites and old ones removed. This is also suitable as they can conduct testings on their released product to receive valuable feedback to enhance their overall product.

The new system is installed for a small number of users, who learn and evaluate it before full installation.

Software is essentially put through another phase of testing before full roll out to ensure the new system is satisfactory for operation before full installation.

Additionally a small user base can now assist with training new users upon the full installation.