iwsm2014 cosmic masterclass part 1 - what's new in version 4.0 (charles symons)
TRANSCRIPT
IWSM 2014, Rotterdam
COSMIC MasterclassAlain Abran, ETS, Montreal, Canada
Jaroslaw Swierczek, 300D&C, Warsaw, PolandCharles Symons, UK
Chris Woodward, CW Associates, UK
The Common Software Measurement International Consortium
© COSMIC 2014
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 Close2
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
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
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
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
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
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
MUB 11: The model showing how a functional process is triggered was not quite complete
9
Triggeringevent
is sensed by
TriggeringEntry
Boundary
Functionaluser
Functionalprocess
V3.0 model
TriggeringEvent
causesthat is moved
into a FP by the FP’s Triggering
Entry
Boundary FunctionalProcess
to generate a data group
Functionaluser
V4.0 model
Many examples added to illustrate the possible cardinalities along the chain
Event – FU – DG –T_Entry – FP
10
MUB 11: The definition of a Functional Process has been revised
V3.0.1 definitiona) 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 definitiona) 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 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.
How to analyse the input to batch processes was not well explained
12
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?
Input data Questions
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.
a menu click to produce an ad hoc report, a ‘clock tick’ to produce month-end reports,
but always count a triggering Entry.
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
MUB 9: The definition of a ‘layer’ now matches industry practice
Application ‘A’
Application Layer
UI Layer
BR Layer
DS Layer
UserInterface
Component
BusinessRules
Component
DataServices
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
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
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
MUB 10: Many NFR’s evolve, as a project progresses, into FUR which can be measured
18
Functional UserRequirements
Non-FunctionalRequirements
Examples:• Maintainability • Interfaces• Operations• Reliability• Usability• etc
Functional UserRequirements
‘True’ NFR e.g.
• Technology,• Project constraints
Project time-line
* (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
Can be sized
Should be recorded;may be quantifiable
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
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)
20
Problem! Rule b) conflicts with the rule that an Entry accounts for all associated data manipulation. Same for R, W, X
‘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.
21
c) FUR may specify multiple data groups to be moved from 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.
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 measuredExample: 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
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
