Have you ever been in a science fair? Whether you participated in one or only went as a spectator, the scientific method must have been something you heard a lot of. Said method is widely used by scientists around the world because, even if you didn’t realize back when you first learned about it, it is quite helpful. It can serve as a guide to know what you are looking for in an experiment; it lets you see what your original thoughts were and review them in case they didn’t completely satisfy your objective and something has to change; you can also take note of what went wrong in your experiments so neither you or others make the same mistakes; among several other possible advantages.
Now you may be thinking “What is this guy talking about? Wasn’t this supposed to be an OOP themed blog? Why is he talking about the scientific method?”. Well, I’ve always thought that comparisons and analogies are very efficient ways of getting ideas across, and I believe this is no exception.
I’ve stated that the scientific method is useful in many ways, wouldn’t it be awesome if we, programmers and developers, had a similar way of working with things? Because we don’t really do experiments per se, but what we do do is applications and programs, along with tests and newer versions that follow. A (somewhat) equivalent to the scientific method in our field is this week’s topic: Software Development Life Cycles (SDLC).
SDLC are methodical processes used to assist programmers with the software they’re developing. They serve as a plan to follow in order to get the best possible product. In what ways do SDLC help? Let’s go back to the last sentence in the first paragraph of this entry and make use of the previously mentioned analogies:
“A guide that lets you know what to look for in an experiment” could translate to “A guide that lets you know what the requirements for your project are”; “Original thoughts that need to be reviewed and/or changed”? Easy: prototypes or versions of your product that you can revisit and update; “Something that went wrong with the experiment” could be an equivalent to the testing and maintenance phases present in SDLC. While I was trying to come up with an analogy to connect the scientific method and SDLC I stumbled upon this entry from Science Buddies, I recommend checking it out for a way more detailed comparison between every step of both processes.
You could have noticed that, up until this line, I’ve been referring to SDLC as a plural noun, and that is because of a very simple reason: unlike the scientific method, there is no standard Software Development Life Cycle. Multiple variants exist, and there are even some versions of each variant. Before I mention some of these variants and what makes each one different from the others I have to clear something up: The number of phases/stages is not consistent between some definitions, I’ve seen from as little as five steps to the double of that, so, for the rest of this entry I will be considering the seven stages enlisted in this Stackify post:
- Identify the current problems
- Plan
- Design
- Build
- Test
- Deploy
- Maintain
The stages are practically self-explanatory, but if you wish, you can visit the Stackify post I just mentioned, it includes very concrete questions that must be answered for each of the phases. Questions like that help clarify a lot.
This week I heard a classmate say that SDLC are a natural approach to tackle software development and that statement stuck to my mind. I really believe that’s the case: any experienced programmer knows that it’d be a pain to just mindlessly code a whole application at once to then find some bug and try to solve every problem with the code. Developers have some notion of what each phase means and why they follow certain order.
Back to the different versions or models of the software life cycle: each one of them has a different approach. I’ve noticed that the main variants are whether you can go back to a previous phase or not, how often you test your progress and how often you deploy your application.
The most straightforward example, which happens to be the most straightforward model, is the Waterfall Model. Can’t go back, test one per cycle and focus in only one phase at a time.
The iterative model focuses on developing one feature or version for each cycle to then start again. Working on fulfilling all of the requirements little by little. Its cycles tend to be quick, and the testing is done after each version is deployed so with every new iteration bugs can be fixed.
The spiral model is very popular, it has its own four phases which are iterated over and over throughout the course of development. With constant testing and a lot of precaution this model is repeated as many times as necessary to achieve the desired product.
The decision of which is the best model for your project depends heavily on what conditions you are working under, Robert Half has summarized what his recommended model is for several cases and has included even more models that you can check out as well.
I think it’s important to clarify that, even if there’s recommendations as to what models use for each case, each developer has the final word on what methodology will be used for their product. Whatever model you choose, just make sure you do it right and everything should be fine.
TL;DR: Useful Software Life Cycle methods are useful.
Roger's Rad Records 