Whether green-field or retro-fitting uSDLC, the top layer can consistently be – Vision – Design – Environment.
There is no way to start a project but with a single paragraph describing the overall vision. Once you have created your project uSDLC document, drop this paragraph into the top of the Vision section.
Next, split all your great ideas into Benefits, Features and Requirements. Stick with the “Rule of Threes” where you can – but the main thing is to move from mind to the written word before the mind moves on to new horizons.
Design is about how. Vision is about what and why. They cut across the project from different perspectives. So, when you feel the need to repeat a design definition or don’t know where a section goes in the design, it is probably better suited to the vision.
Perhaps this will be clearer with an example. “There is a countdown timer” is a benefit or a feature. If we put it into the web design, we would need to repeat ourselves in the mobile application design – and the two may not match.
Every paragraph in the vision will refer to one or more sections in Design or Environment. uSDLC creates tasks to make sure that these references exist.
The software application is, implemented and verified in this section. Pages in the design will be the day-to-day home of the analysts, software designers, developers and testers.
You will notice no implementation section. This is because design and implementation hold a one-to-one relationship. All implementation and test code is reference by and contained within the design. To generalise, the structure will look like:
design (doc) -> verification (dsl) -> implementation (code)
Of course this is over simplified – and only part of an agile development loop. In practice discoveries during implementation will cause a loop back to design to create a new or extend an existing component.
Every design page will reference to either the parent design or to a section in the vision. uSDLC check for and raises tasks if this referential integrity cannot be found.
A software application does not run in the ether (although it can run in a cloud). The environment is all the supporting ‘stuff’ – architecture, frameworks, hardware, communication…
A lot of this ‘stuff’ is defined very early in the project. It is difficult to create spikes during early design phases without knowing the platform.
It is common for architecture and environment documentation to atrophy in later stages of a project – to become (shock, horror) artifacts. This is not to be. Things change as we learn more and as time passes. Updates to a framework are much easier to maintain if earlier work is documented. Changes to the network may not reach production if done on-the-fly. uSDLC helps keep environment documentation alive by creating review tasks.