Measurement Strategy Examples
a) Business Examples: How the purpose affects the other strategy parameters
Suppose the software to be developed and measured is the distributed 3-layer business application system shown below. The context is a contract with a supplier that stipulates that for payment purposes, software sizes will be measured at the level of whole applications, ignoring any component structure.
Three views on the layers of an application
Case 1.
Purpose: to measure the size of a delivered application for contract payment
Scope: The FUR of the one application
Functional users: Human users and any other interfacing applications
Level of decomposition: None
Layer: Application layer, view a)
Case 2.
Purpose: to measure the size of each major component of the distributed application so that the supplier can estimate the project effort, because each component will be developed using a different technology.
Scope: Each component is measured separately (i.e. there are three measurement scopes).
Functional Users: Refer to the three layers as in view b).
The User Interface component has the Human users and the Business Rules component as its functional users
The Business Rules component has the User Interface and the Data Services components as its functional users
The Data Services component has the Business Rules component and any other interfacing applications as its functional users.
Level of Decomposition: First-level decomposition of an application (‘level 1’)
Layers: See the three layers as in view b)
b) Real-time Examples: How the purpose affects the other strategy parameters
The functionality of the software embedded in a hardware device used by humans, for example a combined computer printer/copier can be measured from the viewpoints of two types of functional users. (In both cases assume that we are not interested in any component structure of the software nor any firmware that the embedded software may use.)
Case 1.
Purpose: to measure the size of functionality available to the human user, so as to compare against the offering of competitive products.
Scope: Functionality available to human operator users (i.e. excluding functionality needed by operators over which they have no control or cannot ‘see’, such as some functions needed by the printer to communicate with a computer)
Functional Users: Human operator users
Case 2.
Purpose: to measure the functionality that the embedded software developer must provide for the device to function
Scope: All the functionality of the embedded software
Functional users: All hardware devices with which the software must interact (e.g. keyboard, control buttons, screens, print drive mechanism, paper transport mechanism, etc., any computer that the printer must communicate with and the printer driver software).
Mapping Phase Examples
a) Examples of events and functional processes
Business example. Given a Personnel System a triggering event could be ‘a new person is employed’. The corresponding functional process would be ‘Create employee’.
Real-time example. For a Domestic Alarm System a triggering will be ‘Door opens whilst alarm system is activated’, which entails the functional process ‘Possible intruder detected’.
See the worked examples below.
b) Worked Business Example: Measuring a Personnel System
Outline statement of requirements.
A system is required to enable personnel staff to hold and maintain data about employees, including their salary and the history of their salary progression over time. [The statement also describes the data (attributes) to be recorded about each employee and their validation criteria, but most of this detail need not concern the measurer in this simple example.] A report is required each month listing all employees by name and their current salary, the total number of employees, and the total current salary cost.
Measurement strategy parameters
Measurement purpose: An accurate functional size measurement of the Personnel System for project effort estimating.
Measurement scope: The whole system as specified in the statement of requirements.
Functional users: Personnel staff.
Layer: Application layer.
Level of decomposition: no decomposition.
Mapping phase
Some assumptions:
- The data structure of the Business Example in the Figure below applies.
- Each employee will be allocated a unique ID by a member of personnel. The key of an ‘employee salary history’ record is [employee ID, salary start date].
- The word ‘maintain’ in the outline statement of requirements normally implies that there must be Create, Read, Update and Delete functional processes (the ‘CRUD’ acronym) for each object of interest. ‘Update’ will enable a change of any attribute except the key attribute(s) of any data group.
- There are two objects of interest (‘employee’ and ‘employee salary history’) about which data must be held. The four ‘CRUD’ functional processes will be identified to maintain the employee base data.
- Also assume that an employee salary history record must be created when an employee first starts work. Subsequently, an employee’s salary may be updated at any time, i.e. not just when the employee base data must be updated. So there is no need for separate ‘create’, or ‘delete’ functional processes for the employee salary history. However, there is a need for an ‘update employee salary’ functional process and for a separate ‘read’ functional process for enquiries on employee salary data. Adding in the process to produce the monthly report means the requirements can be satisfied by 7 functional processes. (see below the analysis of four of these.)
- In practical situations there may also be FUR for a ‘read’ functional process to display the employee’s base data separately from the enquiry to display the employee’s salary history. Also, when an employee leaves, the ‘delete’ functional process may be required to archive the employee base and salary history data, rather than actually delete it. Ignore these possible requirements for simplicity.
- Note also as a general rule when measuring on-line business applications, that ‘menus’ that only assist navigation and the selection of functional processes, and ‘blank’ data entry screens should be ignored. It is the movement of data by Entries, Exits, Reads and Writes that must be identified for measurement purposes.
Data Structure (only relevant part shown)
- Analysis of functional process ‘Create employee’.
The requirementis to enter data for a new employee.
(The examples show the data movements and the data group that each of them moves).
Functional process ‘Create employee’. Triggering event: a new person is employed
Triggering Entry : Employee base data
Entry : Initial salary and its start date
Read : Employee base data (to check that no employee already exists with the entered ID)
Write : Employee base data
Write : Employee salary history (a new record is created when the salary is first entered)
Exit : Error/confirmation messages (There must be error messages for various validation failures and also some form of confirmation on successful data entry. Include one Exit to account for all such messages.)
- Analysis of ‘Read and Update employee data’ processes, including possible salary update
Assume a user will first wish to retrieve and display the employee’s base data, before entering a change to one or more attributes, including maybe a new salary. This procedure will require two functional processes. The first is triggered by the event of the user deciding to display the existing data; it is the ‘read employee base data’ functional process. The second is triggered by the event that one or more attribute(s) of the employee have changed in the real world; it is the ‘update employee base data’ functional process. The two functional processes are:
Functional process ‘Read employee data’. Triggering event: Decision to display existing data
Triggering Entry : Employee ID
Read : Employee base data
Read : Employee salary history
Exit : Employee base data
Exit : Employee salary history
Exit : Error/confirmation messages (in case a non-existent ID was entered)
Functional process ‘Update employee data’. Triggering event: Employee data has changed in some way
Triggering Entry : Updated employee base data (for the update of one or more attribute(s))
Entry : Updated salary and its start date
Write : Employee base data (the updated record)
Write : Employee salary history (a new record is created if the salary has been updated)
Exit : Error/confirmation messages (for entry of invalid data or the possible failure of the update)
- Analysis of the process to produce the monthly report for the payroll department
Functional process ‘End-of-month employee’ report. Triggering event: The end of the month
Triggering Entry : End of month time signal (every functional process must have a triggering Entry, even though this one conveys no variable data)
Read : Employee base data (to get employee ID’s and names)
Read : Employee salary history (to obtain the current salary)
Exit : Employee current salary (one line for each employee with their ID, name and salary
Exit : End-of-month employee totals (of number of employees and of their total salary)
Notes: the final Exit moves a data group describing the object of interest ‘All employees’. No data is stored about this object of interest, but the object of interest is a group of real people, i.e. a real ‘thing’ in the world of the functional user. Computing the totals is data manipulation.
An error message for this functional process wasn’t counted as there does not seem to be any reason for the application to have to generate such a message. (The operating system might generate an error message if the data cannot be found, but this is not part of the application.)
c) Worked Real-time Example: A Domestic Alarm System
Outline statement of requirements
Deduce the functionality available to normal house occupants and allocated to software from knowing how to use the system and by examining it physically. Ignore the functionality provided for the alarm maintenance engineer, as well as the functions to set up the system when it is first installed.
The main purpose of the alarm system is, when it is activated, to start one or two sirens if a sensor detects a movement inside the house or if the front door is opened.
The software supports the alarm system’s human interface via a keypad and red/green LED’s. The software also accepts data from a device that can sense whether the main front door of the house is open or not, and from several internal movement detectors. (The alarm system can handle any number up to 10 movement detectors. The number does not matter for this analysis as they are all identical and equivalent.) The alarm system also controls an internal and an external siren.
The alarm system is always powered ‘on’, but is not ‘active’, i.e. the movement detectors and the front door sensor are not working, unless the system is activated by the occupant. When the system is activated, either the software waits in a state where it can receive signals from these sensors, or the software polls the sensors to obtain their state. We do not know which process is used and it does not matter for the functional size measurement.
To activate and de-activate the alarm system, the house occupant must enter the correct PIN (Personal Identification Number) within a pre-set time. The PIN is stored by the software and can be changed, so there must be some persistent storage. When the first digit of a PIN is entered, the internal siren is started; this siren is stopped on entry of all digits of the correct PIN. If the wrong PIN is entered three times or if the correct PIN is not entered within the pre-set time, the external siren is also started.
There is a battery to provide continuity if the electricity power supply fails, so there must be a power voltage detector.
The green LED is illuminated when power is switched on. If a siren is started or if the power fails, the green LED is switched off and the red LED is illuminated.
As certain functions must be completed within pre-set times, there must be a clock mechanism. For example, if the alarm system is activated before leaving the house, the occupants must leave and close the front door within a pre-set number of seconds; if not, the sirens are started. The external siren must not continue for more than the legal limit of 20 minutes.
It is not known how the clock is implemented but assume a software implementation for simplicity, which starts whenever needed. The functionality to keep track of elapsed times is then a form of data manipulation, which can be ignored.
Measurement strategy parameters
Purpose of the measurement: To measure the functional processes of the embedded application software available to the house occupant for normal operation.
Measurement scope: The alarm system embedded application software functions available to the house occupant for normal operation. Ignore an operating system.
Functional users: A context diagram shows the hardware functional users and how they interact with the software. Note that the movement detectors are all functionally identical, so do not need to be distinguished. The human user of the alarm system, referred to as ‘the occupant’ is not a functional user; he/she interacts with the application only via the keypad and the audible and visual signals.
Layer: Application.
Level of decomposition: no decomposition.
Alarm System Context Diagram
The Functional processes: After initial set-up, the alarm system application provides the occupant with nine functional processes. These can be identified by considering the events that the software must respond to.
- The occupant wishes to change the existing PIN.
- The occupant wishes to leave the house and activate the alarm system.
- The front door sensor detects that the door has been opened whilst the alarm system is activated.
- The occupant wishes to activate the alarm system whilst he/she is in the house, e.g. when retiring at night, out of range of the movement detectors.
- The occupant wishes to deactivate the alarm system when inside the house, e.g. when getting up in the morning before moving within range of the movement detectors.
- A movement detector signals a movement whilst the alarm system is activated (which starts the internal siren)
- The occupant wishes to cancel the siren(s) and to deactivate the alarm system by entering the correct PIN following events 3) or 6).
- The power voltage detector signals failure of the mains electrical supply.
- The power voltage detector signals restoration of the mains electrical power supply.
Analysis of an example functional process.
Analysis of event 3) on the list above (the front door is opened whilst the alarm system is activated). When the front door sensor detects this event, the internal siren starts; the correct PIN code must then be entered within a pre-set time to de-activate the system and to stop the internal siren. If the PIN code isn’t entered before the pre-set time, or the wrong code is entered more than three times, the external siren also starts. The functional process has the following data movements.
Functional process: Possible intruder detected. Triggering event: Door opens whilst alarm system is activated.
Triggering Entry : ‘Door open’ message from the front door sensor
Read : Get PIN from persistent storage
Exit* : Message to switch green LED from ‘on’ to ‘off’
Exit* : Message to switch red LED from ‘off’ to ‘on’
Exit : Message to start the internal siren
Entry : PIN code entered (If the wrong code is entered, the user may enter the PIN two more times but the process is always the same so it is only measured once.)
– ** : Message to switch red LED from ‘on’ to ‘off’ (on successful entry of PIN)
– ** : Message to switch green LED from ‘off’ to ‘on’ (on successful entry of PIN)
Exit : Message to stop internal siren (on successful entry of PIN)
Exit : Message to start external siren (after three unsuccessful PIN entries, or if the PIN is not entered in time)
Exit : Message to stop the external siren (after 20 minutes, a legal requirement)
NOTES: (*) The green and red LEDs are subject to different functional user requirements, therefore identify two functional user types. (**) These are repeat occurrences of the Exits to the LEDs earlier in the process, but with different data values (‘on’ instead of ‘off’, and vice versa).
d) Some general lessons from these examples
- Implementation details are generally irrelevant to the Mapping Process. For example the functional processes of the personnel system could be implemented in many ways, all leading to the same data movements in the COSMIC model. Similarly, it is not necessary to know how the ‘door open’ message triggers the process of the Domestic Alarm system. (Either the software, when activated, could poll the front door sensor and the movement detectors to ascertain their status, or these sensors could send their status to the software.)
- It helps understanding to write out the data movements of a functional process in roughly the sequence they would be executed. But the actual sequence will be more complicated in practice. For example the validation of the data entered in the personnel system could be interspersed with the issue of error message occurrences.
- The examples illustrate the part of the definition of a functional process that states that ‘The set of all data movements of a functional process is the set that is needed to meet its FUR for all the possible responses to its triggering Entry’. In the personnel system process that updates an employee data, a new salary history record is created only if the employee’s salary is changed. In the alarm system functional processes, messages sent to the LED’s and/or to the sirens will depend in each case on whether the occupant entered the correct PIN or not. The measurer’s only task is to identify all the data movements that are needed by a functional process to meet the FUR for all of its possible responses to all the data it may receive in its Entries and Reads. The measurer does not have to worry about the sequence of the data movements, nor whether they are needed or not in any particular occurrence of the functional process which will depend on the data values entered.
- The alarm system case is an example where the object of interest of each data group entering or exiting the software is also the functional user that sent the group or that receives it (i.e. the functional user is sending or receiving data about itself). In these cases, having identified the functional users in the Measurement Strategy phase, the objects of interest have been identified as well.