nach oben

2008 | Buch

Kapitel lesen Erstes Kapitel lesen

The IT Measurement Compendium

Estimating and Benchmarking Success with Functional Size Measurement

verfasst von: Manfred Bundschuh, Carol Dekkers

Verlag: Springer Berlin Heidelberg

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

“As projects get more complicated, managers stop learning from their - perience. It is important to understand how that happens and how to change it…. Fallible estimates: In software development, initial estimates for a project shape the trajectory of decisions that a manager makes over its life. For ex- ple, estimates of the productivity of the team members influence decisions about the size of the team, which in turn affect the team’s actual output. The trouble is that initial estimates usually turn out to be wrong. ” (Sengupta, 2008) This book aims directly to increase the awareness among managers and practitioners that estimation is as important as the work to be done in so- ware and systems development. You can manage what you can measure! Readers will find in this book a collection of lessons learned from the worldwide “metrics community,” which we have documented and enhanced with our own experiences in the field of software measurement and estimating. Our goal is to support our readers to harvest the benefits of estimating and - prove their software development processes. We present the 5 ISO/I- acknowledged Functional Sizing Methods with variants, experiences, counting rules, and case studies – and most importantly, illustrate through practical - amples how to use functional size measurement to produce realistic estimates. The book is written in a practical manner, especially for the busy practitioner community. It is aimed to be used as a manual and an assistant for everyday work.

Inhaltsverzeichnis

Frontmatter

1. The Estimation Challenges

Every IT project should commence with an estime of effort, cost, schedule dates and duration, as a basis of project planning as well as for the measurement of project success at the end of the project. Early estimates before project initiation are not only challenging, but rely on the collective corporate knowledge of similar past projects. To produce sound estimates, estimating professionals need knowledge garnered from market trends and trend interruptions, as well as from vendors touting the latest in technological developments. In addition, estimators must rely on historical experiences and scenarios from their own project portfolios. Unfortunately, until recently, there existed little published data to support such early estimation.

2. Estimation Fundamentals

This chapter introduces an estimation framework to enable the reader to position estimation in project management, project control, and quality assurance. The reader will also become acquainted with the characteristic parameters of estimation.

Estimation is the foundation of viability assessment of IT projects. The tools of estimation include e.g., cost benefit analysis, Functional Size Measurement, assessment of non-functional requirements (quality requirements), and a myriad of diverse estimation methods.

The distinction between operative and strategic project management must also be made for its subtasks. Hence, there exists operative and strategic project control as well as operative and strategic estimation.

3. Prerequisites for Estimation

“Estimation must be performed in a professional manner.” You have already heard this over and over in the previous two chapters; however, the point is so important that is bears repeating: Estimating without history is simply an opinion!

Hence, estimation and the formal process to determine it must be carefully planned. When one takes into consideration that 60–99% of software defects post-production (i.e., in commercial off-the-shelf (COTS) software) can be attributed to poor requirements, one can easily digest the importance of clear requirements and estimation formality as predictors of project success. Besides that, estimating principles and assumptions must be documented for each estimate in order to make sense of the estimate itself. To provide knowledge for laying the fundamentals of estimation, this chapter discusses the information prerequisites (what MUST be known) in order to even attempt formal estimation as well as the prerequisites of the process of estimation.

4. The Implementation of Estimation

The implementation of estimation is an innovative project and as such, it must be planned and performed with as much rigor as any other formal IT project. The estimation process is the foundation for successful communication as well as for monitoring and improvement of the project management processes. As in all innovative projects, it is important to take notice of and plan for acceptance issues, that is, for resistance to occur.

In Europe, we speak of the “king’s road,” which is the means to accomplish the best outcomes. This means that the road to gain acceptance in any innovative or new endeavor consists of information, training, and participation of all involved persons. In addition, there is need for time to pass in order to foster awareness for the innovations. If this cornerstone is omitted during the implementation of an IT metrics program, then it has a good chance, as proven by 80% of all IT metrics initiatives (Dekkers 1999), to be abandoned early and without success. An IT metrics program is a strategic project and should be viewed as such. Otherwise, if the project is perceived as extra overhead, its chances of success are minimized.

5. Estimation Methods

Today, there are several popular different approaches available for estimating software project work effort and cost. These models range from overly simplistic models (that rely on straight linear equations) to incredibly complex algorithm-based models. While commercially available products promise the magic elixir to solve estimation problems, and a range of public methods state similar claims, the truth is that most are based on a variation of the same underlying principles that relate the software product size (scope), quality, technology to time constraints. Four major types of software estimating models are prevalent:

Models that require estimated technical size (Those based on source lines of code (SLOC))
Models based on early estimates of functional size (FP shortcut-based)
Models based on functional size of the software product (FSM based models)
Those based on some other sizing mechanism such as analogy or counts of screens
Hybrids of the above.

6. Estimating Maintenance Effort

Project estimation usually does not include lifetime (or even the first year) of maintenance effort. The lifetime maintenance costs, however, typically exceed the original application development effort by up to 10 times. Software maintenance is often defined as the correction or modification of a software product after delivery, to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment. Practical experience shows that IT systems live longer than expected, with the recent case-in-point being the Year 2000 conversion of applications originally intended to be replaced during the 1980s, but surviving through to the turn of the century.

It is a common practice that the costs for maintenance are accumulated during the lifetime of a system without controlling the amount and without differentiating between the different kinds of costs. Yet, the maintenance and support area can be prone to inefficiencies (i.e., cost excesses) and the lack of consistent processes, resulting in IT spending that is not only misunderstood, but many time uncontrolled.

7. Software Measurement and Metrics: Fundamentals

Software metrics are useful to measure both the process to develop and the ultimate product characteristics associated with software development. We differentiate between the word “measure” and the word “metric” (or indicator) although these terms are frequently confused in general practice.

The relevance of software and systems measurement has increased over the past decades; however, the interest in establishing a sustainable software measurement program appears to follow some sort of cyclical trend where waves of commitment surge to a frenzy at times, then wanes to barely a whisper – almost a “management flavor of the month.” In the 1960s and 1970s the focus for IT was on product evaluation in the 1980s and 1990s it was on process evaluation and quality initiatives, and changed in the 1990s to measurement process integration. Today, for measurement to succeed, it must provide a positive return on investment with a direct tie to improvement of the business (the “bottom line” finances so to speak) - not simply to the IT department.

8. Product- and Process- Metrics

Basically one distinguishes between product metrics and process metrics. The distinction is not always unambiguous since some metrics are used to evaluate both products and processes. Even so, at times, the product and processes are viewed so separately that it is almost as if there are two different worlds each with their own special scientific community. When discussing software development processes, there are several models that are representative: the waterfall model, the spiral model, prototyping, agile methods, object-oriented, and entity-based process models.

9. Object-Oriented Metrics

The object-oriented paradigm shows some peculiarities when compared with traditional software development. This is particularly apparent when one considers that object-oriented system development supports prototyping, and uses its own object-oriented programming languages and tools. In addition, there are terms specific to object-oriented development including the following:

Attributes and classes of objects: Data and its states are stored. Attributes define the data that characterize classes.
Classes with attributes and methods: These are essential factors for describing and structuring software programs. Classes define the variables and methods common to all objects of a certain class.
Cohesion: Is a measure of how logically related are the parts of an individual component (class) to each other, and to the overall component.
Coupling: Is a measure of the strength of the connection between any two system components such as classes.
Interfaces: These are lists of methods.
Inheritance: Is the process by which one object acquires characteristics from one or more other objects.
Message: Means of communication and interaction between objects.
Method: Operations that manipulate or process data.
Objects: These are instances of classes.
Object identity: Objects are unique and have a storage address.
Polymorphism: Allows a single name to be used for more than one related purpose, which is technically different.

10. Measurement Communities and Resources

Software measurement is not easy. The majority, over 80% of measurement programs, fail to deliver actual performance improvements for numerous reasons, as we outline in this book. This chapter is intended to familiarize you with useful international standards, to guide you with benchmarking and consulting resources, and to assist you to navigate the quagmire of software measurement standards and communities throughout the world.

Such standards in the area of functional size measurement have evolved and have been available for a number of years from the Geneva-based International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) joint technical committee 1, subcommittee 7: Software and Systems Engineering (ISO/IEC JTC1 SC7), especially through the standard suite of standards ISO/IEC 14143 Parts 1–6, and through a series of standards for each of the major Functional Size Measurement Method standards as listed later. The final standard in the suite is ISO/IEC 14143-6:2007 Guide to Functional Size Measurement (FSM) Usage.

11. Benchmarking of IT Projects

Metrics are ideally suited for comparing IT projects and learning by comparison. This should be the goal of benchmarking: locating one’s organizational situation and defining purposeful measures for its optimization on IT projects and finding opportunities for the organization to learn and move ahead in its project management capability.

The main question of benchmarking is how we can learn from other organizations in order to improve our own organization. In this chapter, we present concepts for benchmarking and introduce some of the publications available from the International Software Benchmarking Standards Group, ISBSG, (www.isbsg.org) and other IT benchmarking resources. Note: The ISO/IEC JTC1 SC7 standards group (see chapter on measurement organizations) approved at their Berlin plenary meeting in May 2008 a new work item (NWI) to standardize IT Project Performance Benchmarking: ISO/IEC 29155, to create an IT project benchmarking framework. This project will likely include several sub-projects and will include some form of the draft standard for a benchmarking process developed by ISBSG in 2007. Pekka Forselius of Finland is the editor of this project, with Carol Dekkers of the USA and Jacky Takahashi of Japan as project co-editors. ISBSG will participate as an active category C liaison to ISO/IEC JTC1 SC7 and the working group responsible for the project as it moves forward.

12. The IFPUG Function Point Counting Method

The IFPUG (International Function Point Users Group) Function Point Method (FPM) is a method to measure the (functional) size of software from the user perspective (depicted in Fig. 12.1).

As an ISO/IEC conformant Functional Size Measurement (FSM) method, the IFPUG FPM measures the functionality in software delivered to the user as required by the user, and quantified by following the IFPUG Counting Practices Manual (CPM) set of counting rules. Note that functional size is purely the unadjusted function point size as outlined in the following paragraphs.

The term user is not defined strictly as a person or end-user, but rather as any person, thing, other application, hardware, or software that needs to interact (send to or receive data from) with a piece of software. This is consistent with the term actor in object-oriented or use case technology.

13. Functional Size Measurement Methods (FSMMs)

There are currently five different ISO/IEC Functional Size Measurement Method standards, four of which are outlined in this chapter, plus the IFPUG method (unadjusted), which was described in an earlier chapter. Additionally, there are variants of the IFPUG method and also of other methods that purport to measure the size of software. For convenience of the reader, the ISO/IEC standards are included here, and the other sizing measures are included in the chapter “Variants of the IFPUG Function Point Counting Method.”

Functional Size Measurement is a term coined by the International Organization for Standardization/International Electrotechnical Commission (ISO/ IEC) in its suite of standards numbered 14143-1 through 14143-6. The definition and framework standard of the series is ISO/IEC 14143-1 Software and Systems Engineering – Software Measurement – Functional Size Measurement – Definition of concepts. This standard was most recently updated and published in 2007, replacing the first published version in 1998. Note that ISO/IEC standards have a lifespan of 5 years from the date of publication, after which they must be reviewed by ISO/IEC to ensure ongoing relevance. ISO/ IEC working groups can then reaffirm a standard as it is, withdraw it, or update it (and a new work item proposal is launched to revise it). The 14143-1: 2007 standard reaffirmed the standard and then republished it via an ISO-specific process called a technical corrigendum to correct minor technical defects and editorial defects.

14. Variants of the IFPUG Function Point Counting Method

There are a number of variants of the IFPUG Function Point method in different countries. This chapter provides an overview of some of these variants.

The IFPUG FP method is an ISO/IEC standard (the ISO standard currently at the time of printing is ISO/IEC 20926 IFPUG 4.1 unadjusted Function Point Counting Method). In addition, there are four additional functional size measurement methods (FSMMs) recognized by ISO/IEC, each of which uses its own approach to measure a piece of software’s functional size. These FSMMs are identified and described in further detail in the previous Chapter Functional Size Measurement Methods.

15. Using Functional Size Measurement Methods

This chapter presents different approaches and experiences in the practical use of Functional Size Measurement. We begin with a report about experiences of an organization that was able to develop a Function Point Prognosis and present related information from other organizations about early Function Points, also called Function Point estimation or FP proposals.

This is only one example presented here since other organizations did similar research. There is strong evidence that different environments lead to different results. This means that each organization should develop its own heuristic solution(s). Nevertheless, comparisons with other organizations are valuable for the enterprise.

16. Estimation of Data Warehouses, Web-Based Applications: Software Reuse and Redevelopment

Data Warehouse and Web-based application development are an increasing part of modern software development, but are different from conventional software development in that they typically involve considerations of software reuse and redevelopment.

These topics give rise to questions of how to measure the software size on data warehouse developments and how to estimate effort when reuse and redevelopment is involved. That is why this chapter deals with the special aspects of sizing Data Warehouses and Web-based application development, as well as work effort estimating with special consideration to software reuse and redevelopment.

17. IFPUG Function Point Counting Rules

This chapter comprises the most important definitions and rules (without the hints, examples and further explanations) of the Counting Practices Manual (CPM) of the IFPUG Release 4.2, for example, the definitions for type of count and system boundary, the counting rules for the files (ILF, EIF) and transactions (EI, EO, EQ), as well as for the 14 GSCs. There is intentionally some redundancy with the chapter about “The IFPUG Function Point Counting Method” in order to increase readability. This chapter focuses more on the technical rule details, while Chap. 11 is aimed to provide an overview.

As of 2009, IFPUG plans to publish its core manual of counting rules in conjunction with ISO/IECs routine 5 year maintenance cycle for all ISO/IEC international standards, and publish a separate document that includes the rule interpretations and examples of how to apply them in practice. IFPUG 4.2 and earlier releases of the CPM were published as an all-inclusive document (sometimes supplemented by interim white papers) and the size was an unwieldy 300+ pages of rules, rule interpretations, examples, exceptions, etc., all interspersed in a single tome. The new strategy of publishing the Function Point Counting rules as an independent and standalone document (which will also be the ISO/ IEC standard) of less than 50 pages will streamline the understanding and, hopefully, the dissemination and widespread use of the IFPUG method.

18. Functional Size Measurement Case Studies

This chapter presents a set of functional user requirements, together with the results of applying the five ISO/IEC-conformant Functional Size Measurement Methods (FSMMs) to determine the functional size of the software.

This chapter starts with the presentation of the functional requirements of the Course Registration case study and the according use case diagram in the first two sections, followed by functional size measurement of the requirements in the following order: COSMIC, FiSMA, IFPUG, Mark II, NESMA, and a concluding comparison.

19. Functional Size Measurement: Additional Case Studies

This chapter provides three additional examples of Functional Size Measurement applied to functional user requirements COSMIC (one case study: Valve Control System); and IFPUG (two case studies: Function Point Calculator, Training Administration Application).

20. Tools for Estimation

A method without tool support has little chance for survival, and will encounter extra resistance for widespread use. The investment in the right tool suited for estimation for your organization can bring benefit for the organization without any doubt, even if the benefit cannot be measured exactly. But, first a warning: “A fool with a tool is still a fool!”

This proverb teaches us that information and training in estimation are a necessary prerequisite for the success of a metrics initiative. The first lesson to be imparted in training for the project leaders is that the tool does not do their job of estimation. The same premise holds true with estimation tools as it is with project management tools: estimating tools must be “fed” with good estimating parameters in order to generate realistic estimates; project management tools do not replace the planning process (which has to be done in the head of a project leader) – it only supports the outcome once the planning parameters have been entered. In the same manner as school children must learn their times tables before they can make effective use of a calculator (especially to be able to detect a wrong answer), project leaders must understand the concepts of software estimation before using a tool for its support.

Backmatter

Titel: The IT Measurement Compendium
verfasst von: Manfred Bundschuh
Carol Dekkers
Verlag: Springer Berlin Heidelberg
Electronic ISBN: 978-3-540-68188-5
Print ISBN: 978-3-540-68187-8
DOI: https://doi.org/10.1007/978-3-540-68188-5