7. Requirement to Deploy Functions
Description
The Requirement to Deploy functions, informally referred to as “Build” enable the creation of high-value Product Releases for new and existing Digital Products that:
-
Are aligned with, and tested against, all new or modified requirements and features, including non-functional requirements such as security, risk, and regulatory requirements
-
Are deployable into standard catalogs, instantiated automatically for any kind of consumer
-
Are instrumented to support effective operational and financial measurement and management throughout the product lifecycle
-
Are packaged for immediate or future deployment through the Deploy value stream
-
Include all changes made to the Digital Product throughout its lifecycle
The Requirement to Deploy functions support the creation of automatable Release Packages for all types of market-facing, internal-facing and foundational products including custom-built software, cloud-native applications, configuration of vendor solutions such as package-based software (COTS), SaaS, infrastructure products, and platforms used to host or support other Digital Products.
The Requirement to Deploy functions support all product engineering activities including technical design, requirements management, backlog and implementation management, sourcing, solution development and configuration, software maintenance, testing, defect management, and release packaging.
The Requirement to Deploy functions are methodology-independent, supporting all approaches to creating Product Releases. The Product Backlog Items (e.g., feature, business requirement, non-functional) are abstractions of implementation tasks. They may originate as a Requirement, Portfolio Backlog Item, Policy, or Problem; or may arise directly within the implementation team during solution development work. Regardless of methodology, the Requirement to Deploy functional components and data objects remain constant.
The Requirement to Deploy functions contain the following functional components:
-
Develop functionality:
-
Product Backlog component
-
Requirement component
-
Product Design component
-
Source Control component
-
Pipeline component
-
Build Package component
-
Release Composition component
-
-
Test functionality:
-
Test component
-
Defect component
-
Related Value Streams
The following value streams use one or more functional components from the Requirement to Deploy functions:
-
Integrate
-
Release
-
Deploy
Business Benefits
The Requirement to Deploy functions describe a prescriptive framework of required functional components, integrations and data objects so organizations can deliver better value, sooner, and safer with lower costs while improving the productivity of the product teams.
The key benefits of using the Requirement to Deploy functions are:
-
Reduced lead time of delivering Product Backlog Items (e.g., new features or resolving Defects or Problems)
-
Increased deployment frequency of new Product Releases
By using the same automatable architecture across teams (and by implication, standardized tools for the most automatable parts of the development and release chains), release frequency can be made more predictable and manageable. By ensuring that the Product Release includes all the content needed for automated instantiation, the Requirement to Deploy functional and data models provide an architecture able to decrease the time from committed code to live systems to zero.
-
More complete and more traceable testing capability, which should result in higher change success rates and reduced security risks
-
End-to-end transparency and traceability from requirement and/or backlog item to Product Release
-
Reduced risk due to Security and Compliance by Design
The Requirement to Deploy functions maintain the association between Policy and Requirement data objects throughout the product lifecycle. This persistent traceability enables designers to ensure that all non-functional requirements are accounted for, so that products are designed in accordance with standards and policies from sources such as Security Management, Governance, Risk, & Compliance, Legal & Regulatory, Enterprise Architecture, and Financial Management.
-
Improved interoperability, communication, and collaboration among involved stakeholders and teams (including external vendors)
Applications and services may be sourced or developed in cooperation with many different parties, all of which work with their own processes and tooling. The Requirement to Deploy functional criteria define a standard for interoperability that enables digital organizations to enforce a consistent, standardized description of planned activities and interoperability of functions and data.
-
Standardized product development and delivery to the point where the reuse of service components is the norm
The Requirement to Deploy functions enable the creation of consistently defined libraries of reusable artifacts by prescribing how to manage Requirements, Source, documentation, test scripts, Service Monitors, and other artifacts of the service development lifecycle as standardized data objects. The explicitly defined interfaces of the Requirement to Deploy functions means that access to such libraries can be extended across multiple organizations and locations. When access to these libraries is integrated with implementation tools such as Integrated Development Environments (IDEs), and supported by management direction, a dramatic increase in reuse becomes a realistic goal.
-
Accelerate the sourcing and delivery of products and services through best practices such as:
-
Reuse – manage, maintain, and leverage reusable components and services
-
Automation – identify the core functional components and data required to streamline the Integrate value stream
-
Collaboration – use data to institutionalize collaboration of teams involved in the development lifecycle
-
7.1. Develop Function
The Develop functionality is centered around the development, enhancement, and maintenance of Digital Products.
7.1.1. Product Backlog Functional Component
Purpose
The Product Backlog functional component manages the creation of, and provides the ongoing execution, oversight, and management of all work items (Product Backlog items) involved in the creation, modification, or improvement of a Digital Product throughout its entire lifecycle, delivered through Product Releases.
Product Backlog functional component manages the lifecycle of Product Backlog Items including organization of Product Backlog Items into prioritized and rationalized team backlogs. It maintains the linkage / traceability from Portfolio Backlog Items to Requirements and Product Releases. It aggregates, tracks, and reports status, resources consumed against the plan (e.g., project, iteration or sprint plan), and communicates these to stakeholders.
The Product Backlog functional component also receives Defects from the Defect functional component to enable the development of fixes and/or temporary workarounds.
The Product Backlog functional component supports the value streams:
Functional Criteria
The Product Backlog functional component:
-
Shall be the system of record (authoritative source) for all Product Backlog Items for a specific Digital Product
-
Shall define standard types of Product Backlog Items such as product epics, product features, and user stories
-
Shall include security, risk, and compliance Product Backlog Items to ensure security and risk management stories are fully embedded into each Product Release
-
Shall have the ability to organize Product Backlog Items into groups associated with a specific Digital Product or implementation team.
-
Shall prioritize each of the Product Backlog Items
-
Shall define the value for the customer of each Product Backlog Item
-
Shall have the ability to capture and maintain the size and effort of each Product Backlog Item
-
Can have associated requirements, including non-functional requirements
-
Shall define acceptance criteria for each Product Backlog Item
-
Shall define the “Definition of Done” for each Product Backlog Item
The Definition of Done is an agreed set of criteria that must be completed before a Product Backlog Item can be considered as “done.” This may include administrative tasks not directly related to acceptance criteria.
-
Shall have the ability to calculate the business impact and cost of delay for each Product Backlog Item
-
Shall have the ability to record risks associated with Product Backlog Items
-
Shall manage the lifecycle and status of the Product Backlog Items
-
Shall coordinate the planning (e.g., sprint plans) of Product Backlog Items and provide ongoing execution oversight of Product Backlog Items
-
Shall aggregate, track, and report status, resources consumed against the plans, or burn down charts, and communicate these to stakeholders such as Financial Management
-
May integrate with the Collaboration & Communication functional component to engage with different stakeholders during design, development, deploy, and test management activities
-
Shall maintain traceability between Product Backlog Items and associated products and service(s) being developed
-
Can relate a Product Backlog Item to a Portfolio Backlog Item
-
Can decompose Product Backlog Items into sub-Product Backlog items (e.g., features with related user stories)
-
Can use different methods or practices to manage and visualize the backlog items such as Scrum, Kanban, or traditional Project Management methodologies
-
Shall maintain the linkage/traceability from Portfolio Backlog Items to actual realization in Product Releases
7.1.1.1. Product Backlog Item Data Object
Purpose
The Product Backlog Item represents a work item associated with a Digital Product that when fulfilled will be associated with a Product Release.
Types of work item vary depending on development methodology and may include epics, features, stories, story tasks, fixes, enhancements, and so on. Product Backlog Items describe the full range of work and artifacts required to complete the Product Release. This includes not only code and configuration information, but also the creation of other deployable artifacts under version control such as training material, user guides, and pricing tables.
A Product Backlog Item can be decomposed into a set of more granular Product Backlog Items; for example, a feature can be decomposed into user stories and related tasks. A group of Product Backlog Items can be assigned to a specific implementation phase, such as an iteration or sprint.
Key Attributes
The Product Backlog Item data object shall have the following key data attributes:
-
Id: unique identifier of the Product Backlog Item
-
Title: short description of the Product Backlog Item
-
Type: type of Product Backlog Item such as epic, feature, and story
-
Description: detailed description of the Product Backlog Item
-
Status: status of the Product Backlog Item
-
Parent Id: unique identifier of the parent Product Backlog Item (decomposition/refinement)
-
Budget: budget for the Product Backlog Item
-
Actual Spend: actual spend on the Product Backlog Item
-
Start Date: Product Backlog Item start date
-
End Date: Product Backlog Item completion date
-
Size: size of the Product Backlog Item; for example, in story points
-
Definition of Done: list of criteria which must be met before a Product Backlog Item is considered "done"
-
Priority: priority of the Product Backlog Item
-
Value: scoring of the Product Backlog Item in terms of business value
Key Data Object Relationships
The Product Backlog Item data object shall maintain the following relationships:
-
Product Backlog Item to Digital Product (n:1): a Product Backlog Item belongs to one Digital Product
-
Portfolio Backlog Item to Product Backlog Item (1:n): a Portfolio Backlog Item can be decomposed into one or more Product Backlog Items (refinement of Portfolio Backlog Items)
-
Product Backlog Item to Product Backlog Item (1:n): a Product Backlog Item can be refined into one or more sub-Product Backlog Items (parent and child Product Backlog Items)
-
Product Backlog Item to Product Backlog Item (n:m): a Product Backlog Item can be dependent upon or related to other Product Backlog Items
-
Product Backlog Item to Product Release (n:1): a Product Backlog Item will be associated with one Product Release; larger Portfolio Backlog Items which cannot be delivered in one release will need to be decomposed into sub-Product Backlog Items (refinement)
-
Product Backlog Item to Product Design (n:1): a Product Backlog Item can modify and/or realize a (part of the) Product Design
-
Product Backlog Item to Source (n:m): modifications in the source code need to be linked to a Product Backlog Item (with a merge request)
-
Product Backlog Item to Defect (n:m): a Product Backlog Item can be related to one or many Defect records in order to investigate and resolve the Defects
-
Product Backlog Item to Requirement (n:m): a Product Backlog Item must be associated with one or more Requirements (such as non-functional requirements); a new or changed Product Backlog Item may require creation or modification of one or more Requirements
-
Product Backlog Item to Test Case (n:m): a Product Backlog Item can have one or more Test Cases defined in the Test functional component
7.1.2. Requirement Functional Component
Purpose
The Requirement functional component manages the Requirements of a product throughout its lifecycle. Requirements are associated with the Product Backlog Items managed in the Product Backlog. The Product Backlog manages all epics, features, and stories, which are short-lived, and closed once completed, while the Requirements are long-lived and provide the definitive specifications of the product. This definitive list of Requirements is also used for regression testing.
|
Note
|
The Requirement functional component also tracks non-functional requirements, such as those related to security, risk, privacy, and compliance. These non-functional requirements are derived from the Policy functional component and are selected based upon the outcome of risk assessments such as a Security Impact Assessment (SIA) and Data Privacy Impact Assessment (DPIA). The relevant security and compliance Requirements should be added to the Requirement functional component. These Requirements are then linked to the Product Design, Product Backlog Items, and associated Test Cases. This ensures the product is designed according to the agreed Policies and enables full traceability on the compliance of the product against defined Policies and controls. |
The Requirement functional component manages all the Requirements (both functional and non-functional requirements) for the different stakeholders such as those related to:
-
Business requirements
-
Security requirements (derived from Policies)
-
Requirements derived from SLOs such as those related to availability, performance, and capacity (to define the expected performance of the product)
-
Legal, regulatory, and compliance requirements (such as those related to data privacy)
-
Data management requirements
-
Business continuity/disaster recovery requirements (related to business and service continuity)
-
Architectural requirements
-
User experience requirements (such as those related to Experience-Level Agreements(XLAs)
-
Operations requirements (such as those related to monitoring and logging)
All Requirements need to be collected, refined, scoped, and have their progress tracked across the full development lifecycle.
The Requirement functional component supports the value streams:
Functional Criteria
The Requirement functional component:
-
Shall be the system of record (authoritative source) for all Requirements
-
Shall manage the lifecycle of the Requirements
-
Shall manage the state of a Requirement
-
Shall track all changes to Requirements
-
Shall manage Requirements through the lifecycle of a product
-
Shall capture service level Requirements such as those related to availability, reliability, and performance
-
Shall capture Requirements related to user experience (such as those related to user experience design, usability, etc.)
-
Shall capture Requirements related to security, risk, privacy, and compliance (for example, those derived from risk assessments and policies), and shall ensure that these Requirements can be traced back to originated Policies and associated legal and regulatory frameworks
-
Shall capture Requirements related to data management, such as those related to data integrity
-
Shall capture Requirements related to monitoring and logging (ensuring the deployed product can be monitored)
-
Shall collect, refine, scope, and track the progress of Requirements linked to the Product Backlog Items
-
Shall maintain traceability of each Requirement to the original Source (Product Backlog Item, a Policy, and/or requestor) and to the appropriate Source and/or Test Cases throughout the product lifecycle
-
Can manage the data flow to provide Requirement information to the Product Design functional component if a Product Design functional component exists
-
Shall allow a Requirement to be traced to one or more Test Cases designed to test the Requirement if a Test functional component exists
-
Shall allow one or more Requirements to be associated to one or more Policies that these Requirements originate from if a Policy functional component exists
-
May relate Requirements to specific stakeholders and personas
-
Shall rank Requirements to define the importance of each of the Requirements (e.g., must have, should have, could have, etc.)
-
May link Requirements to Portfolio Backlog Items (e.g., defining the high level requirements related to portfolio epics)
7.1.2.1. Requirement Data Object
Purpose
The Requirement data object records which functionality or non-functional conditions to meet for a product.
Key Attributes
The Requirement data object shall have the following key data attributes:
-
Id: unique identifier of a given Requirement
-
Name: short description/title of a given Requirement
-
Description: represents the more detailed description and statements of a given Requirement
-
Purpose: purpose of the Requirement
-
Type: identifies the category of a Requirement, such as functional, security, compliance, data privacy, service level, performance, and availability
-
Status: status of the Requirement
-
Reference: reference to the related authoritative sources such as Policies, regulatory requirements, security standards, etc.
-
Priority: the priority of a Requirement
-
Owner: person or team that owns the Requirement statement
-
Version: version of the Requirement specification
Key Data Object Relationships
The Requirement data object shall maintain the following relationships:
-
Product Backlog Item to Requirement (n:m): a Product Backlog Item is mapped to one or more Requirements (e.g., feature or user story) to track how the Requirement is fulfilled/realized
-
Requirement to Product Design (n:m): one or more Requirements will be used to define the required behavior from the Product Design
-
Requirement to Requirement (n:m): Requirements can be mapped to other Requirements (recursive and/or hierarchical)
-
Requirement to Test Case (1:n): a Requirement is traced to one or more Test Cases to ensure stated needs or conditions have been successfully delivered or met
-
Policy to Requirement (n:m): Requirements may be sourced from Policies or may reference Policies in order to remain in compliance with previously agreed Policies for an organization
-
Requirement to Portfolio Backlog Item (n:m): Requirements can be associated with one or more Portfolio Backlog Items
-
Requirement to Defect (n:m): a Defect can be associated with one or more Requirements
7.1.3. Product Design Functional Component
Purpose
The Product Design functional component creates and maintains the Product Design associated with a Digital Product. This functional component ensures the architecture and Product Design of the Digital Product meets specified requirements, is in line with the Enterprise Architecture, and adheres to standards and polices.
The Product Design functional component describes the structure and behavior of the services offered by the product, taking into consideration both the desired product and the associated Service Offers. Various design artifacts (e.g., UML® diagrams, API specifications, data models, process designs, user experience design, etc.) can be created that comply with the Product Backlog Item specifications, Requirements, and product vision. The service delivery model (in-source, outsource, etc.) can be identified, together with the service providers who will meet the Requirements within the chosen delivery model.
The Product Design should include instrumentation so that objective data can be captured on how the digital services are performing rather than relying only on consumer feedback. The service should also be architected to meet the KPIs and SLAs (and associated SLOs) and to ensure that appropriate Service Monitors are included in the Product Release.
The output of the Product Design functional component will be used by the Source data object to source, create, and secure the service, and the traceability will be done through the Requirement functional component.
The Product Design functional component supports the value streams:
Functional Criteria
The Product Design functional component:
-
Shall be the system of record (authoritative source) for all Product Designs
-
Shall identify the required changes in the Product Design to meet the needs of the Product Backlog Items and associated Requirements
-
Shall maintain the design of the Digital Products and its sub-components/parts
-
Shall maintain the design of the data model (mapped to the Enterprise Data catalog to understand what data is managed and/or used by the Digital Product)
-
Shall maintain the design of the integrations (and related data flows) of the Digital Product with other Digital Products (to understand dependencies and integrations with other products)
-
Shall maintain the design related to the security model, covering user profiles, roles, and associated access rights
-
Shall maintain various design artifacts (such as use-case diagrams, data models, data flow diagrams, interaction diagrams, etc.) that comply with the Product Backlog Item specifications and boundaries
-
Shall maintain the design of how the product enables/supports the customer journeys and business processes (if applicable)
-
Shall cover the user experience in the design
-
Shall identify the product delivery model (buy or build, in-source, outsource, etc.)
-
Shall maintain the infrastructure design for hosting the Digital Product (with the associated technology products)
-
May identify service suppliers to meet the Requirements within the chosen delivery model
-
Shall maintain the design of operations and support features of a product, including the support model, monitoring, and design for self-service (designing service interactions through the Service Offer Catalog)
-
Shall document instrumentation so that empirical data can be captured to measure how the digital services are performing, rather than relying only on anecdotal input from the user community
-
Shall document how the Digital Product complies with the non-functional requirements, including security, privacy, legal, etc. (Secure, Privacy, and Compliance by Design)
-
Shall document how the product is architected to meet the SLOs, including availability and performance, as well as XLAs
-
Shall receive the Digital Product specifications and product vision from the Product Portfolio functional component
-
Shall provide the ability to collaborate on the design artifacts, including reviews, capturing feedback, and comments
7.1.3.1. Product Design Data Object
Purpose
The Product Design data object is the collection of design artifacts related to a Digital Product, together with the changes to the Product Design for a specific Product Release. It represents the grouping of logical components necessary to provide the expected outcome or service interaction. This includes the design for non-functional requirements such as those related to security, privacy, availability, and performance.
Key Attributes
The Product Design data object shall have the following key data attributes:
-
Id: unique identifier of the Product Design
-
Name: meaningful name of the Product Design
-
Description: short description of the purpose of the Product Design
-
Version: version of the Product Design
-
Artifacts: reference to the artifacts as part of the Product Design (which are also under version control); this includes, for example: UML diagrams, data models, user experience designs, prototypes, etc.
Key Data Object Relationships
The Product Design data object shall maintain the following relationships:
-
Digital Product to Product Design (1:n): one or more Product Designs represents the logical components necessary to provide the expected outcome of the Digital Product; a Product Design belongs to one Digital Product
-
Product Design to Requirement (n:m): one or more Requirements will be used to define the required behavior from the Product Design
-
Product Design to Product Backlog Item (1:n): Product Backlog Items involved in changing and/or realizing the Product Design
-
Product Design to Product Release (1:n): a Product Release is based upon one Product Design in order to deliver the required service outcomes
7.1.4. Source Control Functional Component
Purpose
The Source Control functional component manages all the source code (and tracks all changes to the source) for a Digital Product. It is the system of record for all sources and configuration changes which fall under version control. The Source Control functional component ensures that access and updates to the source code are securely controlled.
In this context, “Source” also includes code that captures changes and configurations made to package-based software and SaaS applications; for example, configuring or customizing standard packages such as modifying business rules and workflows, configuring APIs, database configuration, etc. The Source Control functional component additionally manages the source code related to infrastructure (referred to as infrastructure as code).
Since all modifications in the source code repository are under change and version control, any source code changes need to be traced back to associated Product Backlog Items. As part of product development, various other automation routines are created such as test scripts, deployment templates, or workflows and monitors (e.g., monitoring as code). These automation scripts are also maintained by the Source Control functional component.
The Source Control functional component supports the Integrate value stream.
Functional Criteria
The Source Control functional component:
-
Shall be the system of record (authoritative source) for all Sources
-
Shall associate the source code repository to the Digital Product (owning the Source)
-
Shall implement the necessary security controls to protect and manage access to source code
-
Shall manage the lifecycle of the Source
-
Shall ensure Source updates are traced back to one or more Product Backlog Items (they understand the origin of changes)
-
Shall allow and promote the reuse of code between products and teams
-
Shall cover all source codes including infrastructure as code, as well as source code for automated Test Cases, monitoring (monitoring as code), etc.
-
Can integrate with external sources such as open-source libraries and third-party vendor repositories
-
Shall integrate with collaboration and communication tools to inform relevant stakeholders of Source updates
-
Shall allow for peer reviews of source code changes/commits
-
Shall allow analytics and statistics of source code changes over time
-
Shall allow the ability to compare Source updates/changes (between the different branches and versions)
-
Shall verify source code quality and conformance to coding and security standards and policies (using Test functional components such as Code Quality Scanning)
-
Shall analyze the code (including all related open-source/third-party source codes) for security issues, vulnerabilities, and risks
-
Shall code or configure Test Cases as part of product development (linked to the Test functional component); automated test scripts are maintained in the Source Control functional component as well
-
Shall integrate with code editors to perform the creation and/or updates of source codes
7.1.4.1. Source Data Object
Purpose
The Source data object represents a collection of source code and configuration settings under version control as part of the configuration of a product. The Source data object fulfills the Requirements associated with the product.
|
Note
|
The Source data object does not only represent the source code such as .NET, JavaScript™, or Java®, but also infrastructure as code, web pages, as well as configuration settings to define; for example, business rules, APIs, database schemas, etc. Consider all use-cases including customizations or configuration changes to SaaS applications or COTS packages. Source represents all changes made to realize the design of the Digital Product which falls under version control and is used to build the Product Release. |
Key Attributes
The Source data object shall have the following key data attributes:
-
Id: unique identifier of the Source
-
Version: version of the Source
-
Repository: link to the repository where the Source is maintained
-
Owner: reference to the organizational owner of the repository and Source
-
Date/Time: date and time of last update (and commit)
-
Person Id(s): references to the identities who have created/modified the Source
-
Tags: one or more tags associated with the Source
-
Comments: comments related to the Source update
Key Data Object Relationships
The Source data object shall maintain the following relationships:
-
Source to Pipeline (n:m): a Pipeline can be triggered by updates of the source code; a Pipeline is associated with one or more Sources
-
Source to Product Backlog Item (n:m): the Source is created or updated with a reference to one or more Product Backlog Items fulfilling one or many Requirements, and for a given Product Backlog Item, there could be multiple Sources created/modified
-
Source to Build Package (n:m): the Source can be built multiple times to create several build versions
-
Source to Test Case (n:m): one or more Test Cases can be defined related to the source code, such as unit tests, code quality scans, and reviewing security coding standards
-
Source to Defect (n:m): one or more Defects can be related to the source code; for example, a Defect can be related to code quality issues identified by the Test functional component
-
Source to Digital Product (n:1): the Source repository is related to the Digital Product owning the Source
7.1.5. Pipeline Functional Component
Purpose
The Pipeline functional component orchestrates the activities needed to deliver a tested, validated, and compliant Product Release. Its purpose is to orchestrate and coordinate the tasks associated with building, verifying, testing, and deploying software changes, and the Pipeline functional component can manage different types of Pipelines, such as:
-
Continuous Integration or build Pipelines
-
Release Pipelines orchestrating the release across the different environments (such as test, acceptance, and production)
A Pipeline defines an orchestration workflow consisting of several steps (jobs or tasks) and stages to be performed, including:
-
Execute build activities and create the Build Package (compiling and packaging) triggered by code changes
-
Initiate code quality checks (executed by the Test functional component)
-
Trigger the execution of Test Plans such as those related to unit testing, functional testing, and performance and security testing
-
Initiate deployments to different environments such as test, stage/acceptance, and production (via the Order functional component)
-
Validate the outcome of build, test, and deployment activities against agreed controls and policies
The Pipeline controls the movement of code from a commit in the Source Control functional component, through its development via the different environments such as test, acceptance, and production. The Pipeline functional component triggers the Fulfillment Orchestration functional component to perform the actual deployment. A Pipeline also embeds the required controls to ensure releases are processed through the Pipeline in a secure and compliant manner. The configuration of a Pipeline should be managed as code and placed under version control.
The Pipeline functional component supports the Integrate value stream.
Functional Criteria
The Pipeline functional component:
-
Shall ensure that the Pipeline is under version control and secured (for unauthorized changes)
-
May manage the Pipeline as code in the Source Control functional component
-
Shall associate the Pipeline to the source code repository (e.g., a merge request can initiate the Pipeline to execute build activities)
-
Shall manage the executions of the Pipelines (and keep track of all activities and outcomes)
-
Can associate the Pipeline to a Digital Product
-
Shall ensure that policies are embedded into the Pipeline so that security, risk, and compliance checks are executed as part of build and release activities
-
Shall track the progress and status of the Pipeline activities/tasks (a Pipeline consists of one or more tasks)
-
Shall associate a Pipeline to one or many Test Plans which are initiated as part of the Pipeline workflow
-
Shall register the Build Package in the Build Package functional component
-
Shall trigger the execution of one or more Test Plans
-
Shall update the status of the associated Build Package reflecting the outcome of the test activities
-
Shall associate the Product Release with the Pipeline (which orchestrated the creation of the release)
-
Shall update the status of the associated Product Release based upon the outcome of the deployment and activities across the different environments
-
Shall create a Change to log the planned and executed deployment of a Product Release
-
Shall create a Change to inform stakeholders about the (planned) Change
-
Shall use the Change functional component to perform a change impact assessment and determine potential conflicts (identifying potential conflicts of multiple changes)
-
Can use the Change functional component to schedule the actual deployment in the appropriate change window (e.g., in case a deployment results into downtime)
-
Shall wait for the approval of the Change functional component to continue with the workflow of the Pipeline
-
Shall initiate the deployment of the Product Release through the Fulfillment Orchestration functional component (e.g., to a test, acceptance, or production environment)
7.1.5.1. Pipeline Data Object
Purpose
The Pipeline data object defines and controls the execution of all the activities (and stages) to orchestrate and validate the build, and the deployment and testing activities required to securely deliver a modified Product Release.
Key Attributes
The Pipeline data object shall have the following key data attributes:
-
Id: unique identifier of the Pipeline
-
Name: name of the Pipeline
-
Version: version of the Pipeline
Key Data Object Relationships
The Pipeline data object shall maintain the following relationships:
-
Pipeline to source code (n:m): the Pipeline is linked to a source code repository
Multiple Pipelines can be defined for one repository. Source code updates trigger the Pipeline to perform a number of tasks such as initiate static code analysis and build activities to create the Build Package (consisting of one or more build artifacts).
-
Pipeline to Test Plan (n:m): a Pipeline triggers the execution of several Test Plans (and associated Test Cases) such as those related to unit testing, performance testing, security testing, etc.
-
Pipeline to Build Package (1:n): a Build Package is created by one Pipeline (using one or more build tools)
-
Pipeline to Product Release Blueprint (1:n): the creation of a Product Release Blueprint is initiated and governed by one Pipeline
-
Pipeline to Change (1:n): a Pipeline can raise one or more Changes to inform stakeholders about new releases/changes, perform change impact assessment, and get formal approval (manually or automated)
7.1.6. Build Package Functional Component
Purpose
The Build Package functional component is the authoritative source for all Build Packages and associated build artifacts. It receives the Build Package and any associated artifacts from the Pipeline functional component.
The Build Package functional component is the single source for the various types of Build Packages including software builds, infrastructure images, container images, etc.
The Build Package functional component supports the Integrate value stream.
Functional Criteria
The Build Package functional component:
-
Shall be the authoritative source for all Build Packages (often referred to as an artifact/build repository) including, for example, container images
-
Shall manage the lifecycle of all Build Packages from registration to archiving and clean-up of build artifacts
-
Shall secure the Build Packages for unauthorized access and unauthorized changes
-
Shall maintain a full audit trail of all additions and modifications in Build Packages and their components
-
May receive Build Packages and artifacts from external sources, such as third-party vendors and open-source libraries
-
Shall receive the Build Package from the Pipeline for a particular Digital Product or product component
-
Shall associate the Build Package with the Pipeline through which the Build Package is created
-
Shall ensure that all Build Packages (e.g., container images) are safe to deploy
-
Shall maintain a bill of materials for all components (and artifacts) that are part of a Product Release (including dependencies and references to third-partly libraries and components)
-
Shall scan and verify all Build Packages (and their components and dependencies) for potential security issues, compliance issues, and vulnerabilities (prior to deployment)
-
Shall associate one or many Build Packages to one or many Test Plans which are executed as part of the Build Package registration; for example, to perform a Software Composition Analysis (SCA) for all software packages and containers for vulnerabilities and software license compliance issues
7.1.6.1. Build Package Data Object
Purpose
The Build Package data object represents a collection of build artifacts (components) packaged into a deployable unit. The Build Packages are securely stored in a build/artifact repository.
Key Attributes
The Build Package data object shall have the following key data attributes:
-
Id: unique identifier of the Build Package
-
Name: meaningful name of the Build Package
-
Description: short description of the Build Package
-
Type: define the Build Package type; e.g., container image
-
Status: lifecycle status of the Build Package
-
Compliance Status: compliance status of the Build Packages (and their components)
-
Version: version of the Build Package
-
Tags and Metadata: a build can have one or more tags (or properties) to provide additional metadata
Key Data Object Relationships
The Build Package data object shall maintain the following relationships:
-
Source to Build Package (n:m): Source can be built multiple times to create several build versions
-
Build Package to Test Plan (n:m): one or many Build Packages can be related to one or many Test Plans used as part of the build creation (e.g., perform security and vulnerability scanning on the new or modified Build Packages)
-
Build Package to Product Release Blueprint (n:m): multiple Build Packages, which represent the deployable units or components, can be assembled into a Product Release Blueprint which is used for the deployment of the Product Release into the different environments
-
Build Package to Pipeline (n:1): a Build Package is associated with the Pipeline through which the Build Package is created (or modified)
-
Build Package to Build Package (n:m): a Build Package can have dependencies with other Build Packages (or components)
7.1.7. Release Composition Functional Component
Purpose
The Release Composition functional component manages the Product Release and creates the associated Product Release Blueprint for delivering new or changed products to the Fulfillment functional component. The Fulfillment functional component uses the Product Release Blueprint to deploy and configure an instance of a Digital Product; for example, an instance used for testing, staging, or production. To ensure that the release can be operated and supported as part of digital operations enablement, the creation of monitors, Service Offers, Knowledge Items, backup/restore procedures, etc. for the product also form part of this component.
The Product Release should include all components and artifacts to be delivered as part of a release, such as:
-
Build Packages used to create the Product Release Blueprint (from the Build Package functional component), which is consumed by the Fulfillment functional component
-
Definitions (and templates) for the new or modified Service Offers with associated request fulfillment automation logic
-
Monitor definitions (to be consumed by the Monitoring functional component) to ensure the new Product Release can be monitored
-
Test results (and full Log of executed tests) from the Test functional component
-
Outstanding Defects from the Defect functional component (as input for Knowledge Management to capture known errors)
-
Definitions of the underlying infrastructures and platforms; e.g., infrastructure as code (and associated parameters)
-
Release notes, as well as new or modified Knowledge Items and associated user guides/support information
The Release Composition functional component supports the value streams:
Functional Criteria
The Release Composition functional component:
-
Shall be the system of record (authoritative source) for all Product Releases
-
Shall be the system of record for all Product Release Blueprints
-
Shall create the Product Release and the associated Product Release Blueprint used by the Fulfillment functional component to create an instance (or deployment) of the Digital Product that, for example, will be utilized by the Test functional component
-
Shall manage the Product Release and Product Release Blueprints for delivering new or changed services to the Fulfillment functional component to facilitate a smooth transition to digital operations
-
Shall include the templates for the associated Service Offers (as part of the Product Release Blueprint)
-
Shall include the templates and definitions for the configuration of Service Monitors executed by the Monitoring functional component (monitoring as code)
7.1.7.1. Product Release Data Object
Purpose
The Product Release data object represents a candidate or actual release of the Digital Product. A release relates to a single Product Design. It represents a version of the Digital Product with all associated documentation and artifacts required to fully support the product, including, for example, release notes, user guides, training materials, updated Knowledge Items, etc. It must contain a set of features that are sufficient to produce an outcome aligned to the value expectations of the Digital Product.
Key Attributes
The Product Release data object shall have the following key data attributes:
-
Id: unique identifier of the Product Release
-
Name: meaningful name of the Product Release
-
Description: description of the Product Release
-
Status: lifecycle status of the Product Release
-
Version: version of the Product Release
-
Tags: a Product Release can have one or more tags to further categorize and classify the release
-
Deployment Model: a representation of the deployable service components and their various configuration options
-
Actual Spend: actual spend for the development of a Product Release
Key Data Object Relationships
The Product Release data object shall maintain the following relationships:
-
Product Design to Product Release (1:n): a Product Design can lead to the creation of one or more Product Releases in order to deliver the required service outcomes
-
Product Backlog Item to Product Release (n:1): a Product Backlog Item represents the changes and work performed on a specific Product Release; a Product Backlog Item should be decomposed into sub-product items which can be fulfilled within one release
-
Product Release to Product Release Blueprint (n:1): each Product Release has one associated Product Release Blueprint
-
Product Release to Defect (n:m): identified Defects (in the form of Problems/known errors) associated with the Product Release
-
Product Release to Desired Product Instance (1:n): one Product Release can be translated to one or more Desired Product Instance(s)
-
Product Release to Product Release (n:m): a Product Release is dependent on other products being available in a particular version
7.1.7.2. Product Release Blueprint Data Object
Purpose
The Product Release Blueprint data object provides the definition and specification of a release with all related components, dependencies, and required configurations as part of the Digital Product. It contains the description and procedures in order to activate, deploy, and operate an instantiation and its underlying components including software components and required resources. It may have many variations for a given Product Release as considerations such as environmental (development, stage, and production) or hosting (on-premise or cloud) could be specified differently. Iterative development methods may reuse a Product Release Blueprint multiple times.
Key Attributes
The Product Release Blueprint data object shall have the following key data attributes:
-
Id: unique identifier of the Product Release Blueprint
-
Name: meaningful name of the Product Release Blueprint
-
Description: description of the Product Release Blueprint
-
Version: a version of the Product Release Blueprint
-
Deployment Model: a definition of the various parameters and configuration options (e.g., used for deployment/provisioning)
Key Data Object Relationships
The Product Release Blueprint data object shall maintain the following relationships:
-
Product Release Blueprint to Pipeline (n:1): a Product Release Blueprint is created by a Pipeline
-
Product Release to Product Release Blueprint (1:n): a Product Release has one Product Release Blueprint
-
Product Release Blueprint to Build Package (n:m): multiple Build Packages, which represent the deployable content of the service components, can be deployed using the instructions contained in the Product Release Blueprints
-
Service Offer to Product Release Blueprint (n:m): a Service Offer is created based on definitions of one or more Product Release Blueprints
7.2. Test Function
The Test function is centered around verifying and testing the Source, Build Package, Product Release, and associated documentation to ensure the product meets the Requirements and adheres to standards and policies, such as those related to security and compliance.
7.2.1. Test Functional Component
Purpose
The Test functional component plans, orchestrates, and executes tests (including reviews) that ensure the Product Release will meet stakeholder expectations, and support all the Requirements at the agreed service levels. Using the Test functional component, Defect data objects are created to be consumed by the Defect functional component. Tests Cases are designed, planned, and executed, covering both manual and automated testing.
The Test functional component covers all verifications, validations, and test activities to ensure the product meets the Requirements and specifications (as part of the Product Design) including non-functional requirements and adherence to policies and standards.
Issues and exceptions found during testing are recorded as Defect data objects, which are consumed by the Defect functional component.
Various tests are planned and executed across the different environments, including:
-
Unit testing
-
Peer reviews
-
Code quality testing (to verify the conformance of the code to policies and coding standards)
-
Performance and stress testing
-
User Interface (UI) testing
-
Functional testing
-
Usability testing
-
Security and compliance testing covering various security tests such as Static and Dynamic Application Security Testing (referred to as SAST and DAST) to validate compliance to security requirements and policies, as well as vulnerability scanning
-
Testing of operations functions, including backup/restore, monitoring, logging, and Runbooks (e.g., used for diagnostics and remediation)
-
Business process testing (testing an end-to-end business process)
-
Mobile testing (for the different mobile platforms)
-
API and integration testing
-
Regression testing
-
Continuity testing (e.g., tests the disaster recovery/continuity plan)
-
Monkey testing (tests the product by providing random inputs and checking the behavior)
-
User Acceptance Testing (UAT)
-
Continuity (and failover) test
The Test functional component should support different test methods, including TDD in which each Product Backlog Item begins with writing a test (instead of writing a test after the code has been written). Test Cases can be created through use-cases and user stories to cover the requirements and exception conditions.
The Test functional component supports the Integrate value stream.
Functional Criteria
The Test functional component:
-
Shall maintain the test strategy and Test Plans
-
Shall link Test Cases to one or more Test Plans
-
Shall leverage the Product Backlog functional component to plan and develop Test Cases, both manual and automated tests
-
Shall manage the automated Test Cases in the Source Control functional component
-
Shall ensure traceability between tests and Requirements
-
Shall plan and execute tests that ensure the Product Release will support the Requirements at the agreed service levels
-
Shall plan and execute tests to ensure non-functional requirements are addressed
-
Shall create Defect data objects that are consumed by the Defect functional component
-
Shall log all test runs and capture the test results (including test logs)
-
Shall include abuse cases to be tested for the product; misuse and abuse cases describe how users could potentially misuse or exploit the weaknesses of controls in software features
-
Shall execute tests such as:
-
Unit tests
-
Code quality scanning
-
Functionality tests
-
Security tests (static and dynamic application security and infrastructure security testing)
-
Vulnerability scanning
-
Penetration tests
-
Performance and stress tests
-
Business process tests
-
Regression tests
-
Integration tests
-
-
Shall create Defects found during testing which are consumed by the Defect functional component
-
Shall define and manage representative test data for all data sets needed to execute the Test Cases
-
Shall provide test execution reports per tested Requirements and/or Product Backlog Items
-
Shall track all executed Test Cases (as part of a Product Release)
-
Shall test operations activities as well, such as monitoring, request fulfillment, etc.
-
Shall be the system of record (authoritative source) for all Test Cases (and associated test data)
-
Shall manage the lifecycle of Test Cases
-
Shall calculate test coverage of a new Build Package and Product Release
-
Shall measure and report upon code quality and compliance to coding standards
-
Shall scan all builds against potential vulnerabilities (e.g., third-party libraries and open-source components)
-
Shall create automated test scripts, including unit testing and scripts for security testing that follow a formal software security assurance methodology
-
Shall run security tests on core code to identify existing security issues at the start of the development cycle so that the assessment of scope/requirements set/scheduled can be scheduled early for existing services that are undergoing change
7.2.1.1. Test Case Data Object
Purpose
The Test Case data object defines how to validate a particular aspect of a Product Release. It is used to document what makes a product fit-for-purpose.
Key Attributes
The Test Case data object shall have the following key data attributes:
-
Id: unique identifier of the Test Case
-
Name: meaningful name for the Test Case
-
Description: summary or short description of the Test Case
-
Status: lifecycle status of the Test Case
-
Result: last known Test Case execution outcome
Key Data Object Relationships
The Test Case data object shall maintain the following relationships:
-
Test Case to Requirement (n:m): a Test Case is associated to one or more Requirements (which are covered by the Test Case)
-
Test Case to Product Backlog Item (n:m): a Test Case can be associated to one or more Product Backlog Items
-
Test Case to Test Plan (n:m): one or more Test Cases are related to one or more Test Plans
-
Test Case to Build Package (n:m): a Build Package is validated by executing one or more Test Cases as part of the build creation
-
Test Case to Defect (1:n): a Test Case can be associated to one or more Defects that are reported as a result of this test
-
Test Case to source code (1:n): a Test Case is associated to the source code which is executed as part of verifying code changes (e.g., code quality analysis)
-
Test Case to Test Case (1:n): a Test Case can be associated to another Test Case
7.2.1.2. Test Plan Data Object
Purpose
The Test Plan data object is a dynamic plan defining the test scope, test coverage, and associated Test Cases to be executed as part of new builds and/or releases. Multiple Test Plans can be created for a Digital Product. The Test Plan ensures that all required Test Cases are executed and verified as part of a Product Release.
Key Attributes
The Test Plan data object shall have the following key data attributes:
-
Id: unique identifier of the Test Plan
-
Name: meaningful name for the Test Plan
-
Description: summary or short description of the Test Plan
-
Status: lifecycle status of the Test Plan
-
Version: version of the Test Plan
-
Test Runs: overview of Test Plan executions
Key Data Object Relationships
The Test Case data object shall maintain the following relationships:
-
Test Case to Test Plan (n:m): one or more Test Cases are related to one or more Test Plans
-
Product Release to Test Plan (n:m): a Product Release can have one or more associated Test Plans
-
Test Plan to Pipeline (n:1): a Test Plan can be associated to and initiated by one Pipeline
-
Test Plan to Test Plan (n:m): a Test Plan can link to another Test Plan (decomposition or relationship)
-
Test Plan to Build Package (n:m): a Test Plan can be created to scan and verify one or more Build Packages (e.g., for software compliance and potential vulnerabilities)
7.2.2. Defect Functional Component
Purpose
The Defect functional component keeps track of all Defects; including their origin, status, importance, and relation to Requirements and Problems (or known errors). Defects of all types are registered (including security-related Defects), together with all relevant details such as description, severity, product version, related requirement, etc. Defects can be analyzed, and resolutions found. Defects can be associated with Requirements.
|
Note
|
A Defect in this context can be any issue that impacts the product in delivering the expected value and outcome for the consumer as described in the product definition and requirements, such as poor user experience, potential vulnerabilities, maintainability issues, technical debt, etc. This includes unfulfilled nonfunctional requirements mandated by policy even if they were omitted from the formal requirements process. In this case defect management should include updating any missing product requirements and design. |
The Defect functional component documents issues that should be communicated to the Release Composition functional component. The Defect functional component consumes Defects from the Problem functional component and the Test functional component, and these are in turn consumed by the Source Control functional component for review and resolution. Defect details can be updated, and used to decide on target release times. The Defect status can be monitored, and Defect reports provided. Defects that remain unresolved by service development can be converted to known errors for Problem Management to document, develop work-arounds for, and/or report in Knowledge Management articles.
The Defect functional component supports the Integrate value stream.
Functional Criteria
The Defect functional component:
-
Shall be the system of record (authoritative source) for all Defects
-
Shall manage the lifecycle of the Defect
-
Shall keep track of all Defects, including their origin, status, importance, and relation to Requirements and known errors
-
Shall register Defects of all types (including security-related) with all relevant details such as description, severity, application version, related requirement, etc.
-
Shall analyze Defects and find resolutions
-
May document issues that should be communicated to the Release Composition functional component
-
May consume Defects from the Problem functional component, as well as the Test functional component, that are in turn consumed by the Source Control functional component for review and resolution
-
Shall report Defect status and provide Defect reports
-
Shall create known errors for unresolved Defects (including the potential work-around and associated Knowledge Items) which can be published to consumers and used by the Operate value stream to provide remediation in case of Incidents
-
Shall receive Defect information from the Test functional component
-
Shall receive Defect information from a Problem (or known error)
-
Shall provide Defect information to the Product Backlog functional component (to plan and work on the Defect resolution in the Product Backlog)
7.2.2.1. Defect Data Object
Purpose
The Defect data object records an issue with the Product Release that should be remediated to fulfill the associated Requirements or designated as a Known Error, including unfulfilled nonfunctional requirements mandated by policy even if they were omitted from the formal requirements process. In this case defect management should include updating any missing product requirements and design.
Key Attributes
The Defect data object shall have the following key data attributes:
-
Id: unique identifier of the Defect
-
Title: short description of the main issue discovered
-
Description: description of the Defect
-
Status: status of the Defect
Key Data Object Relationships
The Defect data object shall maintain the following relationships:
-
Defect to Test Case (n:1): a Defect can be associated with the Test Case that detected the Defect
-
Defect to Product Release (n:m): a Defect can be associated with one or more Product Releases
-
Problem to Defect (1:n): a Problem (or known error) may be the source for submitting one or more Defects (or updating existing ones)
-
Defect to Product Backlog Item (1:n): a Defect is added to the Product Backlog as a Product Backlog Item (for fixing the Defect)
-
Defect to Requirement (n:m): a Defect can be associated with one or more Requirements