COSMIC MEASUREMENT STRATEGY PHASE学习笔记

A statement that defines why a measurement is required, and what the result will be used for.

陈述为什么要度量，以及度量的结果用于什么地方。

The set of Functional User Requirements to be included in a specific functional size measurement exercise.

NOTE: A distinction should be made between the ‘overall scope’, i.e. all the software that should be measured according to the purpose, and the ‘scope’ of any individual piece of software within the overall scope, whose size should be measured separately. In this Measurement Manual, the term ‘scope’ (or the expression ‘measurement scope’) will relate to an individual piece of software whose size must be measured separately.

A sub-set of the User Requirements. Requirements that describe what the software shall do, in terms of tasks and services.

NOTE: Functional User Requirements include but are not limited to:

l  data transfer (for example Input customer data; Send control signal)

l  data transformation (for example Calculate bank interest; Derive average temperature)

l  data storage (for example Store customer order; Record ambient temperature over time)

l  data retrieval (for example List current employees; Retrieve latest aircraft position)

Examples of User Requirements that are not Functional User Requirements include but are not limited to:

l  quality constraints (for example usability, reliability, efficiency and portability)

l  organizational constraints (for example locations for operation, target hardware and compliance to standards)

l  environmental constraints (for example interoperability, security, privacy and safety)

l  implementation constraints (for example development language, delivery schedule)

a) The scope of a Functional Size Measurement (FSM) shall be derived from the purpose of the measurement.

b) The scope of any one measurement shall not extend over more than one layer of the software to be measured

Any level of division of a piece of software showing its components, sub-components, etc

NOTE: Not to be confused with ‘level of granularity’

A layer is a partition resulting from the functional division of a software architecture

l  which together with hardware forms a whole computer system where:

l  layers are organized in a hierarchy

l  there is only one layer at each level in the hierarchy

l  there is a ‘superior/subordinate’ hierarchical dependency between the functional services provided by software in any two layers in the software architecture that exchange data directly

l  the software in any two layers in the software architecture that exchange data interpret only part of that data identically

A peer component is a partition resulting from the functional division of the FUR of a piece of software within one layer into a mutually co-operating set such that each partition fulfills a specific portion of the FUR of that piece of software.

NOTE: The term ‘peer piece of software’ is used where any independent (and peer)

piece of software is meant.

A (type of) user that is a sender and/or an intended recipient of data in the Functional User Requirements of a piece of software.

a) The functional users of a piece of software to be measured shall be derived from the purpose of the measurement

b) When the purpose of a measurement of a piece of software is related to the effort to develop or modify the piece of software, then the functional users should be those for whom the new or modified functionality must be provided.

The boundary is defined as a conceptual interface between the software being measured and its functional users.

NOTE: The boundary of a piece of software is the conceptual frontier between this piece and the environment in which it operates, as it is perceived externally from the perspective of its functional users. The boundary allows the measurer to distinguish, without ambiguity, what is included inside the measured software from what is part of the measured software’s operating environment.

a) Identify the functional user(s) that interact with the software being measured. The boundary lies between the functional users and this software.

b) By definition, there is a boundary between each identified pair of layers where the software in one layer is the functional user of software in another, and the latter is to be measured. Similarly, there is a boundary between any two peer components in the same layer; in this case each component can be a functional user of its peer.

Any level of expansion of the description of a single piece of software (e.g. a statement of its requirements, or a description of the structure of the piece of software) such that at each increased level of expansion, the description of the functionality of the piece of software is at an increased and uniform level of detail.

NOTE: Measurers should be aware that when requirements are evolving early in the life of a software project, at any moment different parts of the required software functionality will typically have been documented at different levels of granularity

A level of granularity of the description of a piece of software at which the functional users

• are individual humans or engineered devices or pieces of software (and not any groups of these) AND

• detect single occurrences of events that the piece of software must respond to (and not any level at which groups of events are defined)

NOTE 1: In practice, software documentation containing functional user requirements often describes functionality at varying levels of granularity, especially when the documentation is still evolving.

NOTE 2: ‘Groups of these' (functional users) might be, for example, a ‘department’ whose members handle many types of functional processes; or a ‘control panel’ that has many types of instruments; or ‘central systems’.

NOTE 3: ‘Groups of events’ might, for example, be indicated in a statement of FUR at a high level of granularity by an input stream to an accounting software system labeled ‘sales transactions’; or by an input stream to an avionics software system labeled ‘pilot commands’

a) 功能度量应该在功能过程系统颗粒级别下进行度量。(Functional size measurement should be made at the functional process level of granularity)

b) Where a functional size measurement is needed of some FUR that have not yet evolved to the level where all the functional processes have been identified and all the details of their data movements have been defined, measurements should be made of the functionality that has been defined, and then scaled to the level of granularity of functional processes. (See the ‘Advanced and Related Topics’ document for methods of ‘approximate sizing, i.e. of estimating a functional size early in the process of establishing FUR.)