There was a recent question posed on LinkedIn about what the acronym SDLC means when you see it in a job posting. The question was asked by a person identifying themselves as a job-seeking business analyst. I followed the thread with amusement as the many responses were posted, none of which answered the question adequately. Of course, I couldn’t resist putting in my two cents only to have someone snidely remark, “It’s good to hear from a self-proclaimed expert on the SDLC.” The commentator then went on to offer badly formed advice. It is very amusing!

The truth is the SDLC is not just about software. While software is a major focus of any SDLC, it is not the only focus.  That’s why I prefer to define the acronym SDLC as System or Solution Development Life Cycle and not Software Development Life Cycle. To do otherwise is a misnomer. Need proof?

Think about all the projects an IT organization takes on. It doesn’t matter if the project is in telecom, infrastructure, application development or even outside of IT as in opening and outfitting a Greenfield location. True or False? All of these projects have certain process commonalities that can be governed by an effective SDLC. Every project needs to:

1. Elicit and analyze requirements
2. Develop design specifications
3. Define success metrics
4. Produce clear, consistent and unambiguous artifacts
5. Deliver products that comply with the highest quality standards that meet or exceed customer expectations
6. Transfer knowledge to operational support and maintenance personnel, sometimes to outsourced, off-shore locations
7. Train end users and support resources
8. Offer post deployment support and maintenance

All of these development aspects are governed by a well-defined and effective SDLC. It doesn’t take a giant leap if faith to conclude that the SDLC is not just about software.