IF4IT SDLC Framework

Systems Delivery Life Cycle (Lifecycle)

Systems Development Life Cycle (Lifecycle)

Software Delivery Life Cycle (Lifecycle)

Software Development Life Cycle (Lifecycle)

Abstract:

The IF4IT SDLC Framework is a highly detailed but easy to use quick reference for IT professionals (i.e. practitioners and educators) and students that helps to better teach, learn, understand, and/or apply the best practices and guidelines which are associated with how Information Systems, Assets, and Software a delivered, from inception all the way through to customers and end users.

This entire document acts as a Framework, composed of loosely structured patterns, templates, best practices, and guidelines, for anyone who is interested in teaching or learning about an SDLC. The reader may use this document as an SDLC Tutorial for the purpose of instruction, learning, and guidance.

As an SDLC represents one of the most critical components of any Information Technology (IT) organization, understanding how one is designed, built, delivered, applied, supported, and optimized helps any reader better understand IT, in general.

It's also important to keep in mind that this document, like all other Foundation material, is constantly evolving in an attempt to improve its contents for the readers. So, we recommend you check back, regularly, to stay current.

If you and your enterprise want to prototype an SDLC or design and implement one, you can use this document as a baseline for the components you'll need to put in place or at least consider, in order to achieve the best possible SDLC implementation.

To best answer the question: "What is an SDLC?," it makes sense to start this document with the definition of SDLC, which is:

SDLC Definition:A time aligned and sequenced or phased methodology that often includes both manual and automated process, and that is based on the patterns and principles of Assembly Line Theory, and that exists to facilitate the inception, delivery, and operations of a single Release of an Information Technology (IT) Asset.

While the definition of SDLC is a good starting point, it is just that... a starting point. The fact is that an SDLC is a very complex and very important piece of any Information Technology (IT) organization that delivers IT Assets, such as but not limited to:

Computing Devices

Non-Computing Devices

Semiconductors

Software

Transmitters

Receivers

Systems (which include any combination of the above)

So, we now know the meaning of SDLC but there's still much more to learn to truly understanding.

As will be discussed in more detail, later, it's important to understand that an SDLC exists to facilitate Releases of technical Assets, where a Release represents a single Version of an Asset that has been adequately tested for quality and packaged for delivery to its customers and/or end users. Many Versions may have been created to get to the single Version that can be called a Release. In other words, an SDLC spans the life cycle of a single Release of an Asset and not the entire life cycle of the Asset.

It's also important to realize and understand that the importance of an SDLC lies in its Assembly-Line-like traits, which rely on high levels of repeatability to achieve higher levels of quality, lower levels of complexity, lower times to deliver, and lower costs to deliver. The more specific and repeatable your enterprise designs its SDLC to be, the more you can achieve such traits.

It's important to understand that there is no short list of best practices for an SDLC. SDLCs represent a very significant portion of any Information Technology (IT) organization, as it is the backbone for all IT delivery. This being said, the reader should look to this entire SDLC Framework as a set of SDLC Best Practices and Guidelines.

The acronym SDLC is used in multiple contexts that include Systems, Software, and Solutions. As a result, IT professionals often use a number of SDLC related terms and phrases interchangeably. Such terms and phrases include the following:

"Software Delivery Life Cycle"

"Software Delivery Lifecycle"

"Software Development Life Cycle"

"Software Development Lifecycle"

"Solutions Delivery Life Cycle"

"Solutions Delivery Lifecycle"

"Solutions Development Life Cycle"

"Solutions Development Lifecycle"

"Systems Delivery Life Cycle"

"Systems Delivery Lifecycle"

"Systems Development Life Cycle"

"Systems Development Lifecycle"

"IT SDLC" (equivalent use)

The above are all considered to be synonyms or synonymous for "SDLC".

As can be seen from the above, it's acceptable to use both the separated form "Life Cycle" and the compound form "Lifecycle." The Foundation recognizes and acknowledges both forms, "Life Cycle" and "Lifecycle," to be correct.

SDLC Best Practices: There's often no need to have separate SDLCs for Software vs. Systems or to address different complexities of Assets. Having more than one SDLC with too many customizations for different scenarios is an indication of low IT maturity and a lack of the technical skills required to optimize one SDLC to know how to deal with different scenarios. Pick one SDLC, clearly define and document it, publicize it, govern it, and adjust it to meet the needs of any Asset that runs through it.

The Foundation and its members have been involved in defining and/or using SDLCs for decades and we've come to the conclusion that all good ones are, fundamentally, the same in their layout. Different organizations, including consumers and vendor alike, have called their versions of SDLCs different things or have labeled and/or ordered phases within their versions in different ways. However, when you really break them all down and align their functions, most of them are very similar in nature. As a result, the Foundation has created a generic and cleansed version of the better SDLCs that we've come across, which we believe covers the fundamental phases of a solidly repeatable SDLC, with easy to understand labels and descriptions. The IF4IT's SDLC has 10 core phases. These phases are:

Phase I: Strategy

Phase II: Research

Phase III: Planning

Phase IV: Requirements

Phase V: Design

Phase VI: Procurement and Coding (or Procurement & Construction)

Phase VII: Common Build

Phase VIII: Integration Testing

Phase IX: User Acceptance Testing

Phase X: Production

Closing (Note: The Closing or Postmortem phase of the SDLC is often implied and, therefore, often left off many depictions of the SDLC.)

NOTE: Phases of the SDLC are sometimes referred to as stages of the SDLC. Neither is more correct than the other.

SDLC Strategy Phase

Phase I - Strategy: This phase represents the work that is performed to ensure that the System Release is fully aligned to all master strategy and intent. It also represents a time period for which System or Asset Owners will work with appropriate stakeholders to develop a high-level strategy or roadmap of work, outlining the details of a specific System Release, with the intent that all work will move forward through the SDLC.

SDLC Research Phase

Phase II - Research: This phase represents a time period where work is performed to detail opportunities and solutions options that will be presented and ratified, with the intent to decide the value of moving forward and, if the decision to move forward is agreed upon, a direction for how such solutions options will move forward. The goal is to get to a high level Solutions Architecture and a Solutions Plan that everyone agrees to, before expensive and time-consuming work is started.

SDLC Planning Phase

Phase III - Planning This phase represents a time period for Release Planning, which includes activities such as detailing what will actually go into the Systems Release (i.e. new features, break-fixes, etc.), creating initial project plans (this includes plans that are complete with accountable working organizations and people, as well as with high-level timeframes for the work. Since the SDLC pipeline of phases is a repeatable pattern, most mature enterprises will have project templates that can be used to facilitate the functions within these phases), and improving budget estimates (e.g. +/-25% estimates).

SDLC Requirements Phase

Phase IV - Requirements: This phase represents a time period of work that revolves around detailed requirements gathering and analysis for the purpose of clearly specifying what needs to be accounted for in downstream design and implementation activities. The more detailed the requirements, the higher the probability that design will align to intended Systems Release Strategy and with end user expectations for the Release.

SDLC Design Phase

Phase V - Design: This phase represents a time period for where detailed design is performed, according to Release Plans and Release Requirements. In addition to designing the operational solutions associated with functional and non-functional requirements, the Design Phase also includes designing Unit, Module, Integration, Performance User Acceptance, and Production Signoff Tests that will be used to verify the quality of all work performed in all downstream phases and environments.

SDLC Procurement and Build Phase

Phase VI - Procurement & Coding (Code or Coding): This phase represents a period of time during which the detailed design of a System Release is realized and optimized, with the intent that it will be handed off for a centralized and repeatable build that can be used for distribution/deployment, quality assurance and signoff in downstream phases and environments.

SDLC Centralized Build Phase

Phase VII - Centralized Build (Build): This phase represents a time period during which a delegated person or group of people (often referred to as the "Build Master(s)") will focus on creating a fully centralized, repeatable and automated build (automated to the best of his/her/their ability) that will be used for distribution/deployment, quality assurance and sign-off in downstream phases and environments. NOTE: It is during this phase that procurement occurs for any vendor specific products and services that are needed to realize the detailed design.

SDLC Systems Integration Testing Phase

Phase VIII - Integration Testing (Integ): This phase, which is also referred to as "Systems Integration Testing" or "SIT," represents a time period during where all data and technology connections are tested for a specific System moving through the SDLC and all of its upstream System dependencies (i.e. Systems that provide data to the System being tested) and all of its downstream System targets (i.e. all downstream Systems that the System being tested provides data to). The goal is to verify all appropriate data connections and data exchanges between Systems that will need to interact in the final Production operating environment.

SDLC User Acceptance Testing Phase

Phase IX - User Acceptance Testing (UAT): This phase exists to allow for explicit testing of System functions that End Users will be able to execute while operating in the final Production environment. Such testing ensures that what an End User does or sees meets appropriate quality expectations.

SDLC Production Phase

Phase X - Production (Prod): This phase exists to control all deployment and sign-off of System delivery to the final Production operating environment. No System delivery can be considered to be "complete" until it has been verified and ratified for operation, before final hand-off to the End Users.

Closing Phase

The Closing Phase: This phase is used to perform all post Release postmortem activities. It does not necessarily mean the decommission of the Asset so much as the clean-up that is often performed after an Asset is released to its customers and/or stakeholders. However, should the last Release of an Asset represent its decommission, then this phase would also include all decommission activities.

Given this delivery model, we can see that it maintains alignment with the Canonical Model for IT:

Figure: Alignment of the SDLC (2nd Row) to the Canonical Model for IT (1st Row)

NOTE: Many organizations will combine Phases VIII and IX, calling the combination "Quality Assurance" (QA). However, the Foundation believes it is important to break the two phases associated with Integration Testing and User Acceptance Testing into two separate phases because of the importance of each. The reader will also note that the Foundation's representation of the SDLC is scalable and that it can be customized to enter new phases in between existing phases. For example, some enterprises may have a phase called "Performance Testing" between Integration Testing and User Acceptance Testing. In essence, neither is wrong. The most important thing is that an enterprise has a clearly defined and socialized SDLC and that the enterprise manages and optimizes the SDLC for constant improvement, as a manufacturing company would manage and optimize its manufacturing plants and assembly lines, as the SDLC represents a manufacturing assembly line for IT solutions.

Some SDLCs will also explicitly include other phases, like a "Performance Testing Phase (usually before User Acceptance Testing), a "Training and Education Phase (usually before transitioning to Production), a "Disaster Recovery Phase" (usually directly after or before Production), and even a "Closing Phase" as their last phase (to address logistical clean up, after the Release is complete).

To be honest, there really is no wrong representation so long as your SDLC is clearly laid out, clearly defined, clearly, documented, highly repeatable, automated (wherever possible), governed, and enforced.

It should be obvious and no surprise to anyone that the IT SDLC phases match those of globally accepted best practices for the manufacturing of any product that is delivered to market. The case can easily be made that the phases used in the manufacturing of software, for example, are really no different than those phases used to deliver a car, a house, an airplane, or even a mobile device.

SDLC Best Practices: Have clearly defined SDLC Phases. While you may have some phases that aren't included in this Framework, do not reinvent the wheel! You're better off taking something like this framework, using it as a baseline, customizing it to the needs of your enterprise and your customers, and iteratively improving it, over time.

Each SDLC Phase is composed of numerous Phase-specific SDLC Activities. These activities, like the SDLC Phases themselves, may either be structured in a waterfall manner (which they rarely are, unless the start of one Activity has clear dependencies on the end of a previous Activity) or in more of an overlapping manner.

The following SDLC example helps highlight how activities can be aligned with and performed within each SDLC Phase. (Note, you can click on the diagram to expand it for easier reading in your browser.) The loose progression of Activities is meant to be from top to bottom and from left to right.

It's important to understand that the SDLC Activities in the above example are only meant to be just examples and a starting point. They can and should be customized to meet the needs of your own enterprise, as you may or may not need all of the activities highlighted, above. At a minimum, it is critical to account for all delivery related activities, such as deployment Activities, as logistical activities like gate reviews are often attributed with overhead.

SDLC Best Practices: Have clearly defined SDLC Activities within each SDLC Phase. The more specific and clear these Activities are to the customers and end users of the SDLC, the higher the probability that the SDLC can be made repeatable and, ultimately, optimized for delivery through it.

The following SDLC example, which you can click on to expand in your browser, shows how SDLC Phases and related activities can be laid out, over time. In this example, there is a combination of both, waterfall and non-waterfall layouts (which is very common). The Phases of the SDLC are laid out from left to right and some phases may have some overlap with other phases, while other phases may not have any overlap, at all, and may be fully dependent on the end of a previous phase before starting. Again, the progression is meant to be from top to bottom and left to right.

The above example also starts to help the reader see and understand how to frame and develop a Release-oriented and SDLC-aligned Project Plan. Setting up your Projects this way and accounting for each phase of the SDLC, along with all key activities within each phase, is considered an IT Best Practice.

Different parts of this SDLC Framework document will refer back to the above SDLC Example, as needed, to help illustrate different points and elaborate on discussion topics.

SDLC Best Practices: It's always a good idea to have an SDLC Diagram to help its customers visualize the magnitude of the work. If you can't create a dynamic experience using the web, at least ensure that you have static diagrams and the documents necessary to support your clients as they move their Assets through the SDLC Process.

Note:This section is meant to be nothing more than a short introduction to SDLC Operating Environments. Far more information about such environment and how they fit into the SDLC can be found in the Foundation's "IT Environment Framework."

As Systems evolve within and throughout the different phases of the SDLC, they get constructed, verified, and promoted from one working location to another. These locations are what the IT industry calls "Environments. These Environments are typically virtual locations, in nature, and are not necessarily physical locations, although they can be physically separated as well, if there is a requirement to do so."

One of the most complicated aspects of any SDLC is the discipline of Environment Management, which at a minimum takes into account things like the provisioning of each Environment (and all required Assets within each Environment) as needed by the System or Software moving through the SDLC, proper and efficient operations of all Assets within each environment, sharing of Environments by multiple Assets, and support of each environment.

Because of 1) the complexity and importance of SDLC Environments, 2) the requirement that operations within and across them be fast, accurate, and cost efficient, and 3) because of the high frequency associated with the provisioning, operating, and tearing down of such environments (often dynamically), the responsibilities for Environment Management are often assigned to Software Engineering teams, who have the advanced technical skills required to know how to automate and rapidly perform the work associated with and necessary to be performed in each Environment. The most successful enterprises know to invest in such functions, as they are at the heart of rapid movement throughout the SDLC. NOTE: At a minimum, you can think of your Software Engineers as your Pit Crew.

While many environments can exist for various reasons, there are six (6) that are part of the core SDLC and are considered to be standard. These six core or standard SDLC environments are:"

Alternate Environments: In addition to the standard SDLC aligned environments, listed above, enterprises will create alternate environments to address their own needs or those needs that may be outside of the SDLC, itself. There are many alternate Environments. A few examples include but are not limited to:

Performance Testing Environment

Disaster Recovery Environment

Training Environment

What Environments enterprises standardize on are really a matter of the needs of each individual enterprise. However, as most experienced IT Professionals will tell you, the type of enterprises rarely, if ever, need to be that different from one enterprise to another. Most people will voice their belief that they are different. However, when you take the time to dissect their processes and their needs, you'll find that their fundamental needs are really not too different, at all.

SDLC Best Practices: It is considered a best practice and a sign of maturity when an enterprise does, in fact, standardize its Operating Environments, the process through and around them, the offerings within them, the shared services that enable and support them, and their explicit integration into the enterprise's documented, published, socialized and governed SDLC. A mature experienced IT Professional understands the highly detrimental and negative impacts of manual operations and, therefore, aggressively works to eliminate manual labor or operations within all environments, wherever possible, through the automation of processes that help deliver things to and through Operating Environments. Another sign of maturity comes with understanding the concept of installing "Shared IT Services" that operate within and across appropriate environments. This concept of Shared IT Services will be explored later.

Again, this section is meant to be nothing more than a short introduction to Operating Environments. We recommend that you read and analyze the Foundation's "IT Environment Framework for a greater understanding of Environments, their purposes, how they're provisioned, and how they work."

SDLC Best Practices: Clearly know, define, document, and staff for effective Environment Management. Provisioning, operating, supporting, and tearing down environments, on demand or dynamically, can drive costs up very rapidly if such processes aren't proactively owned, managed, and improved. A smart enterprise invests in good Environment Management to support good SDLC Practices.

Once an enterprise has standardized on the environments its Systems will pass through, as they move through the SDLC, it becomes clear that the functions performed on or for any given System, in any environment, follow a repeatable pattern.

Accept From Previous Environment

Build & Package

Distribute

Install

Instantiate

Initialize

Execute (and Run Verification Tests)

Sign-Off

Promote to Next Environment (or to Final End Users, if in Production)

These functions are also known as Deployment Functions and you can read more about them in the IT Deployment Framework, which talks about the importance of performing these functions, consistently, within each Phase of the SDLC that has an Environment.

As a matter of best practice and as a sign of maturity, enterprises that understand Information Technology (IT) Operations will, first, ensure that these Deployment Functions are performed as consistently as possible, in every Phase of the SDLC that has an Environment, and then try to automate as many of the above functions as possible to eliminate waste, raise quality, and to optimize their costs. You can read about which Deployment Functions can be automated, how, and why, in the IT Deployment Framework.

Another sign of IT maturity and best practice is to ensure that each of the above functions is accounted for in all project plan templates that are used to control delivery of any System, through the SDLC. Enterprises that deliver solutions through their SDLC, over and over again, use templates to ensure 1) that they don't reinvent the wheel every time they start a new project and 2) to ensure "completeness" of work that needs to be performed, throughout the project. Having all of the above functions listed in your project plan, as clear milestones with clearly defined sub-tasks, in each and every environment, can only help increase the success of delivery for any project.

The following diagram shows how these SDLC Functions are spread across SDLC Operating Environments, in a uniform manner...

SDLC Best Practices: Clearly know, define, document, understand, and staff for the Deployment Functions that your enterprise will require to repeat, over and over again, as they move their Assets through the SDLC. Where possible, automate as many of these functions as you can, as this is where you can gain significant economies of scale and automate the gathering of metrics, such as the time it takes to perform each function, for each iteration through any of the SDLC Phases.

Given that we now understand how SDLC Phases are laid out and how Deployment Functions are performed within each environment, it becomes important to understand the concept of an SDLC Release, or what is sometimes referred to as an SDLC Cycle. A Release is considered to be one successful pass or Version of an IT Asset (i.e. a System, Software, etc.) that will move or has moved completely through the SDLC.

Deployment Functions are performed within Environments, SDLC Activities are performed within each Phase, and a Release is a successful cycle through the SDLC, from start to finish.

It's important to note that an Asset or group of Assets may change many times before it is stabilized for final Release. Every change represents a new Version of the Asset(s). This is where Configuration Management becomes critical to implement and maintain, as doing so allows the reconstruction of any and all Versions of the Asset(s) that move through the SDLC, at any point in the Life Cycle. This is accurate even if they were deemed to be flawed. Such Configuration Management allows an enterprise and its resources can always recreate and go back to any state of such Assets.

SDLC Best Practices: Ensure that the resources within your enterprise are clear on the language of Releases versus Versions and how each fits into every Phase of the SDLC. Also, implement and ensure strong Configuration Management solutions to ensure Version control for any and all Assets that move through the SDLC. Wherever possible, automate as many of these functions as possible.

One of the most common mistakes made by an IT organization is to not have clear and accountable ownership for its SDLC. Since an enterprise's SDLC is the backbone for all delivery, it should be clearly owned and maintained in a manner where everyone who has a stake in it knows who to turn to for help and improvement. Also, there will be no clear way to measure performance of delivery through the SDLC if there's no clear organization (or person) that owns and is accountable for constantly improving it.

SDLCs are based on Assembly Line Theory and they represent a Virtual Assembly Line. In a manufacturing plant, Industrial Engineers are constantly made accountable for the design, implementation, support, and constant improvement of their manufacturing facilities, including all Assembly Lines. Interestingly, it's been discovered that far too many IT organizations have no clear and accountable owner for their SDLCs. As a result, they wonder why their delivery is slow, has low quality, is considered complicated, and has high costs associated with it. If there is one important thing to take away from this entire framework about SDLCs is that they're almost useless without clear ownership and without clear accountability for them.

Good examples of areas where enterprises often place ownership of their SDLCs include but are not limited to:

Software Engineering Organizations: Usually an excellent result, as Software Engineers tend to understand complex system design and delivery, as well as what it takes to automate different areas of delivery.

Systems Engineering Organizations: Also another good area, for the same reasons as those associated with assignment to Software Engineering Organizations.

Architecture Organizations: Also another good area, for the same reasons as those associated with assignment to Software Engineering Organizations. However, this is only true if such Architecture Organizations are technical enough to know how to automate different aspects of delivery.

Software Development Organizations: This tends to work for Software but not too well for Systems, as Software Developers don't all have broader Systems Design and Delivery Experience.

Examples of areas where enterprises should almost never place ownership of their SDLCs include but are not limited to:

Program Management or Project Management Organizations: Project delivery is not the same as Systems or Software delivery. Also, most Program and Project resources have no experience automating delivery.

Hardware Engineering or Hardware Infrastructure Organizations: While very technical, such resources usually have very little understanding of the design and delivery of complex Software, which is at the heart of most IT delivery. Also, these types of resources usually have little or no coding experience and, therefore, have little ability to automate delivery.

Support Organizations: See the reasons for not assigning ownership to Program and Project Management Organizations.

Quality Assurance or Testing Organizations: See the reasons for not assigning ownership to Program and Project Management Organizations. While some Testing Resources know how to automate Tests/Testing, the complexity of automating other areas of Delivery are usually beyond the reach of Quality Assurance and Testing skills.

SDLC Best Practices: Assign a very clear organization (or person, if you're in a smaller enterprise) as the owner of your SDLC and make that ownership highly accountable for constantly improving all aspects of the SDLC for the enterprise. Such accountability should include the responsibility for automating as much of your SDLC as possible.

SDLC Best Practices: Another very important practice is to make sure there is very clear and accountable ownership for any and all Assets moving through the SDLC, as these owners represent the customers or end users of the Release and Deployment processes, through the SDLC.

SDLC Note: While it's a common practice for larger enterprises to implement segregation of duties, there is technically nothing that says that the owner of an SDLC can't also be a customer of the same SDLC. In fact, in smaller enterprises, where there are far fewer people and individuals perform any different Roles and Responsibilities, it is very common for the owners of the SDLC to also be customers of it, owning critical Assets that they also run through its SDLC Phases and SDLC Processes. In fact, there's a strong argument for allowing the SDLC Owners to also be SDLC Customers, as it enures that the SDLC Owners understand the same needs and constantly experience the same issues that SDLC Customers need and experience.

The first way to create security in your SDLC is to create separation of roles or separation of duties. Examples of such separation include ensuring that only one User ID can log into a system and run a Build, while another completely different User ID is used to run Packaging functions, and so on. Such separation helps to ensure that anyone whose responsibility it is to carry out a specific role, cannot damage the work performed by others in other roles.

Note that it doesn't always make sense to separate by Roles and User IDs, as you may want to use one common ID when automating Activities and Functions in your SDLC.

Another common means of creating security in your SDLC is to separate Environments. By doing so, you can minimize the damage of functions performed in any one Environment on any other Environment. Readers can find more information about Environment Separation in the IT Environment Framework.

Note that Separation of Environments does not mean that Assets in any one Environment cannot use, Data, Information, and sometimes even Assets from other Environments, especially when pointing to other Asset SDLC pipelines. Sometimes, it is quite necessary to do so.

SDLC Projects are equivalent to IT Projects and represent the movement of Assets through the SDLC.

An SDLC Project, or what others in the IT community might call an IT Project, is a Project that moves one or more Assets through the SDLC Phases, in order to deliver one or more Releases of that Asset or Assets to the final customers and/or end users. Such a Project might move only one Asset through the SDLC Phases, by itself, or multiple Assets through the SDLC Phases, either in parallel or at different times (depending on how dependencies are laid out for that Project).

Given this definition for an SDLC Project, we can now answer the question: What is SDLC Project Management? SDLC Project Management is the professional discipline or practice of managing SDLC Projects, from inception through to completion.

Given that an IT Project can be represented as a Release (i.e. a single iteration through the SDLC), it now becomes apparent that each phase of the SDLC becomes a timespan of grouped or related Activities or Tasks in the Project Plan, which is sometimes (but not often) referred to as an SDLC Project Plan. This means that the completion of every SDLC phase or SDLC Project Phases represents the completion of a major IT Project "milestone." This pattern can be applied as a consistent and repeatable pattern to any IT Project that focuses on the delivery of an IT Solution (i.e. a Product, Service, System, Application, etc.) The following figure is a high level example of what an IT Project Plan starts to look like when SDLC phases are used as the framework for laying out SDLC-specific Activities or Tasks across an intended period of time (in this example, approximately four calendar quarters).

SDLC Best Practices: Use SDLC Phases as a means to lay out your IT or SDLC Project Plans to include each SDLC Phase as a timespan control for the work performed within each Phase.

SDLC Best Practices: Ensure that Project Plans that drive Assets through the SDLC are clearly aligned to the SDLC by using SDLC Phases as Project Milestones and by ensuring that all SDLC Activities are clearly covered in the Project Plan for completeness.

This entire document covers the work that is performed within and across each SDLC Phase. However, when implementing an enterprise SDLC, it becomes very important to understand both sides of the work for each and every Actitivy that is performed.

The first side is the obvious one that is directly related to the SDLC End Users or SDLC Customers. This side is demand-oriented and is the work done by someone trying to move his or her Asset(s) through the SDLC. The other side represents the work done to support such people. This other side is the demand side of the work equation. For example, someone who needs to work in an Environment would be considered the customer of the Environment. The person or organization that sets up, provides, and maintains the Environment is the Service Provider, in this case.

SDLC Best Practices: It's considered a Best Practice to define, implement, deliver, and support very clear SDLC Services to support all work within and across SDLC Phases. This means having clear Service Owners, clear Service Organizations (with Service Resources) that act as Service Providers, clear Service Deliverables, and even clear Service Level Agreements (SLAs) so that customers of such Services can work as efficiently as possible. And, wherever possible, it is considered a Best Practice to automate as many of these Services (or pieces within them) as possible. For example, automating Software Builds and Software Distribution is very common.

Given the very clear breakdown of SDLC Phases, SDLC Activities, SLDC Environments, SDLC Deployment Functions, and SDLC Projects (or IT Projects), we can now identify clear roles that are aligned with and required for each phase of the SDLC (i.e. work within Phases), as well as those that need to work across Phases.

Examples of the SDLC Roles that need to work within SDLC Phases include but are not limited to:

Phase X: Production Related Roles Production Environment Deployers, Production Environment End Users, Production Environment Support, Production Environment Administrators

NOTE: For each of the above, that have associated Deployment Roles (e.g. "XYZ" Deployers), the Deployment Role can be further broken down into each of the Deployment Functions, such as Builder, Packager, Distributor, Installer, Instantiator, Initializer, Executor.

Should your SDLC use other Phases, not specified above, such as Performance Testing and Training and Education, you can simply define Roles for those phases, as they have been defined, above.

Examples of the SDLC Roles that need to work across SDLC Phases include but are not limited to:

Owners Managers

Release Managers

Program Managers

Project Managers

Each SDLC Activity, within each SDLC Phase will also have specific Roles associated with it. It will be up to you and your enteprise to identify, implement, and support such Roles.

It's also very important to understand that each Role does not require a unique individual or Resource per Role. One person can act in as many Roles as it makes sense to do so for your enterprise. The simplest example is in a Small Enterprise, where one or two people might be accountable for all of the above.

Sometimes, you'll hear people say the phrase SDLC Steps in the context of an SDLC. We recommend not using this phrase as it is ambiguous and could unclearly refer to either the SDLC Phases or the SDLC Activities, with in any Phase. Ambiguous language such as this can lead to confusion among stakeholders and, therefore, should be avoided whenever possible.