|2 Introduction to the Methods Allocation|
Various tools support a method often in different, customized versions. Since the Methods Allocation is not to define how certain tools are to be applied, tool-independent definitions must be set up. This implies that the Methods Allocation is limited to the base concept of the methods and does not define rules about the notation (symbols) within the diagrams and the precise syntax of text-related specifications, etc.
Notations are defined within the scope of the operationalization.
The Methods Allocation does not set up rules for activities for which the V-Model intends a flexible process. For example, this is true for the integration activities, SD7 - SW Integration and SD8 - System Integration, where the allocation of methods is "missing" in order to avoid an undesirable and unnecessary limitation of the implemented flexibility.
The following sections explain the basing terminology of the Methods Allocation and the structure and description pattern used for the definition of methods.
Software engineering methods are of different complexity and potential. Therefore, the differentiation into complex methods (also: combined methods; method groups) and in elementary methods (also: basic methods) is reasonable and will be specified in the following.
Complex methods usually cover several aspects of the system (e. g. the functional aspect, the data aspect, etc.; see also Figure 1.1) and several activities of the development (e. g. analysis, preliminary design, etc.).
As a whole, complex methods are not part of the Methods Standard. They are described in Annex 2.
In this connection, it is irrelevant whether the basic method is comprised of several steps and possibly generates several (sub-) results (example: DFM - Data Flow Modeling) or the basic method exactly generates one result (example: Decision Table Technique).
Basic methods are allocated to individual V-Model activities and (sub-) products in the Methods Standard (see Figure 2.1).
When applying a complex method it must be represented within the scope of the operationalization that the methodical components of the complex method meet the requirements of the basic methods described in the Methods Allocation. To do so, the three steps described in chapter 1.3 Application of the Methods Allocation have to be carried out.
Examples for categories of methods are: design verification, estimation models, reliability models.
To specify a category of methods in the Methods Allocation means that the application of one method is required from this category.
The characterization of the method interfaces is part of the Methods Allocation. Annex 1 to the Methods Allocation includes a detailed description of the individual interfaces.
The allocation tables have the following structure for each main or subactivity of the V-Model which are no further hierarchically partitioned (see Figure 2.2):
For the chapters of a product that is generated by the corresponding (sub-) activity the basic method which has to be applied during its generation is referred to.
If the table does not include an entry for a V-Model (sub-) activity or for a V-Model product or chapter, no further regulation is required by the Methods Allocation beyond the V-Model.
For each basic method a unique abbreviation exists which is used for the identification in the table entries. Chapter 2.3 Method Overview contains an overview of all these abbreviations.
The text of the footnote informs about the manner of limitation.
If several basic methods are listed for one (sub-) chapter it will be explained if these are alternatives or if the methods are required to be complementary:
If the entry into the left column of the table contains a Space " ", this refers to the fact that the methodological standardization does not refer to a certain product, but to the realization of the entire activity.
|ACC||Analysis of Covert Channels||4.2|
|BAR||Bar Plan (Chart)||4.3|
|BBTD||Black Box Test Case Design||4.5|
|CRC||Class Responsibility Collaboration||4.6|
|DFM||Data Flow Modeling||4.7|
|DIAL||Dialog Design Modeling||4.8|
|DNAV||Data Navigation Modeling||4.9|
|ELH||Entity Life History||4.11|
|DTAB||Decision Table Technique||4.13|
|EVT||Earned Value Method||4.14|
|FMEA||Failure Mode Effect Analysis||4.17|
|FNET||Function Net Modeling||4.18|
|CFM||Control Flow Modeling||4.21|
|LOGM||Logical DB Modeling||4.23|
|NPT||Network Planning Technique||4.26|
|ODT||Object Design Technique||4.28|
|PIM||Process Interaction Modeling||4.33|
|SBM||System Behavior Models||4.40|
|UCM||Use Case Modeling||4.43|
|WBTD||White Box Test Case Design||4.44|
|STM||State Transition Modeling||4.45|
|STMO||State Modeling in the OO Field||4.46|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|