Did you know that building and aligning your SDLC phases around your IT operating environments yields phases that are more meaningful to your workers and that can better be measured and automated?
Best Practice: Name SDLC Phases According to IT Environments, Wherever Possible
There are two methods for SDLC phase naming and overall SDLC design. One is to use phases that have vague names and meanings and that, more often than not, serve to confuse key product developers (e.g. Software Developers and Engineers). Another is to use phases that include and are named around standard IT operating environments.
An example of a weak bad SDLC design is the one published in Wikipedia’s page on SDLC. In it, you’ll see phase names that are vague and cause confusion to the workers. For example:
- Concept Development
- Requirements Analysis
- Integration and Test
- Operations and Maintenance
You’ll notice that many of the names are not clear and meaningful. For example, what does Implementation really mean? Don’t we Implement in every environment? Where does User Acceptance Testing (UAT) fit in? What about our Centralized Build Environment, where we need to merge all software developers’ code and create a combined build? Also, since when is Design not a part of Development?
In a more usable SDLC design, you’ll see that phase names are more clearly and closely aligned with the IT operating environments they leverage. This makes them more meaningful to the people who work within them and across them:
- Procurement and Coding
- Centralized Build
- Integration Testing
- User Acceptance Testing
You can see from the above, that the alignment of IT operating environments (depicted in the color purple) is clear and intuitively purposeful.
The Benefits of Measuring and Automating
In addition to being intuitively more meaningful to workers, having IT environment based names for your SDLC allows for two very important benefits… 1) taking measurements within and across environments, and 2) automation of work within and across environments.
The Benefit of Measurement
Having phases that are clearly aligned with IT operating environments means we can now measure things like how often we’re in and how long we spend in any given environment. It also helps us understand things like how much time we spend on specific issues in specific environments, like dealing with and testing new requirements vs. fixing defects.
The Benefit of Automation
Because we can measure, we can now have clear insights into what can and should be automated to improve delivery. This becomes important for the implementation of best practices like Continuous Implementation and Continuous Delivery (CICD) and DevOps.