Share Glossary

Brief table of content

Glossary

Cpdm glossary.

Brief table of content

Detail table of content

CHAPTER 1 Thank mentors

CHAPTER 2 Reveal background

CHAPTER 3 Explain book

CHAPTER 4 Start development

CHAPTER 5 Identify value chain

CHAPTER 6 Utilize processes

CHAPTER 7 Capture staffing & requirements

CHAPTER 8 Predetermine solutions & suppliers

CHAPTER 9 Design architectures

CHAPTER 10 Finalize design & requisites

CHAPTER 11 Realize and integrate white-box

CHAPTER 12 Verify black- & white-box

Watch references

Track indexes

Share glossary

The words and phrases below, from the commonly accepted to the self-invented to fill yet unexplored gaps, are the core building blocks in Cpdm. These are also the building blocks in Process Tasks, Masters, and Schedules, which are mainly defined in chapter “Utilize processes,” page 81.

(Disclaimer: the important thing is not what particular words are used, but rather that the reserved words throughout Cpdm are defined and used in a holistic, consistent, and comprehensible way).

Reserved word

Cpdm definition

Common definition

 . (period)

Delimiter to denote Black-/white-box hierarchy

Not often defined

 : (colon)

 ; (semicolon)

Delimiter to denote Version or Variant (to name a file Version in Windows, colon is not allowed in file names, but instead use semicolon)

Not often defined

- - (hyphens)

Wrapper to denote Connection interface

Not often defined

[  ] (brackets)

Wrapper to denote Boundary interface ( ]outside[, [inside], and ]both sides] )

Not often defined

Ability
(of an architecture ingredient)

Often Architecture ingredients require certain abilities, which may be specified in the Architecture resumé or in advance as a Restriction requirement s. Also see Item .

More vague

Abstract element

An Element in an Architecture encircling ingredients for the purpose of showing that they somehow belong together

Not often defined

Activity

Activities

A piece of human work (see Table 5-2, p. 68)

Not often defined

Activity-oriented

To emphasize the importance of a Value chain ’s progressing Activities , and thereby suppressing the importance of Result s. Also see Result-oriented .

More vague

Added value

The value of a Result generated by an Activity , subtracted the value of the sources used by this Activity

About the same

Address label

Entrance location among assembler instructions (see Table 9-27, p. 396)

About the same

Aggregate

Merging parts to the whole (see Table 6-3, p. 85)

About the same

Aliases
(in programs)

Assigning text names to parameters, in order to make them self-explanatory, thus easier to read and understand

About the same

Alternating activities and results

Illustrating a Value chain as a network of interconnected alternating pairs of Activities and Results

Not defined

Architect

A developer Role in designing and illustrating Architectures

About the same

Architecture

Various kinds of Product structure descriptions containing Architecture ingredient s. This definition includes also immaterial Program ingredients. Also see Architecture resumé , Logical architecture and Physical architecture

About the same

Architecture design

Populate Environment interfaces or White-box es with Architecture ingredient s, in such a way that its Requirements are satisfied as well as possible

Rather similar

Architecture ingredient

Architecture resumé constituents, such as User s, Black-box es, White-box es, Element s, and Interfaces

Not often defined

Architecture resumé

List of decided ingredients, derived from solution alternatives or supplier samples thereof (see Table 9-8, p. 344).

Also see Logical architecture and Physical architecture .

Not often defined

Artifact

Something artificially developed or produced, including immaterial Artifacs

About the same

Artificial complexity

Complex ity caused by incompetent usage of a sufficient model, or correct usage of an insufficient model. Also see Intrinsic complexity .

About the same

Assembler program

Programs containing symbolic mnemonics instead of machine-dependent instructions, arithmetic calculation support, user naming of variables and address labels, which consequently need assembler and linker tools for translation to machine instructions and variables (see Table 10-73, p. 516)

About the same

Asnchronous interface

A connection interface with a storage buffer function, to allow receiving at another pace and rhythm than was transmitted (see Table 9-29, p. 402)

Not often defined

Attachment
(interface graph)

A graph of mechanical Connection interfaces

Not defined

Basic use-case

Stakeholder-expected behavior on interfaces of a black-box, specified by one interaction or a sequence of interactions (see Table 7-30, p. 221)

More vague

Behavior requirement

Stakeholder-expected behavior on interfaces of a black-box (see Table 7-17, p. 206)

More vague

Black-box

Element which conceals all of its inward content, but shows its dynamic behavior via its interfaces. Can be opened to become a white-box (see Table 9-2, p. 335).

About the same

Black-box requirement

Stakeholder-documented and prioritized expectations from a black-box (see Table 7-7, p. 184)

About the same

Black-box test-case

Concretization of behavior requirements, to be a practical base for verification of black-box behavior (see Table 12-31, p. 705)

More vague

Black-box wait-state
(or just wait-state)

A black-box being in stand-by mode, awaiting random stimuli on any of its interfaces or from internal time-out (see Table 7-34, p. 224)

. Also see Wait-state .

Not defined

(in clean room called usage state)

Black-/white-box

An autonomous Element provided with own Requirements

About the same

Black-/white-box hierarchy

The concept of containing Black-box es embedded inside each other, in order to scale up and Master an otherwise flat, vast, and unmanageable Product

Not often defined

Black-/white-box nesting level

The hierarchical Product structure of Embedded black-/white-box es, starting at Nesting level = 1 for the Outermost black-/white-box embedded in the Environment , and incrementing one Nesting level for each Inward Embedded black-/white-box

Not often defined

Boundary interface

The means for two or more elements to keep apart (see Table 9-10, p. 346)

Not often defined

Business case

Estimate of any economical opportunities for a Product (for example return on investments), to motivate the Product to be developed

More general

Capture requirements

To refine Requirements from an Outward Black-box , and supplement these with new stand-alone Requirements

More vague

Cascading results

To understand and illustrate a Value chain as a network of interconnected Results

Only in Cpdm

Class

Collection of Function s, Variable s, Object s, and nested Objects

Accepted

Class shape(requirement)

Program Element , capturing appearance of Function s, Variable s, and Object s, preferably kept in separate Header file s. Also see Shape requirement and Function shape (requirement) .

Only in Cpdm

Clean-room engineering

An approach to apply the same “clean” Intellectual control in Program development as is long established in development and manufacturing of semiconductors

The same

Complex

Something currently not sufficiently understood and thereby not predictable enough, in severe cases denoted as chaos. Paradigm shifts may accelerate understandability. (See  p. 20).

Not often defined

Component

Approved Item s, after the Product prototype has passed Verification , to be used (or Reuse d) when manufacturing the Product .

More vague

Compound requirement

Requirement specified without making any distinction in whether it is a Restriction requirement or a Behavior requirement .

Not often defined

Configuration management(CM)

The science of handling growth of a Modularize d Product over time, by controlling changes through Version handling, in order to judge how Product parts are compatible with each other

About the same

Connection interface

The means for two or more elements to influence each other (see Table 9-10, p. 346)

More vague

Consistency

The degree to which different descriptions of a unified whole fit together. High Consistency means that all descriptions fit together perfectly, and is achieved through heightened Formalism .

About the same

Cpdm

Complex product development model

Cpdm is the abbreviation of Complex Product Development Model, explained in this book; a model based on carefully selected world-class methods, adapted by thorough experience from the development industry

By now defined

Critical path

Activities impossible to execute in parallel, compressed to one sequence without time gaps, in order to estimate the shortest possible execution time of all these Activities

About the same

Customer

The party paying for a developed Product to satisfy a perceived need. Also see User

About the same

Customer-oriented

Satisfying the Customer more than any other Stakeholder , such as technicians or retailers

About the same

Decompose

To open identified Black-box es and get them populated with ingredients, which may in turn be Embedded black-/white-box es

About the same

Demand

How an Activity or Value chain ensures necessary source Result (s)

Not defined

Designer

An engineer who provides Solution alternatives , Architecture ingredient s, and White-box design item s.

About the same

Design item

Material (including linkable programs) specified with desired granularity formal enough to be orderable (see Table 10-1, p. 440)

Vague

Design item properties

Technical characteristic of White-box design item s, such as size, color, Quality , reusability etc.

Not so precise

Determined architecture ingredient

Architecture ingredient to some extent stipulated by a Restriction requirement , but yet chosen rather freely

Not defined

Development board

Package of tools for developing an electronics device, for example, containing a printed circuit board with a processor, memory circuits, IO circuits, sometimes an experimental area, and sometimes a Program loader from Host Development system

The same

Development staffing

From whom to get support for surveying the existing environment, developing the product interfaces to the environment, and developing each inward embedded white-box (see Table 7-3, p. 179)

Sometimes defined

Development system

Package of tools for development of Programs on a Host computer, typically containing editor, compiler, linker, built-in Program libraries , and debugger. A developed Program can be intended for the Host computer or be Port ed to another computer Target

The same

Development system libraries

Precompiled and linkable callable subroutines built into most Development systems to be used to access the computer peripherals

About the same

Downstream

Direction of progressing development, from the original idea to the developed Product ready for manufacturing, also see Upstream

Not often defined

Element

Architecture ingredients package, which has interfaces to its surroundings (see Table 9-1, p. 335)

Many different definitions

Element
(in assembler programs)

Element containing ingredients such as unprotected Variables and unstructured Instructions

About the same

Element
(in structured programs)

Element containing Structured program ingredients, with Functions containing exclusively structured types of Instructions (see Function , Variable , and Instruction )

About the same

Element
(in object-oriented programs)

Elements containing ingredients as in Structured program s, but also containing Objects (see Variable , Object , and Instruction )

About the same

Embedded black-/white-box

Embedded white-box

Embedded black-box

Black-/white-box connected by Interfaces to surrounding White-box design items

Not often defined

End user

See User

About the same

Enfold

To surround White-box es with White-box design item s, which consequently will belong to Outward White-box es or Environment interfaces

Not defined

Environment

The existing surroundings and the interfaces to the product being developed (see Table 9-2, p. 335)

About the same

Environment architecture resumé

List of existing relevant ingredients in the environment and newly developed interfaces to the product (see Table 9-3, p. 336)

Not often defined

Environment interfaces

All Interfaces between the Outermost black-box and the Environment

Not often defined

Environment interfaces design item

Specified design, including technical properties, needed to realize and manufacture the product interface to environment (see Table 10-2, p. 441)

More vague

Environment interfaces solution alternatives

Various interface solution proposals how to best possible satisfy one or several specified environment restrictions (see Table 8-1, p. 287)

Not often defined

Environment nesting level

Name of the Product structure surrounding the Outermost black-/white-box

Not often defined

Environment logical architecture

Logical drawing of the environment ingredients, including the product black-box with its interfaces (see Table 9-3, p. 336)

Not often defined

Environment physical architecture

Appearance illustration of the environment surrounding the black-box of the product (see Table 9-3, p. 336)

Not often defined

Environment restriction requirement

Limitations in the existing environment that will impact the product to be developed (see Table 7-1, p. 178)

About the same

Exception use-case

Unfavorable sequence of stimulus and responses interacting on interfaces to a black-box (see Table 7-29, p. 221)

About the same

Explicit verification

Verification and complete Failure elimination of a Black-/white-box before being integrated in its Outward Black-/white-box

Not defined

Failure detection

Detecting that a Verification outcome doesn’t comply with Test-case pass criteria

Not often defined

Failure localization

An investigation to find the exact position of a failure in the Product prototype and/or underlying documentation. One Failure detection may depend on several Failure localizations

Not often defined

Failure elimination

Removal of a detected failure to get it passed in a re Verification , either through changes in the Test-case , changes in the Realization , and/or changes in underlying documentation.

Not often defined

Failure elimination report

Report of each detected failure, explaining where its source is located, and proposing how to eliminate it in the optimal way (see Table 12-6, p. 672)

Not often defined

Fake black-/white-box

A Black-/white-box containing Embedded black-box es which are (often simple) fakes, in order to make the Black-/white-box partially verifiable. In Programs a fake is also called stub.

Not defined

Finalize design item

Transformation of Architecture ingredients to detailed White-box design item s, exactly orderable from Suppliers or in-house

Very vague

Finalize product requisite

Account for the total cost of material, work, and equipment of manufacturing, Realization , and development.

More vague

Fixture

Temporary device for holding a work-piece (typically a Black-box ) during Verification . also applicable for immaterial Fixtures such as a temporary Program wrapping a Black-box Program to be verified.

More vague

Formal use-case

A sequence of Use-units interacting on interfaces to a black-box, starting from and ending in an explicit wait-state, with all responses in between explicitly calculated from specified stimuli histories (see Table 7-37, p. 228)

More vague

Formal scenario

A network of formal use-cases, assembled by attaching their wait-states (see Table 7-39, p. 230)

Not often defined

Formalism

Complying with concepts consistently shared by colleagues

More vague

Full verification

Verification of a completely realized Black-/white-box , executing a final set of Test-case s, until all failures are eliminated, and all Test-cases have passed.

More vague

Function

Encapsulation of local variables and instructions (see Table 9-31, p. 414)

About the same

Functional decomposition

A bad habit to systematically design Architecture Elements to encapsulate behavior instead of artifacts. a sign of this is that the Element name becomes a verb instead of a noun.

About the same

Function shape (requirement)

Program Element capturing appearance of Function s, kept in separate Header file s. also called “forward function declaration” or misleadingly “function prototypes”. Also see Shape requirement and Class shape (requirement) .

Only in Cpdm

Global variable

Storage of stimuli history which are accessible from any function (see Table 9-31, p. 414). Also see Machine variable and Local variable .

About the same

Govern

Documented process regulation, controlling development in reality (see Table 6-6, p. 89)

Not defined

Guru

Developer primarily promoting own ego rather than ensuring the developing company's best interests

About the same

Granularity

Relative size of parts (compared to size of the whole)

About the same

Header file

Element exclusively containing program commands for better readability and control; never resulting in anything executable in final machine programs (see Table 10-86, p. 533)

The same

High-level program

See Structured program and Object-oriented program .

About the same

Host
(for development)

Capable full development system offered for convenient development of a scanty system, to later be Port ed to its final scanty Target

About the same

Idle wait-state

The Wait-state in a Formal scenario , where most Use-cases originate, and where they depart to when finished

More vague

Implicit verification

Verification and Failure elimination of a Black-/white-box after invaded in its Outward Black-/white-box

Not defined

Incorporative integration

The most preferred way to integrate, meaning that self-contained and fully verified White-box es are inserted into their surroundings (also see Invasive integration )

Not defined

Incremental development

Grouping Requirements into increments, and ordering these for development in such a sequence that during Realization of each increment the Product prototype becomes useful for the Stakeholders to evaluate

About the same

In-house design item

Design developed by in-house workforce (see Table 10-1, p. 440)

Not often defined

In-house role item

Development, realization, and manufacturing in-house workforce (see Table 10-1, p. 440)

Not often defined

Innermost white-box

Innermost black-box

Innermost black-/white-box

Black-/white-box es not containing any Inward Embedded black-/white-box es

Not often defined

Instruction
(in programs)

Computer executable command

About the same

Instruction
(in assembler programs)

Executable limitless command (see Table 9-27, p. 396)

About the same

Instruction
(in structured and object-oriented programs)

Executable command, exclusively consisting of the types: sequence, selection, iteration, or call to functions (see Table 9-31, p. 414)

About the same

Integration

To integrate inside-out, see Incorporative integration , Full verification and Explicit verification . to alternatively integrate outside-in, see Invasive integration , Partial verification , and Implicit verification .

About the same

Integration report

Description of fulfillments and shortcomings when joining and assembling items, like wrongly designed interfaces, items not fitting together, and so forth (see Table 11-3, p. 599)

Not often defined

Intellectual control

A Result so well described that developers understand that it is correct by only inspecting it (and not needing to verify it).

About the same

Interaction requirement

Behavior requirement describing cooperation over a connection interface to a black-box or between black-boxes (see Table 7-19, p. 206)

More vague

Interface

The means for two or more elements to influence each other, or to keep each other apart (see Table 9-1, p. 335). Also see Connection interface and Boundary interface .

Not often defined in this way

Interrupt

A signal from a port or an internal clock that causes a program to jump to a special location to perform an urgent execution before returning (see Table 9-29, p. 402)

About the same

Intrinsic complexity

By nature being Complex , which cannot be reduced (by models so far). Also see Artificial complexity .

Not often defined

Invasive integration

Directly realize an Embedded white-box to existing Environment interfaces or within an existing Black-/white-box (also see Incorporative integration )

Not defined

Inward

Direction from Product Environment towards inner Nesting levels of a Product hierarchical structure. Also see Outward .

Not defined

Item

All resources needed for product development, such as material, workforce, and equipment specified with desired granularity and formal enough to be traceable (see Table 10-1, p. 440)

Not often defined

Jump instruction

Command to continue execution at an Address label (see Table 9-27, p. 396)

About the same

Justified

How a Result qualifies its foregoing Task or Value chain

Not defined

Lead time

Calendar time between starting time and completion time, regardless of how much working time there is in between. Sum of working time between two time points is called effective time.

About the same

Life cycle status

Status of a Result , reflecting its degree of completion during its life from birth to death

About the same

Line

The (rather) static and most often hierarchical structure of Managers to lead a company

About the same

Line management

Organizing and leading organizations

About the same

Linkable program
(object code)

Program Items generated by assembler or compiler tools, to be integrated by a linker tool into an executable Machine program

About the same

Local variable

Storage of stimuli history, which are accessible only within the function (see Table 9-31, p. 414). Also see Machine variable and Global variable .

About the same

Logical architecture

Drawing illustrating how ingredients logically relate to each other (see Table 9-8, p. 344) Also see Architecture resumé and Physical architecture .

More vague

Low-level program

See Machine program and Assembler program .

About the same

Machine program

Machine executable Program resulting from assembler, compiler and linker tools applied on human readable Program s. Also see Machine instruction and Machine variable .

About the same

Machine variable

A read-write memory location to save and retrieve stimuli history data for further calculation (see Table 10-72, p. 515)

About the same

Machine instruction

Coded instruction to be decoded and executed by the controller or processor (see Table 10-72, p. 515)

About the same

Manager

The role of a human supervising Performers and Preparers in a value chain (see table 5-4, p. 79)

About the same

Managed information

Whenever releasing information, it must be documented, provided with unique identification, and spread to all affected people.

About the same

Marketer

A Product management Role to defend customers interest.

About the same

Master

A documented process regulation, governing how to organize a result to justify foregoing activity (see Table 6-1, p. 84)

Not often defined

Message sequence chart
(MSC)

Chart illustrating how stimuli and responses are distributed between architectural elements, including black-/white-boxes (see Table 9-22, p. 380).

About the same

Meta information

Information beyond Product information needed for control of Product development

More vague

Metrics

Measurements collected during Product development in order to follow up the Quality of the Process used

About the same

Modularize

To divide an unmanageable Monolith into interlinked self-sufficient pieces, assigned own unique identifiers

About the same

Module

Self-contained piece of a Result (also see Modularize and Managed information )

About the same

Module coupling

The degree of comprehensible dependency a Module has to its surroundings

About the same

Module strength

Module cohesion

The degree of comprehensible purpose of a Module

About the same

Monolith

An (often huge) Element that can be handled only as a whole, since its content have no evident Interfaces or its evident Interfaces are unmanaged

Not often defined

Nesting level

Location of a Black-/white-box in a hierarchical Product structure , starting with Nesting level = 0 at the Product Environment , and adding one to the Nesting level for each Inward Embedded black-/white-box

Not defined

Normal use-case

A favorable sequence of stimuli and responses interacting on interfaces to a black-box (see Table 7-29, p. 221)

About the same

Null series

Incipient manufacturing of a Product in order to finally adapt it for manufacturing and trimming the manufacturing equipment

About the same

Obey
(a process)

Development in reality performed in accordance with documented process regulation

Not defined

Object

Element created run-time by instantiation of a class specification. Objects may in turn contain objects, thereby enabling objects to be hierarchically organized. (See Table 9-35, p. 424).

About the same

Object-oriented program

Program containing classes instantiating objects, consisting of variables (can also be objects) and structured instruction functions (see Table 10-102, p. 554)

About the same

Observation post

Design for injecting Stimuli into, and drawing Responses off a Connection interface crossing a nondetachable boundary of a Black-/white-box to make it verifiable

Not often defined

Off-the-shelf item

Predeveloped reusable components (see Table 10-1, p. 440)

Not often defined

Off-the-shelf supplier

Suppliers offering Samples off the shelf, to be (almost) immediately delivered as specified by their Sample catalogue with data sheets

About the same

Outermost white-box

Outermost black-box

Outermost black-/white-box

The Black-/white-box having Interfaces to the surrounding existing Environment

Not often defined

Outward

Direction from inner Nesting levels towards the Environment nesting level of a Product hierarchy structure. Also see Inward .

Not defined

Paradigm shift

When a point of Complex ity is passed, where the old understanding no longer is rewarding, and a fundamental new approach must be applied to create better understanding

About the same

Partial verification

Incomplete but otherwise a normal Verification of a Black-/white-box , because inwards Embedded white-box es may be missing or containing fakes.

Not defined

Partition

Detaching parts from the whole (see Table 6-3, p. 85)

About the same

Performer

The role of a human participating in a value chain activity (see Table 5-4, p. 79)

Not often defined

Phase

Distinguished periods of a Process . The Cpdm total Process Schedule contains 13 Phase s, of which the 6 middle Phases are called technical Phase s.

Not defined

Physical architecture

Drawing illustrating how ingredients physically appear and how they combine with each other (see Table 9-8, p. 344). Also see Architecture resumé and Logical architecture .

More vague

Port
(a white-box)

To facilitate Integration of a White-box to its Target , it can be developed and verified in a capable Host , and then more easily be Port ed to its scanty Target .

About the same

Postcondition

The Wait-state to where transitions end up when all Responses have departed. Also see Precondition , Use-unit s, Use-case s.

About the same

Precondition

The Wait-state where a transition originates when Stimuli have arrived. Also see Postcondition , Use-unit s, Use-case s.

About the same

Preparer

The role of a human contributing to a value chain result (see Table 5-4, p. 79)

Not defined

Primordial architecture ingredient

Design chosen because referenced Restriction requirement has stipulated it

Not defined

Process

Regulative documentation(e.g. directives, organizations, Metrics and Schedule s) Govern ing all aspects of Product development

Not so strongly defined

Process management

The science of regulatory systems Govern ing all aspects of Product development, including improvement of it

About the same

Product

An artifact created by somebody, from raw materials to finished goods for a market, to satisfy a need (see Table 4-1, p. 38)

Same

Product development

Prototype development

The Stage from the time a new Product is first identified to the launch of that particular Product on the market. Prototype development is similar but lasts only until the Product prototype is developed and verified.

Same

Product line

A set of related Products (possibly in same Product portfolio ) that Reuse many of their Components from each other

About the same

Product portfolio

The overall market offering of related Products (with possible Reuse between them) in order to exploit a larger market by diversifying in such a way as not to cannibalize each other

About the same

Product proposition

Planned Product based on a profitable Business case and a market optimized Product portfolio

More vague

Product prototype

Realizations made during product development, for the purpose of being verified against its requirements, and to be validated against its user profiles (see Table 4-2, p. 40)

More vague

Product life cycle

Time period from start of development of a Product idea until the Product is phased out of the market, including possible warranties

About the same

Product management

Ensuring that a Product satisfies both User s’ expectation and manufacturers’ return on investment

About the same

Product requisite

Complete information about costs for all types of items, to allow accounting for development, realizations, and manufacturing (see Table 10-7, p. 443)

About the same

Product structure

Hierarchical Partition of a Product , containing mechanics, electronics, and Programs

About the same

Program

Program intended to be machine-readable, such as Machine program and Linkable program , and human-readable (being the origin, sometimes called source code) such as Assembler program , Structured program , and Object-oriented program

About the same

Program libraries

Program set of Elements built like any Component for Reuse . It can be a fully changeable Source system or precompiled to an unchangeable Linkable program .

About the same

Progressing activities

To help understand and illustrate a Value chain as a network of interconnected Activities

Not defined

Project

A temporary organizational structure in a company to accomplish an assigned objective within restricted conditions (time, cost etc.)

About the same

Project leader

The Manager of a Project , reporting to the Project sponsor

About the same

Project management

The science of handling Project s, including hard facts such as preparing and following up on plans, but also soft factors such as improving attitudes and reaching specified Quality

About the same

Project sponsor

A Line Manager owning and controlling a Project

About the same

Prototyping

Early and finite Activity to evaluate crucial Elements and Interface s, in order to consider technical risks and opportunities not yet captured

More vague

Provider

Organization offering workforce for development, Realization , and manufacturing

Not defined

Provider role item

Development, realization, and manufacturing hired workforce (see Table 10-1, p. 440)

Not often defined

Quality

The Ability of a Product to satisfy a User ’s explicit and implicit expectations

About the same

Quality management

The science of keeping (or improving) a specified degree of User Product satisfaction, including indirect soft causes such as capability of the organization, people, and Process es

More vague

Realization

A tangible construction (including Machine program s) being built from a description of it (including human readable Program s)

Not often defined

Received items deviation report

Deviation report on how received items (including linkable and possibly ported programs) match placed orders and other expectations (see Table 11-1, p. 599)

Not often defined

Recycle

Extracting Elements from earlier developed Result s, and rework them into newly desired Element s. Also see Reuse .

More vague

Refactoring

Restructuring an Element design without changing its behavior on its Interfaces

About the same

Refine requirement

See Requirement refinement .

Can mean whatever

Requirement refinement

To capture requirements for a Black-box by detailing Requirements from the Black-box one Nesting level Outwards

Can mean whatever

Requirement summarization

Generic Requirements being the fusion from detailed Requirements one Nesting level Inwards

Not often defined

Regression verification

Executing Test-cases that didn’t necessarily result in failures in previous Verification s, in order to secure that recent Failure eliminations have not caused any new detectable failures

About the same

Requirement

See Environment restriction requirement , Compound requirement , Restriction requirement , and Behavior requirement .

About the same

Requirement management
(RM)

The science of Requirement s, including how to capture and prioritize them, how to organize and store them, and how to refine them to Inward Black-box es

About the same

Response

Output from a black-box via connection interfaces (see Table 7-19, p. 206)

About the same

Restriction requirement

Stakeholders’ documented expectations of design inside a black-box (see Table 7-15, p. 204)

Not often defined

Restriction
(in programs)

Limitation of any parameter in a program (see Table 9-27, p. 396)

Not often defined

Result

Tangible output from an activity or value chain (see Table 5-2, p. 68)

Not often defined

Result-oriented

Emphasizing the importance of Cascading results rather than Progressing activities in a Value chain . Also see Activity-oriented .

More vague

Reuse

Develop a Component that can easily and without significant rework be used in other developments (also see Recycle )

About the same

Reuse plan

Based on proposed Product portfolio , a plan can be made how these Products can Reuse commonalities from each other.

More vague

Reusable item

Component built in such a way that it is easy to Reuse ; common in mechanics and electronics, but not (yet) in Programs

More vague

Road map

Studies of coming standards and trends, predicts new technology to be proactively tried out in-house or by preferred Suppliers

More vague

Role

A set of competencies, authorities, and responsibilities of a person (typically a user, an employee, or third-party contractor) (see Table 5-3, p. 79)

About the same

Role item

Accomplished and estimated work specified with desired granularity and formal enough to be traceable (see Table 10-1, p. 440)

Not defined

Sample

Offering by Supplier to match one or many Solution alternatives . Approved Samples become Architecture ingredient s, which, if still approved for Product prototype s, become White-box design item s, which, if still approved for manufacturing, become Component s.

About the same

Sample catalogue

Brochures from Suppliers showing off-the-shelf offerings appropriate for Product prototypes

About the same

Schedule

A documented process regulation package of alternating tasks and masters, governing how to organize a value chain (see Table 6-2, p. 85)

More vague

Scenario

Scenarios are interlinked use-cases. See Formal scenario .

Many definitions exists

Scenario-thread-machine

Wait-state-machine awaiting a manageable number of Stimuli of predictable sequence from one interlinked Scenario over its synchronized Interface s. Also see Wait-state-machine .

Not defined

Selected solutions supplier opportunities

Determination of which environment solutions are part of the product, and from where (including in-house) to get appropriate samples to match these solutions (see Table 8-1, p. 287)

Not often defined

Shape requirement

Program Element not generating any executable Machine program s, but specifying appearance of Functions or Variables (which may be Object s), or a compound thereof. Preferably kept in separate Header files to be referenced for inclusion in Source file s. Also see Class shape and Function shape .

Only in Cpdm

Solution alternatives

Whatever designs are found to more or less satisfy one or many Requirement s. also see Environment interfaces solution alternatives and White-box solution alternatives .

Not often defined

Source file

Element exclusively containing program instructions, finally resulting in executable machine programs (see Table 10-86, p. 533)

The same

Source system

A complete Element , so well documented that this Element can be fully incorporated and further developed in-house, like anything else developed in-house

About the same regarding programs

Specialization

To restrict an artifact in order to make it more particular with more unique characteristics (the opposite is generalization). (See Table 10-101, p. 553).

About the same

Specifier

A developer Role refining and capturing Requirements

The same

Stage
(of life cycle)

Period of a Product life cycle wherein Product development is the first Stage

Not defined

Stakeholder

Anybody who has legitimate and relevant interest in what to expect from the Product being developed

About the same

Stand-by wait-state

See Idle wait-state .

More vague

Start-up report

Report of obstacles and accomplishments when starting up a white-box or the environment interfaces (see Table 11-5, p. 600)

Not often defined

State

Any combination of Variable values stored in a White-box . Don’t mix it up with Black-box wait-state .

More vague

Stimulus

Stimuli

Input to a black-box via connection interfaces (see Table 7-19, p. 206)

About the same

Stimuli history

Stimuli histories

Referable history of all stimuli with their arguments received on interfaces of a black-box since it started up (see Table 7-36, p. 226)

About the same

Structured program

Program prohibiting unstructured flow by providing only structured machine-independent instructions, exclusively being sequence, selection, iteration, and function call, needing compiler and linker tools support to be translated to machine instructions and machine variables (see Table 10-85, p. 529).

 Also see Structured function call , Structured iteration instruction , Structured selection instruction , and Structured instruction sequence .

About the same

Structured function call

Command transferring execution to a Function bringing parameters to be passed, and with a return command leaving execution back bringing parameters to be passed back. Also see Subroutine call and Structured program .

About the same

Structured iteration instruction

Command forming a loop of Instructions to be repeatedly executed until a termination condition ends the loop. Also see Structured program .

About the same

Structured selection instruction

Command selecting execution to one of several branches of Instruction s, depending on how a selection condition turned out. Also see Structured program .

About the same

Structured instruction sequence

Commands in a sequence executed one after another. Also see Structured program .

About the same

Subroutine call

Command transferring execution to an Address label ed subroutine, and turning back execution after a return command, seldom with support of passing and passing back parameters. Also see Structured function call .

About the same

Subsystem

Parts resulting from Partition ing a system. because of ambiguity, this word is seldom used in this book. Also see System .

About the same

Supplier

Items not developed in-house are bought from Supplier s. In-house-developed Items might be considered as bought from internal Supplier s.

Accepted

Supplier design item

Design developed by suppliers (see Table 10-1, p. 440)

About the same

Supplier opportunities

The chance to buy White-box design items instead of develop them in-house

Not often defined

System

A demarcated part of the whole. Because of often seen ambiguity, this word is rarely used in this book. Also see Subsystem .

About the same

Tailor
(a process)

Adapt and concretize a generic Process to fit a certain Product and organization

About the same

Target

The final location where a Product is supposed to be used (also see Host )

About the same

Task

A documented process regulation governing how to organize an activity demanding source results (see Table 6-1, p. 84)

Not often defined

Terms

Mutual governing regulation of a role between a development company and its employees, consultants, or hired contractors (see Table 6-5, p. 88)

Not often defined

Test-case

Concretization of requirements in order to be a more efficient base for performing all kinds of verification (see Table 12-2, p. 671)

More vague

Test-use-case

A use case arranged in such a way that it is easy to execute it and evaluate its correctness by the human mind

Not defined

Thread

Program elements executing apparently concurrently, but in reality getting a time slot in sequence with all other threads (see Table 9-29, p. 402)

About the same

Traceability

This means that developed Results do reference each other, requiring that Results are Modularize d and each Module is assigned a unique identity.

About the same

Turnaround time

The time it takes from making a change in a finalized design until the change can be observed in the running Product prototype

About the same

Turnkey item

Custom-made design developed to fit very well into own design (see Table 10-1, p. 440)

About the same

Turnkey supplier

Suppliers offering to develop Items well fitting into design, based on own specified Requirements and/or solution proposals

About the same

Unbiased architecture ingredient

Design chosen freely, because referenced Requirements only specify behavior, or there are no Requirements to reference at all

Not defined

Unmanageable complexity

Something whose further development is unpredictable, because is has turned into something that can no longer be sufficiently understood. (See  p. 20).

Not often defined

Unstructured program

Program allowing various dangerous constructs, most notably the goto Instruction , for example Assembler program s, Basic, Cobol, and Fortran. Also see Structured program .

About the same

Upstream

Reverse direction of the normal progressing development, most often applied after Verification for the purpose of localizing and elimination of detected failures done in the past

Not often defined

Usage profile

Every stimulus causing departure from every wait-state is assigned estimated probabilities, to be used by black-box test-cases. (see Table 12-56, p. 732)

About the same

Use-case

A sequence of stimuli and responses interacting on interfaces to a black-box (see Table 7-29, p. 221)

About the same

User

Human role interacting with an element through a man-machine interface (see Table 9-1, p. 335)

The same

User profile

A Role description of an expected or potential User of the Product to be developed. sometimes referred to as persona. (don’t mix up with Usage profile .)

About the same

Use-unit

One stimulus arriving on an interface to a black-box being in a certain wait-state, causing zero, one, or more responses to leave the black-box before it enters its next wait-state (see Table 7-35, p. 225)

About the same

Value chain

Human work ongoing in reality for the purpose of transforming source results to Added value results (see table 5-1, p. 66)

More vague

Variable

Storage for arrived stimuli (see Table 9-27, p. 396). Also see Machine variable , Global variable and Local variable .

About the same

Variability of reusable components

The degree of possibility to adapt a Reusable item when to fit it into all sorts of different Products

About the same

Variant

Version

Variants are contemporary diversifications from a common artifact. A gradually extended diversification is often called version. The opposite is unification of variants to a primal artifact (see Table 6-4, p. 87)

More vague

Verification

To confirm that a realized black-/white-box or a prototype in the environment fulfills requirements on design and behavior (see Table 12-1, p. 661)

More restricted

Verification report

Report of pass/fail conclusions from each executed test-case (see Table 12-4, p. 672)

More vague

View

Different perceptions of same artifact, depending on how the observer relates to the artifact (see Table 6-4, p. 87)

About the same

V-model

Development model, starting with outside-in development in earlier Phase s, proceeding with inside-out development in later Phase s, thus forming a V when graphically illustrated

About the same

Wait-state

Often used for Black-box wait-state . See Black-box wait-state , Idle wait-state , Precondition and Postcondition .

Not defined

Wait-state explosion

Situation when an Element becomes incapable of coping with too many sequences of unsynchronized Stimuli on its Interface s. Also see Black-box wait-state and Scenario-thread-machine .

More vague

Wait-state-machine

Modeling black-box behavior by stimuli-initiated transitions between wait-states (see Table 7-40, p. 232)

The same

Waterfall model

An approach that each and every Result needs to be fully completed before it may be Demand ed by any succeeding Activity

More vague

White-box

Element which is an opened black-box, containing disclosed architecture ingredients, some of them possibly embedded black-boxes (see Table 9-7, p. 343)

Accepted

White-box design item

Specified design, including technical properties, needed to realize and manufacture the white-box (see Table 10-2, p. 441)

More vague

White-box solution alternatives

Various solution proposals for how to best possible satisfy one or several specified requirements (see Table 8-8, p. 296)

Not often defined

White-box supplier opportunities

Proposals of which suppliers (including in-house) can possibly provide appropriate samples to match specified solution alternatives (see Table 8-8, p. 296)

Not often defined

White-box test-case

Concretization of restriction requirements, to be an efficient base for verification of white-box design (see Table 12-31, p. 705)

More vague

White-/black-box

Same as Black-/white-box .

About the same