Continuing our series of articles on the different stages that a software development project goes through, and following on from our post on requirements, we’ll now outline what is involved in the next phase – the design phase.
Why have a design phase at all?
The requirements have all been agreed upon and signed off – so why can’t you just start writing the code to satisfy them? The short answer is “more haste, less speed”. A bit of planning now will save a lot of time, expense and headaches later on.
Every project is different, so it makes sense to scope out everything that needs to be done then plan the most appropriate approach – diving straight in and flapping around is a recipe for disaster!
Pick an approach
With some projects, especially those that are safety related, the requirements are very well defined. It is clear what the system has to do, and the process for getting there is easy to map out. In this instance we tend to follow what is referred to as a Waterfall Approach.
The Waterfall Approach is a sequential design process. We do the design based on the requirements, and then we get client approval of the design before we start implementing it. With a Waterfall Approach we do each stage in sequence and get sign off between each stage. This is the classic way of doing it – you have nice defined phases and you don’t move to next stage till previous stage is signed off. The workflow is smooth and everything moves forward to a clearly defined end point, hence the term “waterfall”.
In many instances, however, the client may not have a very well defined idea of what they need – it’s less clear what the solution is going to look like and how best to get there. What’s more, commercial pressures often mean that you have to start on the next phase while still waiting for sign off on the previous one. Then there will be projects where urgent deadlines mean the client needs an early release of basic functionality. In this instance you won’t design the whole system in one go but break it down into phases, producing a very basic first version then going back to refine and build on it later.
In situations of this nature a Waterfall type approach is inappropriate and we’ll take a more Iterative approach. The basic idea is to break the project up into bite-sized pieces that can be completed relatively quickly. You complete and implement maybe 2% of the system then move onto the next, building up the whole one little bit at a time. It’s a less formal approach where you are, to some extent, feeling your way. As you complete each bit, and discuss it with the client, it becomes clearer what the next step is going to look like. The fact is that with many projects you have to start work in order to clarify the full extent of the requirements – sometimes it’s only when you see what a system doesn’t do that you realise what it should do!
With an Iterative Approach, where people will be working on one little bit at a time, the point of the design is to give them an overall idea of how that unit fits into the whole – it gives everyone an overview, a bit like the picture on the lid of the jigsaw puzzle. They can then see how their piece of the system relates to those around it and makes it easier for individuals to work together in joining everything up. To use another popular metaphor it ensures everyone is singing off the same hymn sheet.
Two more reasons why the design stage is important
The design stage enables us to plan how we are going to tackle the job – and makes sure everyone on the team understands what is required of them.
But that’s not all.
It also gives us the opportunity to show the client that we have understood their brief and have interpreted their requirements correctly. This should make sure that all parties are clear on the solution we are working towards and how the work is going to proceed. Usually we’ll get them to sign off the design and then everyone is confident that we’re heading off in the right direction.
Secondly, the documentation that we produce at the design stage proves invaluable when it comes to maintaining and supporting the system in the future. There will inevitably come a time when the client wants to update the system or add to it. They might ask us to do it, or someone else. If they ask someone else then that team will have no knowledge of the system. If they ask us we have something of a head start, as we designed it in the first place, but we won’t be able to recall all the detail, years later, from memory.
In either instance someone will be scratching their head and wondering where to start. They can dive in and work their way through thousands of code files – but it’s going to take forever and involve a certain amount of trial and error. However, if a design was fully documented, it’s relatively easy to see what parts of the system will have to be modified, what other modules this will affect, and what tests will have to be undertaken at the end to ensure everything is working correctly. Having a design document to refer to saves a huge amount of time and effort – you can complete the job much more efficiently and with greater confidence.
So, for all these reasons, the planning stage is invaluable.
What does the planning stage involve?
In practice we will have started to plan the project way back at the very initial stages – because giving the client a price and a timescale would be impossible unless we scoped out the problem and did some high level thinking about what work was involved.
We now have to revisit those outline plans and flesh them out with more detail. How we do this depends on the size of the project, but with a larger one we’ll start by looking at the overall system architecture, which we’d typically get from the client. This would give us the context for the work we’re going to undertake and show us how our job fits into the grand scheme of things. It will show how all the different systems and sub-systems join up, showing where all the different inputs and outputs will be routed, which bits have got to talk to each other.
How do we do the design?
We’ll then work down from this, breaking the system into its main components and designing the specifications required at this level. Then we’ll go down another level, break the component into its constituent units, and design the specifications for each of these. Eventually we’ll create a schematic map of the whole system, fully drawn out and documented, showing exactly what every little bit is going to do and how it will all fit together.We tend to use UML (Unfied Modelling Language) which is a general-purpose modelling language which provides a standard way of visualizing the design of a system in diagrammatic form. It will include context diagrams, which describe where parts of the system sit and how they fit together, class diagrams that describe individual parts of the software and how they interact, or things like sequence diagrams where you can show sequences of things happening.
Another approach is to use flow charts and state machines – sometimes a simple flow chart can describe each part of a software system.
Where a Graphical User Interface is included in the system we will probably produce a prototype. Strictly speaking this may come at the requirements stage, but it influences the design. Only by creating a prototype and getting the users to try it out, can we fully understand what is going to best meet their needs. They may perform certain regular functions in a particular way and this could influence the positioning of the buttons. And there may be subjective considerations, regarding colours, for instance. It’s only by producing a prototype that we can get the feedback from the people who will actually use the system – feedback that’s invaluable at the design stage.
So that’s the why, the what and the how of the design stage. Each project is different, with its own particular challenges, so it’s hard to be definitive about what’s involved in the design – but hopefully this shows we take a very considered and systematic approach to planning the work. One that ensures our team is clear on what they need to do. That reassures the client that we are heading in the right direction and makes it clear what they can expect from us as we move forward. And one that makes it much easier to maintain and support the system in the future.