Software Life Cycle Models:
Iterative model - This model iterates requirements, design,,
build and test phases again and again for each requirement and builds up a
system iteratively till the system is completely build.
Incremental model - It is non integrated development model. This
model divides work in chunks and one team can work on many chunks. It is more
flexible.
Spiral model - This model uses series of prototypes in
stages, the development ends when the
prototypes are developed into functional system. It is flexible model and used
for large and complicated projects.
Evolutionary model - It is more customer focused model. In
this model the software is divided in small units which is delivered earlier to
the customers.
V-Model - It is more focused on testing. For every phase
some testing activity are done. the following are the list of activity
performed side by side.
Iterative model :
In the first step of iterative enhancement model, a simple
initial implementation is done for a subset of the overall problem. This subset
is the one that contains some of the key aspects of the problem which are easy
to understand and implement, and which forms a useful and usable system.
A
project control list is created which contains, in an order, all the tasks that
must be performed to obtain the final implementation. This project control list
gives an idea of how far the project is at any given step from the final
system.
Each step consists of removing the next step from the list.
Designing the implementation for the selected task, coding and testing the
implementation, and performing an analysis of the partial system obtained after
this step and updating the list as a result of the analysis.
These three phases
are called the design phase, implementation phase and analysis phase. The
process is iterated until the project control list is empty, at the time the
final implementation of the system will be available. The process involved in
iterative enhancement model is shown in the figure below.
The Iterative Enhancement Model
The project control list guides the iteration steps and
keeps track of all tasks that must be done. The tasks in the list can be
include redesign of defective components found during analysis. Each entry in
that list is a task that should be performed in one step of the iterative
enhancement process, and should be simple enough to be completely understood.
Selecting tasks in this manner will minimize the chances of errors and reduce
the redesign work.
Explain the Iterative Model?
The iterative model approach is to iterate on steps as the
project progresses with requirements. Iterative model iterates Requirements,
Design, Build and test phases again and again for each requirement and builds
up a system iteratively till the complete system is built. The advantage is
that iterative model can accommodate changes in requirements which are very
common in most of the projects. It also provides an opportunity to identify and
build upon any major requirement or design flaws throughout the process because
of its iterative nature.
Incremental model:
Incremental model combines
elements of the waterfall model applied in an iterative fashion.
Each linear sequence produces deliverable “increments” of
the software.(Ex: a Notepad delivers basic file management, editing, in the
first increment More refined editing, format and printing in the second
increment Find and Replace in the third increment.)
With an increment model, the first increment is often a core
product. The core product is used by the
customer and after the feedback from the customer, a plan is developed for the
next increment. The plan deals with the modification of the core product to
better meet the needs of the customer and the delivery of additional features
and functionality.
The process is repeated until the complete product is
produced.
When to use Incremental model?
If it is too risky to develop the whole system at once, then
the incremental development should be considered.
Advantages of Incremental model:
As product is to be delivered in parts, total cost of
project is distributed.
Limited number of persons can be put on project because work
is to be delivered in parts.
As development activities for next release and use of early
version of product is done simultaneously, if found errors can be corrected.
Customers or end users get the chance to see the useful functionality early in
the software development life cycle.
Disadvantages of Incremental model:
As product is delivered in parts, total development cost is
higher.
Well defined interfaces are required to connect modules
developed with each phase.
The model requires well defined project planning schedule to
distribute the work
"V" Model
is one of the SDLC Methodologies:
In this methodology Development and Testing takes place at
the same time with the same kind of information in their hands.
Typical "V" shows Development Phases on the Left
hand side and Testing Phases on the Right hand side.
Development Team follow "Do-Procedure" to achive
the goals of the company
and
Testing Team follow "check-Procedure" to verify
them.
SRS User
Acceptance
Design
System Testing
HLD
Integration Testing
SDLC LLD Unit Testing STLC
Coding
- Verification process is called as Do procss and validasation phase is check procedure.
- Development starts with information gathering. After the requirements gathering BRS/CRS/URS will be prepared. This is done by the Business Analyst.
- During the requirements analysis all the requirements are analyzed. at the end of this phase S/wRS is prepared. It consists of the functional (customer requirements) + System Requirements (h/w + S/w) requirements. It is prepared by the system analyst.
- During the design phase two types of designs are done. HLDD and LLDD. Tech Leads will be involved.
- During the coding phase programs are developed by programmers.
- During unit testing, they conduct program level testing with the help of WBT techniques.
- During the Integration Testing, the testers and programmers or test programmers integrating the modules to test with respect to HLDD.
- During the system and functional testing the actual testers are involved and conducts tests based on S/wRS.
- During the UAT customer site people are also involved, and they perform tests based on the BRS.
- From the above model the small scale and medium scale organizations are also conducts life cycle testing. But they maintain separate team for functional and system testing.
The Spiral Model:
The process begins at the center position. From there it
moves clockwise in traversals. Each traversal of the spiral usually results in
a deliverable. It is not clearly defined what this deliverable is. This changes
from traversal to traversal. For example, the first traversals may result in a
requirement specification. The second will result in a prototype, and the next
one will result in another prototype or sample of a product, until the last
traversal leads to a product which is suitable to be sold. Consequently the
related activities and their documentation will also mature towards the outer
traversals. E.g. a formal design and testing session would be placed into the
last traversal.
There are different instances of this model so far I saw it
with 3 to 6 task regions. The above picture shows 4 task regions.
These regions are:
• The
planning task - to define resources, responsibilities, milestones and
schedules.
• The goal
determination task - to define the requirements and constraints for the product
and define possible alternatives.
• The risk
analysis task - to assess both technical and management risks.
• The
engineering task - to design and implement one or more prototypes or samples of
the application.
The most outstanding distinction between the spiral model
and other software models is the explicit risk evaluation task. Although risk
management is part of the other processes as well, it does not have an own
representation in the process model. For other models the risk assessment is a
sub-task e.g. of the overall planning and management. Further there are no
fixed phases for requirements specification, design or testing in the spiral
model. Prototyping may be used to find and define requirements. This may then
be followed by "normal" phases as they can be found in other process
models to handle design and testing.
The advantages of the spiral model are that it reflects the
development approach in many industries much better than the other process
models do. It uses a stepwise approach which e.g. goes hand in hand with the
habit of maintaining a number of hardware sample phases in cases where the
product to be produced is not only software for a given environment, but also
contains the development of hardware. This way the developers and the customer
can understand and react much better to risks in the evolutionary process. By
having an iterative process which reduces formalisms and omittable activities
in the earlier phases the use of resources is optimized. Further, any risks
should be detected much earlier than in other process models and measures can
be taken to handle them.
The disadvantages of the spiral model are that the risk
assessment is rigidliy anchored in the process. First of all it demands
risk-assessment expertise to perform this task and secondly in some cases the
risk assessment may not be necessary in this detail. For completely new
products the risk assessment makes sense. But I dare to say that the risks for
programming yet another book keeping package are well known and do not need a
big assessment phase. Also if you think of the multitude of carry over projects
in many industries i.e. applying an already developed product to the needs of a
new customer by small changes, the risks are not a subject generating big
headaches. Generally speaking the spiral model is not much esteemed and not
much used, although it has many advantaged and could have even more if the risk
assessment phases would be tailored down to the necessary amount.
Prototype model:
1>Based on the initial requirements a prototype is
developed.
2>Prototype is demonstrated to the client and based on
the prototype more requirements are gathered from the clients.
3>After getting clear requirements based on those
requirements software is developed.
The goal of prototyping based development is to counter the
first two limitations of the waterfall model discussed earlier. The basic idea
here is that instead of freezing the requirements before a design or coding can
proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Development
of the prototype obviously undergoes design, coding and testing. But each of
these phases is not done very formally or thoroughly. By using this prototype,
the client can get an "actual feel" of the system, since the interactions
with prototype can enable the client to better understand the requirements of
the desired system.
Prototyping is an attractive idea for complicated and large
systems for which there is no manual process or existing system to help
determining the requirements. In such situations letting the client
"plan" with the prototype provides invaluable and intangible inputs
which helps in determining the requirements for the system. It is also an
effective method to demonstrate the feasibility of a certain approach. This
might be needed for novel systems where it is not clear that constraints can be
met or that algorithms can be developed to implement the requirements. The
process model of the prototyping approach is shown in the figure below.
Prototyping Model
The basic reason for little common use of prototyping is the
cost involved in this built-it-twice approach. However, some argue that
prototyping need not be very costly and can actually reduce the overall
development cost. The prototype are usually not complete systems and many of
the details are not built in the prototype. The goal is to provide a system
with overall functionality. In addition, the cost of testing and writing
detailed documents are reduced. These factors helps to reduce the cost of developing
the prototype. On the other hand, the experience of developing the prototype
will very useful for developers when developing the final system. This
experience helps to reduce the cost of development of the final system and
results in a more reliable and better designed system.
Advantages of Prototyping:
1. Users are actively involved in the development
2. It provides a better system to users, as users have
natural tendency to change their mind in specifying requirements and this
method of developing systems supports this user tendency.
3. Since in this methodology a working model of the system is
provided, the users get a better understanding of the system being developed.
4. Errors can be detected much earlier as the system is mode
side by side.
5. Quicker user feedback is available leading to better
solutions.
Disadvantages:
1.Leads to implementing and then repairing way of building
systems.
