In my last post, I talked about different methods of writing a novel. In software, things are much fancier. Instead of methods, we have methodologies. Also, you don’t “use” things–you “utilize” them. Example: “I utilized the appropriate methodology to garner the appropriate resources to achieve my deliverables.”
All kidding aside, when most companies (especially larger companies) write software systems, they have a methodology that they follow. Large software projects can involve dozens of stakeholders, project managers, various analysts, testers, several development teams, and other sundry players. Things tend to go more smoothly when the project is organized in a such a way that people recognize the framework and know how their role fits into the big picture.
Another point of software methodologies is that they break the software system into its component parts. For instance, you don’t start writing code on day 1 of a software project. And you don’t start testing on day two. There’s an order to things.
The most established type of software development methodology is called The Waterfall Method. The waterfall method involves starting at the beginning and working through the project in a linear fashion. In the purest form of the waterfall method, once you move into a new phase, there is no going back–there is only moving forward (thus, the image of moving down a series of cascading waterfalls).
The phases in a waterfall approach typically look like this:
1) Ideation. This is sometimes a formal step and sometimes is an implied one. But, this is basically the moment when someone or a group of someones brainstorms some ideas and comes up with a novel approach as a solution.
Deliverable at the end of this phase: High-level scope document
2) Requirements. This phase involves the owner of the system (usually someone outside of the IT department) and one or more business analysts sitting down and writing a document that lays out what the system needs to do in detail. The resulting document is usually about two inches thick and gets reviewed by every member of the team on day-long, soul-sucking conference calls. When everybody agrees on the requirements of the system, this phase is complete.
Deliverable at the end of this phase: Detailed requirement document
3) Design. Enter the techies. This is where technical acumen is set loose on business need. The developers and system analysts read the aforementioned requirements document, digest it, cogitate on it, and then create a technical design that meets the requirements of the system. For instance, you might hear a computer programmer say, “Hey, customers are going to have to interact with this system. Should we build a website where customers can login? Or should we create a smart phone app that customers can download? Or should we send out CDs like AOL used to do circa 1996?”
Deliverable at the end of this phase: Usually some diagrams, data mappings, and a detailed estimate of how long the system will take to build
4) Build/Integration. Once the techies have worked out their plan of attack, they start coding. If the project involved more than one of the company’s systems (like the accounting system, the HR system, the main website, etc.), there is probably some integration work to make sure all the systems play nice together.
Delivered at the end of this phase: a working, version of the system in a test environment
5) Testing/Quality Control. A group of quality control analysts takes the requirements document and the working (or semi-working) version of the system and begins to test the system to make sure it actually does what it says it does. When the testers find something that is broken, they report the defect back to the developers who in turn fix it.
Delivered at the end of this phase: a tested, (hopefully) working version of the system (still) in a test environment
6) Implementation. The system has to be rolled out to the production environment (aka, the “real” version that the “real” users of the system can get to). Sometimes this is done all at once, but sometimes there is a “beta” version released first. Sometimes this involves getting your app into the Apple store. In 1996, this involved making CDs of your software that you will send to your customer via snail mail.
Delivered at the end of this phase: the system is launched out into the real world! Yea!!!!
7) Maintenance/Support. This phase involves the monitoring, support, and operation of the system. ‘Nough said.
Delivered at the end of this phase: things don’t fall apart; the lights stay on; the wheels stay on the bus; <insert metaphor here>
So, there you go. That’s a waterfall approach to creating a software system. Is it boring? Yeah, a little bit. Is it obvious? Pretty much. Is it helpful in the real world? Absolutely.
What’s so great about it? It splits up the creation of the project into defined phases with defined roles and defined deliverables. It brings structure to chaos.
Wikipedia’s take on the phases of the waterfall method
Could such a process have value in the creation of other things? Like the writing of a book. What an astute question! Stay tuned for the answer….