In the most general terms, (Systems) Software Development Lifecycle (SDLC) is a process that describes how software or systems are built from beginning to end. There are many methodologies that can be used to develop software including Waterfall, Incremental, Rapid and Agile. No matter which methodology or combination of methodologies are used, a well-defined SDLC process is critical to all successful software development projects.
In addition to being formalized, an SDLC process must be usable by all departments and team members that are associated with the process. It’s pointless to have an SDLC process that is either too complicated that it can’t be followed, or one that’s so simple that it doesn’t provide procedures for all aspects of software development.
When a process is too complicated people will naturally try to circumvent steps to make their jobs easier. This will ultimately cause problems, especially in any type of regulated industries such as banking, payments, e-commerce etc. If it’s over simplified, the benefits of a formalized repeatable process will never be obtained since there will be too much room for individual judgment in the process.
A good SDLC process will be tailored to fit an organizations specific need. Again, the most important thing to remember is that the process should cover as many areas of the development and testing process as required by the individual organization and it should be easily repeatable.
Here is an example of the high level steps of an SDLC process.
- Project Request – An organization will typically have a process used to request a new project. This process could be initiated by filling out a form, sending an email or requesting it in person.
- Request Approval – In some companies project requests go through a formal approval process, which involves business justification and various committee review. Smaller companies may only have one person that all requests live or die through.
- Requirements – Typically project requirements are gathered by a combination of business analysts, project managers and technical staff. The more details and clear the requirements, the better chance a project has of success. If the organization has a separate QA department, this is generally where they would get involved to start developing test procedures.
- Design – Once the requirements are established, a member of the technical staff such as a lead developer will come up with a design. The design should encompass all aspects including UI, UX, services, data etc.
- Design Approval – Once the design is complete it should be reviewed by a senior member of the technical team such as a systems architect.
- Development – This phase is pretty much self-explanatory. It’s where the design is implemented in code.
- Unit Testing – During the development process individual pieces of the code are unit tested. There are many ways to do this from exercising code paths to formal unit test suites. Typically the size and budget of the organization will dictate how this is performed.
- Code Review – Once code has been complete, it’s imperative to have a code review process. This can include peer review as well as formal code review tools.
- Development Testing – Development testing would typically take place against a dedicated test system. This allows other members of the technical staff to perform testing of the integrated design.
- QA Testing – After the development team has completed their implementation and testing, a project would be handed off to the QA team. The QA team will run the test procedures that were developed during the development process. Any defects that are picked up here will be returned to development for re-work.
- UAT Testing – UAT or User Acceptance Testing is where the users that will be the ultimate consumer of the new project or feature set can test prior to production.
- Security Testing – At a minimum, any public facing systems should undergo a thorough security analysis. This can be done internally using a dedicated security analysis tool, or it can be handled by a 3rd party firm that specializes in security auditing and code review. The level of testing required depends on the nature of the system.
- Production Release – After all testing has been completed, the new features are ready for release. This process could be done as a one off for the individual project or included as part of a larger release.
- Production Review – Once the production release is complete, the business unit that requested the project will assist in a review to make sure the features work as expect in the production environment.
Since a picture is worth a thousand words, here is a flow chart that illustrates the implementation of the process above.
