Tags: Reference-Guide

This checklist supports documentation teams in ensuring that userfacing content is accessible to all users, including those using assistive technologies. It can be applied during content creation, review, and prepublication.

Architecture Review Goals

"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.

Performing an Attack Surface Analysis includes analyzing the security architecture to identify and document product interfaces and surfaces that could be attacked, as well as consider if there are planned security measures that will provide enough protection against attacks on these surfaces.

A code review intends to improve the quality of the code. Someone other than the author of the code performs the examination. Code review is mandatory for new code and code changes (pull request).

Code signing is a crucial process in software development that ensures the integrity and authenticity of software code. It involves applying a digital signature to software programs, scripts, or drivers.

Recommendations of colors for dashboards and graphs in Azure DevOps.

This checklist ensures that user documentation adheres to relevant regulatory, legal, and organizational standards. It is particularly important for regulated industries (e.g. medical, automotive, and industrial IoT) or when documentation is published publicly.

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.

This guide gives an overview of the suggested course path for education about the cyber security lifecycle for teams that work with ABB products, systems, or solution offerings that are software related.

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

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.

Use this checklist to ensure user documentation is clear, consistent, accurate, compliant, accessible, ready for localization, properly reviewed, and finalized.

The definition of done (DoD) for L4 bugs are the checks performed when an L4 bug is considered completed.

During L4 fault tracing it may be required to send a debug release outside of PCP. This has to be handled with care as it isn't a formally released software.

This guideline describes how to write Functional Description and Detailed Design documents.

This guideline describes how to perform a Functional Description and Detailed Design review.

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.

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).

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.

What is a pull request?

The "R&D Quality Criteria" is a tool and checklist for Quality Control Managers (QCM), and is used to plan quality audits and assessments for project milestones and report quality status.

The following component test frameworks are recommended but not mandatory.

The following unit test frameworks are recommended but not mandatory.

This page is intended to be a base for the creation of a new PCB layout. It is meant to be supported together with the PCB layout checklist, which is to be used in the development of the layout.

The engineering service request is the main template to be used during development. The purpose of this site is to reference the two different options when communicating with a Service Provider (for instance layout work, parts list, etc.).

Hardware development has a lot of interactions with internal ABB functions and external suppliers, manufacturers, and customers. This page is intended to give an overview of how maintenance tasks come to the R&D Hardware teams.

All relevant formulas which are necessary for highspeed design analysis are listed on this page.

This page is intended to give an overview of what kind of documentation is present for the Combitrol & Combimatic documentation.

A production package is created for every product and is the basis for a manufacturer. A production site is commonly called an electronic manufacturing service (EMS). This list is used by the EMS to create the product (box build).

The developer/author scope definition quick checklist.

Secure coding standards are guidelines, best practices, and coding conventions that can be used by software developers to prevent security vulnerabilities and improve the overall quality of the software during the software design & development phases.

This document describes the secure coding guidelines for the .NET programming language. Some of the guidelines are generic, whereas some are specific to the .NET programming language.

This document describes the secure coding guidelines for the C programming language. Some of the guidelines are generic, whereas some of them are specific to the C programming language.

This document describes the secure coding guidelines for ReactJS. Some of the guidelines are generic, whereas others are specific to ReactJS.

The Security Criticality Analysis is performed to identify which of the components in a product are important to pay extra attention to when trying to minimize the risk of vulnerabilities.

Introduction

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 Test Case 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 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.

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

EntryExit criteria is a set of conditions that permits a task to perform, or in absence of any of these conditions, the task cannot be performed. Entry Criteria give the prerequisite items that must be completed before testing can begin in the respective phase. Exit Criteria define the items that must be completed before testing can be concluded in the respective phase.

Test case audit checklist.

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.