How do you instinctively know what is a great design? We all have a feeling in our various cultures of what is a great piece of architecture. We all appreciate beautiful Scandinavian-designed household artefacts. In technology we all now accept as normal the Graphical User Interface but it was a brilliant revelation when it first appeared (invented by Xerox but first successfully exploited by Apple). And Apple has gone on to become the world’s largest company by market capitalization on the basis of these easy-to-use interfaces and its elegantly designed i-pods, i-phones, and so on.
The common characteristics of great designs are fitness for purpose (or ‘functional suitability’) combined with simplicity and elegance, or even beauty, if possible.
The basic principles of the COSMIC method
It’s interesting to reflect on the development of the COSMIC method against this background. The basic principles were first worked out at an informal meeting in 1999 at Mont Tremblant, north of Montréal, Canada by a bunch of software metrics experts with long experience of functional size measurement. Several of us had been members of the ISO Working Group on the principles of FSM.
Our aim was to develop a FSM method that could be applied to business, real-time and infrastructure software using the same concepts for all domains. We quickly decided on a model of software consisting of functional processes that must respond to events in the world of the user. And functional processes consist of Entries and Exits that move data in and out of the software and Writes and Reads that move data to and from persistent storage. The unit of measure was a single data movement. The size scale was open-ended. Although to be practically useful, COSMIC-measured sizes should correlate with development effort, we saw no need to apply weights to the four types of data movements. Instinctively, we felt that on average the four types of data movements each accounted for about the same amount of functionality.
In some ways, this initial design was the easy task; the design seemed to be elegantly simple. However, we now had to write a ‘Measurement Manual’ containing the principles, rules and definitions so that Measurers could apply the method in practice. This is where the problems began. For example:
- As we aimed to be able to measure software in any layer of an architecture, we needed a definition of a ‘layer’. Our first effort in v2.1 resulted in a definition of 94 words and 8 Principles for distinguishing layers. And this characterization of a layer was unique to COSMIC; for example it could not be used to describe the layers of a 3-layer architecture. By v4.0.1 of the method, the definition has been simplified to 8 words, there are 5 principles, and we can use these to describe the layers of any architecture.
- We soon recognized that the method could measure different sizes of the same software depending on the ‘viewpoint’ of who or what are defined as its ‘users’. In v2.2 of the method, we defined two standard viewpoints, that of the End User and of the Developer, and acknowledged that there might be other viewpoints. But by v3.0 we realized that this terminology was unsatisfactory. Moreover the expression ‘FUR’ could be interpreted as the ‘requirements of the functional users’. So now the Measurement Strategy phase specifies that you must first define the functional users, following which you measure the functionality (the ‘FUR’) that those users require. By generalizing, we could avoid the need to define any ‘Measurement Viewpoints’.
- Initially we had difficulties trying to describe rules to distinguish objects of interest, especially in Entries and Exits. We introduced the concept of ‘transient objects of interest’, as opposed to the objects of interest about which persistent data are stored. This was a mistake. It is the data groups moved by Entries and Exits that may be transient, not the objects of interest. The latter are real things in the real world that are of interest to the functional users. Whether data describing an object of interest is stored persistently or exists only transiently when moved by an Exit is immaterial.
- We initially defined the measurement unit as a ‘COSMIC functional size unit’ (or Cfsu) to be precise but the abbreviation was not easy to pronounce. Later we accepted it was much simpler to call the measurement unit a ‘COSMIC Function Point’ (or CFP).
Improvement by simplification
There are many other examples like these. The lesson from this experience is that each step along the road to improve the method description has been achieved by simplification. The basic design and its principles have barely changed since the method was first designed. Meanwhile the method has been applied to size the FUR of a huge range of software from all domains, at all levels of decomposition. And in spite of there being no effort-related weights applied to the four types of data movement, we now have plenty of experience that functional sizes measured in CFP correlate very well with development effort.
It has been enormously satisfying over the years that whenever we have encountered a difficulty in defining what we mean or in solving a particular measurement problem, the solution has always been found by going back to the basic design principles and in seeking the simplest explanation or solution. This suggests to me we have a great, ‘future-proof’ design.
About the author
Charles Symons is Founder and Past President of the Common Software Measurement International Consortium. If you find any parts of the Measurement Manual or any other COSMIC publication difficult to understand, please let him know, via email@example.com. COSMIC is always seeking to simplify and improve.