COSMIC MEASUREMENT STRATEGY PHASE学习笔记

COSMIC MEASUREMENT STRATEGY PHASE

 

1 确定度量目的

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

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

 

 

1．1          度量目的决定了要度量哪一种规格（The purpose of a measurement determines the particular size that will be measured）

1．2          度量目的范例

以下是典型的度量目的

l  To measure the size of the FUR as they evolve, as input to a process to estimate development effort

l  To measure the size of changes to the FUR after they have been initially agreed, in order to manage project ‘scope creep’

l  To measure the size of the FUR of the delivered software as input to the measurement of the developer’s performance

l  To measure the size of the FUR of the total software delivered, and also the size of the FUR of the software which was developed, in order to obtain a measure of functional re-use

l  To measure the size of the FUR of the existing software as input to the measurement of the performance of those responsible for maintaining and supporting the software

l  To measure the size of some changes to (the FUR of) an existing software system as a measure of the size of the work-output of an enhancement project team

l  To measure the size of functionality of the existing software provided to human functional users

这些目的帮助度量人员决定：

l  the scope to be measured and hence the artifacts which will be needed for the measurement

l  the functional users (as will be shown in section 2.3, the functional size changes depending on who or what is defined as the functional user)

l  the point in time in the project life-cycle when the measurement will take place

l  the required accuracy of the measurement, and hence whether the COSMIC measurement method should be used, or whether a locally-derived approximation version of the COSMIC method should be used (e.g. early in a project’s life-cycle, before the FUR are fully elaborated). Both of these latte two points will determine the level of granularity at which the FUR will be measured.

 

2               定义度量范围

度量范围定义

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.

FUR定义

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)

范围(Scope)定义

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

2.1 度量范围由目的决定

如果软件系统的构架是将软件分成若干层次，那么各个层次应该分别度量之。也就是说，每个层次都有自己的度量范围。同样的，如果软件系统的构架只有一层，该软件层次不同模块构成的，而每个模块都由不同技术开发的，那么就必须为每一个模块定义自己的度量范围。因为不同的技术会带来不同的开发效率，所以这种做法是必要的。

总之，这一步的目的是决定软件那些部分在度量范围之内，哪些在度量范围之外。

2.2 度量范围和分解层次实例

以下是通用的范围：

l  An enterprise portfolio

l  A contractually-agreed statement of requirements

l  项目团队发布产品 (i.e. including that obtained by exploiting existing software parameters, bought-in packages and re-usable code, any software used for data conversion and subsequently discarded, and utilities and testing software developed specifically for this project)

l  项目团队开发产品 (i.e. including any software developed by the team and used for data conversion but subsequently discarded, and any utilities and testing software developed specifically for this project, but excluding all functionality obtained by changing parameters and exploiting re-usable code or by bought-in packages)

l  All the software in a layer

l  A software package

l  An application

l  A major (‘peer’) component of an application

l  A re-usable object-class

l  All the changes required for a new release of a piece of existing software

上述的通用范围与相应的分解层次相对应。具体定义如下

分解层次

Any level of division of a piece of software showing its components, sub-components, etc NOTE: Not to be confused with ‘level of granularity’

2.3 层

层定义

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

2.4 点组件(peer component)

点组件定义

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.

点组件的一个典型例子是软件分成了三个主要组件:UI组件,事务规则组件，数据服务组件。

 

3辨认功能用户(FU)

3.1 软件功能数根据功能用户而变化
3.2 功能用户

功能用户：任何与被度量软件发生关系的实体。（ISO/IEC 14143/1:2007）

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.

4辨认系统颗粒级别

4．1 设立标准系统颗粒级别的必要性

系统颗粒级别定义：

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

4．2 关于系统颗粒级别的补充说明

提高系统颗粒级别相当于’zooming in’操作而不改变系统边界。这个过程中不要对于以下概念有误解：

l  Zooming-in on an artefact describing some software in order to reveal different sub-sets of the functionality delivered to different users, hence probably limiting the functionality to be measured

l  Zooming-in on an artefact describing some software, or on the software itself, and at the same time decomposing it in order to reveal the structure of its components, sub-components, etc (i.e. revealing different ‘levels of decomposition’ – see section 2.2.2 above). Zooming-in to lower levels of decomposition of the software may result (from the measurement purpose) in sub-dividing the overall measurement scope

l  Evolving the description of some software as it progresses through its development cycle, e.g. from requirements to logical design, to physical design, etc. Whatever the stage in the development of some software, we are only interested in the FUR for measurement purposes

4．3 标准系统颗粒级别

功能过程系统颗粒级别定义：

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.)

4.4 一个关于在不同系统颗粒级别下的功能性的例子