SPIRAL MODEL:
Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific engineering project goals and objectives. Software Project Management is a subset of Information Technology Project Management that deals exclusively with the development of software applications. Every application that is created follows some discernible process that can be connected to the set of steps that collectively define Software Project Management.
The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. On the basis of this cycle one can develop the user defined software. This is the backbone of Software Project management.
Several models exist to streamline the development process. Each one has its pros and cons, and it's up to the development team to adopt the most appropriate one for the project. As we have already discussed the COCOMO and Waterfall Model previously in our blog, now let us concentrate on another process called Spiral Model.
In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new Software Development Model, which could help in ensuring the success of software project. One such model was developed which incorporated the common methodologies followed in "The Waterfall Model", but it also eliminated almost every possible/known risk factors from it. This model is referred as "The Spiral Model" or "Boehm’s Model".
The spiral model was defined by Barry Boehm in his 1988 article “A Spiral Model of Software Development and Enhancement”. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.
The steps in the spiral model can be generalized as follows:
- The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
- A preliminary design is created for the new system.
- A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
- A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype.
- At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
- The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
- The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
- The final system is constructed, based on the refined prototype.
- The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.
Advantages
- Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier.
- The model is designed to cope with the inevitable changes to the learning experience that will happen over the course of design and delivery.
- Multimedia producers can get their hands in and start working on a project earlier, and therefore shape the design process as well.
Disadvantages
1. Requires considerable expertise in risk evaluation and reduction
2. Applicable only to large systems
3. Need for further elaboration of spiral model steps (milestones, specifications, guidelines and checklists))
4. Complex and relatively difficult to follow strictly
5. Risk assessment could cost more than development
Applications
For a typical shrink-wrap application, the spiral model might mean that you have a rough-cut of user elements (without the polished / pretty graphics) as an operable application, add features in phases, and, at some point, add the final graphics. The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program
I saw the website really informative..)
ReplyDeleteSoftware Maintenance India