When I design software I split it into two parts- 1) What does the software have to do? and 2) How is it going to do it?
1) I take a list of what it has to do (these are known as software requirements) and start to figure out different scenarios where those things would happen (these are ‘use cases’). Once I know all the scenarios then I break each one down into steps and work out what the software needs to do at each step. By this point, I’ve drawn a ton of diagrams (‘activity diagrams’ and ‘sequence diagrams’) to explain the whole thing and these can then by used by the team to write the software.
2) There are many many different ways of writing one piece of software so on large projects, people have to agree that the software they write is going to fit in with everyone else’s when it’s done. To make sure this happens, I come up with the ‘software architecture’ which explains how everything is going to fit together. The software architecture is a nice picture showing how all the different bits of software fit together, similar to a blueprint for a building, which the whole team use as the basis for writing their software.
Once you’ve got those two parts sorted then the rest of it comes together 🙂 You just have to make sure that you come up with a good design!
Comments