Oct 10 2008
Websites Are Houses Too - Part 2
Continued from Websites are houses too - Part 1
Last week, I talked about a classic recurring dilemma among IT, and especially web development - that is a perception that making websites is somehow easier and less critical than, say, building houses. When a house is getting build, tonnes of time is spent planning and organising it - but with websites, time spent doing that is often perceived as a waste, and the “just get it done” mentality prevails.
There is a solution for the dilemma faces in part 1, and that is a little something called the Software Development Life Cycle (SDLC). There are many difference processes available for handling a project, and the best should be chosen based on the team, the size and nature of the project, time constraints and experience. A few of the more popular ones are Waterfall, Agile and Iterative (Spiral). I will go into a little bit more detail about the waterfall model, as it is what we use to manage our clients’ requirements.
The waterfall model splits development up into a handful of phases - It basically boils down to Requirements, Design, Implementation, Testing, Maintenance. The idea of the model is to specify as much as possible in an early phase, signing it off, before moving down to the next phase. Any irregularities that are found in a lower phase should be passed up to the earlier phase before continuing.
Requirements Specification
The first step involves scoping out the user requirements and writing them into a Software Requirements Specification. A lot of time should be spent in the requirements phase, as it is the cheapest time to scope out any changes in specification. It is during this phase that all-important interview phases and communication goes on. Here is where people ask what colour roof they want for their house, down to what pattern of tiles for the bathroom floor. Everything, from largest to smallest, should be written down here. If a programmer ever needs to know if address is a mandatory field, they can find out in the SRS.
While it is the most important task, it is far too often swept under the rug. This can lead to dismal failure in projects - starting to design something without knowing everything involved in design can lead to horrible confusion in later stages, where it is much more expensive to fix. An extra hour in requirements can potentially save days during implementation.
This document should be sighted, reviewed and signed by all parties involved. It should be completely unambiguous and define all attributes and features of the system. Essentially, this one document IS the project in writing. The perfect SRS will create a perfect solution with no extra resources, no matter who implements it.
If this were a house (and you may notice here that I don’t build houses), an SRS would hold the complete list of things that people want to see in their house - number of rooms, size of the rooms, general layout, colours, landscaping, etc. etc. etc. However, there will not yet be any house plans, materials, labour or anything chosen - it’s about what they want, not how they want it.
Design
The first point of confusion I will hope to destroy straight away is the concept of “design” being about pretty colours, layout and other shiny things. In reality, a programmer has just as much focus on design as a designer. Where a designer needs to make sure that the computer communicates well with a person, a programmer needs to be sure that programs communicate well within itself, to its database and to other programs.
Which is what the design stage is all about - here the database is mapped out, and the high level view of the components and modules being used by the website is all specced out. Designers will also spend the majority of this phase in photoshop, making mock ups of the various screens and flows throughout the application.
Of course, there’s a large chance that during this phase, some errors were found in requirements. That’s fine - as long as we make sure to go BACK to requirements and fix it up there before putting it down in design. This will make sure we don’t conflict with anything! Very important.
At the end of this phase, a Design Document is produced. This design document is purely internal, and used as a foundation to launch implementation from. One of the major benefits of having a good design document is that if, at any time, the programmer working on the project is hit by a bus, then anyone can come along, read the design document, and know how everything is about to be done.
Think of it as a house plan - anyone can read a house plan, and see exactly what the house is going to look like at the end.
Implementation
Well, this is where the magic takes place. The project moves from being an abstract idea on paper to a living and breathing system. There really isn’t a whole lot more to say about it - all the framework is in place to just create and deliver a strong product.
A common misconception is that this phase is extremely time consuming - after all, we’re actually making something! It’s not just a document any more, it’s a software program. In reality, this is far from the truth. The majority of the time in project development is spent designing and analysing it. After the foundation is in place, nutting out the specified functionality is fast. Very fast.
It’s almost certain that things were missed in the design stage - a function here, some database fields there. That’s ok - once again, it’s important to go back and fix up the design before going on and plugging it into the implementation. This is good for other developers who may work on it later, and to ensure that those extra fields won’t destroy anything else.
Think of implementation as the actual building of the house. Hire a bunch of labourers, and get it done. This is probably a lot faster than the building of a house though.
Testing
And finally, testing and maintenance. Once everything is done, we need to make sure everything works. There are a few types of testing that will be performed:
- Unit Testing: This involves running automated software over the code to make sure everything does what it says it will do. An example would be creating a contact, checking the contacts details are the same after saving it, loading the contact and checking it again, deleting the contact and making sure it’s gone. In theory, if all the unit tests succeed, all the code is doing what it says it will do. This is often done during implementation, as each component is added
- Use Case Testing: This involves going through all the use cases (stimulus/response sequences) in the SRS, and making sure all the steps are implemented as specified. Here, it is important to check that failure cases are throwing appropriate errors - what happens if I don’t enter an email? Or put a smiley face in as my phone number? This is generally done by a non-developer.
- Functional Testing: This involves going through all the functional requirements in the SRS and making sure they’re all actually there. Does it send the email it was told to?
- Acceptance Testing: This is a final test to ensure that the program is fulfilling its original purpose. It will be performed by both the development QA, and the client, and encompasses functional and use case testing.
Once the project passes all tests, it is signed off as being completed, and is ready to take live. This is a very important signature - it essentially says that each party agrees that the end product is the expected product, and are happy with the deal. Bugs will almost certainly be found later, and that’s what the final phase is for.
Maintenance
This part is quite straight forward - the system is live and running, but there are still problems. There’s a leaky pipe we missed. One of the lights keeps blowing bulbs after a week. The toilet is running. Generally some form of support agreement is formed, and tickets are raised for each bug that comes up. These bugs are assessed, and go through a ‘fix, test, stage, release’ process. New features work exactly the same way.
For entirely new functionality, or major additions/variations to the project, the process is started again. Time to get the requirements analysed…
Summary
Well, hopefully this overview of the waterfall model has given some insight into the inner workings of software development. By far the hardest thing about the waterfall model is sticking to the process - it’s far to easy to just “jump in and code”, and have it bite us in the butt soon after.
There is a definite increase in project maintainability when we’ve stuck to this method - it’s tried, tested and works.
Super duper.
