When working with a client, they will primarily be interested in two things:
Unfortunately, software developers are terrible at answering these questions.
The goal of software development tools and methodologies is improve our ability to deliver software on time and on budget
An IAG study discovered two types of development teams: teams with “probable success” and teams with “improbable success.”
68% of the teams studied were in the “improbably success” class.
Of the 68% of teams with “improbable success”:
Of the 32% of teams with “probable success”:
What did the study find was the key difference between the two classes of teams?
The successful teams did a better job of gathering requirements, creating specifications, and planning.
The worst way to develop software is to meet with the customer to establish goals, then “go dark” and program furiously until the deadline.
This “Big Bang” methodology is sure to fail.
The crux of the issue with “Big Bang” development is that the assumptions, guesses and even requirements are often misunderstood or simply incorrect!
However, this fact won’t be discovered until the end of the project.
To describe various methodologies that attempt to improve upon the “big bang” model, we will use a general model of development steps referred to as the Software Development Life Cycle (SDLC).
The methodologies we will discuss are all variations on the following steps:
During this stage, we begin to understand the scope of the problem, and the general goals that need to be met.
At this point, we want to turn our general understanding of the project into a concrete set of requirements which define a successful project.
In this stage, we establish the actual design of the solution which we believe will meet the requirements previously established.
After the design is established, we will then implement the design with actual code.
Once we have completed out implementation, we need to test it and determine whether or not the requirements have been correctly implemented.
When we’ve finished testing, we will release the product to the client, then maintain it as additional bugs are discovered and change requests are created.
The waterfall model is a somewhat direct implementation of the SDLC stages. In this model, we complete each step completely before moving on to the next step.
Like a waterfall, we don’t go backwards and revisit steps!
This model depends on the existence of static requirements. If the requirements, plannings, etc. are not sufficient, this model can lead to a similar conclusion as the “big bang” model.
With the iterative model, we add flexibility by establishing requirements up front, then breaking down the requirements into subsets that are completed in different iterations.
Having a well defined set of requirements in the beginning is still important, but there is more flexibility for accomodating change in this model as most steps are revisited.
The spiral model can be viewed, roughly, as a repetition of all SDLC steps over and over until the details are all worked out.
This model does not require a full specification up front and is very flexible, but it can also get out of handle and “spiral” indefinitely.
The agile model is another iterative process which, more or less, repeats all SDLC steps over and over.
A big difference, though, is that agile focuses less on planning and more on reacting to inevitable changes.
With this model, we gather somewhat vague user stories and use cases, then quickly design and implement a solution. This solution is then reviewed with the client to determine what has gone wrong, and correct as needed.
Another interesting aspect of this model is that, to facilitate client review, all iterations are designed to end with a “complete” product. The entire process is, basically, a series of product releases.