A Spiral Model Of Software Development And Enhancement

Submitted By : Souresh Banerjee(Department of BCA , Batch :2016-2019)

“Stop the life cycle-I want to get off!”

“Life –cycle concept considered harmful”

The waterfall model is dead.”

No, it isn’t, but it should be.”

                                      --   Barry W.Boehm

The spiral model is a risk-driven process model for software projects. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall or evolutionary prototyping.

• History: This model was first described by Barry Boehm in his 1986 paper “A   Spiral Model of Software Development and Enhancement”. In 1988 Boehm published a similar paper to a wider audience. These papers introduced a diagram that has been reproduced in many subsequent publications discussing the spiral model. These early papers use the term “Process Model” to refer to the spiral model as well as to incremental, waterfall, prototyping, and other approaches.

Boehm also identifies a number of misconceptions arising from oversimplifications in the original spiral model diagram. He says the most dangerous of these misconceptions are:

• That the spiral is simply a sequence of waterfall model, increment .
• That all project activities follow a single spiral sequence and
• That every activity in the diagram must be performed, and in the order shown.

While these misconceptions may fit the risk patterns of a few projects, they are not true for most projects.

In a National Research Council report this model was extended to include risks related to human users. [2]

• The Six Invariants:-

Authentic applications of the spiral model are driven by cycle that always display six characteristics .Boehm illustrates each with an example of a “Hazardous spiral look-alike” that violates the invariant.

1. Define artifacts concurrently:-

Sequentially defining the key artifacts for a project often lowers the possibility of developing a system that meets stakeholder “win conditions” (objectives & constraints).

These invariants exclude “Hazardous spiral look-alike” processes that use sequences that use a sequence of incremental waterfall passes in setting where the underlying assumption of the waterfall model do not apply.

2. Perform four basic activities in every cycle:-

• Consider the win conditions of all success-critical stakeholders.
• Identify and evaluate alternative approaches for satisfying the win conditions.
• Identify and resolve risks that stem from the selected approach.
• Obtain approval from all success-critical stakeholders, plus commitment to pursue the next cycle.

                  Some “Hazardous spiral look-alike” processes violate this invariant by excluding key stakeholders from certain sequential phases or cycles.

3. Risk determines level of effort:-

For any project activity (e.g., requirements analysis, design, prototyping, testing) , the project team must decide how much effort is enough .In authentic spiral process cycles , these decisions are made by minimizing overall risk.

“Hazardous spiral look-alikes” that violate this invariant include evolutionary processes that ignore risk due  to scalability issues, and incremental processes that invest heavily in a technical architecture that must be redesigned or replaced to accommodate future increments of the product.

4. Risk determines degree of details:-

For any project artifact (e.g., requirements specification, design document, test plan), the project team must decide how much detail is enough. In authentic spiral process cycles, these decisions are made by minimizing overall risk.

5. Risk anchor point milestones:-

Boehm’s original description of the spiral model did not include any process milestones. In later refinements, he introduces three anchor point millstones that serve as progress indicators and points of commitment. These anchor point milestones can be characterizes by key questions-

• Life cycle objectives. Is there a sufficient definition of a technical and management approach to satisfying everyone’s win conditions? If the stakeholders agree that the answer is “Yes”, then the project has cleared this LCO milestone. Otherwise, the project can be abandoned or the stakeholders can commit to another cycle to try to get to “Yes”.
• Life cycle architecture. Is there a sufficient definition of the preferred approach to satisfying everyone’s win conditions, and are all significant risks eliminated or mitigated? If the stakeholders agree that the answer is “Yes” , then the project has cleared this LCA milestone. Otherwise, the project can be abandoned, or the stakeholders can commit to another cycle to try to get to “Yes”.
• Initial operational capability. Is there sufficient preparation of the software, site, users, operators and maintainers to satisfy everyone’s win conditions by launching the system? If the stakeholders agree that the answer is “Yes”, then the project has cleared the IOC milestone and is launched. Otherwise, the project can be abandoned, or the stakeholders can commit to answer cycle to try to get “Yes”.

6. Focus on the system and its lifecycle:-

This invariant highlights the importance of the overall system and long-term concerns spanning its entire life cycle. It excludes “Hazardous spiral look-alikes” that focus too much on initial development of software code. These approaches can result from following published approaches to object-oriented or structured software analysis and design, while neglecting other aspects of the projects process needs.[3]

• How it works:-

The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed and can vary from project to project. Each loop in the spiral represents a phase of the software process.

Each phase in this model is split into four quadrants. The first quadrant determines the objectives and the alternative possible solutions for the phase under consideration. In Second quadrant the alternative solutions are evaluated to select the best possible solutions and develop various strategies that resolve risks. The third quadrant consists of developing and verifying the next level of the product. The forth quadrant is concerned with reviewing the result and planning for the next iteration around the spiral. [4]

• Spiral Model Application:-

Spiral model is very widely used in the software industry as it is in synch with the natural development process of any product. Following are the typical uses of spiral model:-

• When costs there are a budget constraints and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic priorities as the requirements change with time.
• Customer is not sure of their requirements which are usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough customer feedback.
• Significant changes are expected in the product during the development cycle.[5]
• Spiral model pros and cons:-

Pros:-

• Changing of requirements can be accommodated.
• Allows for extensive use of prototype.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and more risky parts can be developed earlier which helps better risk management.

Cons:-

• Management is more complex.
• End of project may not be known early.
• Not suitable for smaller or low risk projects and could be expensive for small projects.
• Process is complex.
• Spiral may go indefinitely.
• Large number of intermediate stages requires excessive documentation.[6]
• Meta Model:-

Spiral model is called Meta Model because it is composed for several other models. For example a single loop spiral actually represents the waterfall model. The spiral model uses prototyping approach before embarking on the actual product development effort .Also the spiral model can be considered as supporting the evolutionary model the iterations along the spiral can be considered evolutionary levels through which the complete system is built. This enables the developer to understand and resolve the risks at each evolutionary mechanism and also retain the systematic step approach of waterfall model. [7]

• Bibliography:-

[1].Boehm, B,”Spiral Development Experience, Principles and Refinements”, special report CMU/SEI-2000-SR-008, July 2000.

[2].Boehm B,”A spiral Model of Software Development and Enhancement”, IEEE Computer, IEEE, 21(5):61-72, May 1988.

[3] .Boehm, B,”Spiral Development Experience, Principles and Refinements”, special report CMU/SEI-2000-SR-008, July 2000.

[4].Fundamental and Database Management, Navathe.

[5]. http://www.tutorialspoint.com/sdlc/sdlc_spiral_model.html

[6]. http://www.tutorialspoint.com/sdlc/sdlc_spiral_model.html

[7]. Database Management System, A.K.Pujari.