Hi there, welcome to Administrate TV. My name’s Iain Brown and I’m going to talk to you today about the software development process.

Imagine the software development process as kind of like a pipeline – we start at the top and we move our way down to the bottom. Typically in software development we use a waterfall model, where we have clearly defined steps and we’d get everything out of the way in the first step before moving onto the second step. Nowadays we use a bit more of an agile process and we reiterate these steps. As I’ll identify later on, we can sometimes encounter problems further down the pipeline and may have to revisit earlier steps. But first, let’s go onto design.

Design

The most important thing to remember when we’re designing software is that we need to understand the problem fully and that we’re solving the problem. It’s not enough just to go and code up a quick fix for this. We need to take a step back and look at the problem and think ‘ok cool, are we solving the problem or do we need to take a step back, look at it from a higher level and solve it there?’ After we’ve done that and we’ve clearly defined the problem, we can start building a mock-up. As you can see here, we can do this in basic HTML – we can do this in basically anything. It can be sketched on a whiteboard for all we know! But the purpose of this is to almost provide a proof of concept for the software. Here, we can identify problems we might nit have thought about earlier on which could pop up later. This also helps to reduce the cognitive load later on. When we start developing, we already have a lot of this defined so we don’t have to think ‘how should I design this?’ – we can pre define all this in a kind of top-down process.

A Wicked Problem

As I mentioned earlier, we can encounter problems moving through the pipeline and I like to think of software design - and design in general - as a wicked problem. We might build a bridge and we might say ‘we designed this bridge to take a van of 2 tons going across it’ – but we might not have taken into account the fact that on a windy day it can easily blow over and we need to redesign the aerodynamics of the bridge. Design is a wicked problem because to clearly define the problem we need to in part solve the problem, which is why software development has moved from a typical waterfall model to a more agile process - reiterating and revisiting our earlier stages.

Once we have the mock-up completed we can move into actually developing the software. Because we have the elements and the proof of concept we can start tying it together with the code, linking up all the individual pieces and tying it together with the rest of the software. If we find a problem we can revisit the design stage and continue through that, fixing the problem, and then we move back down to development. Once it’s completed we can move onto the fun stage – testing.

Testing

I’m a big fan of testing for a good reason, here we use two main types of testing – unit testing and regression testing. Unit testing is internal code that we use in our software, so when we’re developing software we write tests to prove the functionality. We can say ‘we expect the software to be able to complete these steps’ – and the unit tests can prove that. That way, when we push out the software we can say ‘this works, we have confidence in it and we can do that’. If we encounter a problem later on, after it’s released per se, and we fix a bug with this we can add in more unit testing to cover say, that edge case that we didn’t think about when we originally designed the problem. The other type of testing is regression tests. Regression tests are very powerful because whereas unit testing is in the back end, regression tests are in the front end. Here we can load up a web browser and pretend to be a human going through the software. We can record all our actions and then make sure that any changes we make to the software don’t break the existing software. So they’re very powerful in fact, and they’re a great addition to using unit testing.

Release

Once we’ve proved the software works and we know there are no problems with it we can move onto the release. As part of agile software development, we practise ‘scrum’, which is where we commit to a weekly sprint. Think of a sprint as a train going throughout the week. I’ve got some train tracks here, and the idea is that we have all of the software feeding into the train and once it’s finished, once it’s completed at the end of the week we can release. As I identified earlier, we have to reiterate and go over the previous steps. Just because we release it doesn’t mean it’s finished. We might encounter an issue. We might encounter a problem. We might even have to go right back to the drawing board.

To reiterate my steps, we have design, development, testing and release. But remember, at any of these stages we can go back and revisit them. Thanks for watching! If you have any questions, please get in touch with us.