A technique for creating and maintaining measurement sets, measurement types within sets, pick lists for measurement types and instantiating these into measurement instances in DoDAF and other definitions without metamodel changes.
Requirements and features include:
•Measurement instances are 1st class definitions that are used on diagrams, matrices, and reports.
•Measurement instances appear in grid in definitions.
•Measurement sets group measurement types, for example, exchange properties.
•Measurement types specify unit of measure, ranking and list of values, for example, classification.
•Measurement instances are derived from measurement types.
•Measurement instances select a value from the measurement type value list or the user can enter a value. For example, S=Secret with ranking of 4.
•Measurement sets, measurement types and measurement values can be added, deleted and changed without metamodel changes, that is no USRPROPS changes.
•Measurement instance included in all DoDAF 2 definitions as a LISTOF ASGRID, except the current measure (DM2) and subtypes.
•Old DoDAF 2 measures properties are deprecated. They can be shown if required.
•Default sets provided based on source DoDAF material.
•Active by default for DoDAF 2, can be turned on by picking the measurement sets property set otherwise.
Relationships of a measurement instance
Measurement set is the name of each collection of properties or attributes.
•Each measurement set definition contains a list of the attribute or property names in the set.
•Examples measurementsSets from UPDM are security attributes and exchange properties.
•You can add, delete modify measurement sets and their contents by accessing the measurement set definition type.
•To create a new measurement set, create a new definition and specify measurement set as the type using the measurement set name.
Considerations for measurement type and measurement value
•Measurement types definition contain the Unit of Measure (UOM) for the property or attribute.
•The UOM is inherited by the measurement instance as read-only.
•Each measurement type also contains a list of measurement values which can be populated with a pre-set list of values for the property or attribute. Use is optional.
•Each measurement value in the list has a rank property for comparison purposes in reports, heat-maps, and more. Use is optional.
•Measurement types and the measurement sets they participate in and their measurement values can be added, deleted and modified.
•To create a new measurement type, open its containing measurement set and add the measurement type to the measurements in set grid.
•To add a set of values for the measurement type and rank, open its containing measurement type and add the measurement value and rank to the measurement values grid.
Measurement instance
•Each measurement instance is keyed by name.
•Each measurement instance is an instance of measurement type and uses the unit of measure from measurement type.
•A measurement set must be selected from Choices. After selection click Apply.
•The selected measurement set controls the available measurement types. Select a measurement type and click Apply.
•The selected measurement type controls the available measurement values, however the user can also enter a measurement value directly in the grid.
Example of measurement instance
Reusing resource in resource flows
Measurement Instances are no longer keyed by GUID. This has the advantage of allowing their creation in a top-down manner. This change makes the use of Resource definitions and their subtypes (Data, Information, Materiel, and so on) easier to populate with Measurement Instances.
Resource definitions, containing Measurement Instances, can be used and reused by the Resource Flows Activity Resource Overlap, System Data Flow and other definitions that contain a reference to Resources. This approach allows the creation of Resource Flows consisting of DoDAF2 Resources and Resource subtypes and reuse of the Resource as needed. The figure below shows an OV-05b BPMN Operational Activity Model diagram containing ActivityResourceOverlaps. The Temperature ActivityResourceOverlap is open showing its relationship with the Data Resource “Temperature for Friday Next Week” and the Data Resource relationship to three Measurement Instances. One of the Measurement Instances is open. These relationships are used in the OV-03 and SV-06 reports.
Auto-generation
System Architect auto-generation of Operational Exchanges, System Exchanges, Need Lines and System Resource Flows is used to generate the mid and high-level Resource Flows needed to generate OV-03 and SV-06 reports as well as OV-02, OV-12c, SV-01 and SV-12c diagrams. The generated names for the Resource Flows and Roles should be changed by the user in order to show meaningful names in the generated OV-03 and SV-06 reports. Note that the generated Need Lines appear between the Performers on the example OV-05b BPMN Operational Activity Model diagram above and in the OV-03 report below.
Reporting
New OV-03 and SV-06 reports are included in this release. The reports are based on the use of Resources (and subtypes) containing Measurement Instances and referred to by Activity Resource Overlaps and System Data Flows. The “Report Value” property was added to the Measurement Instance definition to capture the measurement value regardless of the Measurement Type making report creation much simpler. The new OV-03 and SV-06 reports make use of the Report Value property. The OV-03 report below shows the use of Resources as reusable Resource Flows. The SV-06 uses the same structure and makes use of Resources.
