COSMIC masterclass part 1 at IWSM2014

1. IWSM 2014, Rotterdam
COSMIC Masterclass
Alain Abran, ETS, Montreal, Canada
Jaroslaw Swierczek, 300D&C, Warsaw, Poland
Charles Symons, UK
Chris Woodward, CW Associates, UK
The Common Software Measurement International Consortium
© COSMIC 2014

2. Agenda
09:00 Version 4.0 of the COSMIC Method
09:45 The COSMIC approach fordealing with
Non-Functional Requirements (NFR)
10:20 (Break)
10:40 Automatic COSMIC sizing of requirements
held in UML
11:15 Project estimating with COSMIC
12:00 Close
2

3. Version 4.0 of the COSMIC method
• Aims of v4.0 and the documentation upgrades
• MUB 11 – the triggering event > functional user >
triggering Entry > functional process chain
• MUB 9 – definition of ‘layer’
• MUB’s 8 & 10 – COSMIC scope of applicability
• Many other improvements to Rules
3

4. Aims of the upgrade to v4.0
• Easier to understand: more diagrams, clearer
examples, etc
• Update for existing Methods Update Bulletins
N.B.
• No changes needed in basic principles
• Existing measurements should remain
valid
4

5. 5
COSMIC documentation has been
re-structured
Measurement Manual v3.0.1
Documentation Overview &
Glossary
Method Overview
Advanced & Related Topics
Measurement Manual v4.0
(incl. Glossary)
Introduction to COSMIC
Guideline on early and fast
approximate sizing
Guideline on convertibility

6. Guidelines are being updated and
more are in preparation
Nearing completion:
•Early and fast approximate size measurement
•Convertibility
Being updated:
•Business applications (nearly ready)
•Real-time, SOA, Data Warehouse, Agile (to do)
In development:
•Accounting for Non-Functional Requirements
•Software Project Estimating
6

7. Other developments
• The Foundation-level certification exam has been
updated to v4.0
• Translations of v4.0:
– Chinese (complete)
– French (final checking)
– Spanish (started)
– Others planned: Italian, Portuguese, Urdu
• Resulting mainly from the translations, we have an
‘Errata & Corrections list’.
• v4.0.1 of the MM to be published early in 2015.
7

8. 8
Version 4.0 of the COSMIC method
• Aims of v4.0 and the documentation upgrades
• MUB 11 – the triggering event > functional user >
triggering Entry > functional process chain
• MUB 9 – definition of ‘layer’
• MUB’s 8 & 10 – COSMIC scope of applicability
• Many other improvements to Rules

9. MUB 11: The model showing how a functional
process is triggered was not quite complete
Boundary Functional
9
Triggering
event
is sensed
by
Boundary
Triggering
Entry
Functional
user
Functional
process
V3.0 model
Triggering
Event
causes
that is moved
into a FP by the
FP’s Triggering
Entry
Process
to generate a
data group
Functional
user
V4.0 model
Many examples added to illustrate the possible cardinalities along the chain
Event – FU – DG –T_Entry – FP

10. 10
MUB 11: The definition of a Functional
Process has been revised
V3.0.1 definition
a) An elementary component of a set of
Functional User Requirements,
b) comprising a unique, cohesive and
independently executable set of data
movements.
c) It is triggered by a data movement (an
Entry) from a functional user that
informs the piece of software that the
functional user has identified a
triggering event.
d) It is complete when it has executed all
that is required to be done in
response to the triggering event
V4.0 definition
a) A set of data movements, representing
an elementary part of the Functional
User Requirements (FUR) for the
software being measured, that is unique
within these FUR and that can be
defined independently of any other
functional process in these FUR.
b) A functional process may have only one
triggering Entry. Each functional process
starts processing on receipt of a data
group moved by the triggering Entry data
movement of the functional process.
c) 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
The rules for a Functional Process have also been simplified
and the process for identifying them explained more clearly

11. The definition of a ‘Triggering Entry’ has been
11
revised
V3.0.1 description
The triggering Entry is normally a
positive, unambiguous message
that informs the software that the
functional user has identified a
triggering event. The triggering
Entry often also includes data
about an object of interest
associated with the event.
V4.0 definition
The Entry data movement
of a functional process
that moves a data group
generated by a functional
user that the functional
process needs to start
processing.

12. How to analyse the input to batch processes
was not well explained
12
Input data Questions
Entered ‘off-line’
Persistent data
created by another
application
Transmitted in by
another application
(one record at a time)
A physical file
of data for
input to a
batch process
• Are these data
Entries, or
persistent data
to be Read?
• What is the
triggering Entry
if no input data
is needed?

13. Rules for how to identify and analyse FP’s
processed in batch mode are much improved
• A requirement to process data in batch mode is a NFR for
the software being measured (i.e. ignore how the data
was entered and stored for batch-processing)
• Input data to be batch-processed consists of the Entries
for one or more functional processes.
• Analyse these Entries as if the data were entered on-line.
• A batch-processed ‘job’ may not need any input data e.g.
13
 a menu click to produce an ad hoc report,
 a ‘clock tick’ to produce month-end reports,
but always count a triggering Entry.

14. 14
Version 4.0 of the COSMIC method
• Aims of v4.0 and the documentation upgrades
• MUB 11 – the triggering event > functional user >
triggering Entry > functional process chain
• MUB 9 – definition of ‘layer’
• MUB’s 8 & 10 – COSMIC scope of applicability
• Many other improvements to Rules

15. 15
MUB 9: The definition of a ‘layer’ now
matches industry practice
Application Layer
Application ‘A’
UI Layer
BR Layer
DS Layer
User
Interface
Component
Business
Rules
Component
Data
Services
Component
c) Layers for SOA
components of
Business Rules
Application Layer
Orchestration Layer
Utility Layer
b) Application ‘A’
components in a
3-layer Architecture
a) View of an
application ‘A’ as a
whole

16. 16
Version 4.0 of the COSMIC method
• Aims of v4.0 and the documentation upgrades
• MUB 11 – the triggering event > functional user >
triggering Entry > functional process chain
• MUB 9 – definition of ‘layer’
• MUB’s 8 & 10 – COSMIC scope of applicability
• Many other improvements to Rules

17. MUB 8: The COSMIC method can be used to
measure a useful size of some ‘data
manipulation rich’ software
• Much software with complex algorithms also has
many data movements
• A standard COSMIC size of such software can be
useful locally for performance comparisons, etc., if:
– data manipulation is required similarly for all
software to be measured
– or data manipulation is concentrated; the effort for
developing it can be isolated and the effect on
size ignored
– or you can use the ‘local extension’ rules to size
data manipulation locally.
17

18. MUB 10: Many NFR’s evolve, as a project
progresses, into FUR which can be measured
Can be sized
18
Functional User
Requirements
Non-Functional
Requirements
Examples:
• Maintainability
• Interfaces
• Operations
• Reliability
• Usability
• etc
Functional User
Requirements
‘True’ NFR
e.g.
• Technology,
• Project
constraints
Project time-line
Should be
recorded;
may be
quantifiable
* (e.g.) Al-Sarayreh, K.T. and A. Abran, Specification and Measurement of System Configuration Non Functional
Requirements, 20th International Workshop on Software Measurement (IWSM 2010), Stuttgart, Germany, 2010

19. 19
Version 4.0 of the COSMIC method
• Aims of v4.0 and the documentation upgrades
• MUB 11 – the triggering event > functional user >
triggering Entry > functional process chain
• MUB 9 – definition of ‘layer’
• MUB’s 8 & 10 – COSMIC scope of applicability
• Many other improvements to Rules

20. When may a functional process have >1 Entry
moving data about the same OOI?
(Also for R, W and X)
V3.0.1 rules:
a) Unless the FUR specify otherwise, count only one
DM of any type, moving data about any one OOI in
the same functional process (OK)
b) Count >1 Entry if required in the FUR, or if the
Entries have different associated data manipulation
Example: when different functional users send
different data groups, each describing the
same OOI
(Same for R, W, X)
Problem! Rule b) conflicts with the rule that an Entry accounts
for all associated data manipulation. Same for R, W, X
20

21. ‘Data uniqueness’ rule b) has been
revised for v4.0 (and again for v4.0.1)
b) FUR may specify data groups to be entered into one
functional process (FP) from different functional users,
where each data group describes the same OOI. Count
one Entry for each of these different data groups.
The same equivalent rule applies for Exits of data to different
functional users from any one FP.
c) FUR may specify multiple data groups to be moved from
21
persistent storage into one functional process, each
describing the same OOI. Count one Read for each of
these different data groups.
The same equivalent rule applies for Writes in any one FP.

22. Other improvements
• The Measurement Strategy phase now refers to
‘Context Diagrams’ and to ‘Measurement Patterns’
22
• Clearer rules on measuring FP’s that share some
common functionality (measure each FP separately.)
• Distinguish the FP that starts the software to be
measured from the FP’s to be measured
Example: an application to be measured may be started by a user
command from a menu or by a clock-tick from the OS. Do not
measure these start-up FP’s
• Rules (previously text) for the data manipulation
associated with each type of data movement (E, X, R
and W)
• New rules for measuring error/confirmation messages

23. Closing remarks
Any time we find a problem with the COSMIC method,
e.g.
– some text is not clear
– two rules are not compatible
we resolve the problem within the existing Principles.
The method is rock-solid!
23
My thanks to all, especially to MPC Members, who
contribute to the continuous improvement of the method

24. 24
Thank you for your
attention
www.cosmicon.com
cr.symons@btinternet.com