Social Icons

Saturday, February 9, 2013

Software Life Cycle Models


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.
2.Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.


                                          PREVIOUS                       NEXT