 |
Terminology
|
| ||||
|
Terminology |
|||
|
||||
| Quick Links | ||
| Guided Tour Online Demo Technology Product Line Studio Software Product Lines Process Scalability Terminology Reference Material Search Contact |
||
Following is a convenient table of terminology used on this web site related to the subject of Software Product Lines.
Note that while the Software Product Line literature has some commonly used terminology, there is as yet not a broad concensus on terminology. Therefore, we are careful to define a consistent set of terminology which we use exclusively. Where applicable, our definitions make reference to alternative terminology sometimes used in other literature on Software Product Lines.
| Asset | An Asset is a file or other item of information (e.g. a database record) that is managed (i.e. version controlled, subject to review and approval) for use in a Product Line. |
| Binding Time | A Binding Time is the name given to a stage in a Staged Configuration process. Each Variation Point is associated with a specific Binding Time; this is the point in the process of Staged Configuration where the Variation Point must be bound. |
| Core Asset | A Core Asset is an Asset which is intended for use in multiple Products with the Product Line. |
| Customization of Documents | Customization of Documents is the ability to generate documents from Document Fragments for a specific Product Configuration or a specific Product Family. Customization of Documents requires a Transformation Engine which takes Document Fragments as inputs and generates a customized document as its output. |
| Customization of Requirements | Customization of Requirements is the ability to generate a product specification (i.e. a requirement document) based on a Product Configuration. This is similar to the Customization of Documents solution, except that it adds the ability to designate individual requirements for traceability purposes, as well as an assortment of queries and reports related to requirements traceability. |
| Customization of Software | Customization of Software is the ability build and configure a software product based on a Product Configuration. Most literature of Software Product Lines emphasizes Customization of Software and de-emphasizes Requirements and Documents. |
| Document Fragment | A portion of a document which is managed as an distinct Core Asset, and which is incorporated into a document aggregated by IDI's "Customization of Documents" solution under defined conditions on the Product Configuration. |
| Domain Specific Language | A Domain Specific Language (DSL) is a custom representation of all or part of a Product Configuration which is designed specifically for a particular Product Line. Configurations in certain types of product lines can be represented more compactly by DSLs than by general-purpose representations of variability. Most DSLs are declarative rather than procedural. Some DSLs are graphical rather than text-based. Any DSL, by definition, requires a domain specific Transformation Engine to interpret it. |
| Mass Customization | Mass Customization is the ability to customize a product or service at Mass Produced prices. More technically, "Mass customization refers to a customer co-design process of products and services which meet the needs of each individual customer with regard to certain product features . All operations are performed within a fixed solution space, characterized by stable but still flexible and responsive processes. As a result, the costs associated with customization allow for a price level that does not imply a switch in an upper market segment." |
| Process Scalability | Process Scalability is a measure of how well a development process for a product line scales when the number of products or number of variation points increases. Simplistic processes that work well for a single product may become very inefficient when applied to a product line with many products. The set of practices and patterns that collectively are called "Software Product Lines" are designed to scale well as the number of products increases. |
| Product | A Product is a single item of output in a Product Line which is produced and marketed by the organization. |
| Product Configuration | A Product Configuration is the features and settings selected for a particular Product. That is, it is the set of answers to all Variation Points for the Product in question. We use the term "Product Configuration" to refer to a fully specified configuration, and the term "Partial Product Configuration" to refer to a partially specified configuration. In other words, a "Partial Product Configuration" leaves some of the Variation Points unbound, while in a complete Product Configuration, every Variation Point is bound. NOTE: The literature on Software Product Lines sometimes refers to "Feature Modeling", particularly in the work of Czarnecki. In "Feature Modeling" the term "configuration" is equivalent to our "Product Configuration", while their term "specialized feature diagram" is equivalent to our "Partial Product Configuration". |
| Product Family | A Product Family is a subset of the Product Line which have certain attributes in common. NOTE: The literature on Software Product Lines sometimes refers to "Feature Modeling", particularly in the work of Czarnecki. In "Feature Modeling" terminology, the term "feature diagram" is equivalent to our "Product Family". We consider the "feature diagram" terminology to be a misnomer because, even in the "Feature Modeling" literature, the term "feature diagram" refers to a Product Family, not to its visual representation. |
| Product Line | A Product Line is the set of related products which are produced by a single organization. |
| Product Team | A Product Team is a team in the organization tasked with releasing a particular Product or Product Family. |
| Production System | A Production System is a tool or set of tools which apply Transformation Engines to Core Assets in order build Products. |
| Software Architecture | The Software Architecture of a Software Product Line consists of the concepts of Software Architecture related to a traditional single-product design, but also includes the Software Component Framework and the Software Component Model, which are related to commonality and variability with a Product Line. |
| Software Component Framework | A Software Component Framework is a set of Transformation Engines and a set of rules which Core Assets must satisfy so the Transformation Engines can properly transform the them into useful output. The Component Framework specifies how components interact with the Production System. |
| Software Component Model | A Software Component Model is a pre-defined set of software components which are needed for most or all Products in the Product Line. The Component Model specifies how components are interact with each other to perform functions which are meaningful in a particular Product Line. |
| Software Product Line | A Software Product Line is a general methodology for creating Products by transforming a set of reusable Core Assets based on a Product Configuration. Virtually any product line of software intensive systems can be called a Software Product Line under this general definition. Therefore some practitioners reserve the "Software Product Line" terminology for processes of a certain level of scalability on the Software Product Line Process Scalability Model. |
| Staged Configuration | The term "Staged Configuration" refers to the process of deriving a Product Configuration in stages rather than in a single step. Staged Configuration is related to the term "Binding Time". When a Product Configuration is derived in stages, each stage binds all Variation Points of a particular Binding Time. That is, each Binding Time is associated with a specific stage in the process of deriving a Product Configuration. |
| Transformation Engine | A Transformation Engine is a tool which programmatically transforms a particular type of Core Asset into a particular type of output, based on a Product Configuration. XSL is a technology often mentioned in connection with Transformation Engines. It is important to recognize XSL as a technology which can be used to build a Transformation Engine, but it is not a Transformation Engine in itself. |
| Validation Rule | A Validation Rule is a verifiable check which can be run on Assets of a particular Asset Type in order to reduce the likelihood of human error. An example could be the rule: no single Product may use two different versions of any given Asset. |
| Variability Management | Variability Management is the overall process of defining what is common and what is different across Products in a Product Line (i.e. allowable Product Configurations), as well as managing the set of actual Product Configurations. |
| Variant | A Variant is one of several closely related Core Assets or Products. |
| Variation Point | A Variation Point is a product option - i.e. a question which must be answered in order to fully specify a Product Configuration. The process of specifying a Product Configuration requires an answer to be given for each Variation Point. The Variation Point is said to be "bound" when its answer is specified. In product lines using Staged Configuration, each Variation Point is also assigned a Binding Time, which is the latest point in the process where the Variation Point must be bound. |
| © 2006 Integrated Dynamics, Inc. All Rights Reserved | Home - Privacy - Terms of Use - Site Map |