A software development process, also known as a software development lifecycle, is a

structure imposed on the development of a software product. There are several models for such
processes, each describing approaches to a variety of tasks or activities that take place during the
process.

Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. There are tons of models, and many companies adopt their own, but all have
very similar
patterns.

The general, basic model is contains the following phases:

1. Analysis
2. Design
3. Coding
4. Testing

The different types of software lifecycle models are:

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed in its entirety before the next phase can begin. At the end of
each phase, a review takes place to determine if the project is on the right path and whether or
not to continue or discard the project. Unlike what I mentioned in the general model, phases
do not overlap in a waterfall model.

The waterfall model shows a process, where developers are to follow these phases in order:

1. Requirements specification (Requirements analysis)

2. Software Design
3. Integration
4. Testing (or Validation)
5. Deployment (or Installation)
6. Maintenance

Advantages

• Simple and easy to use.

• Easy to manage due to the rigidity of the model – each phase has specific deliverables
and a review process.
 • Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.

Disadvantages

• Adjusting scope during the life cycle can kill a project

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Poor model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Poor model where requirements are at a moderate to high risk of changing.

Prototyping model:

It begins with requirements gathering. Developer and Customers meet and define the
overall objectives of the software, identify whatever requirements are known and identify the
areas which require further definition. In many instances the client only has a general view of
what is expected from the software product. In such a scenario where there is an absence of
detailed information regarding the input to the system, the processing needs and the output
requirements, the prototyping model may be employed. This model reflects an attempt to
increase the flexibility of the development process by allowing the client to interact and
experiment with a working representation of the product.

Advantages

• It could serve as the first system.

• The customer doesn’t need to wait long as in the Linear Model.

• Feedback from customers are received periodically and the changes don’t come as a last
minute surprise.

Disadvantages

• Customer could believe the prototype as the working version.

• Developer also could make the implementation compromises where he could make the
quick fixes to the prototype and make is as a working version.

• Often clients expect that a few minor changes to the prototype will more than suffice their
needs. They fail to realise that no consideration was given to the overall quality of the
software in the rush to develop the prototype.
Rapid Application Development (RAD) model :

RAD is incremental software development process model that allows usable systems to be
built in as little as 60-90 days, often with some compromises. The RAD model used for information
systems development.

The RAD model contains the following phases:

 Business modeling

 Data modeling

 Process modeling

 Application generation

 Testing and turnover

Advantages:

There are many advantages of using RAD and it can solve many concerns of the user as well as the
developers.

• Conventional software development methods take, on an average almost 20% more time than
the RAD procedure. Using RAD can enable quicker visualization of the end-design and hence
allow rapid software testing and rectifying steps. The customer is able to have a faster look at
the design to add valuable inputs, in order to make the design more user-friendly.
• The current competitive scenario demands frequently upgraded software in order to
effectively satisfy customers' requirements. RAD enables a faster and updated version to
reach the end user, by systematically eliminating redundant steps or using the prototype
methods.
• Cost overruns and meeting the time constraints are another advantage, though not a big
consideration in high-end uses.
• RAD makes the development process to be a more credible one by facilitating a scope for the
customer to actively provide inputs in the development process. This may also prove a
feasible study from the point of view of a developer.
• It protects the current project from the variations in the market.

Disadvantages

1. For Large (but scalable) projects, RAD requires sufficient resources to create the right
number of RAD teams.
2. Not all applications are compatible for RAD. If a system cannot be properly modularized,
building components for RAD will be problematic.
 3. RAD not appropriate when technical risks are high. This normally occurs when a new
application makes heavy use of new technology or when the new software requires a high
degree of interoperability.
4. It requires equal commitment from both customers and developers. One sided commitment
can be disastrous.

Evolutionary Software Process Model

Software Products can be perceived as evolving over a time period.

However, neither the Linear Sequential Model nor the Prototype Model apply this
aspect to software production. The Linear Sequential Model was designed for straight-line
development. The Prototype Model was designed to assist the customer in understanding
requirements and is designed to produce a visualization of the final system.

But the Evolutionary Models take the concept of “evolution” into the engineering
paradigm. Therefore Evolutionary Models are iterative. They are built in a manner that
enables software engineers to develop increasingly more complex versions of the software.

The two most important models in this section are the incremental model and the spiral
model. The incremental model combines elements of the linear sequential model applied
repetitively with the iterative philosophy of the prototyping model. Each increment produces a
working version of a software product with increasing functionality. There is no throwaway code.
The spiral model also combines the iterative nature of prototyping with the systematic control
found in the linear sequential model. An essential component of the spiral model is that
assessment of both management and technical risks is performed as each incremental release is
completed.

Incremental Model
The incremental model is an intuitive approach to the waterfall model. Multiple
development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles
are divided up into smaller, more easily managed iterations. Each iteration passes through
the requirements, design, implementation and testing phases.
 A working version of software is produced during the first iteration, so you have
working software early on during the software life cycle. Subsequent iterations build on the
initial software produced during the first iteration.

Advantages

• Generates working software quickly and early during the software life cycle.
• More flexible – less costly to change scope and requirements.
• Easier to test and debug during a smaller iteration.
• Easier to manage risk because risky pieces are identified and handled during its
iteration.
• Each iteration is an easily managed milestone.

Disadvantages

• Each phase of an iteration is rigid and do not overlap each other.

• Problems may arise pertaining to system architecture because not all requirements are
gathered up front for the entire software life cycle.

Spiral Model
The spiral model is similar to the incremental model, with more emphases placed on
risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations
(called Spirals in this model). The baseline spiral, starting in the planning phase,
requirements are gathered and risk is assessed. Each subsequent spirals builds on the
baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a
process is undertaken to identify risk and alternate solutions. A prototype is produced at the
end of the risk analysis phase.

Software is produced in the engineering phase, along with testing at the end of the
phase. The evaluation phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the
spiral represents cost.

Advantages

• High amount of risk analysis

• Good for large and mission-critical projects.
 • Software is produced early in the software life cycle.

Disadvantages

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

Component-Based Development

Object-based technologies provide the technical framework for component-based

software engineering. The component-based development (CBD) model incorporates many of
the iterative characteristics of the spiral model. The main difference is that in CBD the
emphasis is on composing solutions from prepackaged software components or classes. This
CBD emphasizes software reusability. The unified software development process is an
example of CBD that has been proposed for industrial use. The unified modeling language
(UML) is used to define the Components and interfaces used in the unified software
development process.

The Formal Methods Model

Formal methods in software development require the use of rigorous mathematical
notation to specify, design, and verify computer-based systems. Mathematical proof is used to
verify the correctness of a system (not empirical testing). Clean room software engineering is
an example of this approach. While formal methods have the potential to produce defect-free
software, the development of formal models is both time consuming and expensive.

Fourth Generation Techniques

This is a broad class of techniques. The general idea is that a software tool is used to
describe a system in manner understood by the customer using a specialized design language
or graphical notation. In the ideal case, the tool then generates source code from this system
description that can be compiled into a running system. The running system then needs to be
tested and refined using other software engineering processes. There is some risk that the
customer is not able to describe the system in sufficient detail or that the initial system will be
deployed without sufficient testing.