The main purpose of any organization’s Software/Systems Development Life Cycle (SDLC) plan is to outline the process it employs to design, develop, test, implement, and maintain high-quality software applications and systems with the goal to meet or exceed customer expectations.
If you ever are asked to evaluate an organization’s (SDLC) plan, or to compose or upgrade your organization’s SDLC plan, you can easily find templates and detailed examples from which to start on the web. Nevertheless, there are at least three critical themes which are often overlooked when most create or evaluate a SDLC plan.
Security
It may seem superfluous these days to cite security as a theme which is overlooked in technology. However, you might be surprised at how many SDLC plans either don’t mention it, or barely reference it. For some software developers or business executives, it may be considered an afterthought, or something which is bolted-on at the end of the software development process. A real SDLC plan is not sound unless it incorporates security throughout the software development process. Best practice is to attempt to build in security at every discrete step in your SDLC process.
Most SDLC plans enumerate most of the following phases: planning, requirements gathering, analysis and design, development and implementation, testing, deployment, evaluation, and maintenance. As you compose or upgrade your SDLC, if you discuss with your team how best to incorporate good security practices at each distinct step, it’s easy to understand how more effective and efficient your team will be at creating a secure application or system. For instance, does the SDLC call for regularly monitoring and evaluating your application or system with regard to errors, login devices, login failures, and new user account creation? Or, during requirements gathering with the customer, does the SDLC call for reviewing how much personal information information is required and can any of it be trimmed down or discarded without negatively impacting the user? Does your SDLC ensure your developers get and remain familiar with the OWASP Top 10 Vulnerability List or the SANS Top 25 Most Dangerous Software Errors List? Is there a standard process called out for incorporating third party libraries not just for licensing, but also for utilizing tools to ensure good security practices?
Regulatory Environment
If your organization’s application or system handles regulated data, such as protected health information, or credit cards, you need to make sure you compose your SDLC with the relevant regulations and standards thoroughly referenced. This may seem obvious, but many times it doesn’t seem to be a consideration in the SDLC. Perhaps this is because it is composed in the early days of the business, when the people involved had this top-of-mind. Nevertheless, you need to refer to and reference those documents throughout your SDLC plan which pertain to the relevant standards for say, Sarbanes-Oxley (SOX) compliance, the Health Insurance Portability and Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI-DSS), the ISO 27001/27002 Cybersecurity Framework, the NIST Cybersecurity Framework, or whatever is required for your business market. That way, as your business and its teams grow and evolve over time, you will have sound documentation by which every relevant party can get up-to-speed about the unique requirements for the business.
Organizational Buy-In
A good SDLC document will help set expectations of the entire business including sales, customers, support, R&D, and the executive team. It shouldn’t be composed in some corner of the business by a software developer, or it may not consider and appreciate real business concerns – like profitability, time-to-market, or customer satisfaction. Nor can it be composed only in the executive suite, because it probably will not be embraced by the development team. A real SDLC plan can be a great asset to the business only if all the relevant parties believe in it and are provided ample opportunities for input and discussion both during drafting of the SDLC and during times it is altered significantly.
Conclusion
The next time you compose, update, or evaluate a SDLC plan, keep these themes in mind so you will create a SDLC plan that is not perfunctory, but one which is adopted and becomes a real asset to your organization, its employees, shareholders, and customers.