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 |
