Glossary
RSP GLOSSARY
-
- Abstract component:
- A family of components characterized by a defining abstraction and the
decisions that are needed to distinguish among the members of the family (or
to extract a concrete component).
- Abstraction:
- A description of a collection of things that applies equally well to any
one of them. Also, a concept that denotes the common properties of a
family.
- Activity:
- A step of a process for producing and/or evaluating work products to
satisfy objective(s) supporting that process. An activity comprises other
steps.
- Adaptable Component:
- A Domain Engineering work product that implements a Component Design.
See Abstract component.
- Application:
- The hardware, software, and manual procedures that characterize a
system.
- Application Engineering:
- An iterative process for the design and development of a product that
satisfies specified customer requirements. Its work products are an
Application Model and an Application Product. For the leveraged Synthesis
process, see Application Modeling (Activity), Application Production
(Activity), Delivery and Operation Support (Activity), and Project Management
(Activity).
- Application Engineering Environment:
- Automated support provided for a prescribed Application Engineering
process. See Process Requirements and Process Support and Infrastructure.
- Application Engineering Process Support:
- A Domain Implementation, from the perspective of an Application
Engineering project.
- Application Model:
- A set of resolved requirements and engineering decisions, as specified
by a Decision Model, that (partially) determine an instance of a family of
systems. See Application Modeling Notation.
- Application Modeling (Activity):
- The Application Engineering activity that produces a validated
Application Model sufficient to derive a production-quality Application
Product that satisfies customer requirements. See Specification (Activity),
Validation (Activity), and Assessment (Activity).
- Application Modeling Notation:
- A notation for expressing an Application Model such that a complete
Application Model is sufficient to distinguish uniquely any system of a
domain. See Process Requirements.
- Application Product:
- Software artifacts, including code and documentation, produced by the
Application Production activity to satisfy customer requirements.
- Application Production (Activity):
- The Application Engineering activity that produces an Application
Product, as specified by an Application Model, and Delivery Support. See
Generation (Activity) and Special Components Implementation (Activity).
- Architecture:
- A set of design structures that characterize a system and each
associated artifact (i.e., work products).
- Assessment (Activity):
- The Application Modeling activity that produces analyses of the degree
to which alternative Application Models satisfy the operational (e.g.,
performance, reliability) and product quality requirements of the customer.
- Business area:
- A coherent market characterized by (potential) customers possessing
similar needs.
- Business-area knowledge:
- Information that characterizes the market for a domain including:
-
Current and future customer and contract profiles
-
Projected growth in contracts (or sales)
-
Value and marketability of features
-
Market analyses
- Business-area organization:
- An organization whose mission is the production and delivery of products
for customers in a specified business area.
- Business objectives:
- The needs of a business-area organization that determine the scope and
extent of a domain.
- Candidate Components:
- A set of previously-built components that have been judged as qualified
for potential use as raw material in the engineering of Adaptable Components.
- Commonality:
- A characteristic of a domain that corresponds to a similarity among
members of the associated family of systems. See Variability.
- Component:
- A work-product fragment whose production is a managed work assignment.
See Abstract component.
- Component Design:
- The element of a Product Design that defines the design of a component
identified in a Product Architecture.
- Component Design (Activity):
- The Domain Analysis activity that creates a Component Design.
- Component Implementation (Activity):
- The Domain Implementation activity that creates Adaptable Components, as
specified by a Component Design.
- Constraint:
- A limitation on decision(s).
- Customer:
- The person(s) or organization(s) that specify the requirements, accept,
and authorize payment for a product.
- Customer requirements:
- A description of the capabilities, as understood by customers, required
of a system and any constraints on the engineering of that system.
- Decision:
- A choice among allowable alternatives.
- Decision constraint:
- A set of constraints on the resolution of interdependent decisions.
- Decision group:
- A logical grouping of decisions in the Application Modeling Notation
that allows the application engineer to separate concerns when describing a
system.
- Decision Model:
- The element of a Domain Specification that defines the abstract form
(concepts, decisions, and structure) of an Application Modeling Notation.
- Decision Model (Activity):
- The Domain Analysis activity that creates a Decision Model.
- Decision specification:
- A specification of the set of decisions that suffice to distinguish
among members of a family.
- Delivery and Operation Support (Activity):
- The Application Engineering activity that delivers an Application
Product to customers and supports its use.
- Delivery Support:
- Software artifacts produced by the Application Production activity to
support the Delivery and Operation Support activity for delivery of an
Application Product to customers.
- Dependency constraint:
- A relationship specifying how decisions made by an application engineer
limit subsequent decisions.
- Derived requirements:
- Requirements that indicate characteristics specific to particular
systems in the domain based on the decisions that an application engineer
expresses in an application model.
- Design structure:
- A set of relationships among a set of components that represent some
characteristic of the aggregate. Examples for a program are dependency
structures that define a program's static structure and process structures
that define its dynamic behavior.
- Document:
- A documentation component, including textual and graphical artifacts.
- Domain:
- A product family and an associated production process supporting a
product line.
- Domain Analysis (Activity):
- The Domain Engineering activity in which domain knowledge is studied and
formalized as a Domain Definition and a Domain Specification. The expertise
in a business area is formalized to create standards for problem descriptions
and corresponding solutions. See Domain Definition (Activity), Domain
Specification (Activity), and Domain Verification (Activity).
- Domain Assumptions:
- The element of a Domain Definition that defines the guiding assumptions
and justifications of domain scope and extent.
- Domain Definition:
- An informal description of the scope, extent, and justification for a
domain. See Domain Synopsis, Domain Glossary, Domain Assumptions, and Domain
Status.
- Domain Definition (Activity):
- The Domain Analysis activity that creates a Domain Definition.
- Domain Delivery (Activity):
- The Project Support activity that assists Application Engineering
projects in the effective use of Application Engineering Process Support.
- Domain Engineering:
- An iterative process for the design and development of (1) a product
family and (2) an Application Engineering process for producing members of
that family. See Domain Management (Activity), Domain Analysis (Activity),
Domain Implementation (Activity), and Project Support (Activity).
- Domain evolution:
- Revision of a Domain Definition, Domain Specification, and associated
Application Engineering Process Support to reflect changes in domain scope.
- Domain Glossary:
- The element of a Domain Definition that defines the terminology of a
domain.
- Domain Implementation:
- A Product Implementation and Process Support that satisfies a Domain
Specification.
- Domain Implementation (Activity):
- The Domain Engineering activity that creates support for Application
Engineering projects in the form of a Domain Implementation. See Product
Implementation (Activity) and Process Support Development (Activity).
- Domain knowledge:
- Knowledge and expertise characteristic to a domain:
-
Relevant scientific theory and engineering practice
-
Capabilities and uses of existing systems
-
Past system development and maintenance experience and work products
-
Potential developments in related or supporting technology
-
Potential changes in customer needs
- Domain Management (Activity):
- The Domain Engineering activity that plans, monitors, and controls the
activities and resources of a Domain Engineering organization and which
coordinates domain development and evolution with client Application
Engineering projects.
- Domain objectives:
- An element of the Domain Plan Master Plan that defines the goals of
domain development.
- Domain Plan:
- Schedules, budgets, assignments, and progress evaluations for the
management of a Domain Engineering organization.
- Domain Specification:
- A specification of a standardized Application Engineering process and
product family for a domain. See Decision Model, Product (Family)
Requirements, Process Requirements, and Product (Family) Design.
- Domain Specification (Activity):
- The Domain Analysis activity that creates a Domain Specification.
- Domain Status:
- The element of a Domain Definition that specifies the current scope,
extent, and viability of a domain relative to its objectives.
- Domain Synopsis:
- The element of a Domain Definition that is an informal description of a
domain.
- Domain Validation (Activity):
- The Project Support activity that evaluates the quality and
effectiveness of Application Engineering Process Support from the perspective
of Application Engineering project needs.
- Domain Verification (Activity):
- The Domain Analysis activity that evaluates a Domain Implementation to
determine compliance with the corresponding Domain Definition and Domain
Specification.
- Entrance criteria:
- Conditions that must be met before an activity can be started.
- Exit criteria:
- Conditions that must be met before an activity can be considered
successfully completed.
- Family:
- A set of things that have enough in common that it pays to consider
their common characteristics before noting specific properties of instances.
- Feasibility:
- The degree to which an objective is amenable to solution with
predictable resources and risk.
- Feedback:
- Information communicated by the consumer of a work product to its
producer regarding issues in the correctness, quality, and viability of the
product.
- Generation (Activity):
- The Application Production activity that applies a Generation Procedure
to an Application Model, Adaptable Components, and Special Components to
produce software work products.
- Generation Design:
- The element of a Product Design that specifies a Generation Procedure
(i.e., the mapping from a Decision Model and Product Architecture to work
products for an application).
- Generation Design (Activity):
- The Domain Implementation activity that creates a Generation Design.
- Generation Implementation (Activity):
- The Domain Implementation activity that creates a Generation Procedure.
- Generation Procedure:
- The definition of a procedure for selecting, adapting, and composing
components to create a work product.
- Goal:
- A specific, time-related, measurable target.
- Implicit requirements:
- Requirements that indicate characteristics that are common to all
systems in a domain. (Comment: These are referred to as implicit because
they are implicit to an Application Model [i.e., there are no decisions in
the Decision Model that affect them]).
- Infrastructure:
- Those mechanisms or attributes of an Application Engineering Environment
that are not determined by the Domain Specification. See Process Support
Development (Activity).
- Instantiation:
- Creating a thing from a representation of an abstraction denoting a set
of such things.
- Iterative process:
- A process in which completion occurs only after repetition of producing
and using activities results in refined work products.
- Legacy Products:
- The element of a Domain Definition that is a collection of work products
(or portions thereof) that are potentially useful raw material for developing
other Domain Engineering work products. Legacy Products are derive from
existing systems in the domain.
- Life cycle:
- A sequence of distinct states of an entity beginning with its initial
conception and ending when it is no longer available for use.
- Metaprogram:
- A description of an abstract component that is sufficient, given a set
of resolved decisions, to instantiate a corresponding concrete component.
- Metaprogramming:
- A method for creating abstract components and extracting concrete
components from them. See Instantiation.
- Metaprogramming notation:
- A notation for defining and instantiating metaprograms.
- Method:
- Guidance and criteria that prescribe a systematic, repeatable technique
for performing an activity.
- Methodology:
- An integrated body of principles, practices, and methods that prescribe
the proper performance of a process.
- Model:
- A representation of a thing from which analysis provides approximate
answers to designated questions about the thing itself.
- Module:
- A software component that consists of design, code, documentation, and
test artifacts.
- Objective:
- The intended or desired result of a course of action.
- Plan:
- A designation of tasks and resource allocations for accomplishing a
specified objective.
- Process:
- A (partially) ordered set of steps, intended to accomplish specified
objective(s).
- Process engineering:
- The construction of a process appropriate to accomplish the objectives
of an organization or project.
- Process Requirements:
- The element of a Domain Specification that defines an Application
Engineering process and concrete forms (syntax) of an associated Application
Modeling Notation.
- Process Requirements (Activity):
- The Domain Analysis activity that creates Process Requirements.
- Process Support:
- Standards and procedures, in the form of documents and supporting
automation, that institute a standard Application Engineering process, as
specified by a Process Requirements. See Application Engineering Environment.
- Process Support Development (Activity):
- The Domain Implementation activity that creates Process Support.
- Product:
- The aggregation of all work products resulting from a process or
activity.
- Product Architecture:
- See Product (Family) Architecture.
- Product Architecture (Activity):
- The Domain Analysis activity that creates a Product Architecture.
- Product Design:
- See Product (Family) Design.
- Product Design (Activity):
- The Domain Analysis activity that creates a Product Design.
- Product Family:
- A family of products. See Family.
- Product (Family) Architecture:
- The element of a Product Design that is a specification of the
(adaptable) architecture of the products for a system (possibly as a set of
components).
- Product (Family) Design:
- The element of a Domain Specification that defines how an Application
Model which satisfies the Decision Model determines the structure and content
of an Application Product and Delivery Support. This includes the criteria by
which components are selected and adapted to create fragments which are then
composed into complete work products.
- Product (Family) engineering:
- The development and evolution, consistent with a Domain Definition and
Decision Model, of Product Requirements, Product Design, and Product
Implementation corresponding to a product family.
- Product (Family) Implementation:
- The implementation of a Product Design as sets of Adaptable Components
and Generation Procedures.
- Product (Family) Requirements:
- The element of a Domain Specification that defines the requirements of
systems in a domain relative to a Decision Model.
- Product Implementation:
- See Product (Family) Implementation.
- Product Implementation (Activity):
- The Domain Implementation activity that creates a Product
Implementation. See Component Implementation (Activity) and Generation
Implementation (Activity).
- Product line:
- A collection of (existing and potential) products that address a
designated business area.
- Product Requirements:
- See Product (Family) Requirements.
- Product Requirements (Activity):
- The Domain Analysis activity that creates a Product Requirements.
- Program:
- (1) An aggregation of software components that, when integrated with
hardware, operates as a unit.
(2) A directed, funded effort to acquire, develop, or maintain a product(s).
- Project:
- An undertaking requiring concerted effort, which is focused on
developing and/or maintaining a specific product. Typically, a project has
its own funding, cost accounting, and delivery schedule.
- Project Management (Activity):
- The Application Engineering activity that plans, monitors, and controls
Application Engineering process execution and provides feedback to Domain
Engineering on desired product family and Application Engineering process
modifications.
- Project Plan:
- Schedules, budgets, assignments, and status evaluations for the
management of an Application Engineering project.
- Project Support (Activity):
- The Domain Engineering activity that validates Application Engineering
Process Support, delivers it to application projects, and supports its use.
See Domain Validation (Activity) and Domain Delivery (Activity).
- Reuse Library:
- The portion of an Application Engineering Environment that provides
access to Adaptable Components.
- Risk:
- A potential for incurring undesirable results.
- Specialization:
- Constraining an abstraction to denote a subset.
- Specification:
- A complete, precise description of the verifiable properties required of
a work product.
- Specification (Activity):
- The Application Modeling activity that analyzes customer needs to
produce an application model. The Application Model expresses requirements
and engineering decisions that describe a system intended to satisfy those
needs.
- Step:
- Either an activity or an unelaborated action.
- Structural constraint:
- A constraint that limits the number of instances of a decision group in
a valid Application Model
- Subdomain:
- The denotation of a subfamily of systems for which a corresponding
domain denotes the larger family.
- Subfamily:
- A subset of the members of a family that have some set of common
characteristics not shared by any members of the family outside that subset.
See subdomain.
- Synthesis:
- A methodology for the construction of software systems as instances of a
family of systems that have similar descriptions. Its primary distinguishing
features are:
-
Formalization of domains as families of systems that share many common
features, but which also vary in well-defined ways
-
System building reduced to resolution of requirements and engineering
decisions that represent the variations characteristic of a domain
-
Reuse of software artifacts through mechanical adaptation of components to
satisfy requirements and engineering decisions
-
Model-based analyses of described systems to help understand the implications
of system-building decisions and evaluate alternatives
- System:
- A collection of hardware, software, and people that operate together to
accomplish a mission.
- Task:
- A work assignment (i.e., subject to management accountability) to
accomplish a specified objective.
- Test scenario:
- A test component, which includes test procedures and test data
artifacts.
- User:
- The person(s) or organization(s) that will use the system for its
intended purpose when it is deployed in its environment.
- Validation:
- The evaluation of work products to determine whether they satisfy
customer needs.
- Validation (Activity):
- The Application Modeling activity that produces analyses of the degree
to which alternative Application Models satisfy the functional requirements
of the customer.
- Variability:
- A characteristic of a domain that corresponds to features that
distinguish among members of the associated family of systems. See
Commonality.
- Verification:
- The evaluation of a work product to determine whether it meets its
specification.
- Viability:
- The degree to which benefits of a feasible undertaking dominate the
costs of its performance, taking into consideration risk-induced
uncertainties.
- Work product:
- Any configuration-managed artifact.
