Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
Faster and more accurate functional size measurement by KISS – keeping it simple Pekka Forselius FiSMA, Software Technology Transfer Finland Ltd,
[email protected]
Abstract Function Point Analysis is often said to be too difficult method for software development estimation purposes. It is said to be unreliable and also too expensive, because only certified function point analysts can apply it correctly. The worst thing is, that all this is true, when using traditional function point counting practices and approaches. In this article the author will introduce the KISS approach to functional size measurement. With 28 questions about different base functional component types belonging to six classes this approach provides a very good size estimate in a very short time. The best piece of news is that any project manager or software developer having good enough requirements specification and capability to understand them, can apply KISS approach after a very brief introduction. KISS is not a new Functional Size Measurement (FSM) Method. It is a different approach to catch all of essential information from requirements specifications for Functional Size Measurement. It is more or less compatible with all most important FSM Methods, like IFPUG 4.1, Mk II, COSMIC-FFP and Nesma. The compatibility with FiSMA FSM 1.0 and its old version (Experience 2.0 FPA) is most perfect, because the KISS approach was developed based on those methods, which are the most widely used in Finland. KISS approach has been available in Finland since January 2001. Already the first trials were very encouraging. Project managers without any experience of FSM and without any training could measure the size of a 200 fp piece of software by +/- 10% accuracy, in less than 30 minutes. With traditional approaches they couldn’t get out any sense making results of the exactly same documents, in any reasonable time. The KISS approach has been tested with several different cases, giving always as good results as told here. This level of applying KISS approach is called “KISS Quick”. Functional Size Measurement is not only getting a size figure. For some uses of FSM it may be enough to know that your piece of software is for example 548 fp in size. For most uses of FSM it’s not enough. For controlling progress or managing changes of a software development, you have to know more details of the functionality. Also the contract management should be based on more detailed functional size measurement. In the end of this article the author introduces the “KISS Perfect” approach, which is essential to be applied for those purposes, and for professional scope management in general. In practice it means a move from rough counting to normal FSM.
1. Introduction Why is it so difficult to count function points? Why should the counters be trained, examined and certified? Why do we need so many different function point methods? Why don’t we keep it simple, stupid? Finland is one of the most successful countries in professional software development. FiSMA, the Finnish Software Measurement Association is one of the most active metrics organisations in 1
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
the world. Approximately one thousand people from FiSMA member organisations have been trained in functional size measurement and effort estimation during the last seven years. The author of this paper has been involved in most of these training sessions. He has heard a lot of questions concerning different interpretation rules related to function point counting. No matter which of the different FPA dialects the user happens to be interested in, there are always too many paragraphs of counting practices manuals to worry about. The same questions and similar mistakes in the first trials always apply. Those interesting, never stupid questions, and finally expected mistakes were the seed of a simple functional size measurement approach, KISS. Functional size measurement is used for two main purposes: to help estimating the effort of a starting development project or measuring the actual productivity of a finished development endeavor. Of course there are other reasons to use functional size measurement too [1], but here we concentrate on these two. In both cases the needed accuracy level varies. The KISS FSM approach can be used at two various levels, KISS Quick for a rough measurement and KISS Perfect for a very detailed and exact measurement. Sometimes it is important to get the reasonably accurate size estimate very soon, without detailed information of functions. In this case we can use KISS Quick, just to get the total size of the software. At rough level we just answer 28 "how many"-questions, asking the numbers of different kinds of functionality of our application. Later on, when the project starts, we always need an accurate list of all named functions and some details of each of them. We have to complete the information got from each of those "how many"-questions by answering the following question "what are they".
2. KISS background Different function point analysis methods collect the functionality in different ways. They all have their own functional size measurement units, which are not comparable without conversion case by case. From the same set of functional requirements we get different numbers of function points depending on the fpa method used. Which one of the methods is right? Probably none. Is it better to have many or few function types? Nobody knows. However, in our experience, the less you have different base functional component types (function types), the more open the method is for different interpretations. The basic concepts and definitions of functional size measurement are standardized by the International Organization for Standardization ISO [2]. These concepts allow very different approaches and methods to be called functional size measurement methods. Some of the current methods have become standardized, i.e. proved to be conformant with the concepts of international standard. On the next pages and in figure 1 we compare three of current FSM methods, IFPUG 4.0, Mk II and Experience 2.0. Figure 1 tries to illustrate how these three methods catch slightly different samples of real functionality and base their size measurement on that set of functional user requirements. As the example shows, different methods provide different results. These figures must always be presented together with the size measurement unit.
2
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
Figure 1 Different FPA methods define the functionality in different ways
The Mk II FPA method has only 2 types of base functional components, as the Experience 2.0 method has 6 and IFPUG 4.0 Function Point Analysis 5. The ISO standard [2] has no rules or recommendations for the number of different base functional component types. As the example above shows, very different methods may work. All those three methods have been used successfully for several years. There is evidence that they all can be applied at several domains, but none of them satisfies measurement requirements of all kind of software development. There are lots of commonalities between these methods, but some differences too. All three recognize and count input and output functional components, but Mk II doesn’t count persistent data storages separately, as the two other methods do. Experience 2.0 is the only one counting algorithmic and manipulation functions. In next paragraphs we discuss about some differences between these three example methods. What are the “real” functional requirements of a software? Is a paper report a functional requirement? Most of different functional size measurement methods say yes, but some of them have been developed for a very narrow application area where there are never any paper reports, and that is why those certain methods don’t accept paper reports as functional requirements at all. They don't even ask for them. KISS does. Basic thinking behind KISS is, that if any of the wellknown and well-tested size measurement methods counts something to be functional, we accept it too. This will cause more base functional component types and basic questions than any other approach has, but we have seen that these questions are very easy to answer for the estimating person. Easy questions make the approach faster than the others. We don't need counting practices manuals and certified specialists to believe the size figures. It is only the list of functions that makes any influence to the application size. The size can then be expressed in any ”standardised” functional size measurement units. KISS FSM does not have its own FSU.
3
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
Are menus or starting icons functional requirements? If they are, are they inputs or outputs or inquiries? Navigation is very important to the web-surfers. They usually think that navigating is functional, actually the most important functionality of their favourite applications. For example Mk II counting practices manual [1] recommends to not count any features like menus or icons when used simply for navigation purposes. Nesma rules and FiSMA Experience 2.0 interpretation guide recommend counting a menu as an inquiry. KISS questionnaire asks "how many menus do you have in your application" and "how many starting icons do you have in your application. It defines that menus are menus and icons are icons, and they both are functional requirements of software. KISS FSM defines six different types of interactive navigation or query functions. The common feature to all of them is that they are visible to the end user and do not update the data storges of the application. The interactive user input functions are understood in a reasonably similar way in all FSM methods mentioned above. All of them recommend counting create, update and delete separately, even if they can be managed by one common user interface. Some of the methods make recommendation to count one inquiry in addition to those three, because you can always use an update window as an inquiry if you dont change anything. This interpretation may cause some noise to KISS FSM results. KISS questionnaire concentrates on different update windows (or screens), dividing them into three categories depending on the updating power they have. The most powerful windows you can use to all three types of update, the second category to two types of updating and the third type of windows are only for creating or updating or deleting entities of the data storage. Many applications provide different outputs to the end-users. They differ from queries by their lacking interactivity. The end-user just receives them and can watch them, but can't change them anyhow. They can be called passive user outputs. Another common feature is, that they are not anymore in digital form and thus can't be processed by other applications (without re-digitalisation). Some of the user outputs are completely formalised, printed probably on pre-filled paper forms. The others are more dynamic reports, depending more on the selected data contents. At some domains there may be provided different short messages from the application to the end-user. In addition to the interfaces between an application and its end-users, there are interfaces between the applications and/or devices. These interfaces must be recognised and recorded as functional user requirements. Some of the FSM methods do not make any difference between data groups sent to another application and data groups received from another application. The data groups can be either on-line messages or batch records. Some FSM methods count every different data group separately as an independent functional component, as some other methods manage interfaces at logical level, using the number of data groups only for weighting, determining the complexity. In the first version of KISS approach we asked both for the number of logical interfaces and the numbers of different records and messages at the lower level. This caused so much confusion and wrong interpretations, that in this current version we only ask for the lower level interface functional components. There has been a lot of conversation if data storage services are functional components of an application. Most of FSM methods count them as independent functions, but for example Mk II and COSMIC-FFP don’t. Similarly with interfaces, the first version of KISS approach asked for data storage services at two levels, logical data storages and their entities (or data classes as they are called in object oriented modelling). Currently we only ask for the entities and other logical records. KISS approach expects the data model being normalised, in 3NF.
4
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
The sixth group of functional requirements of KISS includes algorithmic services provided by applications. They are completely abandoned in FSM methods like Mk II, IFPUG 4.0 and COSMIC-FFP. Some other FSM methods like Experience 2.0 method counts algorithmic functions weighting them based on the number of operations (arithmetic or boolean or others) and the number of different parameters used. The algorithmic functional components counted should be independent and defined by the end-user representatives. The independence here means, that the algorithm is not a natural part of any certain other type of function, but the routine has to be developed. Figure 2 below shows the aggregate concept of functionality of the KISS FSM approach. Asking 28 questions belonging to six categories we can count the size comparable to almost all published software productivity data. When compared to figure 1, the figure 2 tries to illustrate that the sample of functional components caught by KISS approach is broader than the samples caught by any example FSM method.
Figure 2 KISS FSM definition of functionality covers several other FSM methods
The next chapter will introduce the full questionnaire of KISS FSM approach.
3. KISS Quick The KISS FSM questionnaire consists of 28 questions concerning the numbers of occurrences of functional components: Seven questions about navigation and query services, all interactive user functions without update facilities: 1. How many starting icons do you have in your application? ________ 2. How many different log-in and log-out windows do you have? ________ 3. How many different menus do you have in your application ? ________ 4. How many parameter selection lists (so called drop-down lists) do you have in your application? ________
5
Pekka Forselius/STTF
5. 6. 7.
IFPUG FSS 2006 Paper
8.3.2006
How many inquiry windows do you have (showing contents of the database to the user on the screen, not updating anything)? ________ How many browsing list windows (showing several occurrences of same type of data) do you have? ________ How many different screens for starting report generation do you have? ________
Three questions about interactive user input services, each type having different updating power: 8. How many different 3-functional (create, update and delete) user input windows do you have? ________ 9. How many different 2-functional (create and/or update and/or delete) user input windows do you have?________ 10. How many different 1-functional (create or update or delete) user input windows do you have?________ Four questions about non-interactive user output services: 11. How many different output forms (fixed layout) does your application provide? ________ 12. How many different reports does your application provide? ________ 13. How many different text messages or e-mails does your application write and send? ________ 14. How many different monitor screen outputs do you have? ________ Six questions about interface services between this and other applications: 15. How many different messages to other applications do you send? ________ 16. How many different messages from other applications do you receive? ________ 17. How many different signals to a device do you send? ________ 18. How many different signals from a device do you receive? ________ 19. How many different batch records to another application do you send? ________ 20. How many different batch records from other applications do you receive? ________ Two questions about persistent data storage services: 21. How many different entities or business classes (OO) do you have? ________ 22. How many other logical record types do you have? ________ Six questions about independent algorithmic services required by the end-user: 23. How many different independent calculation routines does your application include? ________ 24. How many different independent simulation routines does your application include? ________ 25. How many different independent formatting routines does your application include? ________ 26. How many different independent database cleaning routines does your application include? ________ 27. How many different independent security routines does your application include? ________ 28. How many other different independent algorithmic routines does your application include? ________
If you are using an estimation tool like Experience Pro 3.1, the number of occurrences of each function type is all information you have to give to get the size of your application. If you want to count it manually, in addition to numbers of occurrences you have to know the FSM method specific multipliers for each question. How many function points is an average paper report? We don't know, because the answer is strongly dependent on the functional size measurement unit. You should specify the FSM method first. So, the question is not very good, because an unambiguous answer doesn’t exist. Much better question, closer the real software development world, is: "What does an average paper report contain?" Any experienced software engineer can say, based on his or her experience, that there are 20 different data items on an average report, read from 3 entities. From this information we can easily count and determine the size of an average paper report for any FSM method: 7 fp in IFPUG 4.0, 5,2 fp in Mk II or 5 fp in Experience 2.0. These are the method specific multipliers for question number 11. The complexity of each functional component in each FSM method is determined based on values of certain attributes. All types of functional components deal with data items and/or entity references and/or calculation rules. Data items are called data element types (DET) sometimes [3]. The “entity references” may be updating or only reading data contents of the referenced entity.
6
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
Calculation rules mean simple arithmetic or logical operations. In the previous paragraph we described an average paper report. In a similar way we can define average functions of each 28 types. They are presented in table 1. Table 1 Values of complexity attributes for average occurrences of functional component types of KISS FSM A
Navigation and query functions
Data items
1 2 3 4 5 6 7 B
starting icons log-in windows menus drop-down selection lists inquiry windows browsing list windows report generation windows
8 9 10 C
3-functional (c/u/d) windows 2-functional windows 1-functional windows
11 12 13 14 D
output forms reports e-mails or text messages monitor screen outputs Interfaces between this and other applications
Data items
15 16 17 18 19 20 E 21 22 F
on-line message types out on-line message types in signals to devices signals from devices batch record types out batch record types in
15 15 3 3 15 15
23 24 25 26 27 28
calculation routines simulation routines formatting routines database cleaning routines security routines other algorithmic routines
User input functions
2 8 8 2 12 12 12 Data items
User output functions
Reading references
12 12 12
1 1 1 1 3 3 3 Updating references
3 3 3
Data items
Data storage functions
Reading references
2 2 2 Reading references
12 20 5 20
3 3 2 3 Updating references
0 2 0 1 0 2
Reading references
2 2 1 1 2 2
Data items
entities or classes other logical record types Independent algorithmic functions
12 12 Data items
10 10 10 10 10 10
Calculation rules
9 9 9 9 9 9
The multipliers for IFPUG 4.0, Mk II and Experience 2.0 are shown in table 2. All the multipliers are counted by the rules of each method, counting the average function of each type, shown in the table 1. The multipliers are zeros if the counting practice or the FPA method itself recommends to not count this kind of functionality.
7
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
Table 2 KISS FSM multipliers for the three example FPA methods
A 1 2 3 4 5 6 7
Navigation and query functions
starting icons log-in windows menus drop-down selection lists inquiry windows browsing list windows report generation windows
IFPUG 4.0
0 3 0 3 4 4 4 IFPUG 4.0
B
User input functions
8 9 10
3-functional (c/u/d) windows 2-functional windows 1-functional windows
C
User output functions
11 12 13 14
forms reports e-mails or text messages monitor screen outputs
D
Interfaces between this and other applications
15 16 17 18 19 20
on-line message types out on-line message types in signals to devices signals from devices batch record types out batch record types in
E
Data storage functions
21 22
entities or classes other logical record types
F
Independent algorithmic functions
23 24 25 26 27 28
calculation routines simulation routines formatting routines database cleaning routines security routines other algorithmic routines
18 12 6 IFPUG 4.0
5 7 4 7 IFPUG 4.0
5 5 5 5 5 5 IFPUG 4.0
7 7 IFPUG 4.0
0 0 0 0 0 0
Mk II
0 1,9 0 0 5,2 5,2 5,2 Mk II
26,6 17,8 8,9 Mk II
5,2 5,2 3,6 5,2 Mk II
3,6 7,2 1,9 3,9 3,6 7,2 Mk II
0 0 Mk II
0 0 0 0 0 0
Experience 2.0
1 3 3 1 4 4 4 Experience 2.0
12 8 4 Experience 2.0
5 5 4 5 Experience 2.0
7 4 2 3 7 4 Experience 2.0
7 7 Experience 2.0
4 4 4 4 4 4
If the application measured is very typical MIS (Management Information System) application, KISS Quick may provide a very accurate size figure. There may be many other cases too, when the final result from a thorough, traditional function point analysis doesn’t differ from the KISS Quick result at all. However, sometimes we need more thorough counting, even to get the total size figure, but especially for other reasons discussed in the next chapter.
4. KISS Perfect Unfortunately the functional components of a software application are not always exactly like the average. In fact most of them are either more complicated or simplier. In the variance of complexity of functional components, there are big differencies between different functional and 8
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
technological domains. For example, at some domains there are a lot of very simple different interface messages between the applications, as at another domain the interface messages are typically very long and complicated. In both cases, counting with KISS Quick is not enough. We can’t use average multipliers. We have to re-justify them, or count the size at more detailed level, functional component by functional component. Usually we recommend the latter approach, because it will provide us several other benefits. Sure the KISS Quick gets the right magnitude, but for contracting and scope management the detailed counting is necessary anyway. We call this apprach “KISS Perfect”, where we have to generate the complete list of identified functions of each type, and tell all the details needed for weighting them to any FSU. Except the more accurate size measurement, there are several other reasons to identify and specify each function. If we can identify and nominate them, we can convince everybody that we really know what are we doing. The more complete the list of functions is, the better managed the development project will be. If we cannot nominate the reports, interface messages and so on, we don't know our scope very well and this may cause problems in the project. KISS Perfect approach makes us to identify and specify our functional requirements. To all those KISS Quick questions where we answered having more than zero functions of that type, we have to tell exactly which are they and what are they like, i.e. how many attributes do they have. This will take approximately as much time as traditional FPA counting, but especially in the early phases of the project the KISS Perfect with its complete list of functions is recommended. In addition to the definitions 1 of each functional component type, there are not too many interpretation rules needed for KISS Perfect. There is some guidance for determining the boundary of the piece of software to be measured, but very similar issues are discussed in all counting practice manuals of different FSM methods. One important “FiSMA specific” principle that we try to follow is WYSIWYC, “What You See is What You Count”. That means that in all user interface functions we count every different type of data items, no matter if they are stored in the database or not. Every radio button, every control button and summary field must be counted too. This principle is different than the interpretation rules of most of the other FSM methods, but we have decided to follow it because it makes KISS Perfect much easier to use. You don't have to know anything about the origin or purpose of single elements of the functional components.
5. Experiences of using KISS FSM so far What kind of documents do we need for counting functional size of a piece of software using KISS approach? Somebody could think that the more documents we have, the better, but that is not true. If you have too large documentation, it is very hard to find out the relevant information. It will take too much time too. The three most important documents for KISS counting are the border chart of the application, the entity relationship model (or the object model) and short data flow descriptions of each business use case. This kind of documentation has been available in the first trials of the approach in Finland. The basic estimation and measurement training excercise is an 8-page case study. More than two pages about the project background and circumstances, and almost six pages about the target application. The students have read the case study once before the KISS counting. Usually they do the counting two or three together. In addition to those three documents mentioned in the previous paragraph, this case study documentation contains the menu-hierarchy-diagram. The fastest counting time so far has been 19 minutes and the slowest 45 minutes. The correct size of the 1
The definitions of all 28 base functional component types are in FiSMA FSM Method 1.0 documentation [4].
9
Pekka Forselius/STTF
IFPUG FSS 2006 Paper
8.3.2006
application is 206 fp's, as the students’ counting results have varied between 182 and 230 fp's. The trials using this case study and KISS Quick approach has been done at about 15 training courses so far. Another, more often used training exercise is slightly smaller, including only the entity relationship model and short use case definitions of the five use cases of the target piece of software. Total documentation of this case study is only four pages. It took only 15 minutes from the teacher to measure the size by KISS, but he knew the case study in advance, as the students had never read it before. Their counting times have varied between 22 and 45 minutes so far. The average time for this case study is 31 minutes. A “perfect function point counting” of this smaller case study software had resulted 129 fp's two years ago. The teacher got 133 fp’s by using KISS approach. The students are usually less experienced in project management on the training courses using this exercice than on those using the first one. Their results have been varying from 100 to 200 fp's, but 90 % of the counting results were between 120 and 145 fp’s. The average student’s size has been 139. The results of KISS trials have been so encouraging, that we don’t use any other approach in FSM teaching any more in Finland. The old FPA methods are introduced only for understanding the backgrounds and the tradition of functional size measurement.
6. Conclusions KISS FSM seems to be better and faster approach for functional size measurement than any traditional Function Point Analysis method. It needs more research and maintenance, but obviously it is a step to right direction on the way to better management of software development endeavors. Estimation and measurement are key issues, but mature project management is the real need of FSM user organisations and their customers. So, let's keep estimation and measurement as simple and easy to use as possible! References [1] [2] [3] [4]
MK II Function Point Analysis Counting Practices Manual, Release 1.3, UKSMA Metrics Practices Committee, September 1997 ISO/IEC 14143-1, Information technology – Software measurement – Functional size measurement Part 1: Definition of concepts, ISO, 1998 Function Point Counting Practices Manual, IFPUG, January 1999 FiSMA FSM Method 1.1, FiSMA, 2004, www.fisma.fi :methods
10
