Tech Views
By Ellen Walker, DACS Analyst
The software community has been trying to accurately estimate the size of software products for a long time and has searched for a metric that is objective, consistent, accurate, a good predictor of effort, and is obtainable with minimal resources,. This ideal metric would provide a common frame of reference to communicate and make decisions about software development across organizations, regardless of the domain or development environment. Physical size metrics such as source lines of code (SLOC) or number of requirements statements have been widely used but some groups within the software community believe that functional size metrics are better than physical size metrics because Functional Size Measurement (FSM) [1], in theory, has the following characteristics:
- Works for all types of software (scientific, business apps, web portals, embedded systems, etc.)
- Works for all types of projects (new development, enhancements, maintenance, etc.)
- Is language independent
- Is technology independent
- Is repeatable (consistent) – two analysts independently measuring the same software will arrive at essentially the same size assuming they are both adhering to the same FSM method.
- Produces statistically significant results
- Can be applied early in the development life cycle
But in reality, there is a pervasive perception in the software community that functional sizing is only good for business applications and not applicable to other types of systems. Those who are knowledgeable about functional sizing techniques claim that FSM works for any type of software and assert that those responsible for technical applications such as real time systems, embedded systems, control software and utility software, just need to get educated about functional sizing. Thus, we have “the great divide”, the gap between real world practitioners and the metrics experts who are perceived to be, essentially, “preaching to the choir”. Our goal in presenting this issue of STN is to narrow this gap by providing information to developers and/or acquirers involved with real time and embedded systems that will aid them in understanding the potential benefits that can be achieved from implementing FSM.
Figure 1.
Figure 1, provided courtesy of Pam Morris[2], presents an historical view of the development and evolution of functional sizing methods from one construct to several, illustrating the fact that now there are choices of sizing methods.
Functional sizing first made its debut in the early 80s with Allan Albrecht’s Function Point Analysis (FPA) method. During the 80s and 90s the number of methods grew from one to six (Full FPs emerged)). Some (3-D fps and Feature Points) faded away for lack of support or lack of robustness. In the late 90s there was a convergence of methods into two key methods that gained international support (IFPUG and COSMIC) and two methods with apparent national scope (NESMA and MK II). Appropriately, an International Standards (ISO) framework for FSM (ISO/IEC 14143 series) has been developed along with ISO standards for each of the major FSM methods.
As the diagram in Figure 1 shows, developers today have choices to make regarding the FSM method that best meets their needs. Both of the major FSM methods (COSMIC and IFPUG) assert that their method works for sizing all types of software. Both methods yield a count that quantifies the functionality of the subject software in some way, regardless of the domain. But, so what? The question that each developer must ask is, “What is the value of having this particular functional size metric? What does it do for us?” What does the size metric need to do in order to enable us to say, “It works for us?” We are really talking about how useful the functional size metric is for predicting and decision-making. The theory is that functional size should be a good predictor of effort, which, in turn, enables us to predict cost. Therefore, the size metric must be independent (decoupled) from, rather than a reflection of, effort. We want to be able to determine size easily and early and use it to estimate the effort and cost associated with development in our particular environment with assurance that the estimates are, in fact, reasonably accurate. That is a simple statement to make but the target remains elusive for many developers.
In the last issue of the STN (Vol 9-2 June 2006) the DACS presented the concept of functional sizing and described the implementation of the functional sizing method maintained by the International Function Point Users Group (IFPUG), which has existed since the 1970s, and is used extensively by the business application software community with great success. IFPUG calls its functional size unit a function point (FP). The issue also presented information about sizing with benchmark data from the project repository maintained by the International Software Benchmarking Standards Group (ISBSG) and demonstrated how the repository data could be used to obtain reasonably accurate size estimates early in the project life cycle with minimal effort.
Now, in this issue, we present functional sizing as it relates particularly to non-business applications such as real-time and embedded systems, utility applications and control systems. We also provide some commentary on innovative uses of functional sizing that are independent of the chosen sizing method.
Sizing, by itself, is just a number. It does not increase productivity; it does not increase quality; it does not reduce cost [2]. However, it can provide consistent objective quantitative data, which we can then use to make better decisions that will help us increase productivity, increase quality and reduce costs.
The articles in this issue of the Software Tech News were selected to help you further understand functional sizing by:
- Presenting a synopsis of a methodology specifically designed for use with ‘process-rich’ applications such as real time and embedded systems
- Comparing IFPUG and COSMIC sizing methods to each other to demonstrate why an organization might choose one method over the other depending on how the size metric is to be used
- Illustrating the importance of statistical analysis to determine the circumstances in which the size metric can be considered a good predictor for effort estimates
- Presenting size metric usage scenarios that reflect innovative and effective acquisition strategies based on the ‘cost per delivered functional unit’ paradigm.
In the first article, author, Charles Symons, describes the methodology for functional sizing called COSMIC-FFP (Full Function Point). COSMIC, the Common Software Measurement International Consortium, is the group responsible for the creation and maintenance of COSMIC-FFP, established in 1998”. The consortium designed this sizing approach specifically for real time and embedded systems software that is essentially “process-rich”. This method has a strong user base in Europe and the data from many projects sized with COSMIC-FFP resides in the ISBSG repository. “Cfsu” denotes a COSMIC functional size unit. Symons exemplifies how the sizing method works by applying it to the security alarm system in his home.
In the second article, Pam Morris makes a technical comparison of the IFPUG and COSMIC methods and illustrates the impact that the choice of method can have in the implementation of outsourcing agreements or other types of contracting based on cost per delivered functional unit. This article should help readers to understand why there is currently not a single “one size fits all” functional sizing method that is equally valuable (useable) for all types of software development.
Article three, by Alain Abran, illustrates the use of functional size measures (using COSMIC-FFP) in building estimation models for maintenance projects. The research is based on 19 maintenance projects (implementing small functional enhancements) on a single real-time embedded software application in the Canadian Defense industry. His article illustrates that there is no easy road to deriving value from using functional sizing. An organization must be prepared to do thorough analyses of their data in order to find the best models for their particular environment, whether they are involved in maintenance or developing new software.
Article four, by Terry Wright, titled “With or without a navigator? --- it’s your call!”, describes the use of functional sizing as an acquisition strategy. The initiative, called SouthernSCOPE, undertaken by the State of Victoria in Australia, was unique in two ways: First, it required bidders to submit proposals based on a ‘cost per delivered functional unit’, and second, the acquirer engaged a ‘Scope Surveyor’ throughout the development life cycle.
Although the initiative proved very successful, sustaining the best practices of that initiative proved to be very difficult. Terry tells the story about a functional role that addresses sizing throughout the project and seems to be important for success. He hints, however, that the cultural aspects of project management are a formidable barrier to the adoption of this new role by acquirers and developers alike.
The last article, written by Juan Carlos Molina, describes how his organization has used functional sizing as the basis for charging customers for code generation based on a Model-driven Architecture approach (MDA). The MDA tool automatically sizes the application (using the IFPUG counting method) from the software model before code is generated. Developers or Acquirers can then calculate the cost of code generation before any resources are committed to it. Developers focus on the model, not the code. Subsequently, this approach can have a significant impact on planning both the effort and schedule needed to develop software and therefore the cost. It seems to be a WIN-WIN situation for all --- the developer, the acquirer and the service provider --- because everyone knows up front how much the code will cost, and because the method used for determining size is consistent and objective. The developer can focus on estimating the effort required to develop the model.
The information about FSM is vast. It is of global significance and it touches many software domains. This issue only scratches the surface of FSM knowledge, but it does demonstrate that FSM is no longer relegated to the domain of business applications only. These articles all suggest that FSM is not something you do occasionally. Nor is it very useful in a short-term scenario. Its value increases as it is applied to more and more projects, and as the organization builds its project repository. “Which method is best?” is not necessarily the right question. Instead, you need to ask, “Which method is right for us?” Focus on what you want to do with the metric and let that drive your decision-making. Think usage! Usage! Usage!
References
[1] Tichenor, Charley, “The Management Science of Function Point Analysis”, 2006 Functional Sizing Summit, IFPUG Spring Workshop, Cambridge, Mass
[2] Morris, Pam, “Cosmic-FFP and IFPUG 4.1: Similarities and Differences”, Presentation at 2003 IFPUG Fall Conference, Scottsdale, Arizona.
About the Author
Ellen Walker, a DACS Analyst, is currently developing a series of publications on software “best practices” as part of the
DACS Gold Practice Initiative. She has spent the past 20 years as a software developer in various roles spanning the entire
software life cycle including project management of multiple business process re-engineering efforts within the DoD community.
She is also experienced with assessment initiatives such as the Capability Maturity Model for Software (CMM-SW) and the
quality management practices of the New York State Empire State Advantage program. Ellen has an MS in Management Science
(State University of New York (SUNY) at Binghamton), and bachelor degrees in both Computer Science (SUNY – Utica/Rome) and
Mathematics (LeMoyne College).
Ph: 315-334-4936
Email: ellen.walker@itt.com
| 
DACS Gold Practice Initiative
ROI Dashboard
