Agile Vs Spiral Model for SDLC [closed]

问题:

I believe that Agile is nothing but another implementation of Spiral Model. I am a big supporter of Spiral (The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts) since its beginnings and have seen that lot of projects implement Spiral without knowing that they are operating in a Spiral world. Since the day Agile started gaining popularity the concept of spiral started getting overlooked a little bit. I am sure that for complex projects spiral is still the best alternative but I would like to get a better understanding of the similarities and differences between Agile and Spiral techniques. Can anyone explain their differences/similarities?

回答1:

Agile is spiral. Totally. In part, the name was changed for marketing purposes.

The problem is that spiral tends to imply "big design up front" -- where you plan out many spirals, each in order of risk. Spiral, however, isn't Agile -- it's just incremental execution in order of risk.

One big distinction that Agile adds is the "don't overplan things you can't know yet." Agile is spiral, but you create detailed plans for just one increment at a time.

Agile adds a lot of other things, also. Spiral is a very technical approach. Agile, however, recognizes that technology is built by people. The Agile Manifesto has four principles that are above and beyond the Boehm's simple risk management approach.

回答2:

The basic difference, as I see it, is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.

Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.

They are similar in that they are iterative. They differ in the implementation and understanding of what an iteration is.

回答3:

I'm not an expert for the Spiral Model, but from the wikipedia-definition, it seems to me that there are some significant differences.

For example, in an Agile project, at the end of an iteration doesn't stand a prototype, but a fully functional, fully tested, potentially deployable (1) system, containing the highest priority features on the feature list.

The requirements gathering at the start of the project is meant to be just barely enough to get going (to take the next step) and are meant the be fleshed out just shortly before they get actually implemented. Changes are to the requirements are welcomed.

Also, there is much more to Agile than just doing iterative development - a focus on faces to face conversation instead of written communication, a focus on bringing business people and technical together in their day-to-day work. A focus in collaboratively maximizing value instead of defining and then fulfilling a contract.

In case you didn't see it yet, take a look at the Agile Manifesto, which basically is the definition for Agile Software Development.

(1) That doesn't mean that it has to make business sense to deploy the system, "just" that it is technically feasible. It should be a pure business decision whether to deploy the system at the end of an iteration.

回答4:

I believe Agile is type of Iterative SDLC while spiral is type of Incremental SDLC. Scrum is one the type of Agile other are DSDM/FDD/XP etc. All SDLC after waterfall followed same set of acts(Requirement Analysis, Design, Coding and Testing) in some different combinations. So basic set of action in sequential OR Iterative OR Incremental are same.

As far as Agile and Spiral are concern both have common advantage 1.Changing Requirement handling 2.Short term releases 3.Risk management is easy due to shorter duration of SDLC 4.Cross team helps product and project going smooth

回答5:

First Agile is actually a number of different processes that follow a similar philosophy. One of the philosophy's that makes it different is that each iteration produces a working product. It could be described as iterative and incremental. A lot of emphasis is placed on the working product and on testing. In many agile models testing comes before coding.

In the spiral model the number of iterations are fixed, while each phase of an agile model may consist of any number of iterations.

You are right that there are similarities but the underlying philosophy makes the difference. This page explains in more detail and compares agile to other methods.

You can say that agile processes are Use Case driven...placing a lot of emphasis on people, the end user.

回答6:

I'd say spiral and agile are similar. However, lately agile has often seemingly become a propaganda system to excuse cowboy coding. I.e.

• Extremely minimal requirements
• Minimal technical analysis
• Minimal documentation
• No code comments
• Special Bonus-- misuse of Domain Driven Design to over-complicate the object model

This was never the idea with spiral. I would argue that it's not really the point of Agile either, although you'd be surprised how many times I've seen this recently. More and more experienced developers/PMs are beginning to see the wisdom of a more balanced approach between waterfall and "agile" -- perhaps this simply brings us back to spiral.

Although there are some useful ideas in the Agile mind-space, it often seems as though it manifested from people who were in organizations that had particularly over-burdensome/unhelpful software design methodologies, and was a reaction/over-reaction to that.