Roles: Release-Owner

"Area Path" and "Iteration Path" are standard fields in Azure DevOps (ADO), and they are used to organize work items by product classification, team, and time period.

For an introduction to the concept of baselining, see the Highlevel baseline guide.

This guide describes how bugs – when they are created in Azure DevOps (ADO) – also are classified to ensure that they are handled with regards to their severity and potential impact.

Product Portfolio Management (PPM) defines the standards a product or system must fulfill based on legal requirements and on a business perspective. The system requirements (SRs) specify the regulatory requirements. PPM and R&D collaborate to ensure the standards are followed.

This conceptual guide explains the purpose of configuration audits and presents the main parts of a configuration audit and the highlevel approach adopted in PCP.

This is the overall description of how to handle configuration release management within ABB PCP.

To help our customers protect their critical systems and sensitive information from digital attacks security has to be built into our products.
Therefore, the Cyber Security process is an integrated part of most of the PCP R&D processes.
This page contains an overview of securityrelated activities within PCP R&D, and additional information can be found under respective process area in the QMS.

All ABB products or system offerings which are softwarerelated need to fulfill some mandatory cyber security requirements as described in the CFSCP02 Information & Cyber Security Policy.

User documentation should provide the necessary information to help the customer ensure that the site is as secure as possible.

The quality dashboard can help teams measure and compare product quality by setting appropriate widgets and queries. A common template based on standardized queries will help save effort and improve efficiency. By setting appropriate widgets and queries, the quality dashboard can help teams measure and compare product quality. A template based on standardized queries helps save effort and improve efficiency.

The "Definition of Ready" (DoR) are the checks performed when a system epic, epic, feature, story, or bug is defined and ready to start work on. The "Definition of Done" (DoD) is the checks performed when the work items are completed before it is closed.

The Development Stream process manages the planning, prioritization, and visualization of all activities related to product and component releases of different sizes, such as new versions, rollups, and temporary corrections. The main development streams are Operations, Engineering, Control & IO, and IIoT Platform & Applications.

Division testing (DT) is an optional testing stage carried out with ABB divisions (e.g., PAEN, PAPI, PADI) during the project if it is relevant to the respective product or system release.

The term Document Management includes both Office files and wiki pages. While the general processes are the same – such as version control, review, and approval – the specific procedures for each type of document differ and are described in the relevant guides.

This guideline outlines how to organize and manage product and project documents during development and maintenance. It applies only to internal R&D documents at the product and project level, not for publication through the ABB Library or other channels.

A product issue is a uniquely identified problem impacting a product, requiring clear communication with various stakeholders. It must be documented with accurate information and version details and managed in parallel with bug management and product releases.

The purpose of this guide is to provide handson support to the roles involved in setting up a test plan and test suites in Azure DevOps (ADO), demonstrating the product's test coverage.

This guide describes how to use Markdown to document technical information using the Azure DevOps (ADO) wiki. The Markdown files can be reviewed, approved, and baselined with the code. The code and technical documentation can be restored from the same baseline when a released product needs to be updated.

This guide provides handson support for the roles involved in executing test cases and reviewing test results.

Introduction

A work item of type "Bug" can be used to suggest an enhancement, something that is not a real defect, but an idea for improvement. This guide describes how to handle enhancements as bugs.

When starting a new project there are several tasks to be performed to ensure that tools and systems are well set up when M0/G0, M1/G1, and M2/G2 are reached.

A bug is an unexpected problem in the software or hardware which can be reported for any issue in a product by e.g. product managers, product owners, test engineers, or customers (via L3 or L4 Support).

Dashboard creation can be repetitive and time consuming. This guide describes how to manage dashboards automatically.

Query creation can be repetitive and time consuming. This guide describes how to manage queries automatically.

This guide describes the approach for mapping the lifecycle components derived from the technology product releases, to the branded products (800xA, Symphony Plus, etc.). It also covers how to gather the data and share relevant ECCNrelated information with the product classification team.

The purpose of configuration auditing is to objectively assess the integrity of a product, both from a functional and physical perspective.

The ABB Cyber Security Assessment Tool Importer is an internal utility tool used to import the security requirements from various assessment spreadsheets into Azure DevOps (ADO) as security work items.

This guide describes how to handle epics in streams. It includes examples of epic descriptions and information about the epic definition, grooming, and change management.

This guide describes how to handle features in streams. It includes examples of feature descriptions and information about the feature definition, grooming, and change management.

This guide describes how to handle system requirements and system epics. It includes descriptions and information about the system requirement / system epic definition, workflow, grooming, and change management.

The PCP Intellectual Property process aims to maintain a strong intellectual property portfolio consistent with the market and thought leadership position. IPrelated activities in the R&D processes are carried out in the context of PCP’s active, marketoriented IP protection strategy.

Hardware products are manufactured by Electronic Manufacturing Services (EMS). The EMS is responsible for assembling the product according to ABB design. This page describes key items in the New Product Introduction (NPI).

R&D quality dashboards can be automatically created, based on Azure DevOps (ADO) data, to support the organization in visualizing project progress based on quality key performance indicators (KPIs).

The PCP System Epic Dashboard is used to visualize the implementation progress of system epics, by planning and tracking child epics and features whose completion is required to fulfill a given requirement.

This guide explains what a product issue number (PIN) is and how it is used within the PCP organization.

A Product lifecycle management (PLM) system enables collaboration between different functions by gathering all productrelevant data in one place. For hardware development, the choice is in Windchill. This page intends to be a goto page for how to find information regarding Windchill.

The product test verifies that the product to be released has acceptable quality. It applies to new products and maintenance/updates of existing products.

Key performance indicators (KPIs) are used within PCP R&D to better understand, control, and manage the organization.

A regression bug is a bug that causes a completed feature that worked correctly to stop working after updates (e.g., system upgrade, system patching, or bug fixes). This definition applies both before and after releasing the feature to customers.

The Release process is valid for component, product, and system releases, including limited releases such as rollups and expansion packs. It deploys new functionality into production continuously or on demand and ensures that all R&D deliverables are ready to release.

The release owners play an active role in managing releaserelated activities across all organizational functions within PCP. They ensure that release planning is both realistic and aligned with the program increments (PIs). These release plans are developed based on input from product management, architects, stream owners, and other key stakeholders throughout the PCP organization.

This guide provides insights and definitions for the various release stages of a component, function, product, or system.

Introduction

The Synchronized Program Increment (SPI) sets a common cadence, synchronizes, and aligns the PCP organization (e.g. PPM, R&D, and Operations) towards common PCP business goals. The SPI also creates openness and transparency across organizational functions by inviting key stakeholders to synchronization meetings where issues, conflicting expectations, and dependencies are highlighted before they get critical.

This guideline describes the custom standard fields used in bug templates. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the Document Update work item type and the custom standard fields used in its template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Epic template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Feature template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the fields used in the system epic template.

This guideline describes the custom standard fields used in the User Story template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

Static source code analysis is a method for analyzing the source code without executing it. This guide provides relevant information about static code analysis within PCP R&D.

This guide describes what system interfaces are, how they are documented, and how they are managed.

A system requirement review intends to improve the quality of the requirements. It applies both to system requirements and technology requirements.

The System Stream process manages the planning, prioritization, and visualization of all activities related to system releases of different sizes, such as new versions, rollups, and temporary corrections. The main systems are 800xA, Symphony Plus, Freelance, and Heritage.

The system test is a crucial step in the development process as it integrates and tests deliverables from the various development streams.

This guide gives an overall view of the test performed before a component, container, product, or system is released.

The test phase checklist is a general guide for users to gauge the quality of product build delivery before starting tests in system test (ST) or RAT. Further, tailoring can be done to align the checklist with any specific product.

The traceability of the work items shows the relationship between them in Azure DevOps (ADO).

This guide describes traceability between work products that are not in Azure DevOps (ADO).