Project Life Cycle Models:

The following are the standard project lifecycle models.

Pure Waterfall
This is the classical system development model. It consists of discontinuous phases:
1. Concept
2. Requirements
3. Architectural design
4. Detailed design
5. Coding and development
6. Testing and implementation
The pure waterfall performs well for products with clearly understood requirements or when working with well understood technical tools, architectures and infrastructures. Its weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.

Spiral
The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model. Spiral iterations involve six steps:

1. Determine objectives, alternatives and constraints.
2. Identify and resolve risks.
3. Evaluate alternatives.
4. Develop the deliverables for that iteration and verify that they are correct.
5. Plan the next iteration.
6. Commit to an approach for the next iteration.
For projects with risky elements, it's beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle.

Modified Waterfall
The modified waterfall uses the same phases as the pure waterfall, but is not done on a discontinuous basis. This enables the phases to overlap when needed. The pure waterfall can also split into subprojects at an appropriate phase (such as after the architectural design or detailed design).
Risk reduction spirals can be added to the top of the waterfall to reduce risks prior to the waterfall phases. The waterfall can be further modified using options such as prototyping, JADs or CRC sessions or other methods of requirements gathering done in overlapping phases.

Evolutionary Prototyping
Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration.
The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development.

Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes.

Staged Delivery
Although the early phases cover the deliverables of the pure waterfall, the design is broken into deliverables stages for detailed design, coding, testing and deployment.
For staged delivery, management must ensure that stages are meaningful to the customer. The technical team must account for all dependencies between different components of the system.

Evolutionary Delivery
Evolutionary delivery straddles evolutionary prototyping and staged delivery.
For evolutionary delivery, the initial emphasis should be on the core components of the system. This should consist of lower level functions which are unlikely to be changed by customer feedback.

Design-to-Schedule
Like staged delivery, design-to-schedule is a staged release model. However, the numbers of stages to be accomplished are not known at the outset of the project.
In design-to-schedule delivery, it is critical to prioritize features and plan stages so that the early stages contain the highest-priority features. Leave the lower priority features for later.

Design-to-Tools
When using a design-to-tools approach, the capability goes into a product only if it is directly supported by existing software tools. If it isn't supported, it gets left out. Besides architectural and functional packages, these tools can be code and class libraries, code generators, rapid-development languages and any other software tools that dramatically reduce implementation time.
Consider the tradeoffs of time-to-market versus lock-in and functionality compromises. This may be an appropriate approach for a high-risk element of the overall project or architecture.

Off-the-Shelf
Following requirements definition, analysis must be done to compare the package to the business, functional and architectural requirements.
It is critical to know how the desired features compare with the packaged set and if the package can be customized.
These standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your environment. We can customize a methodology to fit your needs or help you with a special or problem projects.