Computer terms come and go everyday. It seems that as soon as you learn one process, another “New and Improved” process comes along! And of course, they’re TLA’s (Three Letter Acronyms) or more. I want to step back a bit and talk about one that should stick around for a while.
SDLC (or Software Development Life Cycle) is one of many processes that we, as developers are supposed to follow. Now I know, especially in small shops, it’s more of a rush to release and full steam ahead, but a simple process can save time and money in the long run. After all 1 small bug can take weeks or even months to find, and a little process might kill that bug before it ever gets out of the lab.
The approach that we take is fairly simple. In fact it seems more complicated on paper than in practive, but it has caught quite a few bugs, and saved us a great deal of agravation.
The 7 Steps to SDLC
1. Requirements – This is the most important step. Now I know that I ahve been as guilty of this as the rest of us, but no code should be written until you have gathered as complete a set of requirements as you can. Lack of good requirements are more likely to cause you to have to back up and start over than any other issue! Once you have good requirements, you can start…
2. Development – The developer writes code for a new product, or makes changes to an existing product, hopefully with carefully thoughout requirements (this is a bigger problem than you might think. Remember, without good requirements, you will be returning to this step again).
3. Unit Testing – This is the smallest and simplest test effort. In plain english, the developer tests his own code, since he has a pretty good idea of what changed. This is usually performed within Visual Studio (for example). There are also quite a few code libraries available to help automate this testing to some degree. Issues are returned back to development for correction.
4. CIT (Component Integration Testing) – Still the developer, this test is a broader test of what changes might effect. The entire solution is tested (still probably in the Developer Environment), and side effects are identified and corrected by returning back to the development step.
5. SIT (System Integration Testing) – The completed project is installed on an environment similar to the production environment and full testing is preformed against the entire system. In larger shops, dedicated testers perform this testing. Any issues may be returned to the development step for correction.
6. UAT (User Acceptance Testing) – In this step, the user or users actually test the software. The key here is to identify issues that either don’t work like expected, or don’t match the requirements. In my opinion, this step should not be performed by developers, because they know how it works! The end user knows how they expect it to work, and these 2 points of view don’t always match. Remember, drawings that look good on paper, kill test pilots! Issues identified here may return back to the development step for correction.
7. Implementation – You’re done! Well maybe not….Remember issues may still be identified here that will need to be fixed in a later release.
The thing to remember here is that each step is a gate. A decision is made as to whether an issue warrants correction and is big enough to stop the process. Some issues get listed as known issues to be fixed in a later release, and some must be fixed right now. Depending on your internal process depends on who makes that call.