Using COSMIC for Real-Time and Embedded Systems

Search:   

Document Info.
First Published
SM&P Issue 10
Reference Category
Tools and Techniques

Related Info...
Articles
Services
Training

Reference
Categories
Articles by Title
External Ref's
Other Web Sites

by: Tony Rollo

The COSMIC Method has been reported on in our newsletter in the past and many of our readers have some familiarity with the basic concepts. However, you may be interested in exploring the use of COSMIC based estimation in a real-time and embedded systems context.

In order to illustrate this I have chosen to use a simple embedded system, which also has a real time element. The system I will examine is a toy telephone (figure 1). This is quite a sophisticated toy in that it comes with two telephones and a small network box. This case study was published in JSP&JSD the Jackson Approach to Software Development, IEEE Computer Society Press 1989.


Figure 1: Architecture of the Toy Telephone

The toy telephone has to respond to several user-generated stimuli which include:

  • STARTOWNCALL- user lifts handset
  • DIALDIGIT - user dials (or presses) a digit

The telephone must also provide stimuli to, and respond to stimuli from, the telephone network such as:#

  • TIEPOINT- the network allocates a tie point (a resource of the network)
  • NOTIEPOINT- the network is unable to allocate a tie point

This is managed by the use of three software components, 'Telephone', 'Telephone Call' and 'Action Generator'. Essentially the telephone component communicates its state to the telephone call object, which stimulates the action generator as required. For incoming calls the action generator stimulates the telephone as appropriate. The stimuli to telephone call object are therefore a subset of the telephone stimuli, and include:

  • STARTOWNCALL
  • TIEPOINT
  • NOTIEPOINT

To illustrate the COSMIC size let us take a simple functional process as it affects the telephone object, which forms the HCI layer and is sized separately from the other components when we are sizing for the purpose of estimating the project size. NB it is important to remember the viewpoint, we are sizing the telephone component as a subsystem of the system NOT from the viewpoint of the user which would be a very much more abstract view.

STARTOWNCALL - lifting the handset triggers this and the telephone object communicates this fact to the telephone call object, requests a dial tone from the tone generator, which is sent directly to the handset.


Figure 2: User Interface Layer StartOwnCall Process

The diagram above shows the entries, exits and writes involved in this functional process, which contributes 7 COSMIC functional size units or Cfsu's.

Proceeding in this manner we find that the total size of the telephone component is 67 Cfsu's.

So where does that get us?

In order to come up with an estimate we ideally require data from the same development environment that is going to construct this component. In the event that we have no such information, we must use that which we have, and accept a wider range of possible estimates than we might prefer. Remember when this component is constructed, record the actual size and effort so we can make a more precise estimate the next time.

For now, we have the data available from the COSMIC field trials so let us use that.

 

 Cfsu / hour 

 Cfsu / staff month 
 Median

0.0371

4.5
 2nd Quartile 

0.0339

4.1
 3rd Quartile 

0.0483

5.8

The COSMIC Field Trials industry data shows:

 Estimate of Effort   Staff Hours 
 Most Likely 1806
 Lowest Likely 1387
 Largest Likely 1976

Using the data, we get as our basic estimate:

 Proportion of Effort Consumed 
 Specification  22%
 Construction  42%
 Testing  36%

The data also shows that:

 Phase  Staff Hours 
 Specification  1806
 Construction  1387
 Testing  1976

So we can predict likely phase effort of:

 Duration

Hours

 Months 
 Most Likely

452 (1806 / 4)

3.8
 Shortest Likely 

347 (1387 / 4)

2.9
 Longest Likely 

494 (1976 / 4)

4.1

This is a relatively small system so we assume an average team size of 4 persons. Duration = effort/staff, so the estimates for duration will be:

Regression formula for duration given in the COSMIC Field Trials report presented at FESMA 2000 in Madrid gives a duration of 4.1 months. So by using either a regression formula or median values we obtain a very similar estimate.

I have used industry data. However, estimation can be greatly improved if you collect your own - at least the effort, duration by phase and size. You should also categorise your projects by factors which influence productivity. ISBSG suggests these factors - team size, language, project type. What you are trying to do is collect historical data, which can be matched to the project you are trying to estimate, and is both reliable and relevant. You can make good estimates with very little information if the data matches your project.

Related Information

back to top

Articles

Come back Function Point Analysis (modernised) - All is Forgiven!
In this paper, Charles Symons examines the reasons for the decline, and the main advances in thinking on the more general topic of Functional Size Measurement (FSM) which have been made in the last 15 years. Specifically, the COSMIC FFP method is seen as a significant step forward in being the first method designed by an international group of software metrics experts to work for both business application and real-time software.

Software Size Measurement
Undergoing a renaissance, Functional Size Measurement is applicable thorughout the development, maintenance and support lifecycles.

Using Measures to Understand Requirements
Many approaches fashionable with technically-oriented practitioners clearly fail to satisfy the need for clarity of requirements. Some even trade short-term acceleration for long-term maintenance & support costs. What is missing? What can be done to ensure that new technologies help rather than hinder? This paper suggests some simple process improvements that might have made all the difference in a number of cases.

Services

Applying Software Metrics

Data Collection
Services for identifying, collecting and checking measurements.

Starting a Measurement Programme
A measurement programme is part of a means to an end (one or more business objectives). To deliver any benefit the objective(s) must be clearly understood first and then the measurement programme must be designed to support them.

Supporting a Measurement Programme
Once successfully started, there are various activities required to keep the measurement programme operating effectively and the results relevant.

Assessing Capability

Functional Sizing Audits
To ensure that the selected functional sizing method is being used to produce reliable consistent results.

Estimating and Risk

Estimating Size
Estimating Size from detailed requirements and detailed designs.

Measuring Requirements and Changes
Measuring the functional size of change requests and estimating their impact in terms of cost, duration, effort etc.

Tools and Techniques

COSMIC FFP
A method designed to measure the functional size of real-time, multi-layered software such as used in telecoms, process control, and operating systems, as well as business application software, all on the same measurement scale.

IFPUG Function Point Analysis
The original method of sizing, it is currently at version 4. This method is still the most widely used and works well in the business/MIS domain. It is applicable to object oriented developments.

Mark II Function Point Analysis
This method assumes a model of software in which all requirements or ‘user functionality’ is expressed in terms of ‘Logical Transactions’, where each LT comprises an input, some processing and an output component.

Training

Applying Software Metrics

Counting Object-Oriented Applications and Projects  Advanced Workshop
An advanced workshop for practitioners wishing to apply functional size measurement in object-oriented environments.

Uses and Benefits of Function Point Analysis  
Learn how FPA can help your projects manage the acquisition, development, integration and support of software systems

FPA Follow-Up Workshop  Advanced Workshop 
An advanced workshop to help experienced practitioners resolve the issues that arise when using unfamiliar technologies.

Function Point Counting Workshop   
Apply your skills in a coached workshop – consolidate your skills and experience on the job.

Sizing E-commerce Applications  Advanced Workshop
An advanced workshop for practitioners wishing to apply functional size measurement to internet-based solutions

Tools and Techniques

COSMIC FFP for Sizing & Estimating MIS and Real-Time Software Requirements  Formal Course 
Learn how to measure the software component of software-intensive systems using the latest ISO-standard method

Practical use of IFPUG Function Point Analysis  Formal Course 
Learn the most popular technique for measuring the functional size of software applications and projects

Practical use of MkII Function Point Analysis  Formal Course 
Learn the UK Government’s preferred technique for measuring the functional size of software applications and projects

GIFPA Ltd. 2016
    
  
 e-mail: sales@gifpa.co.uk
  www.gifpa.co.uk

Copyright 2002-2016 GIFPA Ltd. 2016 All rights reserved.

                                               
Applying Software Metrics
Assessing Capability     
Estimating and Risk       
Improving Processes     
Measuring Performance
Sourcing                       
Tools and Techniques   
             
                
Services               
Training                
Events                  
Reference             
                
About GIFPA         
Opportunities
Copyright & Legal