Hello. In this post, we’ll go over how software can be developed, and the methodologies (which is a fancy name for type) that are associated with software. This is a bit more general since this can apply to pretty much any type of software you build, and not just apps on the web.
The Waterfall method
Waterfalls are places where water flows over the edge of a steep drop, or a series of drops. The important thing to think about is the water, which represents the software as it gets made. The thing about the waterfall method is that it is linear: each process happens just once, and is then sent to the next process without really talking much to each other:
This can lead to a range of problems, if you end up following this methodology religiously. Deviation of this process in order to fix something, or change something is a costly process, especially if you’re handling a large software project. So while people used to do this, it’s best to leave it to the professionals: The waterfalls.
Iterative Model
The iterative model is a very different beast in comparison. It’s not a waterfall, for one.
Using the iterative model takes a very different focus. Instead of setting out to get everything done at once, you pick a few requirements, and implement those requirements. With that result, you can identify further requirements, and develop for those. This process builds off the work previously done and hence why the model has this name in the first place.
The Spiral
Somewhat similar to the iterative model is the spiral model, which employs a spiral of 4 stages:
Like the iterative model, you go through a series of stages over and over. But unlike the iterative model, there is more structure to the product. You don’t just keep writing code, but you also have to think back over previous work. This also shows off how the costs of software development can for the lack of a better word… spiral out of control.
The Agile model
For most of the above models, they focus on developing the whole thing before dropping the final product in the users’ lap. Then if they have to change or fix it, it’s time to go over the full development cycle again, and it’ll be a good long while before the next version arrives.
The agile model essentially aims to reduce the time of interaction between the development side and the end users. By rapidly developing software, testing it, then taking it to users, they can quickly gain feedback and insight into the software’s features (or lack of, depending). This means they can get to work again and have the next version available, ready to fly before the next year.
Of course, this does mean that you’re depending on users for feedback, and they might not necessarily understand what they need from your piece of software.
Which approach you’ll end up using depends. For something small, you can probably dive into the agile methodology, and things will work out. Something larger, and you’ll have to consider the behemoth of other options out there. Until next time…
M Nguyen - web based developer 