SLDC. No, it doesn’t stand for some sexually transmitted disease. At least not in this post.
Software Development Life Cycle, that is. Okay, but what does it mean? Essentially, it’s the thing you should do to ensure some software gets to be and stays good.
Software Development Life Cycle, that is. Okay, but what does it mean? Essentially, it’s the thing you should do to ensure some software gets to be and stays good.
For this to happen, you first observe; you’ll be making some investigation and analysis. This is very important, it will tell you where to go, what you’ll need; you define expectations and requirements, communicating with the end users. You can do this by doing interviews and surveys, considering multiple cases that describe what users might do (or even show real-life users some prototypes).
Only after you gather this detailed information, should you start planning: you establish technical requirements (hardware and software) and security processes/vulnerabilities. Further specifications like how the user interaction will be (entry fields, buttons, screens). You should also think about how easy it would be in the future to add new features, and make modifications.
Then, what would maybe be your first step had you not read this: coding. The difference is that by this point you have expectations at which to aim, user-desired features, hardware/software limitations, parameters to be tested and tweaked. After this phase is completed, you’ll have the finished product, but not the end of your hard work; after every coding milestone is reached, you have to evaluate how close it came to what was actually planned. However, you should also be open-minded for unexpected changes and issues. Team communication is crucial here, for progress to be really accomplished and not get stucked on some sort of loop.
Only after you gather this detailed information, should you start planning: you establish technical requirements (hardware and software) and security processes/vulnerabilities. Further specifications like how the user interaction will be (entry fields, buttons, screens). You should also think about how easy it would be in the future to add new features, and make modifications.
Then, what would maybe be your first step had you not read this: coding. The difference is that by this point you have expectations at which to aim, user-desired features, hardware/software limitations, parameters to be tested and tweaked. After this phase is completed, you’ll have the finished product, but not the end of your hard work; after every coding milestone is reached, you have to evaluate how close it came to what was actually planned. However, you should also be open-minded for unexpected changes and issues. Team communication is crucial here, for progress to be really accomplished and not get stucked on some sort of loop.
So what do you do next? Well, you can’t (shouldn’t) just launch your software like that, testing should come . You’re going to want to consider how your software will be implemented in different environments, as well as its user acceptance. Be sure to document every step of your way, so anything can be referenced in the future. Bug capturing tools might save your life at this point. This might lead you straight back to the coding phase, or even the design phase!
Ok, so we’re done with testing. Finally we can start the deployment/implementation! Depending on how your user-testing went, you might want to decide to train end users, or at least have some initial guiding for how to use your product (although not always necessary). You’re going to want to consider location factors.
If you’ve made it this far, don’t expect it to be the end. For software to be reliable and updated, you should frequently reevaluate its whole concept from the beginning multiple times. You know, that’s why it’s called a cycle. If it weren’t, why not just create a product that’s only usable for a short time, under certain conditions and with no real future implementation? You don’t want to do that. Please.
