ISO/IEC 24744:2014 ソフトウェアエンジニアリング—開発方法論のメタモデル | ページ 5

3.1

information-based domain

realm of activity for which information is the most valuable asset

Note 1 to entry: This means that information creation, manipulation and dissemination are the most important activities within information-based domains. Typical information-based domains are software and systems engineering, business process reengineering and knowledge management.

3.2

methodology

method

specification of the process to follow together with the work products to be used and generated, plus the consideration of the people and tools involved, during an IBD development effort

Note 1 to entry: A methodology specifies the process to be executed, usually as a set of related activities, tasks and/or techniques, together with what work products must be manipulated (created, used or changed) at each moment and by whom, possibly including models, documents and other inputs and outputs. In turn, specifying the models that must be dealt with implies defining the basic building blocks that should be used to construct these models.

Note 2 to entry: The term “methodology” is used throughout this Standard, reserving the term “method” for conventional phrases such as “method engineer” or “method fragment”.

3.3

metamodel

specification of the concepts, relationships and rules that are used to define a methodology

3.4

endeavour

IBD development effort aimed at the delivery of some product or service through the application of a methodology

Note 1 to entry: Projects, programmes and infrastructural duties are examples of endeavours.

3.5

methodology element

simple component of a methodology

Note 1 to entry: Usually, methodology elements include the specification of what tasks, activities, techniques, models, documents, languages and/or notations can or must be used when applying the methodology. Methodology elements are related to each other, comprising a network of abstract concepts. Typical methodology elements are Capture Requirements, Write Code for Methods (kinds of tasks), Requirements Engineering, High-Level Modelling (kinds of activities), Pseudo-code, Dependency Graphs (notations), Class, Attribute (kinds of model building blocks), Class Model, Class Diagram, Requirements Specification (kind of work products), etc.

3.6

endeavour element

simple component of an endeavour

Note 1 to entry: During the execution of an endeavour, developers create a number of endeavour elements, such as tasks, models, classes, documents, etc. Some examples of endeavour elements are Customer, Invoice (classes), Name, Age (attributes), High-Level Class Model number 17 (a model), System Requirements Description (a document), Coding Cycle number 2, Coding Cycle number 3 (tasks), etc.

3.7

generation

act of defining and describing a methodology from a particular metamodel

Note 1 to entry: Generating a methodology includes explaining the structural position and semantics of each methodology element using the selected metamodel. Thus, what methodology elements are possible, and how they relate to each other, are constrained by such a metamodel. Usually, method engineers perform generation, yielding a complete and usable methodology.

3.8

enactment

act of applying a methodology for some particular purpose, typically an endeavour

Note 1 to entry: Enacting a methodology includes using the existing generated methodology to create endeavour elements and, eventually, obtain the targeted IBD system. Thus, what kinds of endeavour elements can be created, and how they relate to each other, is governed by the methodology being used. Usually, technical managers, together with other developers, perform enactment.

3.9

method engineer

person who designs, builds, extends and maintains methodologies

Note 1 to entry: Method engineers create methodologies from metamodels via generation.

3.10

developer

person who applies a methodology for some specific job, usually an endeavour

Note 1 to entry: Developers apply methodologies via enactment.

3.11

powertype

type, the instances of which are subtypes of another type called the “partitioned type”

Note 1 to entry: This definition must be interpreted in the context of the object-oriented paradigm. For example, the class Tree­Species is a powertype of the class Tree, since each instance of Tree­Species is also a subclass of Tree.

3.12

clabject

dual entity that is a class and an object at the same time

Note 1 to entry: This definition must be interpreted in the context of the object-oriented paradigm. Because of their dual nature, clabjects exhibit a class facet and an object facet, and can work as either at any time. Instances of powertypes are usually viewed as clabjects, since they are objects (because they are instances of a type, the powertype) and also classes (subtypes of the partitioned type).