7. Build Functions
Description
The Build functions (formerly Requirement to Deploy) enable the creation, enhancement, and maintenance of Digital Products throughout their entire lifecycle: planning the work, designing, developing (or configuring), testing, and releasing a new Product Release. The Build functions support the creation and sourcing of new, or the modification of existing, Digital Products. This includes the product engineering of all types of products, such as the development of custom-built software, the development of cloud-native applications, the configuration of package-based software (COTS) or SaaS, as well as the development of infrastructure products (or platforms) which can be used to host other Digital Products.
This function includes the development of the initial Product Release (e.g., an MVP release) as well as fulfilling new (or modified) requirements and features, improving user experience, performing maintenance activities (such as fixing Defects and Problems), and ensuring the product remains compliant with policies and non-functional requirements (including security, risk, and regulatory requirements), etc.
The Build 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
-
The Build functions are process-agnostic; while methods and processes may change (i.e., SCRUM for Agile development, Kanban, Project Management methods, Test-Driven Development (TDD), etc.), the functional components and data objects that comprise the Build functions remain constant.
The Build functions provide the framework for creating and sourcing new, or modifying existing, applications or products. This function maintains a Product Backlog which can receive demand signals from a consumer (e.g., new features or business requirements), or from other components such as Portfolio Backlog Management, Policy Management, and Problem Management. This may take the form of an approved Portfolio Backlog Item from the Plan functions, or may be a smaller-grained signal such as an individual feature, user story, Defect, or Problem. The Build functions deliver the Product Release (for a new or modified product), which is packaged for immediate or future deployment through the Deploy value stream.
Related Value Streams
The following value streams use one or more functional components from the Build functions:
-
Integrate
-
Release
-
Deploy
Business Benefits
The Build functions describe a prescriptive framework of required functional components, integrations and data objects so organizations can deliver better value, sooner, safer with lower costs while improving the happiness and productivity of the product teams.
The key benefits of using the Build functions are:
-
Reduce lead time of delivering Product Backlog Items (e.g., new features or resolving Defects or Problems)
-
Ensure predictable, cost-effective, and high-quality products delivered to consumers
-
Increase the deployment frequency of delivering new Product Releases
-
Increased change success rate (and reduce issues introduced with the new Product Release)
-
Improved code quality and reduced security risks (and vulnerabilities)
-
Provide end-to-end transparency and traceability from a new requirement and/or backlog item to the delivery of a new release
-
Increased management information for benchmarking of internal and external service developers and suppliers
-
Reduced risks, as products are designed in accordance with standards and policies (from sources including Security Management, Governance, Risk, & Compliance, Legal & Regulatory, Enterprise Architecture, Financial Management, and so on)
-
Provide full transparency of the value delivered per release, as well as tracking the cost associated with the development of new features
-
Provide insight into time spent on new feature development versus time spent on eliminating technical debt and/or resolving Defects
-
Make service delivery predictable, even across geographically dispersed teams, multiple suppliers, and multiple development methodologies
-
Improve collaboration between involved stakeholders and teams (including external vendors)
Applications and services are now sourced or developed in cooperation with many different parties, all of whom work with their own processes and tooling. Digital organizations must be able to provide a good overview of the planned activities, speak a common language with all parties involved, and provide a methodology for how to achieve the highest quality results. Cloud sourcing, Agile development, and other innovations have created the need for enterprises to be able to manage development and delivery of services in a hybrid or multi-sourced environment.
-
Ensure that products are developed in line with policies, e.g., secure by design
-
Ensure that each Product Release is high quality, fit-for-purpose, and meets customer expectations
Organizations delivering Digital Products and services still experience too many incidents immediately after an application or service is released into production. Organizations must establish control over the quality of a service regardless of the number of vendors involved in development and/or delivery.
-
Standardize product development and delivery to the point where the re-use of service components is the norm
Operations in the development of Digital Products must ensure increased quality and speed of service delivery, while also lowering costs. In support of these efficiency and quality goals, organizations must have a framework in which to drive the re-use of existing service components at multiple stages of the development lifecycle across multiple applications and services. They must work successfully with multiple internal and external contributors and be able to integrate the data, process, and tools required to work with geographically dispersed teams, outsourcers, and traditional and cloud-based suppliers. Furthermore, organizations must maintain control of the governance of the Build functions and be able to track and measure internal and vendor performance, costs, quality, and on-time delivery. The abilities to re-use Requirements, source code, documentation, test scripts, Service Monitors, and other artifacts of a service development lifecycle are key contributors to managing costs, increasing quality and predictability, and accelerating release cycles.
-
Reduce number of Incidents occurred in production caused by the new release (better product quality)
-
Improved availability, performance, and resilience of the product in production due to better designs, architecture, and ensuring non-functional requirements are integrated into the overall Product Design
-
Accelerate the sourcing and delivery of products and services through best practices such as:
-
Re-use – manage, maintain, and leverage re-usable 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 lifecycle of all work items (Product Backlog Items) involved in designing and delivering new releases (or updates) of a product. Each Product Backlog is associated with a Product Manager and one or more teams (for example, an Agile or DevOps team); multiple teams building a single Digital Product work from a single Product Backlog that defines all of the work to be done. A product, however, can be decomposed into sub-products (or components) each having their own related Product Backlog and associated teams.
The Product Backlog is the single authoritative source for all work items (referred to as Product Backlog Items) that teams work on to achieve the outcome. The Product Backlog lists all features, stories, story tasks, enhancements, and fixes that constitute the changes to be made to the product in future releases. A Product Backlog Item can be decomposed into sub-Product Backlog Items. For example, a feature can be decomposed into user stories and related tasks. A subset of the Product Backlog Items can be assigned to an iteration or sprint backlog.
The Product Backlog functional component coordinates the creation and provides ongoing execution oversight of backlog items aimed at creating or modifying a product, together with associated deliverables such as training materials and user guides. The Product Backlog aggregates, tracks, and reports status, resources consumed against the plan (e.g., iteration or sprint plan), and communicates these to stakeholders. The Product Backlog governs, coordinates, influences, and directs initiative execution, as well as ensuring financial goals and boundary conditions are adhered to. The Product Backlog functional component maintains the linkage/traceability from Portfolio Backlog Items to Product Release.
The Product Backlog also receives Defects from the Defect functional component to enable the development of fixes and/or temporary work-arounds.
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 prioritize each of the Product Backlog Items
-
Shall define the value for the customer for each Product Backlog Item
-
Shall 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 the Product Backlog Items
-
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”.)
-
Shall have the ability to calculate the business impact and cost of delay for each Product Backlog Item
-
Shall assess the risks associated with the 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 via auxiliary functional components such as Resource Management, Supplier Management, and Financial Management
-
Shall track the time spend for Product Backlog Items (e.g., derived from allocated team resources and/or assigned story points), and the ability to break down cost and effort for the different types of work
-
May integrate with the Collaboration 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
-
Shall associate the Product Backlog with one Product Manager and one or more teams (and assigned team members)
-
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
A Product Backlog Item data object represents all work items associated with a product to fulfill the needs and requirements. Different types of work item can be differentiated such as epics, features, stories, and story tasks (depending upon the development methodology).
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 (1:n): 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 can have one or more Requirements defined in the Requirement functional component (such as non-functional requirements); a Product Backlog Item can add new Requirements and/or modify existing 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. For example, based upon the BIA, Security Impact Assessment (SIA), Threat and Vulnerability Assessment (TVA), 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
-
Continuity/disaster recovery requirements (related to business and service continuity)
-
Architectural requirements
-
User experience requirements (such as those related to XLAs)
-
Operations requirements (such as those related to monitoring and logging)
The Requirements need to be collected, refined, scoped, and have their progress tracked across the different sprints and releases.
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 service 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 experience, maintainability, architecture, performance, etc.)
-
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 (i.e., functional requirements, security, compliance, data privacy, service level requirements, 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
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.
It is important to ensure that the product architecture and Product Design are compliant with all policies and standards, including security standards and architectural guidelines; this helps to ensure the confidentiality, integrity, and availability of the service, as well as to ensure “Secure by Design” and “Privacy by Design”.
It is also useful to put instrumentation in place so that empirical data can be captured on how the digital services are performing rather than relying only on anecdotal input from the user community. The service should also be architected so that it can meet the KPIs and SLAs (and associated SLOs). 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 Experience-Level Agreements (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 develops and 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 re-use 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 re-use 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 is not just a bug (not meeting a specified requirement) but can be any issue that impacts the product in delivering the expected value and outcome for the consumer, such as poor user experience, potential vulnerabilities, maintainability issues, technology debt, etc. |
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.
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)