Post-development phases of the SDLC

The portions of the SDLC that happen after the core code of a system is written can still have significant impacts on the development cycle. Historically, they might not involve a lot of real development effort—some code may be written as a one-off for various specific purposes such as packaging the system's code, or facilitating its installation on a target environment, for example. If the structure of the system's code base or, rarely, the language that the system is written in doesn't somehow prevent it, most of any code that was written in support of post-development activities would probably be created very early on in the development process in order to meet some other need.

As a case in point, packaging the code-base, and/or the creation of some installation mechanism is pretty likely to be undertaken the first time the code-base needs to be installed on an environment for user acceptance testing. If that expectation is known ahead of time—and it should be, at some level—then efforts to write the packaging process in order to write the installer may well start before any real code is created. After that point, further efforts will usually happen infrequently, as new components need to be added to a package structure, or changes to an installation process need to be undertaken. Changes at that level will often be minor, and typically needed with less and less frequency as the process matures and the code base installation. This sort of process evolution is at least a starting point for DevOps and some Continuous Delivery practices.

The last two phases of the SDLC, concerned with the day-to-day use of the system and with its eventual retirement, will have less relevance to the core development process in general. The most likely exception to that would be re-entry into the development cycle phases in order to handle bugs or add new features or functionality (the Use and Maintenance part of the Operations/Use and Maintenance phase).

From the perspective of system administrators, the staff responsible for the execution of activities in those phases, developers are contributors to the knowledge and processes they need in much the same way that all of the pre-development contributors to the system's development were with respect to developer knowledge and processes. System administration and maintenance staff will be looking for and using various artifacts that come out of the development process in order to be able to execute their day-to-day efforts with respect to the system. The odds are good that those artifacts will mostly be knowledge, in the form of documentation, and perhaps the occasional system administration tool.

Finally, with respect to the process of decommissioning a system, taking it offline, presumably never to be used again: someone, probably at a business decision level, will have to provide direction, or even formal business policies and procedures around what needs to happen. At a minimum, those will likely include the following

• Requirements for preserving and archiving system data (or how it should be disposed of, if it's sensitive data)
• Requirements for notifying users of the system's decommissioning

There may well be more, even a lot more—it's very dependent on the system itself, both structurally and functionally, as well as any business policies that might apply.