Glossary
Glossary for the most common words in the processes and guidelines.
See also 3BSE039243 Terminology Document for other general terms.
A
ABB Software Vulnerability Report
Internal document used by ABB Group Cyber Secuirty Council (GCSC) to track vulnerability remediation status.
Acceptance Criteria
The criteria a deliverable must satisfy to be accepted by a user, customer, or other authorized entity.
Acceptance Testing
Formal testing is conducted to enable a user, customer, or other authorized entity to determine whether to accept a deliverable.
Access Control
Access Control is the set of mechanisms responsible for protecting resources from illegitimate usage. It is divided into three main sub-mechanisms: Identification, Authentication, and Authorization.
Agile
Agile is an iterative development methodology that values human communication and feedback, adapting to change, and producing working results.
Agile Team
An Agile Team is a cross-functional group of 5 to 11 people who have the responsibility to define, build, test, and deploy (when applicable) some element of value — all in a short iteration timebox. Specifically, the Agile Team incorporates the Dev Team, Scrum Master, and Product Owner roles.
Approved Manufacturer List (AML)
The AML is a list of electronic components, PCBs, mechanical parts, and labels, which are all approved by ABB PA PCP. The list includes the internal ABB Identity number (CPN) with a description and the relationship to the manufacturer and their part no (MPN). The AML is owned by ABB PA PCP.
Architect
The Architect is responsible for defining and communicating a shared technical and architectural vision across multiple Streams to help ensure the system or solution under development is fit for its intended purpose.
Architectural Runway
The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. The architecture runway is built incrementally.
Attack Surface
Refers to the sum of all points or pathways in a system that can be targeted by an attacker to gain unauthorized access, compromise, or exploit the system.
It encompasses all the potential entry and interaction points that could be exploited to breach security.
Physical and functional interfaces of a system that can be accessed and, therefore, potentially exploited by an attacker (from IEC 62443-4-1)
Authentication
A mechanism or process that an entity uses to provide proof of controlling a certain identity (or other claims).
Authorization
A process for granting approval to a system entity to access a system resource. (from RFC 4949)
B
Backdoor
A computer system feature -- which may be (a) an unintentional flaw, (b) a mechanism deliberately installed by the system's creator, or (c) a mechanism surreptitiously installed by an intruder -- that provides access to a system resource by other than the usual procedure and usually is hidden or otherwise not well-known. (from RFC 4949)
Baseline
In testing, a baseline refers to a reference point or a set of specifications, documents, and artifacts that define the expected behavior and characteristics of a product or system. e.g., Product Baseline/System Baseline.
Buffer Overflow
A vulnerability that would allow more data to be written to a buffer than it can hold, potentially leading to arbitrary code execution.
Build
A build refers to a version of a software product or system that has been compiled or assembled from source code and other components. The build process involves taking the source code and other necessary files and converting them into executable code that can be tested and evaluated.
Built-in Quality
Built-in Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.
Bug
Unexpected problems in the SW or HW; the different bug types are described below. Scope bugs: bugs detected in previous releases (identified through the product version or build or using a proper tag) and targeted to be fixed in the current release (identified via the "area path field").
Scope bugs are usually defined at G2, but they can be added or removed during the release project, after G2.
Introduced bugs: bugs detected in the current release; they can be fixed or deferred to later releases.
Regression bugs: bugs causing a completed feature that used to work properly to stop working after new updates (they are identified via the regression field).
Bill of Materials (BOM)
The list of parts needed to manufacture the product including HW, FW, packaging, etc.
C
Capabilities
There are two kinds of capability artifacts - Component capabilities and Product capabilities. Component capabilities describe what the corresponding version of a component is capable of in its currently implemented state. Product capabilities describe the same thing but on a more aggregated product level (usually including multiple components).
Circuit Diagram (CD)
Graphical representation of an electrical circuit.
Change Control Board (CCB)
Group of people with authority to make decisions of changes of products and releases.
Communities of Practice (CoP)
Communities of Practice (CoP) are organized groups of people with a common interest in a specific technical or business domain. They regularly collaborate to share information, improve their skills, and actively work on advancing their general knowledge of the domain.
Compliance
Compliance refers to a strategy and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems with the highest possible quality while simultaneously assuring they meet any regulatory, industry, or other relevant standards.
Computer-Aided Drawing (CAD)
Drawing of a product in 2D or 3D.
Configuration Management (CM)
Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items.
Configuration Management Team
The CM Team is a specialized team across Streams that assists in building and supporting the agile development environment, typically including the development and maintenance of the tool chain that supports the Continuous Delivery Pipeline.
Continuous Delivery Pipeline
The Continuous Delivery Pipeline (also referred to as the "pipeline") represents the workflows, activities, and automation needed to shepherd a new piece of functionality from ideation to an on-demand release of value to the end user.
Continuous Deployment (CD)
Continuous Deployment (CD) is the process that takes the validated Features from a staging environment and deploys them into the production environment when they are ready for release.
Continuous Exploration (CE)
Continuous Exploration (CE) is the process that fosters innovation and builds alignment on what should be built by continually exploring the market and customer needs and defining a vision, roadmap, and set of Features for a Solution that addresses those needs.
Continuous Integration (CI)
Continuous Integration (CI) is the process of taking features from the Program Backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.
Core Values
The four Core Values of alignment & accountability, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to Lean-Agile effectiveness. These guiding principles help dictate behavior and action for everyone who participates in Portfolio or R&D.
Cryptography
The practice of securing information by transforming it into an unreadable format using algorithms.
Customer Part Number (CPN)
Internal ABB Identity number used for electronic components, printed circuit board (PCB), mechanical parts, and labels.
Customers
Customers are the ultimate buyers of a solution. They are an integral part of the Lean-Agile development process and the Value Stream and have specific responsibilities.
Cyber Security Advisory
A document that includes information about a security issue including vulnerability details, mitigation steps, and remediation. This should be used for customer communication and public disclosure.
D
Daily Standup / Daily Scrum
The Daily Scrum (also known as the daily stand-up) is a short meeting (15-30 minutes) attended by all members of the Scrum Team and facilitated by the Scrum Master. The Daily Scrum is not a status meeting. It is a commitment in front of peers. During the Daily Scrum, each team member provides answers to the following three questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
Defense In Depth
A comprehensive security strategy that involves implementing multiple layers of defense mechanisms to protect an organization’s information systems and data. The idea is that if one layer of defense fails, others will still provide protection, reducing the likelihood of a successful attack.
Denial of Service (DOS)
The prevention of authorized access to a system resource or the delaying of system operations and functions. (from RFC 4949)
Design Description (DD)
A complement to the Circuit Diagram which describes the design in words.
Dev Team
The Dev Team is a subset of the Agile Team. It consists of dedicated professionals who can develop, test, and deploy a Story, Feature, or component. The Dev Team typically includes software developers and testers, engineers, and other dedicated specialists required to complete a vertical slice of functionality.
DevOps
DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a solution.
Develop on Cadence
"Develop on Cadence" is an essential method for managing the inherent variability of systems development in a flow-based system. It makes sure important events and activities occur on a regular, predictable schedule.
Device Security Assurance Committee (DSAC)
The team that tests and validates the TCP/IP stack, robustness, and security vulnerabilities for any network-attached device.
Description of Function (DoF)
Provide an overview of a function when the information available in the epics/features/stories is too fragmented.
E
Electronic Manufacturing Services (EMS)
The manufacturer of electronic products. Can be used for both serial production and prototypes.
Enablers
Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.
Epic
An Epic is a container for a development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval before implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup build-measure-learn cycle.
Environmental Type Test
Tests that investigate environmental conditions, i.e. pressure, humidity, magnetic interference, and more.
Ex prefix
Usually refers to the engineers or documents that relate to Explosion protection for products.
External interface
The point at which a system or component interacts with entities outside of its trusted boundary. This could include interactions with users, external systems, 3rd-party services, or networks.
Examples: Web APIs exposed to the internet, user interfaces, email gateways, and public-facing services.
F
Failure Modes, Effects, and Diagnostics Analysis (FMEDA)
Systematic analysis technique to obtain subsystem/product-level failure rates, failure modes, and diagnostic capability
Features
A feature is a service that fulfills a stakeholder's need. Each feature includes a benefit hypothesis and acceptance criteria and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).
Firmware Integration Test
Integration test between hardware and firmware in a product.
Foundation
The foundation contains the supporting principles, values, mindset, implementation guidance, and leadership roles needed to deliver value successfully at scale.
Function Type Test (FTT)
Test of hardware functionality
Fuzz testing (or fuzzing)
A software testing technique used to identify vulnerabilities and bugs by inputting a large volume of random, unexpected, or invalid data into a program. The goal is to discover flaws that could lead to crashes, security vulnerabilities, or unintended behavior.
GHI
Group Cyber Security Council (GCSC)
An ABB group that oversees cyber security.
Hardening
A process intended to reduce the attack surface of a system by patching vulnerabilities and turning off non-essential services.
The process of decreasing the vulnerability of a system or component by design techniques. (from IEC 62443-4-1)
Identification
An act or process that presents an identifier to a system so that the system can recognize a system entity and distinguish it from other entities. (from RFC 4949)
IEC 62443
A series of international standards developed by the International Electrotechnical Commission (IEC) to address cyber security for industrial automation and control systems (IACS).
Innovation and Planning (IP) Iteration
The Innovation and Planning (IP) iteration is the last iteration in every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.
Inspect & Adapt (I&A)
The Inspect and Adapt (I&A) is a significant event held at the end of each Program Increment (PI), where the current state of the solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured problem-solving workshop.
Integrated Project Planning (IPM)
Coordination of all resources and stakeholders to make sure all organizational functions are aligned for a release and are working consistently. All the functions share plans and information with the Release Owner, who defines an integrated plan to reach the release objectives.
Internal interface
The point at which different components or systems within the same trusted boundary interact with each other. These interactions occur within a controlled and trusted environment.
Examples: Communication between microservices in a backend system, database connections within an application, and interactions between different modules of a software application.
Iteration
Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where agile teams deliver incremental value in the form of working, tested software and systems. The recommended duration of the timebox is two weeks. However, one to four weeks is acceptable, depending on the business context.
Iteration Execution
Iteration Execution is how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment.
Iteration Goals
Iteration Goals are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams.
Iteration Planning
Iteration Planning is an event where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming Iteration. The team summarizes the work as a set of committed Iteration Goals.
Iteration Retrospective
The Iteration Retrospective is a regular meeting where the agile team members discuss the iteration result, review their practices, and identify ways to improve.
Iteration Review
The Iteration Review is a cadence-based event, where each team inspects the increment at the end of every iteration to assess progress and then adjusts its backlog for the next iteration.
Implementation Proposal (IMP)
This is a description of alternative technical solutions based on the system requirements.
JKL
Key Performance Index (KPI)
A Key Performance Indicator (KPI) is a measurable value that demonstrates how effectively a company achieves key business objectives.
Lean User Experience (Lean UX)
Lean User Experience (Lean UX) design is a mindset, culture, and process that embraces Lean-Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against a benefit hypothesis.
Lean-Agile Leadership
The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential. They do this by learning, exhibiting, teaching, and coaching the Lean-Agile mindset, values, principles, and practices.
Lean-Agile Mindset
The Lean-Agile Mindset is the combination of beliefs, assumptions, and actions of Lena-Agile leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It is the personal, intellectual, and leadership foundation for adopting and applying Lean-Agile principles and practices.
Lean-Agile Principles
These are the nine defined Lean-Agile principles in SAFe. These tenets and economic concepts should inspire and inform people about the Lean-Agile roles and practices.
Least privilege
A principle that restricts user access to the minimum level required to perform their tasks, reducing the risk of accidental or intentional misuse.
M
Mean Time Between Failure (MTBF)
The predicted elapsed time between inherent failures of a mechanical or electronic system, during normal system operation.
Media Verification Test (MVT)
Verification of the final releasable media
Metrics
Metrics are agreed-upon measures to evaluate how well the organization progresses toward the portfolio, large solutions, program, and team's business and technical objectives.
Milestones
Milestones are used to track progress toward a specific goal or event. There are three types of Lean-Agile milestones: Program Increment (PI), fixed-date, and learning milestones.
Mitigation
Actions taken to reduce the impact or likelihood of threats.
Model-Based Systems Engineering (MBSE)
Model-Based Systems Engineering (MBSE) is the practice of developing a set of related system models that help define, design, and document a system under development. These models provide an efficient way to explore, update, and communicate system aspects to stakeholders while significantly reducing or eliminating dependencies on traditional documents.
N
Nonfunctional Requirements (NFRs)
Non-functional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.
Open Source Intelligence (OSINT)
The process of gathering information from publicly available sources for intelligence purposes.
Open-Source Scanning (OSS)
Scans source code for Open-Source Licenses needing approval.
Operational Technology (OT)
Hardware and software used to detect or control physical processes, devices, and infrastructure in industrial environments.
Patch Management
The process of applying updates to software and systems to fix vulnerabilities and improve security.
Penetration testing
A testing technique used to identify vulnerabilities in the different parts of an information system by approaching testing like an attacker. It requires a very specialized skill set and is performed by persons dedicated to this type of testing.
PI Objectives
Program Increment (PI) Objectives summarize the business and technical goals that an Agile Team or Train intends to achieve in the upcoming Program Increment (PI).
Printed Circuit Board (PCB)
The baseplate for components in manufacturing.
Printed Circuit Board Assembly (PCBA)
The PCB with the addition of the electrical components.
Product Issue Number (PIN)
Product Issue Numbers are unique for every identified problem of the product life cycle and are not changed once assigned. A Product Issue Number shall be the only used identifier for an issue during communication via support cases, Field Communications, etc.
Portfolio Backlog
The Portfolio Backlog is the highest-level backlog. It provides a holding area for upcoming business and enabler epics intended to create and evolve a comprehensive set of solutions.
Portfolio Canvas
The Portfolio Canvas is a type of Business Model Canvas adapted to a charter and describes the structure and purpose of the portfolio.
Portfolio Kanban
The Portfolio Kanban is a mechanism used to visualize, manage, and analyze the prioritization and flow of portfolio Epics from ideation to implementation and completion.
Portfolio Level
The Portfolio Level contains the principles, practices, and roles needed to initiate and govern a set of development Value Streams. This is where strategy and investment funding are defined for value streams and their solutions. This level also provides Agile portfolio operations and Lean governance for the people and resources needed to deliver solutions.
Pre-and Post-PI Planning
Pre– and Post–Program Increment (PI) Planning events are used to prepare for, and follow up after, PI Planning for Agile Release Trains (ARTs) and Suppliers in a Solution Train.
Product Portfolio Management (PPM)
Product Portfolio Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban, and developing the program Vision and Roadmap.
Product Owner (PO)
The Product Owner (PO) is a member of the Agile Team responsible for defining stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.
Product Security Context
Security provided to the product by the environment (asset owner deployment) in which the product is intended to be used (from IEC 62443-4-1)
Program Increment (PI)
A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.
Program Increment (PI) Planning
Program Increment Planning is a cadence-based, face-to-face event that serves as the heartbeat of the streams. It aligns all the teams in the streams to a shared mission and Vision.
Program Kanban
The Program and Solution Kanban systems are a method to visualize and manage the flow of Features and Capabilities from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline.
Program Level
The Program Level contains the roles and activities needed to continuously deliver solutions via an Agile Release Train (ART).
QR
Release Owner
The Release Owner ensures the system or product is ready to be released from an R&D perspective. He/she collaborates with the teams, stream owners, product owners, product managers, managers, steering committees, and other stakeholders to prepare the release.
Release on Demand
Release on Demand is the process by which new functionality is deployed into production and released immediately or incrementally to customers based on their requirements.
Release Roadmap
The Release Roadmap is a high-level overview of key events and milestones that communicate the planned intermediate and final deliverables to achieve a release. It shows all ongoing releases in a stream.
Responsible, Accountable, Consulted, Informed -matrix (RACI)
A standard method of defining and documenting the expected involvement of organizational roles/functions (e.g. release owner, product owner, etc.) for activities in a work process.
Role-Based Access Control (RBAC)
A method of restricting access to resources based on the roles assigned to users within an organization.
Root Cause Analysis (RCA)
For defects, RCA is an approach for developers to better understand why a fault occurred and to take steps to drive improvements. The cause can e.g. depend on requirements, architecture, design, coding, test, and deployment. The development process can be improved to prevent the issues.
It is a systematic process that identifies possible causes of a particular event of interest, performed with the understanding that events may be due to several causes, rather than only the immediately obvious symptoms. It may require the analysis of architectural and design processes,
organizational and management characteristics, human aspects, and external events, following appropriate techniques.
S
Scrum Master
Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, development principles, and practices, ensuring that the agreed Agile process is being followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.
Scrum
Scrum is a lightweight process to deliver value for cross-functional, self-organized teams in streams. It combines the power of Scrum team management practices with development principles and practices.
Security Controls
Countermeasures are designed to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets.
Security Critical Component (SCC)
Any element within a system whose compromise could significantly impact the system's security posture, leading to potential breaches, data loss, or operational disruption.
Identifying and protecting these components is essential for maintaining the overall security of a system or network.
Security Design Analysis
A systematic process used to evaluate and ensure the security of a system or application during its design phase. The goal is to identify potential security issues and incorporate measures to mitigate risks before the system is built and deployed.
This proactive approach helps in creating a robust security posture and preventing vulnerabilities.
Set-Based Design
Set-Based Design (SBD) is a practice that keeps requirements and design options flexible for as long as possible during the development process. Instead of choosing a single-point solution upfront, SBD identifies and simultaneously explores multiple options, eliminating poorer choices over time. It enhances flexibility in the design process by committing to technical solutions only after validating assumptions, which produces better economic results.
Shared Services
Shared Services represent the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be dedicated full-time.
Solution
Each Value Stream produces one or more solutions, which are products, services, or systems delivered to the customer, whether internal or external to the enterprise.
Steering Committee (SteCo)
A steering committee is a group of managers and experts. They provide direction, scope, budget, and timeliness, and recommend what processes/methods to be used.
Stream
The system- and development streams (aka Agile Release Train) are a long-lived team of agile teams, which, along with other stakeholders, incrementally develop, deliver, and where applicable, operate one or more solutions in a value stream.
Stream Backlog
The Stream Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Stream. It also contains the enabler features necessary to build the Architectural Runway.
Stream Owner/ Release Train Engineer (RTE)
The Stream Owner (Development or System Stream) is a servant leader and coach for the Stream. The Stream Owner's major responsibilities are to facilitate the Stream events and processes and assist the teams in delivering value. Stream Owners communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.
Synchronized Program Increment (SPI)
The SPI aligns the Program Increments across all streams. See Program Increment (PI).
System Test (ST)
System Test (ST or STT) includes non-functional requirements testing, DSAC testing, and other acceptance tests for system releases.
System Test Team
The test team(s) are performing tests on the system releases.
System Stream
The System Stream contains the roles, artifacts, and processes needed to build large and complex system releases.
System Stream Backlog
The System Stream Backlog is the holding area for upcoming capabilities and enablers, each of which can span multiple Dev. Streams and is intended to advance the system solution and build its architectural runway.
System Stream Configuration
The System Stream configuration introduces the Business Solutions and Lean Systems Engineering competency, which supports those building the largest and most complex solutions that require multiple Agile Release Trains and suppliers but do not require portfolio-level considerations.
System Context / Solution Context
System Context identifies critical aspects of the operational environment for a solution. It provides an essential understanding of the requirements, usage, installation, operation, and support of the solution itself. System context heavily influences opportunities and constraints for Release on Demand.
System Stream Demo
The System Stream Demos evaluate the results of integrated deliverables from the streams and make the results visible to customers and other stakeholders.
Solution Intent
The Solution Intent is the repository to store, manage, and communicate the knowledge of current and intended solution behavior. Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, functional and non-functional tests; and traceability.
Stories
Stories (aka User Stories) are short descriptions of a small piece of desired functionality written in the user's language. Agile teams implement small, vertical slices of system functionality. Complete a story in a single iteration.
Supplier
A Supplier is an internal or external organization that develops and delivers components, sub-systems, or services that help Solution Trains and Agile Release Trains provide Solutions to their Customers.
Stream Demo
The Stream Demo (system and development streams) is a significant event that provides an integrated view of new features for the most recent iteration delivered by all teams in the streams. Each demo gives stream stakeholders an objective measure of progress during a Program Increment (PI).
System Architect Team
The System Architect Team is responsible for defining and communicating a shared technical and architectural vision for systems and products to help ensure the system or product under development is fit for its intended purpose.
T
Team Backlog
The Team Backlog contains user stories and enablers that originate from the program backlog, including stories that arise locally from the team's local context. It may include other work items representing all the things a team needs to do to advance their portion of the system.
Team Kanban
Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work in Process (WIP) limits, measuring throughput, and continuously improving their process.
Team Level
The Team Level contains the roles, activities, events, and processes in which Agile Teams build and deliver value in the context of the Agile Release Train (ART).
Team and Technical Agility Competency
The Team and Technical Agility Competency describes the critical skills and Lean-Agile principles and practices that are needed to create high-performing Agile teams that create high-quality, well-designed technical solutions.
Temporary Correction (TC)
A correction of a bug delivered to a specific customer.
Test Automation (TA)
Perform automatic tests of epics, features, and user stories using test automation tools.
Test Strategy and Plan
A high-level document outlining the test approach for a release. Describe the test strategy (test levels, test stages, test environment) and plan (milestones, resources, key activities, and meetings).
Threat
A circumstance or event with the potential to adversely affect operations (including mission, functions, image, or reputation), assets, control systems, or individuals, via unauthorized access, destruction, disclosure, modification of data, and/or denial of service. (from IEC 62443-4-1)
Threat modeling
A structured approach to identify, evaluate, and address potential threats and vulnerabilities in a system or application. The goal is to proactively identify security risks and design effective countermeasures to protect against these threats.
Threat modeling helps to understand security posture and prioritize their efforts to mitigate risks.
Security design analysis technique that identifies potential security issues. (from IEC 62443-4-1)
Trust Boundary
A point between components within a system where a trust decision has to be made by the components. The decision may require authentication, the evaluation of whether the component is authorized to operate in a certain way (different privilege levels at stake), or data validation is needed (e.g. if data comes from an untrusted/unauthenticated source).
Trust Boundary is typically described in threat models.
An element of a threat model that depicts a boundary where authentication is required or a change in trust level occurs (higher to lower or vice versa) (from IEC 62443-4-1)
UV
Validation
It is the process of evaluating the final product to check whether the software meets the business or operational needs of the end user. Validation means are we building the right product.
Value Stream Coordination
Value Stream Coordination guides how to manage dependencies and exploit the opportunities in a portfolio.
Value Streams
Value Streams represent the series of steps an organization uses to build systems and products that provide a continuous flow of value to a customer. The portfolio consists of a set of development value streams, each of which builds and supports one or more solutions.
Verification
It is the process of evaluating the intermediary work products of a software development lifecycle to check if we are on the right track to creating the final product. Verification means are we building the product right.
Vision
The Vision is a description of the future state of a solution under development. It reflects the customer and stakeholder needs described in features and capabilities.
Vulnerability
A weakness or flaw in a system, application, or network that could be exploited by an attacker to gain unauthorized access, compromise data, or disrupt operations.
Vulnerabilities can exist in software, hardware, or even organizational processes.
Vulnerability Assessment
The process of identifying, analyzing, evaluating, and prioritizing vulnerabilities in systems or applications.
W
Weighted Shortest Job First (WSJF)
Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (e.g., SystemEpics, Epics, and Features) to produce maximum economic benefit. Estimate WSJF by dividing the Cost of Delay (CoD) by the size of the job.
Witadmin
Witadmin is a command-line tool that comes with Visual Studio and is used to customize and manage objects for tracking work in Azure DevOps Server (on-premises). With Witadmin, you can:
- Create, delete, import, and export objects such as categories, global lists, global workflows, types of links, and types of work items.
- Manage work item fields by deleting, listing, or changing their attributes.
- Handle work item types by importing, exporting, renaming, or permanently deleting them.
Y
YAML Ain't Markup Language (YAML)
YAML is a human-readable data serialization language often used for writing configuration files and data exchange between languages with different data structures.
Z
Zero-Day Exploit
An attack that takes advantage of a previously unknown vulnerability, which has not yet been patched or addressed.
Zero Trust
A security model that assumes no implicit trust and requires verification for every request or access attempt, regardless of where it originates.