IFPUG Function Point Counting Practices (2010)

Function Point Counting Practices Manual Release 4.3.1 International Function Point Users Group (IFPUG) Function Point...

Author: IFPUG

57 downloads 1556 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Function Point Counting Practices Manual Release 4.3.1

International Function Point Users Group (IFPUG) Function Point Counting Practices Manual Release 4.3.1

Chairperson, Counting Practices Committee Adri Timp Equens SE, Netherlands [email protected]

© 2010 IFPUG. All Rights Reserved. International Function Point Users Group, 2010. Members of IFPUG may reproduce portions of this document within their internal counting practices manuals. If portions of this document are used, the following text must appear on the title page of the derivative document: "This document contains material that has been extracted from the IFPUG Counting Practices Manual. It is reproduced in this document with permission of IFPUG." ISBN 978-0-9753783-4-2

Release 4.3.1, January 2010 This release replaces Release 4.2.1, which is now obsolete. Changes are made periodically to the information within.

Counting Practices Committee

Bonnie S. Brown, EDS an HP Company Royce Edwards, Software Composition Technologies E. Jay Fischer, JRF Consulting, Inc. David Garmus, The David Consulting Group Janet Russac, Software Measurement Expertise, Inc. Adri Timp, Equens SE, Netherlands Peter Thomas, Steria

For information about additional copies of this manual, contact IFPUG 191 Clarksville Road Princeton Junction, NJ 08550 U.S.A. (609) 799-4900 E-mail: [email protected] Web: http://www.ifpug.org

The IFPUG FSM method as reflected in this manual finds it origin in CPM 4.0, released in 1990. Many individuals have served as members on the CPC over the years, and they sharpened each other’s vision and insight through numerous and complex discussions about the methodology. Thanks to the contribution of all of the current and past members, the method has evolved to the current ISO FSM standard. The CPM is an accumulation of the contributions of all who have served on the CPC. The CPC has been blessed as well by the support and contribution of our Counting Standards Directors, including Carol Dekkers, Bruce Rogora and Mary Bradley, and the effort by Carol Dekkers in advancing both ISO documents through the process to gain approval. IFPUG extends our appreciation to all current and past CPC members, Counting Standards Directors and ISO Representatives.

Current and Past CPC Members Allan Albrecht, FPA Founder Kim Albee (CPM 4.0) Maarten Barth (CPM 4.0) Andy Belden (CPM 4.0) Angela Benton (CPM 4.1) Mary Bradley (CPM 4.0, CPM 4.1, Past Chair) Bonnie Brown (CPM 4.2, CPM 4.3, Vice Chair) Kevin Chinoy (CPM 4.1) Jean-Marc Desharnais (CPM 4.0) Rob Donnellan (CPM 4.0) Ian Drummond (CPM 4.0) Martin D'Souza (CPM 4.2, CPM 4.3) Boyd Edmiston (CPM 4.0) Royce Edwards (CPM 4.3) Peter Fagg (CPM 4.1) Jay Fischer (CPM 4.2, CPM 4.3) Sean Furey (CPM 4.1) Steve Galea (CPM 4.1) Barbara Gardner (CPM 4.0) David Garmus (CPM 4.0, CPM 4.1, CPM 4.2, CPM 4.3) Jim Glorie (CPM 4.1, CPM 4.2) Paul Goodman (CPM 4.0) Phil Hain (CPM 4.0) David Herron (CPM 4.0) Steve Hone (CPM 4.2) Bob Huckaby (Past Chair) Valerie Marthaler (CPM 4.1, CPM 4.2, CPM 4.3, Past Chair) Frank Mazzucco (CPM 4.0) Pam Morris (CPM 4.0, CPM 4.1, CPM 4.2) Jolijn Onvlee (CPM 4.0, CPM 4.1) Bruce Paynter (CPM 4.2) Dave Phillips (CPM 4.1) Ben Porter (CPM 4.0, Past Chair) Robin Ragland (CPM 4.0, CPM 4.1, Past Chair) Roger Roy (CPM 4.0) Eberhard Rudolph (CPM 4.0) Grant Rule (CPM 4.1)

Past CPC Members (cont.) Bill Rumpf (CPM 4.0) Janet Russac (CPM 4.3) Michael Schooneveldt (CPM 4.0, CPM 4.1) Linda Smith (CPM 4.0, Past Chair) Jack Sprouls (CPM 4.0) Denis St. Pierre (CPM 4.0, CPM 4.1) Peter Thomas (CPM 4.3) Koni Thompson (CPM 4.1, CPM 4.2) Adri Timp (CPM 4.1, CPM 4.2, CPM 4.3, Chair) Tony Tiongson (CPM 4.0) Stephen Treble (CPM 4.1) Eddy van Vliet (CPM 4.1, CPM 4.2, CPM 4.3) Terry Vogt (CPM 4.2) Gary Walker (CPM 4.0, CPM 4.1) Ewa Wasylkowski (CPM 4.0, CPM 4.1)

This page intentionally left blank.

Table of Contents

Part 1

Preface

iii

Introduction to the Counting Practices Manual

vii

FSM Forword

i

Introduction

iii

Chapter 1

Scope………………………………………………...........

1

Chapter 2

Normative References …………………………...........

1

Chapter 3

Terms and Definitions …………………………...........

1

Chapter 4

Abbreviated Terms …………………………................

8

Chapter 5

Measurement Process…………………………………..

8 A-1

Annex A

Part 2

The Bridge - Applying the IFPUG Functional Size Measurement Method Chapter 1

Introduction………………………………………………..

1-1

Chapter 2

IFPUG FSM Method Overview………..…………..........

2-1

Chapter 3

Gather Available Information…………………………..

3-1

Chapter 4

Determine Type of Count……………………………….

4-1

Chapter 5

Determine Counting Scope and Application Boundaries

5-1

Chapter 6

Measure Data Functions…………………………………...

6-1

Chapter 7

Measure Transactional Functions………………………..

7-1 i-1

Index

January 2010

Function Point Counting Practices Manual

i

Table of Contents

Part 3

Counting Practices 1-1

Introduction Chapter 1

Code Data………………………………………………….

1-3

Chapter 2

Logical Files……………………………..………….........

2-1

Chapter 3

Shared Data………………………………………………..

3-1

Chapter 4

Enhancement Projects and Maintenance Activities..

4-1

Chapter 5

Data Conversion Activity………………………………..

5-1 i-1

Index

Part 4

Examples 1-1

Introduction Chapter 1

Data Function Counting Examples…..………………...

1-3

Chapter 2

Transactional Function Counting Examples ..………

2-1 i-1

Index

Part 5

Appendices and Glossary Appendix A

Functional Size Calculation Table……………………..

A-1

Appendix B

The Change from Prior Version…..…...……………….

B-1

Appendix C

Adjusted Functional Size…....……..…………..............

C-1 G-1

Glossary

ii

Function Point Counting Practices Manual

January 2010

Preface Introduction

The use of function points, as a measure of the functional size of software, has grown in the past decade from a few interested organizations to an impressive list of organizations worldwide.

IBM CIS & A Guidelines 313

In the late 1970s, Allan Albrecht of IBM defined the concepts that enabled measuring the output of software development projects. These definitions were extended in IBM CIS & A Guideline 313, AD/M Productivity Measurement and Estimate Validation, dated November 1, 1984.

Release 2.0

With the growth in the use of function points, there was wider and wider application of the measure. This broadening of the application tested the original description of the measure and made it necessary to create guidelines to interpret the original rules in new environments. This was reflected in Release 2.0 (April 1988) of the International Function Point Users Group (IFPUG) Function Point Counting Practices Manual.

Release 3.0

Release 3.0 (April 1990) of the IFPUG Function Point Counting Practices Manual was a major milestone in the evolution of functional size measurement. For the first time, the IFPUG Counting Practices Committee made an effort to change the document from a collection of many interpretations of the rules to a truly coherent document that represented a consensus view of the rules of function point counting. In this sense, it was the first step to truly establishing standards for function point measurement which could be applied across organizations.

January 2010

Function Point Counting Practices Manual

iii

Preface

Release 4.0

Release 4.0 (January 1994) was the next milestone in the evolution of functional size measurement. This release reflected the use of function points early in project development to estimate project size using information engineering disciplines. The rapidly increasing number of graphical user interface (GUI) windows applications mandated that we include GUI counting in the release. Because more counting was occurring across a wider variety of situations, the release placed an emphasis on interpreting and practicing using the counting rules. Examples were included throughout the documentation and case studies supplemented the material. Finally, release 4.0 continued to clarify and increase the consistency of function point counting.

Release 4.1

Release 4.1 (January 1999) provided clarifications to existing rules, new or amended rules which address previously undocumented situations and new hints and examples to aid understanding. The IFPUG Counting Practices Committee has reviewed and processed requests from members, following the Manual Revision Process contained in Chapter 1 of this manual. The revisions included in 4.1 clarify: •

the identification of a user, an elementary process, and control information

•

the differentiation between External Outputs (EOs) and External Inquiries (EQs)

•

the identification of Data Element Types (DETs) and Record Element Types (RETs) for data functions

•

the identification of Data Element Types (DETs) for transactional functions

Release 4.1 continues the process of clarifying and improving the consistency of function point counting. Finally, with the exception of the 14 General Systems Characteristics, it was designed to be compliant with existing ISO standards if and when any compliance guide becomes a standard. Release 4.1.1 Release 4.1.1 (April 2000) corrected a small number of typos and errors.

iv

Function Point Counting Practices Manual

January 2010

Preface

Release 4.2

Release 4.2 (January 2004) does not modify any previously promulgated rules, but it provides clarification and enhanced interpretations for existing rules that will further increase inter-counter consistency. The IFPUG function point analysis (FPA) process and rules are concise and easy to use. To reflect that, and to make the Counting Practices Manual (CPM) even more attractive as a reference manual, the Counting Practices Committee (CPC) decided to restructure CPM 4.2 into four parts: 1. Process and Rules 2. Counting Practices 3. Examples 4. Appendices To assist worldwide practitioners of FPA in a timely manner, the CPC initially published the results of its research as separate publications, addendums to the CPM: • Counting Logical Files (September 2001) • FPA in an Enhancement Environment (April 2002) • Counting Code Data (September 2003) • Counting Shared Data (September 2003) These documents have now been incorporated as chapters in Part 2 of the CPM. The CPC believes that CPM 4.2, with its added guidelines and examples will ensure more consistent results between Certified Function Point Specialists.

Release 4.2.1 Release 4.2.1 (January 2005) Corrected a small number of typographical errors. Release 4.3

Release 4.3 (January 2010) The IFPUG function point analysis (FPA) process and rules are concise and easy to use. To reflect that, and to make the Counting Practices Manual (CPM) even more attractive as a reference manual, the Counting Practices Committee (CPC) restructured CPM 4.3 to comply with ISO formatting Standards. Besides that, release 4.3 contains minor modifications and provides new examples, clarification and enhanced interpretations for existing rules that will further increase inter-counter consistency. The CPC believes that CPM 4.3, with its new format and examples will ensure more consistent results among Certified Function Point Specialists.

Release 4.3.1 Release 4.3.1 (January 2010) Corrected a number of printing errors and incorporated ISO editorial revisions.

January 2010

Function Point Counting Practices Manual

v

Preface

Future Releases

This document is meant to be a living one. We must recognize how to count new environments as they are introduced. We need to be able to do this in the context of maintaining the validity of the counts we have already made. This will not be an easy task, yet it is an essential one if we are to be able to measure the progress we are making in delivering value to the users and to the organizations they represent. The Counting Practices Committee wishes to thank all those who have helped us in our research and in the production of this manual. Adri Timp Chairperson, Counting Practices Committee

vi

Function Point Counting Practices Manual

January 2010

Introduction to the Counting Practices Manual Introduction

This introduction defines the objectives of the manual and the revision process. It also describes publications that are related to this manual.

Contents

This chapter includes the following sections: Topic Objectives of the Counting Practices Manual

January 2010

See Page viii

Documents Used for Release 4.3

viii

Intended Audience

ix

Organization of the Counting Practices Manual

x

Manual Revision Process

xi

Frequency of Changes

xi

Change Process

xi

Related IFPUG Documentation

xiii

Training Requirements

xv

Function Point Counting Practices Manual

vii

Introduction to the Counting Practices Manual

Objectives of the Counting Practices Manual The primary objectives of the IFPUG Counting Practices Manual, Release 4.3, are to •

Comply with ISO/IEC 14143-1:2007 Information technology – Software measurement – Functional size measurement – Definition of concepts

•

Provide a clear and detailed description of function point counting

•

Ensure that counts are consistent with the counting practices of IFPUG affiliate members

•

Provide guidance to allow function point counting from the deliverables of popular methodologies and techniques

•

Provide a common understanding to allow tool vendors to provide automated support for function point counting

Documents Used for Release 4.3 The following documentation was used to develop this release: •

The IFPUG FPA method is based on IBM CIS & A Guideline 313, AD/M Productivity Measurement and Estimate Validation, dated November 1, 1984. The function point counting methodology described in 313 is generally referred to as Albrecht 1984.

•

The current version of the manual, CPM 4.3, is based primarily on the IFPUG Function Point Counting Practices Manual, Release 4.2.1.

•

CPM 4.3 is designed to be compliant with ISO/IEC 14143-1:2007 Information technology – Software measurement – Functional size measurement – Definition of concepts.

•

“Framework for Functional Sizing”; this IFPUG paper explains that product size contains three dimensions: functional size, technical size and quality size. The IFPUG FPA-method provides a measure for the functional size.

•

Issues not sufficiently covered in the sources listed above were decided by the IFPUG Counting Practices Committee based on variants of existing counting practices and validated through impact studies.

With its release, this manual should be considered the IFPUG standard for function point counting. It is imperative that each IFPUG member take an active role to ensure counting consistency. IFPUG member adherence to this standard will contribute greatly to counting consistency.

viii

Function Point Counting Practices Manual

January 2010

Introduction to the Counting Practices Manual

Intended Audience The standard in this manual should be applied by anyone using function point analysis for functional size measurement. The manual was designed for use by persons new to functional size measurement as well as those with intermediate and advanced experience.

January 2010

Function Point Counting Practices Manual

ix

Introduction to the Counting Practices Manual

Organization of the Counting Practices Manual There are five major parts in the Counting Practices Manual (CPM): • Part 1: FSM-IFPUG functional size measurement method • Part 2 The Bridge - Applying the IFPUG Functional Size Measurement Method • Part 3: Counting Practices • Part 4: Examples • Part 5 Appendices and Glossary Part 1 – FSM Part 1 is the IFPUG functional size measurement method which contains the rules. To speak a language as a native, learning the grammar and the words alone are not sufficient. They just provide a framework. You need language experience to understand how the language is spoken in practice, how the grammar rules should be applied, what idiomatic expressions are common, and so on. The same is true for FPA. The knowledge of process and rules: as reflected in Part 1, is a necessity, but the knowledge alone is not a sufficient condition to apply FPA correctly. That’s why the CPM contains the parts below. Part 2 – The Bridge Part 2 provides guidance for sizing software following the IFPUG functional size measurement (FSM) Method, included as Part 1 of this IFPUG Function Point Counting Practices Manual. Part 3 – Counting Practices and Part 4 -Examples. Part 3 and 4 provide detailed examples to explain counting practices concepts and rules. Each example should be considered on its own merits. Since each example is intended to illustrate a specific scenario, variations may exist between examples. Although the examples throughout the manual deal with similar subject matter, they are not intended to represent a single set of user requirements. Part 5 – Appendices and Glossary Part 5 contains valuable additional information, such as ready to use calculation templates, the transition from CPM 4.2 (and CPM 4.2.1) to CPM 4.3, the General Systems Characteristics and the glossary. In principle, each part stands on its own.

x

Function Point Counting Practices Manual

January 2010

Introduction to the Counting Practices Manual

Manual Revision Process This section explains the frequency of changes to the Counting Practices Manual and defines the change process.

Frequency of Changes During January of each year, a new version of the Counting Practices Manual may become effective. It will include any new or changed definitions, rules, or counting practices that have been finalized by the Counting Practices Committee (CPC) since the previous version.

Change Process The following activities outline the process for adding or changing information in the Counting Practices Manual. Explanations of each activity follow the table. Step

Action

1

The issue is submitted to the CPC.

2

The issue is assigned for research.

3

The CPC reviews and discusses the issue.

4

The CPC presents a proposed solution to the IFPUG membership.

5

An impact study is initiated if the proposed change would have any impact on existing counts.

6

The final decision is made.

7

The IFPUG membership is informed of the decision.

8

Changes become effective with, and are reflected in, the next release of the Counting Practices Manual.

Issue Submitted

The reader submits ideas, changes, or issues to the Counting Practices Committee by sending email to [email protected] or [email protected]

Research Assigned

A member of the CPC is assigned the responsibility for identifying all alternatives, the rationale, and the potential impact of each alternative if it is implemented. Thorough examination of existing counting standards and historical papers is completed while compiling alternatives. In addition, an effort is made to determine what is thought to be common practice.

January 2010

Function Point Counting Practices Manual

xi

Introduction to the Counting Practices Manual

CPC Review

The CPC reviews and discusses the rationale for each alternative, and its potential impact. The review and discussion may result in a proposal for change or the review may lead the committee to reject the change request.

Solution Proposed

A proposed solution is made to the IFPUG membership and written comments are solicited. A copy of the proposed changes is mailed to IFPUG contacts at member organizations. The proposal also may be announced and distributed during an IFPUG conference. The latter depends on the timing of the committee meeting rather than the conference schedule.

Impact Study The CPC has adopted a conservative stance on initiating impact studies. If it is possible that common practice must change, or several organizations or Initiated types of applications will be impacted by the change, an impact study is initiated. The success of the impact study is the responsibility of every IFPUG member. If the CPC receives written feedback indicating there is little or no impact, the study is discontinued. Final Decision Made

The committee makes a final decision using results from research, written comments from members, and the impact study. The committee can complete more than one iteration of Steps 2 through 5 (research through impact study) before making a final decision. The final decision can result in a change or the committee may decide that a change is not warranted.

Decision Communicated

The final decision is communicated in writing to IFPUG members via the IFPUG contact at the various organizations.

Decision Effective Date

The Counting Practices Manual is updated to reflect the decisions. The effective date of the decisions is the date of the next January release of the manual.

xii

If any impact study results contributed to making a decision, the results and a recommendation on how to minimize the impact of the change will also be communicated.

Function Point Counting Practices Manual

January 2010

Introduction to the Counting Practices Manual

Related IFPUG Documentation This Counting Practices Manual is one module in the IFPUG documentation. All documents complement each other. The following table describes the other publications. Document

Description

IFPUG Brochure

This publication is an introduction to the International Function Point Users Group. It includes a brief history of the organization, introduces function point analysis, and defines the purpose of IFPUG. The brochure also includes a membership application.

(Available)

Audience: This publication is for anyone who wants an overview of IFPUG or an application for membership. IFPUG: Organizational Structure and Services

This publication describes IFPUG services, and lists the board of directors, committees, and affiliate members worldwide.

(Available)

Audience: This publication is for anyone who wants background information about IFPUG.

Guidelines to Software Measurement

This manual provides an overview of software metrics for organizations working to create or improve software measurement programs. The manual addresses both system and customer management, provides high-level justifications for software measurement, and examines the components of effective measurement programs.

(Release Date: August 2004)

Audience: This manual is intended for IFPUG members, Function Point Coordinators, persons who prepare the reports to management, and other persons knowledgeable about and working directly with function points. Quick Reference Counting Guide

This quick reference guide is a summary of function point counting rules and procedures.

(Release Date: 2010)

Audience: This summary information is intended for anyone applying function point analysis.

Adjusted Functional Size Quick Reference Guide

This quick reference guide is a summary of the General Systems Characteristics.

(Release Date: 2010)

Audience: This is intended for anyone using the optional General Systems Characteristics.

January 2010

Function Point Counting Practices Manual

xiii

Introduction to the Counting Practices Manual

Document

Description

Function Point Analysis Case Studies

The case studies illustrate the major counting techniques that comprise the Function Point Counting Practices Manual. The cases illustrate function point counts for a sample application. The cases include the counting that occurs at the end of the analysis phase of software development and after system construction.

(Release Dates: Case Study 1 Release 3.0 September 2005 (CPM 4.2) Case Study 2 Release 3.0 March 2006 (CPM 4.2)

Audience: The case studies are intended for persons new to function point analysis as well as those with intermediate and advanced experience.

Case Study 3 Release 2.0:September 2001 (CPM 4.1) Case Study 4 Release 2.0 September 2005 (CPM 4.2) IFPUG Glossary (Available with CPM and Guidelines for Software Measurement)

This is a comprehensive glossary that defines terms used across IFPUG publications. Audience: The glossary is recommended for anyone who receives any of the other IFPUG documents or anyone who needs definitions of IFPUG terms.

“A Framework for Functional Sizing”, IFPUG, September 2003

This paper explains that product size contains three dimensions: functional size, technical size and quality size. The IFPUG FPA-method provides a measure for the functional size.

“IT Measurement: Practical Advice from the Experts”, Addison-Wesley, April 2002

This book is an excellent compilation of articles written by experts in the field of Information Technology. It was compiled by IFPUG to include recent insights in the application of software metrics in practice.

xiv

Function Point Counting Practices Manual

January 2010

Introduction to the Counting Practices Manual

Training Requirements Usability evaluations of this publication have verified that reading the Counting Practices Manual alone is not sufficient training to apply function point counting at the optimum level. Training is recommended, particularly for those new to function point counting. Note: For function point training, be sure you are trained using IFPUG certified materials. Call the IFPUG Executive Office at 609-799-4900 for a list of instructors with certified training courses. In addition to the function point specific information, this manual includes the use of structured analysis and design terms, such as business systems and entity. The glossary includes definitions of these terms, but the Counting Practices Manual does not include detailed explanations of structured analysis and design techniques. Therefore, all of the material will not apply or be helpful if you have not been trained in structured analysis and design techniques.

January 2010

Function Point Counting Practices Manual

xv

Introduction to the Counting Practices Manual

This page intentionally left blank.

xvi

Function Point Counting Practices Manual

January 2010

Part 1 - FSM

This page intentionally left blank.

Part 1 – FSM

Contents

Contents Foreword ................................................................................................................................................ii Introduction ..........................................................................................................................................iii 1 1.1 1.2 1.3 1.4

Scope.........................................................................................................................................1 Purpose.....................................................................................................................................1 Conformity ................................................................................................................................1 Applicability..............................................................................................................................1 Audience ...................................................................................................................................1

2

Normative references ..............................................................................................................1

3

Terms and definitions..............................................................................................................1

4

Abbreviated terms....................................................................................................................8

5 5.1 5.2 5.3

Measurement Process .............................................................................................................8 Overview ...................................................................................................................................8 Gather the available documentation ......................................................................................9 Determine the counting scope and boundary and identify Functional User Requirements ...........................................................................................................................9 Measure data functions .........................................................................................................10 Overview .................................................................................................................................10 Identify and group all logical data into data functions ......................................................10 Classify each data function as either an ILF or an EIF ......................................................11 Count DETs for each data function......................................................................................11 Count RETs for each data function......................................................................................12 Determine the functional complexity for each data function ............................................13 Determine the functional size for each data function ........................................................13 Measure transactional functions..........................................................................................13 Overview .................................................................................................................................13 Identify elementary processes .............................................................................................14 Classify each elementary process as a transactional function ........................................16 Count FTRs for each transactional function .......................................................................18 Count DETs for each transactional function.......................................................................18 Determine the functional complexity for each transactional function .............................19 Determine the functional size of each transactional function ..........................................19 Measure conversion functionality........................................................................................19 Measure enhancement functionality....................................................................................20 Calculate functional size .......................................................................................................20 Document the function point count .....................................................................................21 Report the result of the function point count......................................................................22

5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.5 5.5.1 5.5.2 5.5.3 5.5.4 5.5.5 5.5.6 5.5.7 5.6 5.7 5.8 5.9 5.10

Annex A (informative) Consolidated complexity and functional size tables.................................23

January 2010

Function Point Counting Practices Manual

i

Foreword

Part 1 – FSM

Foreword ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. International Standard ISO/IEC 20926 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee SC 7, Software and Systems Engineering. This second edition cancels and replaces the first edition (20926: 2004) in its entirety which has been technically revised.

ii

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

Introduction

Introduction The use of function points, as a measure of the functional size of software, has grown since the mid 1970s from a few interested organizations to an impressive list of organizations worldwide. Allan Albrecht was the first to publicly release a method for functionally sizing software called function point analysis. With the growth in the use of function points, there has been wider application and use of the measure. Since its formation in 1986 the International Function Point Users Group (IFPUG) has continuously enhanced the original Albrecht method for functionally sizing software. This International Standard is the latest release in the continually improving IFPUG method that promotes the consistent interpretation of functional size measurement in conformance with ISO/IEC 14143-1:2007. The IFPUG functional size measurement method is known as function point analysis and its units of functional size are called Function Points. Organizations can apply this International Standard to measure the size of a software product to: ⎯ support quality and productivity analysis; ⎯ estimate cost and resources required for software development, enhancement and maintenance; ⎯ provide a normalization factor for software comparison; ⎯ determine the size of a purchased application package by functionally sizing all the functions included in the package; ⎯ assist users in determining the benefit of an application package to their organization by functionally sizing functions that specifically match their requirements. Function point analysis measures software by quantifying the tasks and services (i.e., functionality) that the software provides to the user based primarily on logical design. The objectives of function point analysis are to measure: ⎯ functionality implemented in software, that the user requests and receives; ⎯ functionality impacted by software development, enhancement and maintenance independently of technology used for implementation. The process of function point analysis is: ⎯ simple enough to minimize the overhead of the measurement process; ⎯ a consistent measure among various projects and organizations. In order to effectively apply this International Standard, persons can be formally trained in the method using IFPUG Certified course materials.

January 2010

Function Point Counting Practices Manual

iii

Introduction

Part 1 – FSM

This document is one component in the IFPUG publications. It is recommended that this document be read in conjunction with the other IFPUG publications. These provide guidance to application of the rules described within this International Standard and background information to aid in understanding the use and applicability of the resulting functional size. Supporting IFPUG publications include the following: ⎯ The current version of the IFPUG Counting Practices Manual, which incorporates this International Standard supplemented with counting practices and examples that support its implementation; ⎯ “Framework for Functional Sizing”, 2005, which discusses the contribution of both functional size and non-functional size to the overall software product size; the IFPUG FSM method is a method for measuring the functional size; ⎯ IFPUG website at www.ifpug.org.

iv

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

1

1 Scope

Scope

1.1 Purpose This International Standard specifies the set of definitions, rules and steps for applying the IFPUG functional size measurement (FSM) method.

1.2 Conformity This International Standard is conformant with all mandatory provisions of ISO/IEC 14143-1:2007.

1.3 Applicability This International Standard can be applied to all functional domains. NOTE: domains.

IFPUG continues to publish white papers providing guidelines for use in evolving environments and

This International Standard is fully convertible to prior editions of IFPUG sizing methods. IFPUG function point analysts have identified different delivery rates (hours to deliver a function point) related to building applications in different functional domains calibrated for varying project sizes and software complexities.

1.4 Audience This International Standard can be applied by anyone requiring a measurement of functional size. Persons experienced with the method will find this document to be a useful reference.

2

Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISO/IEC 14143-1:2007, Information technology — Software measurement — Functional size measurement — Part 1: Definition of concepts

3

Terms and definitions

3.1 adaptive maintenance modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment NOTE Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which a software product must operate. These changes are those that must be made to keep pace with the changing environment. For example, the operating system might be upgraded and some changes may be made to accommodate the new operating system. [ISO/IEC 14764:2006 Software engineering – Software life cycle processes – Maintenance, definition 3.1]

January 2010

Function Point Counting Practices Manual

1

3 Terms and definitions

Part 1 – FSM

3.2 application cohesive collection of automated procedures and data supporting a business objective; it consists of one or more components, modules, or subsystems EXAMPLES accounts payable, accounts receivable, payroll, procurement, shop production, assembly line control, air search radar, target tracking, weapons firing, flight line scheduling and passenger reservations.

3.3 application functional size measure of the functionality that an application provides to the user, determined by the application function point count 3.4 application function point count activity of applying this International Standard to measure the functional size of an application 3.5 arranging activity of sequencing attributes in a transactional function 3.6 associative entity type entity type that contains attributes which further describe a many-to-many relationship between two other entity types 3.7 attributive entity type entity type that further describes one or more attributes of another entity type 3.8 base functional component BFC elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes EXAMPLES A Functional User Requirement could be “Maintain Customers” which might consist of the following BFCs: “Add a new customer”, “Report Customer Purchases”, and “Change Customer Details”. Another example might include a collection of logically related business data maintained by the software under study such as “Customer Details”. There are many other examples. [ISO/IEC 14143-1:2007, definition 3.1]

3.9 boundary conceptual interface between the software under study and its users [ISO/IEC 14143-1:2007, definition 3.3] NOTE

Prior versions of this International Standard used the term application boundary.

3.10 consistent state point at which processing has been fully executed; the Functional User Requirement has been satisfied and there is nothing more to be done EXAMPLE 1 The Functional User Requirement is to print a check and mark the appropriate account as paid. If only part of the Functional User Requirement is completed (e.g., only printing the check or only marking it as paid), the application is not in a consistent state. The printing of a check without marking the account as paid causes an inconsistency in the application as does marking it as paid without printing it.

2

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

3 Terms and definitions

EXAMPLE 2 The Functional User Requirement is to have a batch process that accepts an input file to update a data store, produce a production control report and return an error report back to the sending application. The process is not in a consistent state unless all of these parts are completed. EXAMPLE 3 The Functional User Requirement is to transfer an employee to a new job and validate his/her security clearance level. To complete this, a real-time request is sent to the security application (which maintains government security clearances and not application security) and a response received before the transfer can be completed. All steps are needed to create a consistent state. The interaction with the security application is not an independent step or action. It does not happen in and of itself, and the transaction to transfer an employee is not in a consistent state without it.

3.11 control information data that influences an elementary process by specifying what, when or how data is to be processed 3.12 conversion functionality transactional or data functions provided to convert data and/or provide other user specified conversion requirements NOTE

Conversion functionality exists only during the development or enhancement of an application.

3.13 corrective maintenance reactive modification of a software product performed after delivery to correct discovered problems NOTE

The modification repairs the software product to satisfy requirements.

[ISO/IEC 14764:2006 Software engineering – Software life cycle processes – Maintenance, definition 3.2]

3.14 counting scope set of Functional User Requirements to be included in the function point count 3.15 Data Element Type DET unique, user recognizable, non-repeated attribute 3.16 data function functionality provided to the user to meet internal or external data storage requirements NOTE

A data function is either an Internal Logical File or an External Interface File.

3.17 derived data data created as a result of processing that involves steps, other than or in addition to, direct retrieval and validation of information from data functions 3.18 development project project to develop and deliver the first release of a software application 3.19 development project functional size measure of the functionality provided to the users with the first release of the software, as measured by the development project function point count NOTE

The functional size of a development project may include the size of conversion functionality.

January 2010

Function Point Counting Practices Manual

3

3 Terms and definitions

Part 1 – FSM

3.20 development project function point count activity of applying this International Standard to measure the functional size of a development project 3.21 elementary process smallest unit of activity that is meaningful to the user 3.22 enhancement project project to develop and deliver adaptive maintenance NOTE An enhancement project can also develop and deliver corrective and perfective maintenance, but these do not contribute to the enhancement project functional size.

3.23 enhancement project functional size measure of the functionality added, changed or deleted at the completion of an enhancement project, as measured by the enhancement project function point count NOTE

The functional size of an enhancement project can include the size of conversion functionality.

3.24 enhancement project function point count activity of applying this International Standard to measure of the functional size of an enhancement project 3.25 entity dependent entity that is not meaningful or is not significant to the business, in and of itself without the presence of other entities such that —

an occurrence of entity X must be linked to an occurrence of entity Y, and

—

the deletion of an occurrence of entity Y results in the deletion of all related occurrences of entity X.

3.26 entity independent entity that is meaningful or significant to the business, in and of itself without the presence of other entities 3.27 External Input EI elementary process that processes data or control information sent from outside the boundary NOTE

An External Input is a type of base functional component.

3.28 External Inquiry EQ elementary process that sends data or control information outside the boundary NOTE

4

An External Inquiry is a type of base functional component.

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

3 Terms and definitions

3.29 External Interface File EIF user recognizable group of logically related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application NOTE

An External Interface File is a type of base functional component.

3.30 External Output EO elementary process that sends data or control information outside the boundary and includes additional processing logic beyond that of an External Inquiry NOTE

An External Output is a type of base functional component.

3.31 File Type Referenced FTR data function read and/or maintained by a transactional function 3.32 functional complexity specific complexity rating assigned to a function using the rules as defined within this International Standard 3.33 functional size size of the software derived by quantifying the Functional User Requirements [ISO/IEC 14143-1:2007, definition 3.6]

3.34 Functional User Requirements sub-set of the user requirements specifying what the software shall do in terms of tasks and services NOTE

Functional User Requirements include but are not limited to:

—

data transfer (for example: Input customer data, Send control signal);

—

data transformation (for example: Calculate bank interest, Derive average temperature);

—

data storage (for example: Store customer order, Record ambient temperature over time);

—

data retrieval (for example: List current employees, Retrieve aircraft position).

User requirements that are not Functional User Requirements include, but are not limited to, the following: —

quality constraints (for example: usability, reliability, efficiency and portability);

—

organizational constraints (for example: locations for operation, target hardware and compliance to standards);

—

environmental constraints (for example: interoperability, security, privacy and safety);

—

implementation constraints (for example: development language, delivery schedule).

[ISO/IEC 14143-1:2007, definition 3.8]

January 2010

Function Point Counting Practices Manual

5

3 Terms and definitions

Part 1 – FSM

3.35 Function Point FP unit of measure for functional size as defined within this International Standard 3.36 Function Point Analysis FPA method for measuring functional size as defined within this International Standard 3.37 function point count activity of applying the rules within this International Standard to measure the functional size of an application or project NOTE project.

There are three types of function point counts: application, development project and enhancement

3.38 function type five types of base functional components identified in this International Standard NOTE The five function types are: External Input, External Output, External Inquiry, Internal Logical File and External Interface File.

3.39 Internal Logical File ILF user recognizable group of logically related data or control information maintained within the boundary of the application being measured NOTE

An Internal Logical File is a type of base functional component.

3.40 maintain ability to add, change or delete data through an elementary process 3.41 meaningful user recognizable and satisfies a Functional User Requirement 3.42 perfective maintenance modification of a software product after delivery to detect and correct latent faults in the software product before they are manifested as failures NOTE 1: Perfective maintenance provides enhancements for users, improvement of program documentation, and recoding to improve software performance, maintainability, or other software attributes. NOTE 2:

Contrast with: adaptive maintenance; corrective maintenance.

[ISO/IEC 14764:2006 Software engineering – Software life cycle processes – Maintenance, definition 3.7]

3.43 primary intent intent that is first in importance

6

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

3 Terms and definitions

3.44 processing logic any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function 3.45 purpose of the count reason for performing the function point count NOTE

See 5.3 a).

3.46 Record Element Type RET user recognizable sub-group of data element types within a data function 3.47 self-contained no prior or subsequent processing steps are needed to initiate or complete the Functional User Requirement(s) EXAMPLE The Functional User Requirement states that an employee is to be both added and updated. There might be multiple parts that make up the complete employee information. This can be represented by separate physical screens, windows or tabs such as —

Employee identification,

—

Employee location,

—

Dependent information,

—

Salary information, and

—

Education.

To add an employee, one or more of the tabs must be completed, depending on the business rules. The add process is not self-contained until all mandatory information has been entered. To update an employee, one or more of the tabs can be updated at any given time, but they are all process steps that meet the Functional User Requirement of updating an employee. Adding, changing or deleting information on any individual tab is not a separate elementary process. It is a process step involved in updating an employee. Even though additional information is possible to be entered into the employee record, all of the information together is considered to be a part of the single elementary process: update employee. Add Employee and Update Employee would each be a self-contained process.

3.48 sorting activity of sequencing of rows or records in a transactional function 3.49 transactional function elementary process that provides functionality to the user to process data NOTE

A transactional function is an External Input, External Output or External Inquiry.

3.50 user any person or thing that communicates or interacts with the software at any time

January 2010

Function Point Counting Practices Manual

7

4 Abbreviated terms

Part 1 – FSM

EXAMPLES Examples of 'thing' include, but are not limited to, software applications, animals, sensors, or other hardware. [ISO/IEC 14143-1:2007, definition 3.11]

3.51 user recognizable requirements for processes and/or data that are agreed upon, and understood by, both the user(s) and software developer(s) 3.52 user view Functional User Requirements as perceived by the user NOTE

4

Developers translate the user view into software in order to provide a solution.

Abbreviated terms

BFC

Base Functional Component

DET

Data Element Type

EI

External Input

EIF

External Interface File

EO

External Output

EQ

External Inquiry

FP

Function Point

FPA

Function Point Analysis

FTR

File Type Referenced

ILF

Internal Logical File

RET

Record Element Type

5

Measurement Process

5.1 Overview To conduct a function point count, the following activities shall be performed to identify and classify the base functional components (ILF, EIF, EI, EO, EQ) a) gather the available documentation in accordance with 5.2, b) determine the counting scope and boundary and identify Functional User Requirements in accordance with 5.3, c) measure data functions in accordance with 5.4, 5.6 and 5.7, NOTE Conversion functionality (if applicable) is measured in accordance with 5.6; enhancement functionality (if applicable) is measured in accordance with 5.7.

d) measure transactional functions in accordance with 5.5, 5.6 and 5.7, NOTE Conversion functionality (if applicable) is measured in accordance with 5.6; enhancement functionality (if applicable) is measured in accordance with 5.7.

8

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5 Measurement Process

e) calculate the functional size in accordance with 5.8, f)

document the function point count in accordance with 5.9, and

g) report the result of the function point count in accordance with 5.10. NOTE

Figure 1 provides a graphical overview of the function point counting process.

gather available documentation

measure data fu nctions

determine counting scope & bou ndaries, and identify functional user requirements

calcu late functional size

docu ment & report

measure transactional fu nctions

Figure 1 — Graphical overview of the function point counting process

5.2 Gather the available documentation Documentation to support a function point count shall describe the functionality delivered by the software or the functionality that is impacted by the software project that is being measured. Sufficient documentation to conduct the function point count or access to subject matter experts, who are able to provide additional information to address any gaps in the documentation, shall be obtained. NOTE Suitable documentation may include requirements, data/object models, class diagrams, data flow diagrams, use cases, procedural descriptions, report layouts, screen layouts, user manuals and other software development artifacts.

5.3 Determine the counting scope and boundary and identify Functional User Requirements To determine the counting scope and boundary of each application and identify Functional User Requirements, the following activities shall be performed a) identify the purpose of the count, NOTE 1 A function point count is conducted to provide an answer to a business question, and it is the business question that determines the purpose. NOTE 2

The purpose of the count determines the counting scope.

EXAMPLE 1

The purpose of the count could be to determine the size of a particular software release.

EXAMPLE 2 The purpose of the count could be to determine the size of an application as part of the organization's effort to determine the size of its software portfolio.

b) identify the type of count, based on the purpose, as one of: 1)

a development project function point count;

2)

an application function point count;

January 2010

Function Point Counting Practices Manual

9

5 Measurement Process

3)

Part 1 – FSM

an enhancement project function point count,

c) determine the counting scope, based on the purpose and type of count, d) determine the boundary of each application within the counting scope, based on the user view, not on technical considerations EXAMPLE 3 If the purpose is to estimate the cost of an enhancement to the Human Resources (HR) and Benefits applications, then: —

the type of count is an enhancement project count;

—

the scope shall include the transactional and data functions added, changed or deleted for both the HR and Benefits applications as well as any conversion requirements for each application;

—

the user view is that HR and Benefits are different functional areas, and therefore they are separate applications;

—

a boundary exists between the HR and Benefits applications as well as between each application and user.

e) the user requirements may include a mixture of both functional and non-functional requirements; identify which requirements are functional, and exclude the non-functional requirements.

5.4 Measure data functions 5.4.1

Overview

Data functionality satisfies the Functional User Requirements to store and/or reference data. All data functionality within the counting scope shall be evaluated to identify each logical group of data. To measure data functions, the following activities shall be performed a) identify and group all logical data into data functions in accordance with 5.4.2, b) classify each data function as either an ILF or an EIF in accordance with 5.4.3, c) count the DETs for each data function in accordance with 5.4.4, d) count the RETs for each data function in accordance with 5.4.5, e) determine the functional complexity for each data function in accordance with 5.4.6, and f)

determine the functional size for each data function in accordance with 5.4.7.

5.4.2

Identify and group all logical data into data functions

NOTE 1 Data functions are most easily identified using a logical data model; however, this does not preclude the use of the measurement process in environments where alternative data or object modeling techniques are employed. Data modeling terminology is used to document the data function rules, but the same approach can be applied with other techniques.

To identify data functions, the following activities shall be performed a) identify all logically related and user recognizable data or control information within the counting scope, b) exclude entities that are not maintained by any application,

10

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5 Measurement Process

c) group related entities that are entity dependent, NOTE 2

Entities that are entity independent are considered to be separate logical groups of data.

d) exclude those entities below, referred to as code data: 1)

substitution data entity that contains a code and an explanatory name or description;

2)

single occurrence entity that contains one or more attributes that rarely change, if at all;

3)

entity that contains data that is basically static or may change very rarely;

4)

default values entity that contains values for populating attributes;

5)

valid values entity that contains available values for selection or validation;

6)

entity that contains a range of values for validation,

NOTE 3 These entities referred to above as code data may also contain other attributes for audit purposes and to define effective dates. The presence of these attributes does not alter the nature of these entities.

e) exclude entities that do not contain attributes required by the user, and f)

remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities.

NOTE 4 function.

5.4.3

Foreign key attributes are data required by the user to establish a relationship with another data

Classify each data function as either an ILF or an EIF

A data function shall be classified as an a) Internal Logical File (ILF) if it is maintained by the application being measured, or b) External Interface File (EIF) if it is —

referenced, but not maintained, by the application being measured, and

—

identified in an ILF in one or more other applications.

5.4.4

Count DETs for each data function

To count Data Element Types (DETs) for a data function, the following activities shall be performed a) count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope, NOTE 1 For example, within an ILF or EIF, count one DET for the 12 repeated Monthly Budget Amount fields. Count one additional DET to identify the applicable month.

b) count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function, NOTE 2

Attributes that are not referenced by the application being measured are not counted.

January 2010

Function Point Counting Practices Manual

11

5 Measurement Process

Part 1 – FSM

c) count one DET for each attribute required by the user to establish a relationship with another data function, and d) review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs. Grouping will depend on how the elementary processes use the attributes within the application. EXAMPLE

The attributes (first name, middle initial, last name) are grouped and counted as

—

name (first name, middle initial, last name) if these attributes are always used together,

—

first names (first name and middle initial) and last name if, in addition, last name is sometimes used on its own, or

—

first name, middle initial and last name, if all three can be used independently.

5.4.5

Count RETs for each data function

To count Record Element Types (RETs) for a data function, the following activities shall be performed a) count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET), b) count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: 1)

associative entity with non-key attributes;

2)

sub-type (other than the first sub-type);

3)

attributive entity, in a relationship other than mandatory 1-1

NOTE 1 A mandatory 1-1 relationship reflects a relationship between two entities where each is related to one and only one instance of the related entity. NOTE 2

If you don’t have a data model, look for repeating groups of data in order to identify RETs.

EXAMPLE 1 An invoice has a header section of the customer information and line items of the purchases (e.g., item number, description, price, weight). The Header section is counted as one RET. The line items are a repeating group and is counted as an additional RET. EXAMPLE 2 A single repeating attribute such as multiple account numbers for a customer is not a repeating group and is counted as a single DET and not as a RET. EXAMPLE 3 A multiple occurring group of DETs such as year, month and budget amount is a repeating group but is counted as three DETs and not as a RET.

12

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5.4.6

5 Measurement Process

Determine the functional complexity for each data function

The functional complexity of each data function shall be determined using the number of RETs and DETs in accordance with Table 1. Table 1 — Data function complexity DETs

RETs

5.4.7

1 – 19

20 – 50

> 50

1

Low

Low

Average

2–5

Low

Average

High

>5

Average

High

High

Determine the functional size for each data function

The functional size of each data function shall be determined using the type and functional complexity in accordance with Table 2. Table 2 — Data function size Type

Functional complexity

5.5 5.5.1

ILF

EIF

Low

7

5

Average

10

7

High

15

10

Measure transactional functions Overview

Transaction functionality satisfies the Functional User Requirements that process data. All transactional functionality within the counting scope shall be evaluated to identify each unique elementary process. To measure transactional functions, the following activities shall be performed a) identify each elementary process required by the user in accordance with 5.5.2, b) classify each transactional function as an External Input (EI), External Output (EO) or an External Inquiry (EQ) in accordance with 5.5.3, c) count the File Types Referenced (FTRs) for each transactional function in accordance with 5.5.4, d) count the Data Element Types (DETs) for each transactional function in accordance with 5.5.5, e) determine the functional complexity for each transactional function in accordance with 5.5.6, and

January 2010

Function Point Counting Practices Manual

13

5 Measurement Process

f)

Part 1 – FSM

determine the functional size of each transactional function in accordance with 5.5.7.

5.5.2

Identify elementary processes

5.5.2.1 To identify each elementary process, the following activities shall be performed a) Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: 1)

is meaningful to the user;

2)

constitutes a complete transaction;

NOTE For users of prior versions of this International Standard, item 2) is not a change, but rather a refinement to increase the specificity to promote consistent interpretation.

3)

is self-contained;

4)

leaves the business of the application being counted in a consistent state,

EXAMPLE 1 A Functional User Requirement may state that a function is to be provided to Maintain Employee information. That requirement is decomposed into smaller units of work such as Add Employee, Change Employee, Delete Employee, Inquire about Employee. EXAMPLE 2 Individual requirements may state the need to add different types of employee information (e.g., address, salary and dependent information), but the smallest unit of activity meaningful to the user is to Add Employee.

b) Identify an elementary process for each unit of activity identified that meets all of the criteria in 5.5.2.1 a). 5.5.2.2 To determine unique elementary processes, the following activities shall be performed a) When compared to an elementary process already identified, count two similar elementary processes as the same elementary process if they: 1)

require the same set of DETs;

2)

require the same set of FTRs;

3)

require the same set of processing logic to complete the elementary process (refer to the list below 5.5.2.2 b),

NOTE 1 The activities to measure transactional functions are depicted sequentially; however, they are in fact iterative. FTRs and DETs are identified in accordance with 5.5.4 and 5.5.5, but are necessary to compare two similar elementary processes. NOTE 2 One elementary process may include minor variations in DETs or FTRs as well as multiple alternatives, variations or occurrences of processing logic below. EXAMPLE When an elementary process to Add Employee has been identified, it is not divided into two elementary processes to account for the fact that an employee may or may not have dependents. The elementary process is still Add Employee, and there is variation in the processing logic and DETs to account for dependents.

14

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5 Measurement Process

b) Do not split an elementary process with multiple forms of processing logic into multiple elementary processes. NOTE 3 An elementary process that accepts and validates data from the user, reads and filters data from an ILF and sorts and presents the results back to the user cannot be split into multiple elementary processes.

5.5.2.3 Various forms of processing logic to complete an elementary process are identified in Table 3: Table 3 — Forms of processing logic Forms of processing logic 1. Validations are performed EXAMPLE 1

When adding a new employee to an organization, the employee process validates the employee type DET.

2. Mathematical formulas and calculations are performed EXAMPLE 2 When reporting on all employees within an organization the process includes calculating the total number of salaried employees, hourly employees and all employees.

3. Equivalent values are converted EXAMPLE 3

Employee age is converted to an age range group using a table.

4. Data is filtered and selected by using specified criteria to compare multiple sets of data EXAMPLE 4 To generate a list of employees by their assignment, an elementary process compares the job number of a job assignment to select and list the appropriate employees with that assignment.

5. Conditions are analyzed to determine which are applicable EXAMPLE 5 Processing logic exercised by the elementary process when an employee is added will depend on whether an employee is paid based on salary or hours worked. The entry of DETs (and the resulting processing logic) based upon a different choice (salary or hourly) in this example is part of one elementary process.

6. One or more ILFs are updated EXAMPLE 6 data.

When adding an employee, the elementary process updates the employee ILF to maintain the employee

7. One or more ILFs or EIFs are referenced EXAMPLE 7 When adding an employee, the currency EIF is referenced for the correct US dollar conversion rate to determine an employee’s hourly rate.

8. Data or control information is retrieved EXAMPLE 8

To view a list of employees, employee information is retrieved from a data function.

9. Derived data is created by transforming existing data to create additional data EXAMPLE 9

To determine (derive) a patient’s registration number (e.g., SMIJO01), the following data is concatenated:

—

the first three letters of the patient’s last name (e.g., SMI for Smith);

—

the first two letters of the patient’s first name (e.g., JO for John);

—

a unique two-digit sequence number (starting with 01).

January 2010

Function Point Counting Practices Manual

15

5 Measurement Process

Part 1 – FSM

Forms of processing logic 10. Behavior of the application is altered EXAMPLE 10 The behavior of the elementary process of paying employees is altered when a change is made to pay them every other Friday versus on the 15th and the last day of the month; resulting in 26 pay periods per year vs. 24.

11. Prepare and present information outside the boundary EXAMPLE 11

A list of employees is formatted and displayed for the user.

12. Capability exists to accept data or control information that enters the boundary of the application EXAMPLE 12

A user enters information to add a customer order to the application.

13. Sorting or arranging a set of data. This form of processing logic does not impact the identification of the type or contribute to the uniqueness of an elementary process; i.e., the orientation of the data does not constitute uniqueness EXAMPLE 13

The list of employees is sorted in either alphabetical or location order.

EXAMPLE 14 On an order entry screen, the order header information is arranged at the top of the screen, and the order details are placed below. NOTE 1 Prior versions of this International Standard (ISO/IEC 20926:2003) misstated the terms “resorting” and “rearranging”; use of the terms, “sorting” and “arranging”, is a correction rather than a change.

5.5.3

Classify each elementary process as a transactional function

5.5.3.1 For each elementary process a) the primary intent shall be identified as one of the following: 1)

altering the behavior of the application;

2)

maintaining one or more ILFs;

3)

presenting information to the user,

b) the forms of processing logic required to complete the elementary process shall be identified from the list presented in 5.5.2.3. 5.5.3.2 Each elementary process shall be classified as a) an EI, if it:

16

1)

includes processing logic to accept data or control information that enters the boundary of the application;

2)

has a primary intent of either i)

maintaining one or more ILFs, or

ii)

altering the behavior of the application,

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5 Measurement Process

b) an EO, if it has the primary intent of presenting information to the user and it includes at least one of the following forms of processing logic: 1)

mathematical calculations are performed;

2)

one or more ILFs are updated;

3)

derived data is created;

4)

the behavior of the application is altered,

c) an EQ, if it has the primary intent of presenting information to the user and it: 1)

references a data function to retrieve data or control information;

2)

does not satisfy the criteria to be classified as an EO.

NOTE 1 type.

Table 4 presents a summary of the relationship between the primary intent and transactional function

Table 4 — Relationship between primary intent and transactional function type Transactional function type EI EO EQ PI F N/A PI F N/A F PI PI

Function Alter the behavior of the application Maintain one or more ILFs Present information to a user key PI the primary intent of the transactional function type F a function of the transactional function type that is sometimes present but which is not the primary intent N/A the transactional function type is not allowed to perform this function type

NOTE 2 Table 5 presents a summary of the relationship between forms of processing logic and transactional function type.

Table 5 — Relationship between processing logic and transactional function type

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Form of processing logic Validations are performed Mathematical calculations are performed Equivalent values are converted Data is filtered and selected by using specified criteria to compare multiple sets of data Conditions are analyzed to determine which are applicable At least one ILF is updated At least one ILF or EIF is referenced Data or control information is retrieved Derived data is created Behavior of the application is altered Information is prepared and then presented outside the boundary Data or control information entering the boundary of the application is accepted A set of data is sorted or arranged

January 2010

Function Point Counting Practices Manual

Transactional function type EI EO EQ c c c c m* n c c c c c c c m* c c c m* c m

c m* c c m* m* m c

c n m m n n m c

c

c

c

17

5 Measurement Process

key m m*

Part 1 – FSM

it is mandatory that the transactional function type perform the form of processing logic it is mandatory that the transactional function type perform at least one of these (m*) forms of processing logic the transactional function type can perform the form of processing logic, but it is not mandatory the transactional function type cannot perform the form of processing logic

c n 5.5.4

Count FTRs for each transactional function

For each transactional function, one FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function. NOTE The activities to measure transactional functions are depicted sequentially; however, they are in fact iterative. To compare two similar elementary processes, identification of FTRs is necessary as stated in 5.5.2.2.

5.5.5

Count DETs for each transactional function

To count DETs for a transactional function, the following activities shall be performed a) Review everything that crosses (enters and/or exits) the boundary, b) Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function, EXAMPLE 1

DETs that cross the boundary include

—

attributes the user enters via a screen as well as those displayed on a report or screen,

—

attributes that enter the boundary of the application that are required to specify when, what and/or how the data is to be retrieved or generated by the elementary process,

—

attributes provided by, or presented to, the user of the transactional function, and

—

attributes in an electronic file that enter or exit the boundary.

c) Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages, EXAMPLE 2

If multiple error/confirmation messages are presented to the user, only one DET is counted.

d) Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so, and EXAMPLE 3 If the user can initiate the generation of a report by clicking on the OK button or by pressing a function key, only one DET is counted.

e) Do not count the following items as DETs:

18

—

literals such as report titles, screen or panel identifiers, column headings and attribute titles;

—

application generated stamps such as date and time attributes;

—

paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’;

—

navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents;

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5 Measurement Process

—

attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary;

—

attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary.

NOTE The activities to measure transactional functions are depicted sequentially; however, they are in fact iterative. To compare two similar elementary processes, identification of DETs is necessary as stated in 5.5.2.2.

5.5.6

Determine the functional complexity for each transactional function

The functional complexity for each transactional function shall be determined using the number of FTRs and DETs in accordance with Table 6 or Table 7. Table 6 — EI functional complexity

Table 7 — EO and EQ functional complexity

DETs

FTRs

DETs

1–4

5 – 15

> 15

0–1

Low

Low

Average

2

Low

Average

High

>2

Average

High

High

FTRs

NOTE

5.5.7

1–5

6 – 19

> 19

0–1

Low

Low

Average

2–3

Low

Average

High

>3

Average

High

High

An EQ has a minimum of 1 FTR.

Determine the functional size of each transactional function

The functional size of each transactional function shall be determined using the type and functional complexity in accordance with Table 8. Table 8 — Transactional function size Type

Functional complexity

5.6

EI

EO

EQ

Low

3

4

3

Average

4

5

4

High

6

7

6

Measure conversion functionality

The counting scope of a development or enhancement project can also include the functional size of conversion functionality required for the project. Conversion transactional functions and data functions (that have not already been counted) shall be counted in accordance with 5.4 and 5.5. NOTE

The counting scope dictates whether conversion functionality is counted.

January 2010

Function Point Counting Practices Manual

19

5 Measurement Process

5.7

Part 1 – FSM

Measure enhancement functionality

Enhancement projects can involve adds, changes to and deletion of existing functionality. Enhancement functionality shall be measured in accordance with the following a) Do not modify the boundary already established for the application(s) being modified, b) Count data functions that are added, changed or deleted in accordance with 5.4, c) Count transactional functions that are added, changed or deleted in accordance with 5.5, and d) The application functional size may be updated to reflect: 1) 2)

3) NOTE 1

added functionality, which increases the application functional size; changed functionality, which may increase, decrease or have no effect on the application functional size; deleted functionality, which decreases the application functional size. A change to a data function may involve adding, changing or deleting of DETs and/or RETs.

NOTE 2 A change to a transactional function may involve adding, changing or deleting of DETs and/or FTRs and/or changing of processing logic.

5.8

Calculate functional size

The purpose and counting scope shall be considered when selecting and using the appropriate formula to calculate the functional size. A development project functional size shall be calculated using Formula (1): DFP = ADD + CFP

(1)

where DFP

is the development project function point count;

ADD

is the size of the functions to be delivered to the user by the development project;

CFP

is the size of the conversion functionality.

An application functional size from a measurement after the development project or at any time during the application’s life cycle shall be calculated using Formula (2): AFP = ADD

(2)

where AFP

is the application function point count;

ADD is the size of the functions to be delivered to the user by the development project (excluding the size of any conversion functionality) or the functionality that exists whenever the application is counted.

20

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

5 Measurement Process

An enhancement project functional size shall be calculated using Formula (3): EFP = ADD + CHGA + CFP + DEL

(3)

where EFP

is the enhancement project function point count;

ADD

is the size of the functions being added by the enhancement project;

CHGA is the size of the functions being changed by the enhancement project – as they are / will be after implementation; CFP

is the size of the conversion functionality;

DEL

is the size of the functions being deleted by the enhancement project.

An application functional size after an enhancement project shall be calculated using Formula (4): AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL)

(4)

where AFPA is the application function point count after the enhancement project; AFPB is the application function point count before the enhancement project; ADD

is the size of the functions being added by the enhancement project;

CHGA is the size of the functions being changed by the enhancement project – as they are / will be after implementation; CHGB is the size of the functions being changed by the enhancement project – as they are / were before the project commenced; DEL

5.9

is the size of the functions being deleted by the enhancement project.

Document the function point count

The function point count shall be documented as follows: ⎯ the purpose and type of count; ⎯ the counting scope and boundary of the application; ⎯ the date of the count; ⎯ a list of all data and transactional functions, including their type and complexity and number of function points assigned; ⎯ the result of the count (refer to 5.10); ⎯ any assumptions made and issues resolved. The documentation of the function point count can also include the following: ⎯ identification of the source documentation on which the count was based;

January 2010

Function Point Counting Practices Manual

21

5 Measurement Process

Part 1 – FSM

⎯ identification of the participants, their roles and qualifications; ⎯ for each data function, the number of DETs and RETs; ⎯ for each transactional function, the number of DETs and FTRs; ⎯ a cross-reference of all data functions to transactional functions; ⎯ a cross-reference of all data functions to the related abstractions in the source documentation; ⎯ a cross reference of all transactional functions to the related abstractions in the source documentation. NOTE 1 benefits.

Negotiate the level of documentation with the client, and inform the client about the related costs and

NOTE 2 A fully documented Function Point Count will facilitate traceability, usability and maintainability; however, a client may be interested only in the final result.

5.10 Report the result of the function point count NOTE Consistently reporting the results of function point counts enables the readers to identify the standard to which they comply.

5.10.1 Results that comply with this International Standard shall be reported as follows: S FP (IFPUG–IS) where S

is the result of the function point count;

FP

is the unit of size of the IFPUG FSM Method;

IS

is this International Standard (ISO/IEC 20926:200x).

EXAMPLE

250 FP (IFPUG-ISO/IEC 20926:200x)

5.10.2 Results that comply with a local customization of this International Standard shall be reported as: S FP (IFPUG–IS–c) where c represents one or more characters indicating the result does not fully comply with this International Standard. EXAMPLE

22

250 FP (IFPUG–ISO/IEC 20926:200x–a)

Function Point Counting Practices Manual

January 2010

Part 1 – FSM

Annex A

Annex A (informative) Consolidated complexity and functional size tables

For convenience, the complexity and functional size tables are repeated in Tables A.1 through A.5. Table A.1 — Data function complexity

Table A.2 — Data function size

DETs

RETs

Type ILF

EIF

Low

7

5

High

Average

10

7

High

High

15

10

1 – 19

20 – 50

> 50

1

Low

Low

Average

2–5

Low

Average

>5

Average

High

Functional complexity

Table A.3 — EI functional complexity

Table A.4 — EO and EQ functional complexity

DETs

FTRs

DETs

1–4

5 – 15

> 15

0–1

Low

Low

Average

2

Low

Average

High

>2

Average

High

High

FTRs

NOTE

1–5

6 – 19

> 19

0–1

Low

Low

Average

2–3

Low

Average

High

>3

Average

High

High

An EQ has a minimum of 1 FTR.

Table A.5 — Transactional function size Type

Functional complexity

January 2010

EI

EO

EQ

Low

3

4

3

Average

4

5

4

High

6

7

6

Function Point Counting Practices Manual

23

Annex A

Part 1 – FSM

This page intentionally left blank.

24

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

This page intentionally left blank.

Part 2 Chapter 1

Part 2 The Bridge - Applying the IFPUG Functional Size Measurement Method Introduction

Part 1 provides the function point analysis process for functionally sizing software following the IFPUG Method as well as the detailed rules for identifying and measuring data functions and transactional functions. Part 2 provides an overview of the IFPUG Method, along with guidance in applying the rules for determining the type of count, establishing application boundaries and measuring data and transactional functions.

Contents

Part 2 includes the following chapters: Topic Relationship between IFPUG and ISO

January 2010

Page 1-2

IFPUG FSM Overview

2-1

Gather Available Documentation

3-1

Determine Type of Count

4-1

Determine Counting Scope and Application Boundaries

5-1

Measure Data Functions

6-1

Measure Transactional Functions

7-1

Index

i-1

Function Point Counting Practices Manual

1-1

Part 2 – The Bridge – Applying the IFPUG FSM Method

Part 2 – The Bridge – Applying the IFPUG FSM Method

Relationship between IFPUG and ISO IFPUG Strategic Direction

IFPUG’s method for function point analysis is an ISO standard and must be conformant to ISO/IEC 14143-1:2007. The method can measure “functional size” only and not “non-functional size”. This does not mean that the nonfunctional size cannot, or should not, be measured, only that it must be clearly stated as a separate measure (“A Framework for Functional Sizing” [IFPUG, 2003]).

“A Framework for Functional Sizing” “A Framework for Functional Sizing” provides the basis for understanding functional sizing as it relates to requirements. The paper explores different types of requirements; these concepts provide the basis for sizing software in accordance with ISO/IEC 14143-1 and the IFPUG CPM. The basis behind “A Framework for Functional Sizing” is that there may be multiple sizing methods for different purposes. The functional size could be measured using the IFPUG functional size measurement method for function point analysis, based on the functional user requirements. Other sizing measures can be used to size, for instance, non-functional requirements. Both result in different size measures representing different dimensions of software size: IFPUG-FP for functional size and any other for non-functional size. While these sizes cannot be added together because they represent different dimensions (like volume and temperature of a room), they can both be used in estimating the effort towards the development of an application or a system. “A Framework for Functional Sizing” provides guidance in distinguishing between functional size and non-functional size.

ISO/IEC 14143-1 - Definition of User Requirements In 1998, the first ISO/IEC Functional Size Measurement standard was published (ISO/IEC 14143-1:1998). This standard defines the Functional Size as “a size of the software derived by quantifying the Functional User Requirements.” It was updated in 2007 and published as ISO/IEC 141431:2007. ISO/IEC 14143-1 defines the fundamental concepts of Functional Size Measurement (FSM) and describes the general principles for applying an FSM Method. It does NOT provide detailed rules on how to: •

1-2

Select a particular method

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Part 2 – The Bridge – Applying the IFPUG FSM Method

•

Measure Functional Size of software using a particular method

•

Use the results obtained from a particular method

The definition of FSM in ISO/IEC 14143-1 is applicable when determining if a method for sizing software is a Functional Size Measurement Method. It does not prevent the development of various methods, but rather provides a basis for assessing whether a particular method conforms to FSM. ISO/IEC 14143-1 distinguishes between two subsets of user requirements: •

Functional User Requirements

•

Non-Functional User Requirements

The ISO/IEC 14143-1 definitions are as follows:

ISO/IEC 14143-1 - Definitions Functional Size

A size of the software derived by quantifying the Functional User Requirements

Functional User Requirement

A subset of the user requirements specifying what the software shall do in terms of tasks and services.

January 2010

Note: Functional User Requirements include but are not limited to: •

Data transfer (for example: input customer data, send control signal)

•

Data transformation (for example: calculate bank interest, derive average temperature)

•

Data storage (for example: store customer order, record ambient temperature over time)

•

Data retrieval (for example: list current employees, retrieve aircraft position)

Function Point Counting Practices Manual

1-3

Part 2 – The Bridge – Applying the IFPUG FSM Method

NonFunctional User Requirement

1-4

Part 2 – The Bridge – Applying the IFPUG FSM Method

ISO does not provide a definition for Non-Functional User Requirements, but gives some examples in a note. User requirements that are Non-Functional User Requirements include, but are not limited to the following: •

Quality constraints (for example usability, reliability, efficiency and portability)

•

Organizational constraints (for example locations for operation, target hardware and compliance to standards)

•

Environmental constraints (for example interoperability, security, privacy and safety)

•

Implementation constraints (for example development language, delivery schedule)

Function Point Counting Practices Manual

January 2010

Part 2 Chapter 2

IFPUG FSM Method Overview Introduction

This chapter presents an overview of the IFPUG Functional Size Measurement Method (FSM). It presents a summary and example of the function point counting procedures.

Contents

This chapter includes the following sections: Topic

Page

Functional Size Measurement Method Procedure

2-2

Procedure by Chapter

2-2

Summary Counting Example

2-3

Summary Diagram

2-3

Gather the Available Documentation

2-4

Determine the Counting Scope and Boundary and Identify Functional

2-4

User Requirements

January 2010

Measure Data Functions

2-5

Measure Transactional Functions

2-6

Calculate the Functional Size

2-7

Function Point Counting Practices Manual

2-1

IFPUG FSM Method Overview

Part 2 – The Bridge – Applying the IFPUG FSM Method

Functional Size Measurement Method Procedure This section presents the high-level procedure for the IFPUG Functional Size Measurement Method.

Procedure Diagram

gather available documentation

determine counting scope and boundaries and identify functional user requirements

measure data functions calculate functional size

document and report

measure transactional functions

Procedure by Chapter The following table shows the function point counting procedures as they are explained in the remaining chapters of Part 2. Note: A summary example of the counting procedures is presented on the following pages in this chapter. Procedure Gather Available Documentation Determine Counting Scope & Boundary and Identify Functional User Requirements Determine Counting Scope & Boundary & Identify Functional User Requirements Measure Data Functions Measure Transactional Functions

Chapter 3 Gather Available Documentation 4 Determine Type of Count

5 Determine the Counting Scope and Boundary and Identify Functional User Requirements 6 Measure Data Functions 7 Measure Transactional Functions

Note: There are not separate chapters for Calculate Functional Size and Document and Report as these procedure steps do not require explanation beyond that provided in Part 1.

2-2

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

IFPUG FSM Method Overview

Summary Counting Example This section presents a summary example of the function point counting procedure and the components that comprise the functional size.

Summary Diagram The following diagram shows the components for the summary counting example of a Human Resources Application. Refer to the diagram while reading the remaining paragraphs in this chapter.

User 1 Request and Display Employee Information (together = EQ)

Currency Application Conversion Rate (EIF) Enter New Employee Information (EI)

User 1

Human Resources Application Employee Information (ILF) Employee Summary Report (EO)

User 1

Boundary

January 2010

Function Point Counting Practices Manual

2-3

IFPUG FSM Method Overview

Part 2 – The Bridge – Applying the IFPUG FSM Method

Gather the Available Documentation The first step in the function point counting procedure is to gather the available documentation, in accordance with 5.2 of Part 1, to support a functional size measurement. It shall describe the functionality delivered by the software or the functionality that is impacted by the software project that is being measured. Suitable documentation may include requirements, data/object models, class diagrams, data flow diagrams, use cases, procedural descriptions, report layouts, screen layouts, user manuals and other software development artifacts. If sufficient documentation is not available, access to subject matter experts who are able to provide additional information to address any gaps in the documentation shall be obtained. Chapter 3 discusses the documentation available during the life cycle of an application.

Determine the Counting Scope and Boundary and Identify Functional User Requirements A functional size measurement is conducted to provide an answer to a business question. In accordance with 5.3 of Part 1, it is the business question that determines the purpose of the count. Function point counts can be identified, based on their purpose, as one of the following: • Development project function point count • Enhancement project function point count • Application function point count

Chapter 4 provides guidance for determining the type of function point count. The counting scope defines the set of Functional User Requirements to be included in the function point count. The boundary is a conceptual interface between the software under study and its users. The preceding summary diagram shows the application boundary between the Human Resources Application being measured and the external Currency Application. It also shows the application boundary between the Human Resources Application and its users. Chapter 5 further discusses the counting scope and application boundary.

2-4

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

IFPUG FSM Method Overview

Measure Data Functions A data function represents functionality provided to the user to meet internal and external data storage requirements. A data function is either an internal logical file or an external interface file. • An internal logical file (ILF) is a user recognizable group of logically related data or control information maintained within the boundary of the application being measured. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being measured. The preceding summary diagram shows a group of related employee data maintained within the Human Resources Application as an example of an Internal Logical File. • An external interface file (EIF) is a user recognizable group of logically

related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application measured. This means an EIF counted for an application must be in an ILF in another application. The preceding summary diagram shows conversion rate information maintained by the Currency Application and referenced by the Human Resources Application as an example of an External Interface File. Chapter 6 of Part 2 discusses the application of the rules for measuring the data functions. Part 3 contains additional guidance for measuring data functions. Part 4 contains examples that illustrate the application of the rules for measuring data functions.

January 2010

Function Point Counting Practices Manual

2-5

IFPUG FSM Method Overview

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions A transactional function is an elementary process that provides functionality to the user to process data. A transactional function is an external input, external output, or external inquiry. • An external input (EI) is an elementary process that processes data or

control information sent from outside the boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system. The preceding summary diagram shows the process of entering employee information into the Human Resources Application as an example of an External Input. • An external output (EO) is an elementary process that sends data or control

information outside the application’s boundary and includes additional processing beyond that of an external inquiry. The primary intent of an external output is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs, and/or alter the behavior of the system. The preceding summary diagram shows the process of producing a report that summarizes all employees stored in the Human Resources Application as an example of an External Output. • An external inquiry (EQ) is an elementary process that sends data or

control information outside the boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered. The preceding summary diagram shows the process of inquiring on employee information as an example of an External Inquiry. Chapter 7 of Part 2 discusses the application of the rules for measuring transactional functions. Part 3 contains additional guidance for measuring transactional functions. Part 4 contains examples that illustrate the application of the rules for measuring transactional functions.

2-6

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

IFPUG FSM Method Overview

Calculate the Functional Size The functional size represents a size of the software derived by quantifying the functional user requirements. The application's specific user functionality is evaluated in terms of what is delivered by the application, not how it is delivered. Only user-requested and defined components are counted. The functional size is derived from measuring data and transactional functions. These functions are further defined into function types as described in the following paragraphs. Some individuals may apply a value adjustment factor (VAF), which considers 14 general system characteristics (GSCs). For guidance in the use of the VAF and GSCs, refer to Appendix C.

January 2010

Function Point Counting Practices Manual

2-7

IFPUG FSM Method Overview

Part 2 – The Bridge – Applying the IFPUG FSM Method

This page intentionally left blank.

2-8

Function Point Counting Practices Manual

January 2010

Part 2 Chapter 3

Gather Available Documentation Introduction

This chapter presents the availability of documentation during the life cycle of an application and the concept of the user’s role.

Contents

This chapter includes the following:

Topic

January 2010

Page

User View

3-2

Documentation Available During the Application Life Cycle

3-3

Phase: Initial User Requirements

3-4

Phase: Technical Requirements

3-5

Phase: Final Functional User Requirements

3-6

Life Cycle Phase Comparisons

3-8

Useful Project/Application Documentation

3-9

Functional Size

3-10

Function Point Counting Practices Manual

3-1

Gather Available Documentation

Part 2 – The Bridge – Applying the IFPUG FSM Method

User View A user is any person or thing that communicates or interacts with the software at any time. A user view is the Functional User Requirements as perceived by the user. Functional User Requirements are a sub-set of the user requirements specifying what the software shall do in terms of tasks and services. A user view represents a formal description of the user’s business needs in the user’s language. Developers translate the user information into information technology language in order to provide a solution. A user view: •

Is a description of the business functions

•

Can be verbal statements made by the user as to what their view is

•

Is approved by the user

•

Can be used to measure the functional size

•

Can vary in physical form (e.g., catalog of transactions, proposals, requirements document, external specifications, detailed specifications, user handbook)

A functional size measurement is accomplished using the information in a language that is common to both user(s) and developers.

3-2

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Gather Available Documentation

Documentation Available During the Application Life Cycle User requirements evolve rapidly in the early phases of a project. Decisions must be agreed upon by the users and the developer on which functions will be included in an application. These decisions regarding the functions of the project may be influenced by: •

The needs of the organization

•

The risk (business and technical) associated with the project

•

The resources available (e.g., budget, staff) in the organization for the project

•

The technology available in the organization

•

The influence of either users or developers through comments and suggestions

At the beginning of a project, the feasibility study is produced. The feasibility study is the highest level of specification and is usually very short; for example: •

The organization needs an application to comply with a new tax law

•

The organization needs an application to manage inventory more efficiently

•

The organization needs an application to manage human resources more efficiently

After the feasibility study, the user develops requirements that become more precise over time. At some point, the user will consult with software developers to create the detailed requirements. Software developers can get an early start with their own development and implementation requirements based upon the feasibility study. The discussions between the user and the software developers lead to enhanced requirements. The development process varies among different organizations. This manual will consider, for illustration purposes, a model with three categories of requirements documents: •

Initial User Requirements

•

Initial Technical Requirements

•

Final Functional User Requirements

As with other development methodologies, the Final Functional User Requirements Phase is the most accurate phase to measure functional size.

January 2010

Function Point Counting Practices Manual

3-3

Gather Available Documentation

Part 2 – The Bridge – Applying the IFPUG FSM Method

Phase: Initial User Requirements This phase represents user requirements prior to the sessions between the users and the software developers. It may have one or more of the following characteristics: •

Incomplete For example, Initial User Requirements may lack specifications necessary for referential integrity.

•

Lack "utility" functionality For example, essential validation reports or inquiries may be missing.

•

Impossible to implement or very difficult to use For example, a user may ask for an on-line inquiry that requires an hour of CPU processing.

•

Too general For example, requirements may not include the specific list of userrecognizable fields.

•

Does not address the needs of all users of the application For example, the requirements of a specific project may vary from one user to another if they do not have the same functional needs.

•

Stated requirements without regard for application boundaries For example, current and/or future application boundaries may not have been considered.

•

Expressed in a different context or a terminology incompatible with function point analysis For example, Initial User Requirements may refer to the physical or manual aspects of the system.

Example

In the Human Resources Department of a corporation, a user expresses his requirements as: "Whenever I’m working with an employee, I want to be able to view the employee's information by entering his or her name." This requirement implies the development of an inquiry and a group of data on employees. Functions of the Initial User Requirements example:

3-4

EQ

inquiry on a specific employee

ILF

employee group of data

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Gather Available Documentation

Phase: Technical Requirements This second phase represents the software developers' view of requirements created from the feasibility study. One task of the software developers, among others, is to organize the requirements into existing applications, if any. The Technical Requirements may include elements which are necessary for the implementation, but which are not considered in functional size measurement (e.g., temporary files, index, etc.). This phase may have one or more of the following characteristics: •

Technology dependence For example, physical files vary based on the database environment.

•

Terminology unfamiliar to the users For example, software developers may refer to physical files rather than to logical groups of data.

•

Functionality may be determined by placing too much emphasis on technical constraints For example, some developers tend to limit the scope of the requirements by focusing on the computing capacity currently available in the organization.

•

Boundaries may be determined according to the technical architecture rather than by business processes For example, there may be separate technical requirements for client and server, but they would be contained in the same application boundary when measuring the functional size.

Example

Developer: "I recognize the need for an employee inquiry. An index is necessary to speed up the retrieval of specific employees." Functions of the Initial Technical Requirements might be identified as: EQ

inquiry on a specific employee

ILF

employee group of data

ILF*

index on the employee file *Index files are not included in the functional size measurement. In this example, the index file was incorrectly identified as an ILF to illustrate a potential counting error by software developers.

January 2010

Function Point Counting Practices Manual

3-5

Gather Available Documentation

Part 2 – The Bridge – Applying the IFPUG FSM Method

Phase: Final Functional User Requirements This third phase of requirements results from joint sessions between the user(s) and the software developer(s). The joint sessions are necessary to achieve consistent and complete functional user requirements for the application. This provides the final version of the functional user requirements before the development phase begins and has the following characteristics:

Example

•

Terminology can be understood by both users and software developers

•

Integrated descriptions of all user requirements, including requirements from all groups of users are provided

•

All business processes are fully defined, including all user actions, fields coming into and leaving the application boundary, sources of data are defined for each business process, and validations that occur as part of each business process

•

Each process and group of data is agreed upon by the user and developer

•

The feasibility and usability are approved by the software developers

User: "Whenever I’m working with an employee, I want to be able to view the employee's information by entering his or her name." Developer: "I recognize the need for an employee inquiry, but many employees may have the same name. It is not possible to specify an individual employee by typing his/her name; therefore, I suggest an on-line employee list (name, location and social security number) from which to select an employee. An index will be necessary to speed up the retrieval of a specific employee." User: "I agree that the employee selection list is necessary in this case, and it may also be used for purposes other than selecting an employee.” Result of the discussions between the user and the developer: •

Add the on-line list of employees to the functional user requirements and the functional size

•

Exclude the employee index from the functional size since it is a technical solution

Functions of the Final Functional User Requirements example:

3-6

EQ

inquiry on a specific employee

EQ

on-line list of employees

ILF

employee group of data

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Gather Available Documentation

The Final Functional User Requirements document is the final version of the requirements before beginning the development phase. At this time, there should be agreement that the documented requirements are complete, formal and approved. The functional size measurement, assuming no additional changes of scope, should be consistent with the measurement at the completion of development.

January 2010

Function Point Counting Practices Manual

3-7

Gather Available Documentation

Part 2 – The Bridge – Applying the IFPUG FSM Method

Life Cycle Phase Comparisons Prior to beginning a functional size measurement, determine the application’s life cycle phase and whether you are approximating or measuring the size. Document any assumptions. Approximating permits assumptions to be made about unknown functions and/or their complexity in order to determine an approximate functional size. Measuring includes the identification of all functions and their complexity to accomplish a function point analysis. At an early stage, Initial Users Requirements could be the only document available for function point analysis. Despite the disadvantages, this size can be very useful to produce an early estimate. Uses of function point analysis for approximating size at the various life cycle phases are presented below:

Life Cycle Phase Proposal: users express needs and intentions Requirements: developers and users review and agree upon expression of user needs and intentions Design: developers may include elements for implementation that are not used for function point analysis Construction Delivery Maintenance

Size can be approximated yes yes

Size can be measured no yes

yes

yes

yes yes yes

yes yes yes

Note: No specific development life cycle is implied. If using an iterative approach, you may expect to approximate the size for some time into the application life cycle. Be aware and measure only new or refined requirements based upon user needs and intentions.

3-8

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Gather Available Documentation

Useful Project/Application Documentation In general, the following items are useful when conducting any functional size measurement: •

Requirements document(s)

•

Entity relationship diagrams

•

Object models

•

Data models

•

File and database layouts (with logical, user required attributes identified)

•

Interface Agreements with descriptions of batch feeds/transaction files and interfaces to/from other applications

•

Samples of reports, on-line screens and other user interfaces

•

Demonstration of application operation

•

One or more application experts (for the application being measured)

•

One or more customers/application users (on call during the counting session)

•

User guide, training manuals and application help

•

System design documentation

•

Functional specification

•

Use cases

Note: The list above is not all-inclusive.

January 2010

Function Point Counting Practices Manual

3-9

Gather Available Documentation

Part 2 – The Bridge – Applying the IFPUG FSM Method

Functional Size The IFPUG CPM has been transformed into an ISO standard for functional size measurement with the exclusion of the General System Characteristics, which measure non-functional (technical and quality) requirements. To some extent, this transformation has allowed the Counting Practices Committee to address issues such as code tables consistently. The most important consideration in relation to these issues is how the non-functional requirements affect the size. Since they are not functional user requirements, they do not contribute to the functional size. However, they are still part of the overall user requirements (functional and non-functional) for the software, and therefore contribute to requirements size. For a detailed discussion on functional size and how it will both guide and constrain the evolution of function point analysis, refer to the IFPUG Framework for Functional Sizing 1.

1

Framework for Functional Sizing, IFPUG CPC, Release 1.0, September 2003

3-10

Function Point Counting Practices Manual

January 2010

Part 2 Chapter 4

Determine Type of Count Introduction

This chapter includes a detailed explanation of the types of counts: development project, enhancement project, and application.

Contents

This chapter includes the following sections: Topic

January 2010

Page

Definitions: Types of Function Point Counts

4-2

Development Project

4-2

Enhancement Project

4-2

Application

4-3

Diagram of Types of Counts

4-4

Estimated and Final Functional Size Measurements

4-4

Function Point Counting Practices Manual

4-1

Determine Type of Count

Part 2 – The Bridge – Applying the IFPUG FSM Method

Definitions: Types of Function Point Counts The functional size can be measured for either projects or applications. The type of function point count is determined, based on the purpose, as one of the following: • Development project function point count • Enhancement project function point count • Application function point count

The following paragraphs define each type of function point count. Note: For those individuals who apply a value adjustment factor (VAF), refer to Appendix C for the formulas to calculate the VAF and adjusted functional size.

Development Project A development project is a project to develop and deliver the first release of a software application. The development project functional size is a measure of the functionality provided to the users with the first release of the software, as measured by the development project function point count by the activity of applying the IFPUG Functional Size Measurement (FSM) Method.

Enhancement Project An enhancement project is a project to develop and deliver adaptive maintenance. The enhancement project functional size is a measure of the functionality added, changed or deleted at the completion of an enhancement project, as measured by the enhancement project function point count by the activity of applying the IFPUG Functional Size Measurement (FSM) Method. Additional guidelines are included in Part 3.

4-2

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Determine Type of Count

Application An application is a cohesive collection of automated procedures and data supporting a business objective; it consists of one or more components, modules, or subsystems. An application’s functional size is a measure of the functionality that an application provides to the user, determined by the application function point count by the activity of applying the IFPUG Functional Size Measurement (FSM) Method. It is also referred to as the baseline or installed functional size. This size provides a measure of the current functions the application provides the user. This number is initialized when the development project function point count is completed. It is updated every time a completed enhancement project alters the application's functions.

January 2010

Function Point Counting Practices Manual

4-3

Determine Type of Count

Part 2 – The Bridge – Applying the IFPUG FSM Method

Diagram of Types of Counts The following diagram illustrates the types of function point counts and their relationships. (Project A is completed first, followed by Project B.)

Estimated and Final Functional Size Measurements It is important to realize that early functional size measurements are estimates of delivered functionality. In addition, as the scope is clarified and the functions developed, it is quite normal to identify additional functionality that was not specified in the original requirements. This phenomenon is sometimes called scope creep. It is essential to update the application functional size upon completion of the project. If the functionality changes during development, the functional size at the end of the life cycle should accurately reflect the full functionality delivered to the user.

4-4

Function Point Counting Practices Manual

January 2010

Part 2 Chapter 5

Determine the Counting Scope and Boundary and Identify Functional User Requirements Introduction

This chapter provides guidance on applying the rules, procedures, and hints to determine application boundaries and to establish the scope of the count.

Contents

This chapter includes the following sections: Topic

January 2010

Page

Counting Scope and Boundary

5-2

Purpose of the Count

5-2

Counting Scope

5-3

Boundary

5-4

Determine Counting Scope and Boundary - Rules and Procedures

5-5

Boundary Rules

5-5

Counting Scope and Boundary Procedures

5-5

Hints to Help Identify the Counting Scope and the Boundary

5-6

Function Point Counting Practices Manual

5-1

Determine the Counting Scope and Boundary and Identify Functional User Requirements

Part 2 – The Bridge – Applying the IFPUG FSM Method

Counting Scope and Boundary This section discusses counting scope and boundary of the application(s) and explains how they are influenced by the purpose of the count.

Purpose of the Count A functional size measurement is conducted to provide an answer to a business question, and it is the business question that determines the purpose. The purpose: •

Determines the type of function point count and the scope of the required count to obtain the answer to the business problem under investigation

•

Influences the positioning of the boundary between the software under review and the surrounding software; e.g., if the Personnel Module from the Human Resources System is to be replaced by a package, the users may decide to reposition the boundary and consider the Personnel Module as a separate application

Examples of purposes are:

5-2

•

To provide the functional size of a project as an input to the estimation process to determine the effort to develop the first release of an application

•

To provide the functional size of the installed base of applications to determine the support costs per function point

•

To provide the functional size of two candidate supplier packages to enable the comparison of functionality delivered by each

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Determine the Counting Scope and Boundary and Identify Functional User Requirements

Counting Scope The counting scope defines the set of Functional User Requirements to be included in the function point count. The scope: • Defines a (sub) set of the software being sized • Is determined by the purpose for performing the function point count • Identifies which functions will be included in the functional size

measurement so as to provide answers relevant to the purpose for counting • Could include more than one application

The scope of: • A development project function point count includes all functions impacted

(built or customized) by the project activities. It also includes conversion functions developed as part of the development project. • An enhancement project function point count includes all the functions

being added, changed and deleted. It also includes conversion functions developed as part of the enhancement project. The boundary of the application(s) impacted remains the same. The functionality of the application(s) reflects the impact of the functions being added, changed or deleted. • An application function point count may include, depending on the purpose

(e.g., provide a package as the software solution) as either: − only the functions being used by the user − all the functions delivered

The scope of the two counts above is different resulting in a different functional size being measured for the same application. However the position of the boundary of the application(s) remains the same and is not influenced by the decision to change the scope. The position of the boundary is independent of scope.

January 2010

Function Point Counting Practices Manual

5-3

Determine the Counting Scope and Boundary and Identify Functional User Requirements

Part 2 – The Bridge – Applying the IFPUG FSM Method

Boundary The boundary is a conceptual interface between the software under study and its users. The boundary (also referred to as application boundary): • Defines what is external to the application • Indicates the border between the software being measured and the user • Acts as a ‘membrane’ through which data processed by transactions (EIs,

EOs and EQs) pass into and out from the application • Encloses the logical data maintained by the application (ILFs) • Assists in identifying the logical data referenced by but not maintained

within this application (EIFs) • Is dependent on the user’s external business view of the application. It is

independent of technical and/or implementation considerations The positioning of the boundary between the software under investigation and other software applications may be subjective. It is often difficult to delineate where one application stops and another begins. Try to place the boundary from a business perspective rather than based on technical or physical considerations. It is important that the boundary is placed with care, since all data crossing the boundary can potentially be included in the scope of the count. For example, the following diagram shows boundaries between the Human Resources application and the external applications, Currency and Fixed Assets. The example also shows the boundary between the human user (User 1) and the Human Resources application. User 1

Currency Human Resources (Project being counted)

Fixed Assets

5-4

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Determine the Counting Scope and Boundary and Identify Functional User Requirements

Determine Counting Scope and Boundary - Rules and Procedures This section defines the rules and procedures that apply when determining counting scope and boundary of the application(s). The position of the boundary is important because it impacts the result of the functional size measurement. The boundary assists in identifying the data entering the application which will be included in the scope of the count.

Boundary Rules The following rules shall apply for boundaries:

The boundary is determined based on the user's view. The focus is on what the user can understand and describe.

The boundary between related applications is based on separate functional areas as seen by the user, not on technical considerations.

The initial boundary already established for the application or applications being modified is not influenced by the counting scope.

Note: There may be more than one application included in the counting scope. If so, multiple application boundaries would be identified. When the boundary is not well-defined (such as early in analysis), it should be located as accurately as possible.

Counting Scope and Boundary Procedures When you perform a functional size measurement, the following steps shall be performed: Step 1 2 3 4

January 2010

Action Establish the purpose of the count Identify the counting scope Identify the boundary of the application(s) Document the following items: • The purpose of the count • The counting scope • The boundary of the application(s) • Any assumptions related to the above

Function Point Counting Practices Manual

5-5

Determine the Counting Scope and Boundary and Identify Functional User Requirements

Part 2 – The Bridge – Applying the IFPUG FSM Method

Hints to Help Identify the Counting Scope and the Boundary Counting Scope

The following hints can help you to identify the counting scope: • Review the purpose of the function point count to help determine the

counting scope. • When identifying the scope of the installed or baseline functional size (e.g.,

the functionality supported by the maintenance team), include all functions currently in production and used by the users. Boundary

The following hints can help you to identify the boundary of the application(s): • Use the system external specifications or get a system flow chart and draw a

boundary around it to highlight which parts are internal and which are external to the application. • Look at how groups of data are being maintained. • Identify functional areas by assigning ownership of certain types of analysis

objects (such as entities or elementary processes) to a functional area. • Look at associated measurement data, such as effort, cost, and defects. The

boundaries for function points and the other measurement data should be the same. • Interview subject matter experts for assistance in identifying the boundary.

5-6

Function Point Counting Practices Manual

January 2010

Part 2 Chapter 6

Measure Data Functions Introduction

This chapter provides guidance for applying the rules and procedures to measure data functions. A data function represents functionality provided to the user to meet internal and external data storage requirements. A data function is either an internal logical file or an external interface file. The term file here does not mean physical file or table. In this case, file refers to a logically related group of data and not the physical implementation of those groups of data.

Contents

This chapter includes the following: Topic

January 2010

Page

Definition and Primary Intent: ILFs and EIFs

6-2

Internal Logical File

6-2

External Interface File

6-2

Difference between ILFs and EIFs

6-2

Definitions for Embedded Terms

6-2

Data Function Counting Procedure

6-4

Data Function Identification Rules

6-4

Data Function Classification Rules

6-5

Complexity and Contribution Definitions and Rules

6-5

DET Definition

6-5

DET Rules

6-5

RET Definition

6-7

RET Rules

6-7

Determination of Complexity and Contribution

6-8

Hints to Help with Counting

6-10

Function Point Counting Practices Manual

6-1

Measure Data Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Definition and Primary Intent: ILFs and EIFs This section includes the definition and primary intent of an internal logical file (ILF) and an external interface file (EIF). Embedded terms within these definitions are defined and examples are included throughout this section.

Internal Logical File An internal logical file (ILF) is a user recognizable group of logically related data or control information maintained within the boundary of the application being measured. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being measured.

External Interface File An external interface file (EIF) is a user recognizable group of logically related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application measured. This means an EIF counted for an application must be in an ILF in another application.

Difference between ILFs and EIFs The primary difference between an internal logical file and an external interface file is that an EIF is not maintained by the application being measured, while an ILF is maintained by the application being measured.

Definitions for Embedded Terms The following paragraphs further define ILFs and EIFs by defining embedded terms within the definitions. Control Information

Control Information is data that influences an elementary process by specifying what, when or how data is to be processed. For example, someone in the payroll department establishes payment cycles to schedule when the employees for each location are to be paid. The payment cycle, or schedule, contains timing information that affects when the elementary process of paying employees occurs.

6-2

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

User Recognizable

Measure Data Functions

The term user recognizable refers to requirements for processes and/or data that are agreed upon, and understood by, both the user(s) and software developer(s). For example, users and software developers agree that a Human Resources Application will have functionality to maintain and store Employee information in the application.

Maintain

The term maintain refers to the ability to add, change or delete data through an elementary process. Examples include but are not limited to add, change, delete, populate, revise, update, assign, and create.

Elementary Process

An elementary process is the smallest unit of activity that is meaningful to the user. Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

•

constitutes a complete transaction

•

is self-contained and

•

leaves the business of the application being counted in a consistent state

For example, the user requirements to add an employee include setting up salary and dependent information. If all the employee information is not added, an employee has not yet been created. Adding some of the information alone leaves the business of adding an employee in an inconsistent state. If both the employee salary and dependent information is added, this unit of activity is completed and the business is left in a consistent state.

January 2010

Function Point Counting Practices Manual

6-3

Measure Data Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Data Function Counting Procedure This section provides guidance in applying the rules for measuring data functions (internal logical files and external interface files). This summary is included to show the rules in the context of the ILF and EIF counting procedure. Note: The detailed counting procedures begin on page 6-4. Additional guidance and examples are also provided in Part 3 Logical Files. The data function counting procedure shall include the following steps: Step 1

Action Identify the data functions.

2

Classify each data function as an ILF or EIF.

3

Determine the ILF or EIF complexity and contribution to the functional size.

Data Function Identification Rules A data function represents functionality provided to the user to meet internal and external data storage requirements. A data function is either an internal logical file or an external interface file. Note: Data functions are most easily identified using a logical data model; however, this does not preclude the use of the measurement process in environments where alternative data or object modeling techniques are employed. Data modeling terminology is used to document the data function rules, but the same approach can be applied with other techniques. To identify data functions, the following activities shall be performed: Identify all logically related and user recognizable data or control information within the counting scope Exclude entities that are not maintained by any application Group related entities that are entity dependent (refer to Part 3 Logical Files) Note: Entities that are entity independent are considered to be separate logical groups of data. Exclude those entities referred to as code data (refer to Part 3 Code Data)

6-4

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Data Functions

Exclude entities that do not contain attributes required by the user Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities Note: Foreign key attributes are data required by the user to establish a relationship with another data function.

Data Function Classification Rules Classify as an ILF if the data is maintained by the application being measured. Classify as an EIF, if it: Is referenced, but not maintained, by the application being measured and Is identified in an ILF in one or more other applications Note: If the data function satisfies both rules, classify it as an ILF.

Complexity and Contribution Definitions and Rules The number of ILFs, EIFs, and their relative functional complexity determine the contribution of the data functions to the functional size. Assign each identified ILF and EIF a functional complexity based on the number of data element types (DETs) and record element types (RETs) associated with the ILF or EIF. This section defines DETs and RETs and includes the rules for each. DET Definition

A data element type is a unique, user recognizable, non-repeated attribute.

DET Rules

To count Data Element Types (DETs) for a data function, the following rules shall be performed: Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope For example, the result(s) of a calculation from an elementary process, such as calculated sales tax value for a customer order maintained on an ILF is counted as one DET on the customer order ILF.

January 2010

Function Point Counting Practices Manual

6-5

Measure Data Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

For example, accessing the price of an item which is saved to a billing file or fields such as a time stamp if required by the user(s) are counted as DETs. For example, if an employee number which appears twice in an ILF or EIF as (1) the key of the employee record and (2) a foreign key in the dependent record, count the repeated DET only once. For example, within an ILF or EIF, count one DET for the 12 repeated Monthly Budget Amount fields. Count one additional DET to identify the applicable month. Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function Note: Attributes that are not referenced by the application being measured are not counted. For example, Application A may specifically identify and use an address as: street address, city, state, and zip code. Application B may see the address as one block of data without regard to individual components. Application A would count four DETs; Application B would count one DET. For example, Application X maintains and/or references an ILF that contains a SSN, Name, Street Name, Mail Stop, City, State, and Zip. Application Z maintains and/or references the Name, City, and State. Application X would count seven DETs; Application Z would count three DETs. Count one DET for each attribute required by the user to establish a relationship with another data function For example, in an HR application, an employee's information is maintained on an ILF. The employee’s job name is included as part of the employee's information. This DET is counted because it is required to relate an employee to a job that exists in the organization. This type of data element is referred to as a foreign key. For example, in an object oriented (OO) application, the user requires an association between object classes, which have been identified as separate ILFs. Location name is a DET in the Location EIF. The location name is required when processing employee information; consequently, it is also counted as a DET within the Employee ILF. Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

6-6

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Data Functions

For example, an account number that is stored in multiple fields is counted as one DET. For example, a before or after image for a group of 10 fields maintained for audit purposes would count as one DET for the before image (all 10 fields) and as one DET for the after image (all 10 fields) for a total of 2 DETs. RET Definition

A record element type (RET) is a user recognizable sub-group of data element types within a data function.

RET Rules

To count Record Element Types (RETs) for a data function, the following activities shall be performed: Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET) Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: o associative entity with non-key attributes o sub-type (other than the first sub-type) and o attributive entity, in a relationship other than mandatory 1-1 Note: A mandatory 1-1 relationship reflects a relationship between two entities where each is related to one and only one instance of the related entity. For example, in a Human Resources Application, information for an employee is added by entering some general information. In addition to the general information, the employee is a salaried or hourly employee. The user has determined that an employee must be either salaried or hourly. Each type of employee has unique attributes. Either type can have information about dependents. For this example, there are three subgroups or RETs as shown below: •

Salaried employee; includes general information

•

Hourly employee; includes general information

•

Dependent of employee

Note: If you don’t have a data model, look for repeating groups of data in order to identify RETs. Note: There are two types of subgroups: Optional and Mandatory. Optional subgroups are those that the user has the option of using one or none of the subgroups during an elementary process that adds or creates an instance of the data. January 2010

Function Point Counting Practices Manual

6-7

Measure Data Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Mandatory subgroups are subgroups where the user must use at least one during an elementary process that adds or creates an instance of the data.

Determination of Complexity and Contribution The functional complexity of each data function shall be determined using the using the steps below. Step 1 2

Action To identify and count the RETs and DETs, the complexity and contribution counting rules that begin on page 6-5 shall be used. The functional complexity of each data function shall be determined using the number of RETs and DETs in accordance with this matrix. 1 to 19 DETs 1 RET Low 2 to 5 RETs Low 6 or more RETs Average

3

20 to 50 DETs

51 or more DETs

Low Average High

Average High High

For example, a data function with 51 DETs and 2 RETs translates to an high functional complexity. The functional size of each data function shall be determined using the type and functional complexity in accordance with the tables below. ILF Translation Table: Use the following table to assign a functional size to each ILF. Functional Complexity Rating

Function Points

Low Average High

7 10 15

EIF Translation Table: Use the following table to assign a functional size to each EIF. Functional Complexity Rating

Function Points

Low Average High

5 7 10

For example, a high complexity rating for an EIF translates to 10 function points. Continued on next page

6-8

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Step 4

Measure Data Functions

Action The ILF and EIF contribution to the functional size can be totaled. For example, the following table shows the calculation for one high complexity ILF, two average and one high complexity EIFs. Function Type

ILF

EIF

Functional Complexity

Complexity Function Totals Type Totals

0 0 1

Low Average High

X7 = X 10 = X 15 =

0 0 15

15

0 2 1

Low Average High

X5 = X7 = X 10 =

0 14 10

24

In this example, there are no ILFs of low or average complexity and one ILF of high complexity; therefore, the total size for ILFs is 15 points. For the EIFs, there are no low complexity, two average complexity EIFs (14 points) and one high complexity (10 points) for an EIF total of 24. The functional size includes the final total for all function types. The contributions for ILFs and EIFs can be added to the table that lists all function types. Appendix A includes a table that can be used to record the totals for all functions.

January 2010

Function Point Counting Practices Manual

6-9

Measure Data Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Hints to Help with Counting The following hints may help you apply the ILF and EIF rules. These hints are not rules and should not be used as rules. •

•

•

6-10

Is the data a logical group that supports specific user requirements? −

An application can use an ILF or EIF in multiple processes, but the ILF or EIF is counted only once.

−

A logical file cannot be counted as both an ILF and EIF for the same application. Consider the primary intent of the data group. If the data group satisfies both rules, count as an ILF.

−

If a group of data was not counted as an ILF or EIF itself, count its unique data attributes as DETs for the ILF or EIF that includes the group of data.

−

Do not assume that one physical file, table or object class equals one logical file when viewing data logically from the user perspective.

−

Although some storage technologies such as tables in a relational DBMS or sequential flat file or object classes relate closely to ILFs or EIFs, do not assume that this always equals a one-to-one physical-logical relationship.

−

Do not assume all physical files must be counted or included as part of an ILF or EIF.

Where is data maintained? Inside or outside the application boundary? −

Look at the workflow.

−

In the process functional decomposition, identify where interfaces occur with the user and other applications.

−

Work through the process diagram to get hints.

−

Credit ILFs maintained by more than one application to each application at the time the application is measured.

−

Only the DETs being used by each application being measured should be used to size the ILF/EIF.

Is the data in an ILF maintained through an elementary process of the application? −

An application can use an ILF or EIF multiple times, but you count the ILF or EIF only once.

−

An elementary process can maintain more than one ILF.

−

Work through the process diagram to get hints.

Function Point Counting Practices Manual

January 2010

Part 2 Chapter 7

Measure Transactional Functions Introduction

This chapter provides guidance for applying the rules for measuring external input (EI), external output (EO), and external inquiry (EQ) transactional functions. A transactional function is an elementary process that provides functionality to the user to process data. A transactional function is an external input, external output, or external inquiry. For examples that illustrate the application of these rules, see Part 4 Examples.

Contents

This chapter includes the following sections: Topic

Page

Definition and Primary Intent: EIs, EOs and EQs

7-3

External Input

7-3

External Inquiry

7-3

External Output

7-3

Summary of the Functions Performed by EIs, EOs, and EQs

7-4

Definitions for Embedded Terms

7-5

Summary of Processing Logic Used by EIs, EOs and EQs

7-8

Transactional Function Counting Rules

7-9

Transactional Function Counting Procedures

7-9

Identify Each Elementary Process

7-10

Determine Unique Elementary Processes

7-11

Classify Each Elementary Process

7-13

Classify as an EI

7-13

Classify as an EO

7-13

Classify as an EQ

7-13 Continued on next page

January 2010

Function Point Counting Practices Manual

7-1

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Topic

7-2

Page

Complexity and Contribution Definitions and Rules

7-14

FTR Definition

7-14

FTR Rule

7-14

DET Definition

7-14

DET Rules

7-14

EI Complexity and Contribution Guidelines

7-15

FTR Guidance for an EI

7-15

DET Guidance for an EI

7-15

EO/EQ Complexity and Contribution Guidelines

7-17

FTR Guidance for EQs

7-17

FTR Guidance for EOs

7-17

Shared DET Guidance for EOs and EQs

7-17

Determination of Complexity and Contribution

7-19

Hints to Help with Counting EIs, EOs, and EQs

7-21

Additional Hints to Help Counting EOs and EQs

7-23

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Definition and Primary Intent: EIs, EOs and EQs This section includes the definition and primary intent of an external input (EI), an external output (EO) and an external inquiry (EQ). Embedded terms within these definitions are defined, and examples are included throughout this definition section.

External Input An external input (EI) is an elementary process that processes data or control information sent from outside the boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.

External Inquiry An external inquiry (EQ) is an elementary process that sends data or control information outside the boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered.

External Output An external output (EO) is an elementary process that sends data or control information outside the application’s boundary and includes additional processing beyond that of an external inquiry. The primary intent of an external output is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs, and/or alter the behavior of the system.

January 2010

Function Point Counting Practices Manual

7-3

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Summary of the Functions Performed by EIs, EOs, and EQs As indicated in Part 1, the main difference between the transactional function types is their primary intent. The table below summarizes functions that may be performed by each transactional function type, and specifies the primary intent of each.

Function: Alter the behavior of the system Maintain one or more ILFs Present information to a user

Transactional Function Type: EI EO EQ PI F N/A PI F N/A F PI PI

Legend: PI

the primary intent of the transactional function type

F

a function of the transactional function type, but is not the primary intent and is sometimes present

N/A

the function is not allowed by the transactional function type

The main difference between EIs and EOs/EQs is the primary intent. Some of the differences between EOs and EQs are that an EO may perform the functions of altering the behavior of the system or maintaining one or more ILFs when performing the primary intent of presenting information to the user. Other differences are identified in the section below that summarizes forms of processing logic used by each transactional function.

7-4

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Definitions for Embedded Terms The following paragraphs include the definitions from Part 1 necessary to determine EIs, EOs and EQs. Elementary Process

An elementary process is the smallest unit of activity that is meaningful to the user. For example, requirements may state the need to add different types of employee information (e.g., address, salary and dependent information), but the smallest unit of activity meaningful to the user is to Add Employee. In this example, adding an employee (without adding address, salary and dependent information) does not meet all of the criteria. Other systems may treat maintenance of salary and/or dependent information independently from employee.

Control Information

Control Information is data that influences an elementary process by specifying what, when or how data is to be processed. For example, someone in the payroll department establishes payment cycles to schedule when the employees for each location are to be paid. The payment cycle, or schedule, contains timing information that affects when the elementary process of paying employees occurs.

Maintain

The term maintain refers to the ability to add, change or delete data through an elementary process. Examples include, but are not limited to add, change, delete, populate, revise, update, assign, and create.

User

A user is any person or thing that communicates or interacts with the software at any time. Examples include people within the HR department who interact with the application to set up employees, and the Benefits application that interacts with the HR application to receive information about employees’ dependents.

Meaningful

Is user recognizable and satisfies a Functional User Requirement.

Processing Logic

Processing logic is defined as any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function. Those requirements may include the following actions: 1. Validations are performed For example, when adding a new employee to an organization, the employee process validates the employee type DET.

January 2010

Function Point Counting Practices Manual

7-5

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

2. Mathematical formulas and calculations are performed For example, when reporting on all employees within an organization the process includes calculating the total number of salaried employees, hourly employees and all employees. 3. Equivalent values are converted For example, employee age is converted to an age range group using a table. 4. Data is filtered and selected by using specified criteria to compare multiple sets of data For example, to generate a list of employees by their assignment, an elementary process compares the job number of a job assignment to select and list the appropriate employees with that assignment. 5. Conditions are analyzed to determine which are applicable For example, processing logic exercised by the elementary process when an employee is added will depend on whether an employee is paid based on salary or hours worked. The entry of DETs (and the resulting processing logic) based upon a different choice (salary or hourly) in this example is part of one elementary process. 6. One or more ILFs are updated For example, when adding an employee, the elementary process updates the employee ILF to maintain the employee data. 7. One or more ILFs or EIFs are referenced For example, when adding an employee, the currency EIF is referenced for the correct US dollar conversion rate to determine an employee’s hourly rate. 8. Data or control information is retrieved For example, to view a list of employees, employee information is retrieved from a data function. 9. Derived data is created by transforming existing data to create additional data For example, to determine (derive) a patient’s registration number (e.g., SMIJO01), the following data is concatenated:

7-6

•

the first three letters of the patient’s last name (e.g., SMI for Smith)

•

the first two letters of the patient’s first name (e.g., JO for John)

•

a unique two-digit sequence number (starting with 01)

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

10. Behavior of the application is altered For example, the behavior of the elementary process of paying employees is altered when a change is made to pay them every other Friday versus on the 15th and the last day of the month; resulting in 26 pay periods per year vs. 24. 11. Prepare and present information outside the boundary For example, a list of employees is formatted and displayed for the user. 12. Capability exists to accept data or control information that enters the boundary of the application For example, a user enters information to add a customer order to the application. 13. Sorting or arranging a set of data. This form of processing logic does not impact the identification of the type or contribute to the uniqueness of an elementary process; i.e., the orientation of the data does not constitute uniqueness For example, list of employees is sorted in either alphabetical or location order. For example, on an order entry screen, the order header information is arranged at the top of the screen, and the order details are placed below. One elementary process may include multiple alternatives or occurrences of the above actions. For example: validations, filters, re-sorts, etc.

January 2010

Function Point Counting Practices Manual

7-7

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Summary of Processing Logic Used by EIs, EOs and EQs The following table summarizes which forms of processing logic may be performed by EIs, EOs, and EQs. For each transactional function type, certain types of processing logic must be performed to accomplish the primary intent of that type. The 13 actions do not by themselves identify unique elementary processes.

Form of Processing Logic: 1. Validations are performed 2. Mathematical calculations are performed 3. Equivalent values are converted 4. Data is filtered and selected by using specified criteria to compare multiple sets of data 5. Conditions are analyzed to determine which are applicable 6. At least one ILF is updated 7. At least one ILF or EIF is referenced 8. Data or control information is retrieved 9. Derived data is created 10. Behavior of the application is altered 11. Information is prepared and then presented outside the boundary 12. Data or control information entering the boundary of the application is accepted 13. A set of data is sorted or arranged

Transactional Functional Type: EI EO EQ c c c c m* n c c c c

c

c

c

c

c

m* c c c m* c

m* c c m* m* m

n m m n n m

m

c

c

c

c

c

Legend: m it is mandatory that the function type perform the form of processing logic m* it is mandatory that the function type perform at least one of these (m*) forms of processing logic c the function type can perform the form of processing logic, but it is not mandatory n function type cannot perform the form of processing logic

7-8

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Transactional Function Counting Rules This section provides guidance in applying the rules for measuring EIs, EOs and EQs.

Transactional Function Counting Procedures The transactional function counting procedures shall include the following steps: Step

Action

1

Identify each elementary process.

2

Determine unique elementary processes.

3

Classify each transactional function as an External Input (EI), External Output (EO) or an External Inquiry (EQ).

4

Determine the functional complexity for each transactional function and its contribution to functional size.

The rules from Part 1 are explained in the following paragraphs.

January 2010

Function Point Counting Practices Manual

7-9

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Identify Each Elementary Process To identify each elementary process, the following activities shall be performed Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: is meaningful to the user For example, the functional user requirement requires the ability to add a new employee to the application. constitutes a complete transaction For example, the user definition of employee includes salary and dependent information. If the number of dependents is greater than zero, adding an employee must include dependent information. In this example, adding an employee (without adding address, salary and dependent information) does not meet all of the criteria. Other systems may treat maintenance of salary and/or dependent information independently from employee. is self-contained and For example, the add process is not self-contained unless all mandatory information is entered and all the processing steps are included; e.g., validations, calculations, updating the ILFs. leaves the business of the application being counted in a consistent state For example, the user requirements to add an employee include setting up salary and dependent's information. If all the employee information is not added, an employee has not yet been created. Adding some of the information alone leaves the business of adding an employee in an inconsistent state. If both the employee salary and dependent information is added, this unit of activity is completed and the business is left in a consistent state. Identify an elementary process for each unit of activity identified that meets all of the above criteria.

7-10

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Determine Unique Elementary Processes To determine unique elementary processes, the following activities shall be performed When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: Require the same set of DETs and Require the same set of FTRs and Require the same set of processing logic to complete the elementary process Note: One elementary process may include minor variations in DETs or FTRs as well as multiple alternatives, variations or occurrences of processing logic below. Note: When the two elementary processes are compared and it is determined that they contain different DETs, FTRs or Processing Logic, they are identified as separate elementary processes if they are specified as distinct functional requirements by the user. Note: The uniqueness test stated above is intended to be used as a means to compare two EPs that have already been identified and not as justification for splitting a single EP into two EPs as a result of variations. Splitting a single EP into two EPs based on variations would indicate that the rules for identifying an EP were not being satisfied. For example, when an EP to Add Employee requires additional DETs to account for European as well as US employee addresses (postal code/zip code, country/state, phone number country and city code). The EP is not divided into two EPs to account for the minor differences in the employee’s address. The EP is still Add Employee, and there is variation in the processing logic and DETs to account for differences in the address and phone number. For example, when an EP to Add Employee has been identified, it is not divided into two EPs to account for the fact that an employee may or may not have dependents. The EP is still Add Employee, and there is variation in the processing logic and DETs to account for dependents.

January 2010

Function Point Counting Practices Manual

7-11

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

For example, when the functional user requirements specify the need for two similar reports (such as when Report 1 contains Customer Name, Customer Id, and Address and Report 2 contains Customer Name, Customer Id, Address, and Phone Number), the reports are identified as separate EPs since the functional user requirements specify the need for different DETs. The reports are not combined into a single EP simply because they have similar DETs. Do not split an elementary process with multiple forms of processing logic into multiple elementary processes. If an elementary process is inappropriately sub-divided, it would no longer meet the criteria (listed above) of an elementary process.

7-12

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Classify Each Elementary Process Classify each elementary process as an External Input (EI), External Output (EO) or an External Inquiry (EQ) based upon its primary intent. The primary intent of the elementary process shall be identified as one of the following: altering the behavior of the application maintaining one or more ILFs presenting information to the user The forms of processing logic required to complete the elementary process shall be identified from the list presented on page 7-8.

Classify as an EI

It has a primary intent of either: maintaining one or more ILFs or altering the behavior of the application and It includes processing logic to accept data or control information that enters the boundary of the application

Classify as an EO

It has the primary intent of presenting information to the user, and It includes at least one of the following forms of processing logic: mathematical calculations are performed one or more ILFs are updated derived data is created or * the behavior of the application is altered Note: *Calculated fields are a form of derived data, although derived data can also be created without performing a calculation.

Classify as an EQ

It has the primary intent of presenting information to the user, and it: references a data function to retrieve data or control information and does not satisfy the criteria to be classified as an EO

January 2010

Function Point Counting Practices Manual

7-13

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Complexity and Contribution Definitions and Rules The number of EIs, EOs, and EQs and their relative functional complexities determine the contribution of the transactional functions to the functional size. Assign each identified EI, EO and EQ a functional complexity based on the number of file types referenced (FTRs) and data element types (DETs). In applying the FTR/DET rules to the individual transactional function types, it is important to also recognize the differences in the functions that each type can perform in accordance with its classification rules (i.e., an EQ by rule cannot update an FTR; consequently the guidance for counting an FTR for an ILF updated does not apply). To identify the functions that a transactional function type can perform, refer to the table on page 7-8. FTR Definition

A file type referenced is a data function read and/or maintained by a transactional function. A file type referenced includes: •

An internal logical file read or maintained by a transactional function or

•

An external interface file read by a transactional function

FTR Rule

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function.

DET Definition DET Rules

A data element type is a unique, user recognizable, non-repeated attribute. To count DETs for a transactional function, the following activities shall be performed Review everything that crosses (enters and/or exits) the boundary Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

7-14

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Do not count the following items as DETs: literals such as report titles, screen or panel identifiers, column headings and attribute titles application generated stamps such as date and time attributes paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’ navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary EI Complexity and Contribution Guidelines

This section provides guidance used to determine the complexity and contribution of external inputs.

FTR Guidance for an EI

Recognizing that an EI must either update an ILF or control the behavior of the application, the following guidance applies when counting FTRs: Count an FTR for each ILF maintained Count an FTR for each ILF or EIF read Count only one FTR for each ILF that is both maintained and read

DET Guidance for an EI

Recognizing that an EI must either update an ILF or control the behavior of the application, the following guidance applies when counting DETs: Review everything that crosses (enters and/or exits) the boundary Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function For example, job name and pay grade are two fields that the user provides when adding a job.

January 2010

Function Point Counting Practices Manual

7-15

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages For example, if a user tries to add an existing employee to a Human Resources application, the system generates one of several error messages and the incorrect field is highlighted. Count one DET that includes all the system responses which indicate the error conditions, confirm that processing is complete or verify that processing should continue. Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so For example, if the user can initiate the adding of an employee by clicking on the OK button or by pressing a PF key, count one DET for the ability to initiate the process. Do not count the following items as DETs: literals such as report titles, screen or panel identifiers, column headings and attribute titles application generated stamps such as date and time attributes paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’ navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary For example, in order to maintain the US hourly rate for hourly employees working in other countries with other currencies, the local hourly rate is provided by the user. During the processing of all the pieces of data provided to add an employee, a conversion rate is retrieved from the currency system to calculate the US hourly rate. The calculated US hourly rate is maintained on the employee ILF as a result of adding the employee. The US hourly rate would not be counted as a DET for the EI because it does not enter/exit the boundary, but is internally calculated (i.e., it is derived data). attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary For example, when the customer order is added to the system, the unit price is automatically retrieved for each ordered item and stored on the billing record. The unit price would not be counted as a DET for the EI because it did not cross the boundary when the user adds the customer order.

7-16

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

EO/EQ Complexity and Contribution Guidelines

This section provides FTR and DET guidance used to determine the complexity and contribution of external outputs and external inquiries.

FTR Guidance for EQs

Recognizing that an EQ cannot update an ILF, the following guidance applies when counting FTRs for EQs:

FTR Guidance for EOs

Recognizing that an EO can update an ILF, the following additional guidance applies when counting FTRs for EOs:

Count an FTR for each ILF or EIF read

Count an FTR for each ILF or EIF read Count one FTR for each ILF maintained Count only one FTR for each ILF that is both maintained and read

Shared DET Guidance for EOs and EQs

The following guidance applies when counting DETs for both EOs and EQs. Review everything that crosses (enters and/or exits) the boundary Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function For example (EO/EQ), to generate a list of employees, employee name is a field the user provides when indicating which employees to list. For example (EO/EQ), a text message may be a single word, sentence, or phrase—a line or paragraph included on a report to indicate an explanatory comment counts as a single DET. For example (EO/EQ), an account number or date physically stored in multiple fields is counted as one DET when it is required as a single piece of information. For example (EO/EQ), a pie chart might have a category label and a numerical equivalent in a graphical output. Count two DETs —one for designating the category and one for the numerical value. Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages For example (EO/EQ), if a user tries to request a listing, but does not have access to the information, count one DET for the system response.

January 2010

Function Point Counting Practices Manual

7-17

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so For example (EO/EQ), if the user can initiate the generation of a report by clicking on the OK button or by pressing a PF key, count one DET for the ability to initiate the report. Do not count the following items as DETs: literals such as report titles, screen or panel identifiers, column headings and attribute titles For example (EO/EQ), literals include report titles, screen or panel identification, column headings, and field titles. application generated stamps such as date and time attributes For example (EO/EQ), date and time fields if they are displayed. paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’ For example (EO/EQ), page numbers appearing on a report. navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents For example (EO/EQ), previous and next buttons that allow the user to navigate forward and backward through a list of entries. attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary For example (EO), when a paycheck is printed, a status field on the employee ILF is updated to indicate that the check has been printed. Do not count the status field as a DET since it did not cross the boundary. Note: An EQ by rule cannot update an ILF, so this rule would not apply. attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary For example (EO/EQ), when a report of past due accounts is created, the account due date field is referenced to determine whether the account is past due, but it does not appear on the report. Do not count the account due date field as a DET since it did not cross the boundary.

7-18

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Determination of Complexity and Contribution The functional complexity of each transactional function shall be determined using the using the steps below. Step

Action

1

To identify and count the FTRs and DETs, the complexity and contribution counting rules that begin on page 7-14 shall be used.

2

The functional complexity of each transactional function shall be determined using the number of FTRs and DETs in accordance with the following matrices. External Inputs: 1 to 4 DETs

5 to 15 DETs 16 or more DETs

0 to 1 FTRs

Low

Low

Average

2 FTRs

Low

Average

High

High

High

3 or more FTRs Average

External Outputs and External Inquiries: 1 to 5 DETs

6 to 19 DETs 20 or more DETs

0 to 1 FTRs

Low

Low

Average

2 to 3 FTRs

Low

Average

High

High

High

4 or more FTRs Average

January 2010

Function Point Counting Practices Manual

7-19

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

Step 3

Action The functional size of each transactional function shall be determined using the type and functional complexity in accordance with the tables below. External Inputs and External Inquiries: Functional Complexity Rating

Function Points

Low

3

Average

4

High

6

External Outputs: Functional Complexity Rating

7-20

Function Points

Low

4

Average

5

High

7

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Hints to Help with Counting EIs, EOs, and EQs The following hints may help you apply the EI, EO, and EQ rules and perform the functional size measurement. The hints are not rules and should not be used as rules. •

•

Is data received from outside the application boundary? −

Look at the work flow.

−

Identify where the user and other application interfaces occur in the process functional decomposition.

Is the process the smallest unit of activity from the user perspective? − Look at the different paper or on-line forms used. − Review the ILFs to identify how the user groups the information. − Identify where the user and other application interfaces occur in the

process functional decomposition. − Look at what happened in the manual system. − Note that one physical input or transaction file or screen can, when

viewed logically, correspond to a number of EIs, EOs, or EQs. − Note that two or more physical input or transaction files or screens

(e.g., tabs on a screen) can correspond to one EI, EO, or EQ. − Remember that two or more physical reports, screens or batch output

files can correspond to one EO/EQ if the processing logic is identical. •

Is the process self-contained and does it leave the business in a consistent state? − Review other external inputs, external outputs and external inquiries to

understand how the user works with the information. − Work through the process diagram to get hints. − Look at what happened in the manual system. − Check for consistency with other decisions.

January 2010

•

Identify the primary intent of the elementary process before classifying it as an EI, EO, or EQ.

•

Identification of the elementary process(es) is based on a joint understanding or interpretation of the requirements between the user and the developers.

•

Each element in a functional decomposition may not map to a unique elementary process.

Function Point Counting Practices Manual

7-21

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

•

The identification of the elementary processes requires interpretation of the user requirements.

•

Is the processing logic unique from other EIs, EOs, and EQs? − Identify batch inputs or outputs based on the processing logic required. − A transaction which occurs in multiple physical inputs, transaction files

or screens, but which has identical processing logic, typically corresponds to one transactional function (EI, EO, or EQ). − Remember that sorting or arranging a set of data does not make

processing logic unique. •

Are the data attributes different from those for other EIs, EOs, or EQs? − If the data attributes appear to be a subset of the data attributes of

another EI, EO, or EQ, be sure two elementary processes are required by the user—one for the main data attributes and one for the subsets. •

7-22

Count only one FTR for each ILF/EIF referenced even if the ILF/EIF has multiple RETs.

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Measure Transactional Functions

Additional Hints to Help Counting EOs and EQs •

Is the process the smallest unit of activity from the user perspective? − An EO or EQ can be triggered by a process inside the application

boundary. For example, the user requires that a report of all changed employee pay rates be sent to the budgeting area every 8 hours based on an internal clock. Situation A.

The report contains employee name, SSN, and hourly pay rate which are all retrieved from the employee file. This is the smallest unit of activity from the user’s perspective, contains no mathematical formulas or calculations, and no ILF is maintained in the process. This is one EQ.

Situation B.

The report contains employee name, SSN, and hourly pay rate which are all retrieved from the employee file. The report also includes the percentage pay change for the employee which is calculated from the data on the employee file. This is the smallest unit of activity from the user’s perspective, and no ILF is maintained in the process. However, since the process contains a mathematical formula, this is one EO.

− Derived data for an EO does not have to be displayed on the output.

For example, each month, a report is generated listing all employees due for appraisal in the next 30 days. The records are selected by calculating next appraisal date based on the employee’s last appraisal date, which is a field on the employee file, and the current date plus 30 days. This would be counted as an EO, and not as an EQ.

January 2010

Function Point Counting Practices Manual

7-23

Measure Transactional Functions

Part 2 – The Bridge – Applying the IFPUG FSM Method

This page intentionally left blank.

7-24

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

Index

Index to Part 2

A Application function point count, 4-2 B Boundary hints, 5-6 rules, 5-5 C Classify Each Elementary Process, 7-13 Complexity and contribution ILF/EIF definition, 6-5 Complexity and Contribution Definitions and Rules, 7-14 Complexity and contribution procedures external interface files, 6-8 internal logical files, 6-8 Complexity and contribution rules external interface files, 6-5 internal logical files, 6-5 Complexity matrices external inputs, 7-19 external interface files, 6-8 internal logical files, 6-8 Complexity rules. See Complexity and contribution rules Contribution rules. See Complexity and contribution rules Control information

January 2010

ILF/EIF example, 6-2 Counting hints. See Hints D Data element type. See DET Data function types introduction, 6-1 overview, 2-5 Definitions complexity and contribution, 6-5 control information, 6-2 elementary process, 6-3 external interface files, 6-2 functional user requirements, 1-3 internal logical files, 6-2 maintained, 6-3 user identifiable, 6-3 DET definition, 6-5 DET rules ILFs/EIFs, 6-5 Determine Unique Elementary Processes, 7-11 Development project function point count, 4-2 Diagram Types of count, 4-4 Difference between ILFs and EIFs, 6-2 Documentation, 3-1, 3-3 Useful, 3-9

Function Point Counting Practices Manual

i-1

Index

Part 2 – The Bridge – Applying the IFPUG FSM Method

E EI Complexity and Contribution Guidelines, 7-2, 715 EIFs. see External interface files EIs, EOs and EQs Control Information, 7-5 Definition and primary intent, 7-3 Elementary Process, 7-5 Hints, 7-21 Processing Logic, 7-5 Elementary process EIF example, 6-3 ILF example, 6-3 Enhancement project function point count, 4-2 EO/EQ Complexity and Contribution Guidelines, 717 Estimated count, 4-4 Examples control information, 6-2 elementary process for ILFs/EIFs, 6-3 ILF/EIF mandatory subgroups for RETs, 6-7 ILF/EIF optional subgroups for RETs, 6-7 maintained for ILFs/EIFs, 6-3 user identifiable for ILFs/EIFs, 6-3 External inputs complexity matrix, 7-19 External interface files complexity and contribution procedures, 6-8 complexity and contribution rules, 6-5 definition, 6-2 DET rules, 6-5 difference from ILFs, 6-2 example control information, 6-2 example elementary process, 6-3 example maintain, 6-3 example user identifiable, 6-3 hints to help with counting, 6-10 mandatory subgroups for RETs, 6-7 optional subgroups for RETs, 6-7 translation table, 6-8 F File, 6-1 Final counts, 4-4 Function point analysis procedures by chapter, 2-2 Functional Size, 3-10 Functional User Requirements definition, 1-3 G Gather Available Documentation, 3-1 H Hints boundary, 5-6 counting EIFs, 6-10 counting ILFs, 6-10

I Identify Each Elementary Process, 7-10 ILFs. see Internal logical files Internal logical files complexity and contribution procedures, 6-8 complexity and contribution rules, 6-5 complexity matrix, 6-8 definition, 6-2 DET rules, 6-5 difference from EIFs, 6-2 example control information, 6-2 example elementary process, 6-3 example maintain, 6-3 example user identifiable, 6-3 hints to help with counting, 6-10 mandatory subgroups for RETs, 6-7 optional subgroups for RETs, 6-7 translation table, 6-8 International standards ISO/IEC 14143-1 2007, 1-2 L Life Cycle, 3-1, 3-8 M Maintained definition, 6-3 ILF/EIF example, 6-3 Mandatory subgroups, 6-7 Matrices. See Complexity matrices O Optional subgroups, 6-7 P Primary intent table, 7-4 Procedures by chapter, 2-2 external interface files complexity and contribution, 6-8 internal logical files complexity and contribution, 6-8 steps, 2-2 Processing logic table, 7-8 R Record element type. See RET RET definition, 6-7 RET rules mandatory subgroups for ILFs/EIFs, 6-7 optional subgroups for ILFs/EIFs, 6-7 Rules boundary, 5-5 complexity and contribution for ILFs/EIFs, 6-5 DETs for ILFs/EIFs, 6-5 ILF/EIF mandatory subgroups, 6-7 ILF/EIF optional subgroups, 6-7 S Scope creep, 4-4

i-2

Function Point Counting Practices Manual

January 2010

Part 2 – The Bridge – Applying the IFPUG FSM Method

T Transactional function types overview, 2-6 Translation tables ILFs/EIFs, 6-8 Type of count estimated and final counts, 4-4

January 2010

Index

U Unadjusted function point count transactional function types, 7-1 User identifiable definition, 6-3 ILF/EIF example, 6-3 User View, 3-2

Function Point Counting Practices Manual

i-3

Index

Part 2 – The Bridge – Applying the IFPUG FSM Method

This page intentionally left blank.

i-4

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

This page intentionally left blank.

Part 3 Counting Practices Introduction

Contents

Part 3 provides detailed counting practices and enhanced examples to assist practitioners in understanding: •

Code data, including a description of the various types of data, how to distinguish business and reference data from code data, and how to consider code data

•

Logical files, including a description of logical files and the process to correctly group data into logical files, to correctly count record element types, and to correctly count data element types

•

Shared data, including a description of shared data and the process to identify when shared data is a data function (internal logical file, external interface file) or transactional function (external input, external output, external inquiry)

•

Enhancement projects and maintenance activities, including descriptions of enhancement and maintenance and those activities recognized by the function point counting process

Part 3 includes the following chapters: Chapter

January 2010

Page

Code Data

1-3

Logical Files

2-1

Shared Data

3-1

Enhancement Projects and Maintenance Activities

4-1

Data Conversion Activity

5-1

Function Point Counting Practices Manual

1-1

This page intentionally left blank.

1-2

Function Point Counting Practices Manual

January 2010

Part 3 Chapter 1

Code Data Introduction

This chapter uses the concepts of functional and non-functional user requirements (described in Part 1, and in “A Framework for Functional Sizing” [IFPUG, 2003]) to identify code data and determine how it should be considered. This chapter addresses specifically a number of examples pertaining to code data. It is recognized that there may be other examples of code data and these may be addressed in a future release of the CPM.

Contents

This chapter includes the following sections: Topic

January 2010

See Page

Types of Data Entities

1-4

Methodology

1-9

Identifying Code Data

1-10

Considering Code Data and Code Data Transactions

1-14

Bibliography

1-15

Function Point Counting Practices Manual

1-3

Code Data

Part 3 – Counting Practices

Types of Data Entities A review of the application data and its purpose provides an understanding of the various categories of data entities. In general, counters should distinguish between three categories of data entities: •

Business Data

•

Reference Data

•

Code Data

The first two categories of entities are usually identified to satisfy the Functional User Requirements, and as such these entities will be investigated for counting as logical files (see Part 3, Chapter 2). The third category of data, further referred to in this chapter as “Code Data”, however, usually exists to satisfy non-functional user requirements from the user (for quality requirements, physical implementation and/or a technical reason) rather than functional user requirements. The different categories of data are outlined below to assist in identification.

Business Data Business Data may also be referred to as Core User Data or Business Objects. This type of data reflects the information needed to be stored and retrieved by the functional area addressed by the application. Business Data usually represents a significant percentage of the entities identified. It has most of the following characteristics: Logical

1-4

Logical characteristics include: •

Mandatory for the operation of the users’ functional area

•

User identifiable (usually by a business user)

•

User maintainable (usually by a business user)

•

Stores the users’ Core User Data to support business transactions

•

Very dynamic - normal business operations cause it to be regularly referenced and routinely added to, changed or deleted

•

Reported on

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Physical

Examples

Code Data

Physical characteristics include: •

Has key fields and usually many attributes

•

May have zero to infinity records

Examples of Business Data include: •

Customer File, Invoice File, Employee File, Job File

•

Job File, within the Job Management System, would include items such as: •

Job Number,

•

Job Name,

•

Division Name,

•

Job Initiation Date, etc.

Reference Data This type of data is stored to support the business rules for the maintenance of the Business Data; e.g., in a payroll application it would be the data stored on the government tax rates for each wage scale and the date the tax rate became effective. Reference Data usually represents a small percentage of entities identified. It has most of the following characteristics: Logical

January 2010

Logical characteristics include: •

Mandatory for the operation of the users’ functional area

•

User identifiable (usually by a business user)

•

Usually user maintainable (usually by an administrative user)

•

Usually established when the application is first installed and maintained intermittently

•

Stores the data to support core user activities

•

Less dynamic – occasionally changes in response to changes in functional areas’ environment, external functional processes and/or business rules

•

Transactions processing Business Data often need to access Reference Data

Function Point Counting Practices Manual

1-5

Code Data

Physical

Examples

Part 3 – Counting Practices

Physical characteristics include: •

Has key fields and few attributes

•

Usually at least one record or a limited number of records

Examples of Reference Data include: •

Jobs Rates, Discount Rates, Tax Rates, Threshold Settings

•

Job Rates File – stores information about the rates paid for each type of job and the skill required to do that type of job •

Job Type

•

State, Charge Rate, Effective Date (1:n)

•

Job Skill Description (1:n)

Code Data The user does not always directly specify Code Data, sometimes referred to as List Data or Translation Data. In other cases it is identified by the developer in response to one or more non-functional user requirements of the user. Code Data provides a list of valid values that a descriptive attribute may have. Typically the attributes of the Code Data are Code, Description and/or other ‘standard’ attributes describing the code; e.g., standard abbreviation, effective date, termination date, audit trail data, etc. When codes are used in the Business Data, it is necessary to have a means of translating to convert the code into something more recognizable to the user. In order to satisfy non-functional user requirements, developers often create one or more tables containing the Code Data. Logically, the code and its related description have the same meaning. Without a description the code may not always be clearly understood. The key difference between Code Data and Reference Data is: •

With Code Data, you can substitute one for the other without changing the meaning of the Business Data; e.g., Airport-Code versus AirportName, Color-Id versus Color-Description.

•

With Reference Data, you cannot substitute (e.g., Tax Code with the Tax-Rate).

Code Data has most of the following characteristics:

1-6

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical

Physical

Examples

Logical Characteristics include: •

Data is mandatory to the functional area but optionally stored as a data file

•

Not usually identified as part of the functional user requirements; it is usually identified as part of design to meet non-functional user requirements

•

Sometimes user maintainable (usually by a user support person)

•

Stores data to standardize and facilitate business activities and business transactions

•

Essentially static - only changes in response to changes in the way that the business operates

•

Business transactions access Code Data to improve ease of data entry, improve data consistency, ensure data integrity, etc.

•

If recognized by the user: •

Is sometimes considered as a group of the same type of data

•

Could be maintained using the same processing logic

Physical characteristics include: •

Consists of key field and usually one or two attributes only

•

Typically has a stable number of records

•

Can represent 50% of all entities in Third Normal Form

•

Sometimes de-normalized and placed in one physical table with other Code Data

•

May be implemented in different ways (e.g., via separate application, data dictionary, or hard-coded within the software)

Examples of Code data include: •

•

January 2010

Code Data

State •

State Code

•

State Name

Payment Type •

Payment Type Code

•

Payment Description

Function Point Counting Practices Manual

1-7

Code Data

Part 3 – Counting Practices

Origin of Code Data Historically, the reason for Code Data was to save space by storing a code rather than a lengthy textual description. For ease of maintenance, these codes and descriptions were placed in files or tables to eliminate software changes when updates were necessary. The Code Data is a property of a descriptive attribute, so called “Meta Data”. Examples are valid values, code-descriptions or translation tables. Some Code Data is developed to meet specific user requirements and contain data that is within the user’s domain. Other Code Data may be derived from user requirements to restrict the values allowed. Code Data may also be created in an attempt to reduce requirements for disk space. Requirements may also include the ability to maintain Code Data. All of these are non-functional user requirements. Code Data is an implementation of non-functional user requirements. As a consequence, Code Data may influence the non-functional size of the software product, but not the functional size of the software product [“A Framework for Functional Sizing”, IFPUG 2003].

1-8

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Code Data

Methodology The impact of code data belonging to the non-functional dimension is that Code Data should not be counted nor should the transactions to maintain Code Data.

Introduction The section “Identifying Code Data” below provides a stepwise process for identifying what is and what is not code data. The section is typically referenced in the step “Identify Logical Files”, as defined in Part 3 – Chapter 2, where code data is filtered out. As previously stated, code data is not considered part of the functional size. This has several consequences. To be perfectly clear in this Implementation Guide we summarize the consequences below.

Consequences 1

Do not count Code Data as a Logical File

2

A consequence of filtering out Code Data is that Code Data cannot be considered an ILF or EIF. Do not count Code Data as a RET or DETs A consequence of filtering out Code Data is that Code Data cannot be considered a RET or DETs on an ILF or EIF.

3

Do not count Code Data as an FTR A consequence of filtering out Code Data is that Code Data cannot be considered an FTR while assessing the complexity of a transactional function (EI, EO, EQ), because it is not a logical file.

4

Do not count Code Data Transactional Functions A consequence of Code Data being a part of another dimension (the non-functional dimension as opposed to the functional dimension) is that Code Data maintenance or reporting functions are not taken into account when measuring the functional size of the application.

January 2010

Function Point Counting Practices Manual

1-9

Code Data

Part 3 – Counting Practices

Identifying Code Data The Code Data types summarized in “What Is Code Data” and “What Is Not Code Data” may be used as a practical help in order to determine whether or not an entity is Code Data. Some criteria partly overlap. As soon as the criteria of one of the subsections have been satisfied, the entity should be considered Code Data and not counted. The examples provided are not an exhaustive list and may not cover all possible cases. When in doubt, evaluate entity types within the context of “Types of Data Entities”.

What Is Code Data Introduction

Types of Code Data

These are the several different types of Code Data, which fall into three general areas: •

Substitution Data provides a code and an explanatory name or description for an attribute of a business object (Substitution is a sufficient condition, but not a necessary condition to be considered Code Data).

•

Static or Constant Data is data that rarely changes.

•

Valid Values Data provides a list of available values for an attribute of one or more business object types.

Substitution Code + Description

Static or Constant One Occurrence Static Data Default Values

Valid Values Valid Values Range of Valid Values

Any of these types of Code Data may also include other attributes, such as effective date and termination date to define the time period for which the value is available. It may also include audit type attributes of creation date, created by (user-id), last updated date, last updated by (user-id). Also, a number of variations are possible (e.g., code + short/long description). The presence of these additional attributes does not affect the categorization process, but the attributes are considered to be part of the Code Data.

1-10

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Code Data

Substitution Code + Description

Examples

Variations

This type of Code Data contains a code and an explanatory name or description. This type of Code Data may serve as quick data entry means for experienced users, the explanatory name / description for less experienced users or for listings as in reporting. This type of Code Data may also be implemented to save storage space or be a result of normalization. If it is substitution data, it is Code Data and is not counted. •

States: State Code, State Name

•

Colors: Color Code, Color Description

•

Code, Language, Description (for descriptions in multiple languages)

•

Code, Short Description, Long Description, Abbreviation

Static or Constant One Occurrence

Examples

Static Data

Examples

Default Values (template)

January 2010

This type of Code Data contains one and only one occurrence regardless of the number of attributes. The Code Data has only one row of data and the attributes are relatively constant; it may change, but very rarely. •

An entity with data about a particular organization; e.g., name and address.

•

COTS Software with airline name, customized by user organization

This type of Code Data contains data that is basically static. The number of instances of static data may change, but very rarely, and the contents of an instance rarely change. •

An entity chemical elements: mnemonic, atomic number, description

•

The function point tables for valuing function types and complexity levels

This type of Code Data contains default values for (some attributes in) new instances of a business object.

Function Point Counting Practices Manual

1-11

Code Data

Part 3 – Counting Practices

Valid Values Valid Values

Examples

Range of Valid Values Examples

1-12

This type of Code Data provides a list of valid values for an attribute of one or more business object types. This type of Code Data is implemented to satisfy requirements such as reducing errors and increasing user friendliness. This type of Code Data is typically used to list available values for user selection and/or validating input provided by the user. This type of Code Data contains data that is basically static; if it is not, it may be Reference Data or Business Data. •

State name: contains all valid values for the attribute state name

•

State code: contains all valid values for the attribute state code

•

Color: contains all valid values for the attribute color of a business object

This type of Code Data contains data that is basically static; if it is not, it may be Reference Data. •

Allowable Telephone Number Ranges: lowest telephone number, highest telephone number.

•

Heat temperature range.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Code Data

What Is Not Code Data This section describes data that is not considered Code Data because it is either Business Data or Reference Data. CPM Part 1 and Part 2 – Chapter 2 (Logical Files) contain the rules for these types of entities. Sometimes tables are called ‘code tables’ but are in reality Reference Data or even Business Data. Examples

January 2010

Examples of Business or Reference Data that should not be considered Code Data: •

Entity types with financial amounts, exchange rates, and tax rates, if they are not constants. This data does not restrict valid values; rather, it adds meaning to a value within a particular range.

•

Control data: User-maintained data that contains business rules telling the application what to do or how to behave.

•

Currency Exchange Rate Table: Exchange rates contain country and current exchange rate to US dollars. It is not possible to substitute the code for exchange rate of the country, the data is essentially not static, and the data supports business activities; therefore, this is an example of Reference Data.

•

Tax Rate Ranges for a Progressive Tax System: A different tax rate is applicable for different ranges of income. This contains minimum and maximum values for each tax rate. However, you cannot substitute the value for the entity, and the data supports business activities. The tax rate does not restrict the income range. Therefore, this is an example of Reference Data.

Function Point Counting Practices Manual

1-13

Code Data

Part 3 – Counting Practices

Considering Code Data and Code Data Transactions The Code Data as identified in “What Is Code Data” represents the implementation of non-functional user requirements rather than the implementation of a Functional User Requirement. As a consequence, Code Data and the transactions to maintain Code Data do not count towards the functional size of an application. However, data that exists as part of non-functional user requirements could be measured using a separate measure to size the non-functional size. At this moment there are no separate methods available to count Code Data and their maintenance and reporting functions to yield a size of the nonfunctional dimension.

1-14

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Code Data

Bibliography The following sources were consulted or cited in this chapter: Definitions and Counting Guidelines for the Application of Function Point Analysis: A Practical Manual, Version 2.2. (NESMA, 2003). ISBN: 90-76258-17-1. Note: This manual is also called NESMA Counting Practices Manual. It describes the standard FPA methodology, and many aspects related to the application of FPA. It may be used together with the IFPUG manual. For more information, see the NESMA web site www.nesma.org. IFPUG “A Framework for Functional Sizing”, IFPUG, 2003. ISO/IEC 14143-1:2007 Information technology – Software measurement Functional size measurement – Part 1: definition of concepts, ISO/IEC, 2007

January 2010

Function Point Counting Practices Manual

1-15

Code Data

Part 3 – Counting Practices

This page intentionally left blank.

1-16

Function Point Counting Practices Manual

January 2010

Part 3 Chapter 2

Logical Files Introduction

This chapter applies the definitions and rules pertaining to logical files, using a descriptive process for the identification and classification of data functions. These guidelines illustrate the identification of data functions from normalized data models. An overview of data normalization is provided to support this approach. However, this does not preclude the use of these guidelines in environments where alternative data or object modeling techniques are employed.

Contents

This chapter includes the following sections: Topic

January 2010

See Page

Outline of the Methodology

2-2

Data Modeling Concepts

2-3

Step 1: Identify Logical Files

2-8

Step 2: Classify Logical Files

2-21

Step 3: Identify Data Element Types

2-21

Step 4: Identify Record Element Types

2-31

Bibliography

2-42

Function Point Counting Practices Manual

2-1

Logical Files

Part 3 – Counting Practices

Outline of the Methodology Introduction A stepwise process for establishing the set of logical files (Internal Logical Files and External Interface Files) is used where each step looks at the data at a finer level of detail. Details of each step are explained in the subsequent sections. Step 1

Action Identify Logical Files

2

For each logical data entity, identify how related entities are to be grouped into logical files, which reflect the ‘user view’. e.g., determine whether data entities are themselves an independent logical file or whether related entities should be grouped into a single logical file. This step is explained in the Section "Step 1: Identify Logical Files". Classify Logical Files

3

Each identified logical file is classified as ILF or EIF. This step is explained in the Section "Step 2: Classify Logical Files". Identify Data Element Types For each logical file, identify the data elements used by the application being measured. This step is explained in the Section "Step 3: Identify Data Element Types".

4

Identify Record Element Types For each logical file, identify how related data are to be grouped into record element types, which reflect the ‘user view’. This step is explained in the Section "Step 4: Identify Record Element Types".

The step with the most impact on the functional size is Step 1: Identify Logical Files, because the identification of the right number of logical files is crucial in achieving inter-counter consistency. The remaining steps influence the functional size to a considerably lesser degree because they don’t affect the number of logical files, only their type and complexity rating.

2-2

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Data Modeling Concepts Introduction A review of the definitions used in the domain of data analysis (which includes logical and physical data modeling) can provide both a foundation of understanding as well as a clarification to the intent of the counting practices rules as they relate to the identification of Logical Files, Record Element Types, and Data Element Types. A strong understanding of data modeling concepts is implicit in Function Point Analysis when appropriately and correctly measuring the Data Functions. Section “Data Modeling Terms” summarizes the data modeling terms. Key Concepts in Data Modeling A review of the definitions used in the domain of data analysis (which includes data modeling and DBMS) can provide both a foundation of understanding as well as a clarification to the intent of the counting practices rules as they relate specifically to Logical Files, Record Element Types (RETs), and Data Element Types (DETs). An understanding of data concepts is implicit to apply the guidelines as described in the next chapters to appropriately and correctly measure the Data Functions. Entity (type)

January 2010

Definitions of Entity (or Entity Type)

Any distinguishable person, place, thing, event or concept about which information is kept (Thomas Bruce, 1992)

A thing that can be distinctly identified (Peter Chen, 1976).

Any distinguishable object that is to be represented in the database (C.J. Date, 1986)

A data entity represents some "thing" that is to be stored for later reference. The term entity refers to the logical representation of the data (Clive Finkelstein, 1989)

The word entity means anything about which we store information (e.g. a customer, supplier, machine tool, employee, utility pole, airline seat, etc.). For each entity, certain attributes are stored (James Martin, 1989)

An entity may also represent the relationship between two or more entities, called associative entities (Michael Reingruber, 1994)

An entity may represent a subset of information relevant to an instance of an entity, called subtype entity (also known as secondary or category entity) (Michael Reingruber, 1994)

Function Point Counting Practices Manual

2-3

Logical Files

Part 3 – Counting Practices

To summarize, an entity:

Data Element

is a principal data object about which information is collected

is a person, place, thing or event of information

can have an instance (an occurrence)

is a fundamental thing of relevance to the user, about which a collection of facts is kept; an association between entities that contains attributes is itself an entity

involves information, a representation of similar things that share characteristics or properties

often depicted in a data model through a rectangle, with entity name written inside the rectangle

In the world of data modeling, the base element is called the data element or data item. It is

the fundamental component

the fundamental atomic particle in the information system universe (Gary Schutt)

the smallest named unit of data that has meaning in the real/user world (Graeme Simsion)

Data Modeling Activities Data modeling addresses data items, logical records and files. A File System is composed of records and data items. Data items are defined as the smallest named unit of data that has meaning to the real world. A group of related items that is treated as a unit is known as a record. A file is a collection of records of a single type. In the physical implementation of data through relational databases, the following terms are used: a data item is called an "attribute" or "column", a record is called a "row" or "tuple", and a file is called a "table". These terms do not change the base meaning of the concepts.

2-4

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Mapping Data Concepts to Function Point Terminology

We can further map these terms to function point analysis as shown in the following matrix: Data Modeling Concept Smallest named unit of data that has meaning to the real world Groups of related items which are treated as a unit

Collection of records of a single type

Data Modeling Term Data Item

Relational FPA Term Database Term Attribute or Data Element Column Type (DET)

Record

Row or Tuple

Record Element Type (RET)

File

Table

Logical File (Internal Logical File ILF or External Interface File EIF)

FPA Concept

A data element type (DET) is a unique, user recognizable nonrepeated field A record element type (RET) is a user recognizable subgroup of data elements within an ILF or EIF File refers to a logically related group of data and not the physical implementation of those groups of data

Once all required data has been identified, the data analyst applies various normalization rules to depict the data in various Entity Relationship Diagrams. A summary of normalization rules can be found in Section “Data Modeling Terms”.

Data Modeling Terms Principal data objects about which information is collected Entity (or Entity Type) Person, place, thing or event of information

Associative Entity Type

January 2010

Entity instance (an occurrence)

Depicted through a rectangle, with entity name written inside the rectangle

A fundamental thing of relevance to the user, about which a collection of facts is kept. An association between entities that contains attributes is itself an entity

An entity type that contains attributes which further describe a many-to-many relationship between two other entity types.

Function Point Counting Practices Manual

2-5

Logical Files

Part 3 – Counting Practices

Attributive Entity Type

An entity type that further describes one or more characteristics of another entity type.

Entity Subtype

A subdivision of entity type. A subtype inherits all the attributes and relationships of its parent entity type, and may have additional, unique attributes and relationships.

Relationships Represent real-world associations among one or more entities

One-to-One

One-to-Many

Many-to-Many

Represented by a line which connects the entities.

The relationship name is written besides the line

Relationships are defined by the way the entities are connected:

Attributes

Normalization

Optional, shown in text with parentheses 1:(N), (1):(N)

Mandatory, shown in text without parentheses 1:1, 1:N

A characteristic of an entity. Attributes are generally analogous to Data Element Types (DETs).

Data is normalized through 5 rules 1. Eliminate Repeating Groups (1st Normal Form) 2. Eliminate Redundant Data (2nd Normal Form) 3. Eliminate Columns not dependent on Key (3rd Normal Form) 4. Isolate Independent multiple Relationships (no table may contain two or more 1:N or N:M relationships – 4th Normal form) 5. Isolate semantically related multiple relationships (practical constraints may justify separating logically related many to many relationships – 5th Normal form) When performing function point analysis, it is preferable to analyze the logical data model in 3rd Normal Form. Ignore multiple entities placed for technology (often 5th normal form)

2-6

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Entity Relationship Concepts Once all required data has been identified, the data analyst applies various normalization rules to depict the data in various Entity Relationship Diagrams. The following table can be applied to further understand the concept of Record Element Types. Entity Relationship Concept Principal data objects about which information is collected (person, place, thing or event); a fundamental item of relevance to the user about which a collection of facts is kept An entity type that contains attributes which further describe relationships between other entities An entity type that further describes one or more characteristics of another entity type A division of an entity type, which inherits all the attributes and relationships of its parent entity type; may have additional, unique attributes and relationships

January 2010

E-R Term

FPA Term

IFPUG Definition

Entity or Entity Type

Internal Logical File (ILF) or External Interface File (EIF)

File refers to a logically related group of data and not the physical implementation of those groups of data

Associative Entity Type

Record Element Type (RET)

User recognizable (optional or mandatory) subgroup of data elements within an ILF or EIF

Attributive Entity Type

Record Element Type (RET)

User recognizable (optional or mandatory) subgroup of data elements within an ILF or EIF

Entity Subtype

Record Element Type (RET)

User recognizable (optional or mandatory) subgroup of data elements within an ILF or EIF

Function Point Counting Practices Manual

2-7

Logical Files

Part 3 – Counting Practices

Step 1: Identify Logical Files Background In FPA, a logical file is a logical group of data as seen by the user. A logical file is made up of one or more data entities. This chapter provides guidelines on how to group the candidate entities identified into one or many logical files. The process consists of the following steps, all of which are explained in detail in the following paragraphs of this section: Step 1 Substep 1.

Identify all logically related and user recognizable data or control information within the counting scope

2. 3. 4. 5. 6.

Exclude entities that are not maintained by any application Group related entities that are entity dependent into logical files Exclude those entities referred to as code data Exclude entities that do not contain attributes required by the user Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

The most difficult step is the grouping of data (Substep 3). The final grouping of data into logical files is the result of the combined effect of two grouping methods:

Method a) is process driven, based on the user transactions in the application

Method b) is data driven, based on the business rules

However, because the user transactions are (or should be) based on the business rules as well, both methods support each other. This double approach may disclose eventual shortcomings in the functional specifications and makes the identification process of logical files reliable and repeatable. Substep 1.1

2-8

Identify all logically related and user recognizable data or control information within the counting scope Before deciding which entities should be grouped together into logical files, one should determine which candidate entities should be taken into consideration for the logical grouping of the entities (Substep 1.3) and which should be excluded. The following steps will help to identify these entities in a repeatable way.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

The general guiding principle of Part 1 – Measure Data Functions is clear: consider only entities that are significant to and required by the user. Pay special attention when identifying logical files from a (normalized) data model:

Do not assume that all entities are logical files; e.g., index files, entities on a physical data model

Logical files may exist from a user perspective, but may not be identified in the (normalized) data model in some cases; e.g., historical files containing aggregated data. Do not forget to include these logical files in the rest of the process

Substep 1.2

Exclude entities that are not maintained by any application Determine which entities are not maintained by an elementary process in this or another application. Exclude these entities from further consideration because they are not counted.

Substep 1.3

Group related entities that are entity dependent into logical files For each remaining logical data entity, identify how related entities are to be grouped into logical files, which reflect the ‘user view’; i.e., determine whether data entities are themselves an independent logical file or whether related entities should be grouped into a single logical file. Identify the user view (= business view) of the data grouping by investigating: a) How the data is accessed as a group by elementary processes within the boundary (Substep 1.3a, page 2-11) b) The relationships between the entities and their interdependency based on business rules (Substep 1.3b, page 2-12 through 2-20).

Substep 1.4

Exclude those entities referred to as code data Filter out code data. Code data is included as a response to non-functional user requirements from the user (quality requirements, physical implementation and/or a technical reason). Code data is explained in detail in Part 3 - Chapter 1 “Code Data”.

Substep 1.5

Exclude entities that do not contain attributes required by the user Determine which entities do not contain user-recognizable attributes required by the user, but contain non-functional attributes only. Examples of these non-functional attributes are attributes that exist as a result of a design or implementation consideration; e.g., index files created for performance reasons such as the alternate index (see Part 1 – Measure Data Functions). Exclude these entities from further consideration; they are not counted as a logical file or RET.

January 2010

Function Point Counting Practices Manual

2-9

Logical Files

Part 3 – Counting Practices

Substep 1.6

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities 1.6.1 Determine which entities are associative entities. An associative entity contains the foreign keys of the connected entities in addition to other attributes. Note that two situations can arise as a result: a) The additional non-key attributes are a result of a design or implementation consideration or to satisfy a non-functional user requirement (not required by the user; e.g., a date/time stamp for data recovery purposes). These non-functional attributes are not counted as data elements. Treat these entities as key-to-key entities (see below). b) The additional non-key attributes are necessary to satisfy the functional user requirements and are required by the user. These entities are assessed in the next sections: Identify Logical Files (Step 1.3a/1.3b). Example: Order Order#

Order-Product Order# (FK) Product# (FK) Timestamp

Product Product#

Timestamp is usually a non-functional attribute not recognized by the user. In that case, for the Order-Product entity, situation 1.3a applies. The key-to-key entity is resolved by adding the Product# as a foreign key to Order and the Order# to Product (step 1.6).

1.6.2 Determine which entities are key-to-key (intersection) entities; i.e., they only have keys as their data elements and do not have any other non-key attributes. These entities typically represent the implementation of a many to many (N:M) relationship in a normalized data model. They exist for data modeling and data base design purposes only and not as the result of a user requirement. Exclude these entities from further consideration; they are not counted as a logical file or RET. According to the rules (Part 1), the referring attribute (foreign key) is counted as a data element for both entities connected by this key-to-key entity. See also the guidelines in Section "Step 3: Identify Data Element Types". Final Check

2-10

Check if all remaining entities are a result of functional user requirements. These entities, and the relationships and interdependencies between these entities, will be assessed in the next Section: Identify Logical Files (Substep 1.3a/1.3b).

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Identify Logical Files Using Elementary Process Method (Substep 1.3a) The user’s business view of the data is reflected in how the user transactions access the data. Review how the elementary processes within the boundary maintain the entities. If several entities are always created together and deleted together then this is a strong indication that they should be grouped into a single logical file. Also review the elementary processes used to extract the data to determine if the extraction processes access the same group of entities. Note: transactions which modify data will often just target one entity in the group, so the modify transactions are not as effective for grouping data as the create and delete transactions. Example

A customer purchase order is a single group of data from a user business perspective, it is made up of the Order Header (customer, address, date, etc.) and the details about each item ordered. From a business perspective an order cannot be created unless it has at least one item and if the order is deleted both the header and all items are deleted. However the header and items may have independent maintenance transactions; e.g., change order status, is a different function than changing items ordered. The create and delete functions indicate from a user perspective that ‘order’ is a single logical file which has grouped the order header and order items. Use Substep 1.3a to validate the identified candidate logical data groups.

January 2010

Function Point Counting Practices Manual

2-11

Logical Files

Part 3 – Counting Practices

Identify Logical Files Using Entity (In-)Dependency Method (Substep 1.3b) Introduction The Entity (In-)Dependency Method, as defined and explained in this section, provides a repeatable approach to correctly identifying logical files (LFs) from a data model. The term "entity" in this section refers to an entity in a data model in a normalized form (usually 3rd Normal Form). Section “Types of Relationships” explains the different types of relationships, and the difference between the concepts "mandatory/optional relationship" and "entity dependence/independence". Section “Entity (In-)Dependence Illustrated for All Types of Relationships” explains the method in more detail for each type of relationship. Section “Summary: from Entities to Logical Files via Entity (In-)Dependence” summarizes the types of relationships and the conditions when to count a LF. The Entity (In-)Dependency Method groups entities by assessing the relationships and interdependencies of the entities against the business rules. The guiding principles are entity independence and entity dependence. Entity Independence

Entity independence means An entity that is meaningful or significant to the business, in and of itself without the presence of other entities.

Entity Dependence

Entity dependence means An entity that is not meaningful or is not significant to the business, in and of itself without the presence of other entities such that

Note

2-12

•

an occurrence of entity X must be linked to an occurrence of entity Y

•

the deletion of an occurrence of entity Y results in the deletion of all related occurrences of entity X

Do not confuse the concept of entity independence/entity dependence with the concept of optional / mandatory relationship. The examples in Section "Entity (In-)Dependence Illustrated for All Types of Relationships" clearly show that these are different concepts.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Determine Dependency

Logical Files

To determine whether entity B is dependent on or independent of A, one needs to determine: “Is B significant to the business apart from the occurrence of A linked to it?” An easy test to determine the situation (entity dependency or independence) is the following. Even if there is no user requirement for deletion, (still) ask yourself the question: "Suppose we would want to delete an occurrence "a" of entity A, what would happen to an occurrence "b" of entity B linked to “a”?" Depending on the business rules two essentially different situations are distinguished:

Situation 1

If an occurrence of B according to the business rules does not have independent meaning/significance to the user and might be deleted as well, then apparently the occurrence of B does not have meaning to the user apart from the linked occurrence of A. Entity B is considered to be entity dependent on A. The entities A and B should be grouped together into one logical file.

Situation 2

If the occurrence of B does have meaning to the business even apart from the linked occurrence of A, the business rules will not allow deleting the occurrence of B. The entities A and B are considered to be separate logical files. Assessing the data model of an information system by assessing all pairs of linked entities results in the identification of the logical files. In Section "Entity (In-)Dependence Illustrated for All Types of Relationships" this method is explained in more detail for different types of relationships. Section "Summary: from Entities to Logical Files via Entity (In-)Dependence" summarizes per relationship type how to count it within FPA.

January 2010

Function Point Counting Practices Manual

2-13

Logical Files

Part 3 – Counting Practices

Types of Relationships Before making the Entity (In-)Dependence principle conclusive for all types of relationships, one should clearly understand the different types/natures of relationships. This section explains the different types as well as the concepts "optional" and "mandatory". Example

Two entities, Job and Employee for example, can be connected to each other via a relationship; e.g., "employs".

Nature of Relationship

The nature of the relationship determines how many employees can work on a job according to the data model (0, 1, or more) and how many jobs a single employee can work on (0, 1, or more).

1:N

Assume that the business rule states that several employees can be used for a job (but at least one), and that a single employee must work on one (and only one) job. In such a case we say that the relationship between Job and Employee is 1:N.

Job

employs Employee

1 : (N)

More likely the business rules state that a job can have a vacancy, i.e., no employee(s) is (are) assigned to the job. In this case the relationship between Job and Employee is optional and denoted as 1:(N).

Job

employs Employee

(1) : N

If the business rules state that an employee can exist without a job, but a job always must have an employee assigned to it, we denote the relationship between Job and Employee as (1):N.

Job

employs Employee

(1) : (N)

In the situation where a job can have vacancies and an employee can exist without a job, both sides of the relationship are optional. The relationship between Job and Employee is denoted as (1):(N).

Job

employs Employee

2-14

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Concept “Mandatory/Optional” versus “Entity (In)Dependence”.

To clarify the difference between the concepts "mandatory/optional relationship" and "entity dependence/independence" assume, as an example, the following extension of the business rules “employee(s) is (are) not allowed without a job” (relationship types 1:N and 1:(N)). When a job becomes obsolete, this does not mean that employees are no longer of significance to the business. An employee has significance to the business apart from the linked job. Employee is entity independent of job. Because of the mandatory relationship with job, all employee(s) must be reassigned to a new job, before job can be deleted. So it can happen that an occurrence of entity B (e.g., Employee) may have a mandatory link to an occurrence of entity A (e.g., Job) in the relationship A:B between entities A and B, but that entity B does have significant meaning of its own to the business. In such a case, when one would want to delete an occurrence of entity A, one must first reassign a linked occurrence of B to another occurrence of A.

Entity (In-)Dependence Illustrated for All Types of Relationships Entity (In-)Dependence in a (1):(N) Relationship

(1) : (N)

If a relationship between two entities A and B is bilaterally optional, the entities can exist independently and (all occurrences of) A and B are significant to the business apart from the linked occurrence(s) of the other entity. Therefore, A and B are considered entity independent of each other. FPA counts the entities A and B as two separate logical files as indicated in the table in Section "Summary: from Entities to Logical Files via Entity (In-)Dependence".

Entity (In-)Dependence in a 1:(N) Relationship

1 : (N)

In a 1:(N) relationship between two entities A and B (see figure 1), an occurrence of entity A may exist to which none, one or many occurrences of entity B are linked. On the other hand, each occurrence of B must be assigned to an occurrence of A.

Example

In the 1:(N) relationship between Employee and Child (or Dependent) in an HR-application, an Employee may have 0, 1 or many Children linked to it, but a Child must be linked to one (and only one) Employee (see figure 2).

January 2010

Function Point Counting Practices Manual

2-15

Logical Files

Part 3 – Counting Practices

Because B must be linked to an A, this raises the question whether B is dependent on or independent of A. To determine whether entity B is dependent on or independent of A, one needs to answer: “Is B significant to the business apart from the A linked to it?” The following is an easy test to differentiate between entity dependence and independence. Even if there is no user requirement for deletion, ask yourself the question: "Suppose we would want to delete an occurrence of entity A, what would happen to the linked occurrences of entity B which has a mandatory link to an occurrence of A?" The business rules can result in two possibilities: Situation 1

If the deletion of A is allowed, all Bs linked to it must be deleted as well, because the business is no longer interested in the occurrences of B. For example (see figure 2): An HR application maintains information about employees and their children. Assume that the business rule states that when an Employee (A) leaves the company, there is no significance for the business to keep the information about the Children (B).

Situation 2

The deletion of A is not allowed as long as Bs are still linked to it, because the business is still interested in the Bs, even beyond the context of the linked A. For example (see figure 3): An organization adopts children and assigns each child to an employee. The employee is the contact person between the company and the child. In the case when an employee leaves the company, information about the associated children (of the terminated employee) is still significant to the business. So, before you are allowed to delete the Employee (A), you will first have to assign an associated Child (B) to another Employee (A) (because the nature of the relationship does not allow a Child without a linked Employee). In situation (1) we say that B is entity dependent on A, and in situation (2) that B is entity independent of A. FPA counts the entities A and B as one logical file in situation (1) (dependence), whereas in situation (2) A and B are each a separate logical file (independence) as indicated in the table in Section "Summary: from Entities to Logical Files via Entity (In-)Dependence".

2-16

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Illustration of 1:(N) relationships:

A

Employee

Employee

B

Child

Company Adopted Child

Fig. 1: Each entity of type A may be linked to 0, 1 or many entities of type B. An entity of type B must be linked to exactly one entity of type A.

Fig. 2: HR application maintains information about Employees and their Children.

Fig. 3: HR application maintains information about Employees and about company adopted Children who are assigned to an Employee. Figures 2 and 3 have similar data models, but different business rules result in different logical files identified.

Entity (In-)Dependence in a (1):N Relationship

(1) : N

A (1):N relationship between two entities A and B (see figure 4) can be treated in a similar way. These kinds of relationships, however, seldom appear in practice. In a (1):N relationship between two entities A and B, each A must be assigned 1 or many Bs. On the other hand, a B may (but need not) be assigned to one occurrence of A.

Example

In the (1):N relationship between Committee and Organization Member, a Committee must have members (at least 1). An organizational member may (but need not) serve on a Committee (see figure 5 and 6). Because an occurrence of A must be linked to a B, this raises the question whether A is dependent on, or independent of B. To determine whether entity A is dependent on or independent of B, one needs to answer: “Is A significant to the business apart from the B linked to it?” The following is an easy test to differentiate between entity dependence and independence. Even if there is no user requirement for deletion, ask yourself the question:

January 2010

Function Point Counting Practices Manual

2-17

Logical Files

Part 3 – Counting Practices

"Assume we have an occurrence of entity A to which one or more occurrences of entity B are linked. Suppose we would want to delete the final linked occurrence of entity B, what would happen to that occurrence of A which has a mandatory link to at least one occurrence of B?" The business rules can result in two possibilities: Situation 1

When the last B is deleted, the linked A is also deleted because the business is no longer interested in that A. For example (see figure 5): An organization has committees to which members are assigned. The business rule is that a committee must have members, but not all members need to participate in a committee. An additional business rule is that the organization disbands a committee as soon as no members participate in it; one could say that committees are seen as ad hoc working groups. In this case when the last member of a specific committee leaves, there is no significance to the business to keep information about the committee. The committee data is deleted as soon as the last member leaves the committee.

Situation 2

The deletion of the last B is not allowed as long as an A is still linked to it, because the business is still interested in that specific A, even beyond the context of the linked Bs. For example (see figure 6), an organization has committees to which members are assigned. The business rule is that a committee must have members but not all members need to participate in a committee. Committees are seen as part of the organizational structure. They have meaning to the business beyond the members serving on it. Before the last member of a specific committee leaves, a new member must be assigned to that committee because the nature of the relationship does not allow a committee without members. In situation (1), A is apparently not significant to the business unless it is related to one or more Bs, whereas in situation (2) it is significant. In situation (1) we say that A is entity dependent on B and in situation (2) that A is entity independent of B. FPA counts the entities A and B as one logical file in situation (1) (dependence), whereas in situation (2) A and B are each a separate logical file (independence), as indicated in the table in Section "Summary: from Entities to Logical Files via Entity (In-)Dependence".

2-18

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Illustration of (1):N relationships:

A

Ad hoc Committee

Committee

B

Organization Member

Organization Member

Fig. 5: Members of an organization may (but need not) be active in a working committee. A Committee must have (one or more) members participating.

Fig. 6: Members of an organization may (but need not) be active in a working committee. A Committee must have (one or more) members participating.

Fig. 4: Each entity of type A must be linked to 1 or many entities of type B; an entity of type B may, but need not, be linked to an entity of type A.

Figures 5 and 6 have similar data models, but different business rules result in different logical files identified.

Entity (In-)Dependence in a 1:N Relationship

1:N

In a 1:N relationship between two entities A and B, each entity B must be assigned to one and only one A, and each A must be assigned to at least one B. The same guidelines regarding entity dependence and independence apply.

Order

has Order Entry

Situation 1

If B is not significant to the business apart from the A linked to it, then B is considered to be entity dependent on A.

Situation 2

If B is significant to the business apart from the A linked to it, then it is considered to be entity independent of A. FPA counts the entities A and B as one logical file in situation (1) (dependence), whereas in situation (2) A and B are each a separate logical file (independence), as indicated in the table in Section "Summary: from Entities to Logical Files via Entity (In-)Dependence".

January 2010

Function Point Counting Practices Manual

2-19

Logical Files

Part 3 – Counting Practices

Summary: from Entities to Logical Files via Entity (In-)Dependence In the table below, A and B are two entities from a (normalized) data model that should be counted according to this section and that are interconnected via a relationship. The table summarizes how occurring situations are counted. Type of relationship between two entities, A and B (1) : (N) 1 : N 1 : (N) (1) : N (1) : (1) 1 : 1 1 : (1) (N) : (M) N : M N : (M)

When this Condition Exists

Then Count as LF

(A and B are independent) If B is entity dependent on A If B is entity independent of A If B is entity dependent on A If B is entity independent of A If A is entity dependent on B If A is entity independent of B (A and B are independent) (A and B are dependent) If B is entity dependent on A If B is entity independent of A (A and B are independent) If B is entity dependent on A If B is entity independent of A If B is entity dependent on A If B is entity independent of A

2 LFs 1 LF 2 LFs 1 LF 2 LFs 1 LF 2 LFs 2 LFs 1 LF 1 LF 2 LFs 2 LFs 1 LF 2 LFs 1 LF 2 LFs

Legend

LF (..)

= Logical File (ILF or EIF) = Optional side of relationship

Notes

1. When in doubt, choose entity independent. 2. In some situations more than two entities can also form a logical file.

2-20

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Step 2: Classify Logical Files The identified logical files need to be checked against the ILF/EIF rules in Part 1. Classify a logical file as an Internal Logical File (ILF) if elementary processes within the boundary of the application being measured, maintain (create, update or delete) data elements within the file. Classify a logical file as an External Interface File (EIF) if elementary processes within the boundary of the application being measured only reference data elements within the file, and the logical file is maintained by an elementary process of another application. If an identified logical file is not maintained by an elementary process (either within the application or in another), then the logical file is not counted at all.

Step 3: Identify Data Element Types The data element is the smallest unit that has meaning to the user and represents a specific fact about a business, for example: Data Element Name Fee Date of Birth Name

Data Element Value $900 15 Jan 1965 InfoMerge

Data Element Terms and Definitions Once we start looking at a logical data model, we begin to consider these data elements as attributes. An attribute represents a specific fact about an entity or a relationship. In the following table the entities are shown in UPPER CASE, the attributes in lower case:

January 2010

Representation

Example

ENTITY_attribute

COURSE_fee

ENTITY.attribute

CLIENTCOMPANY.name

Function Point Counting Practices Manual

2-21

Logical Files

Part 3 – Counting Practices

Data elements/attributes can be found in

user views (reports, screens)

data dictionaries (business models, data models)

current files (record structures in programs, file layouts)

When reviewing the data, the data analyst follows this basic premise: every data element known to the user must be treated as an attribute, and thus must be shown in relation to a specific entity. The attribute may have the following properties: attribute name (alias), characteristic, purpose (usage), value source, value range, value (structure), unit of expression, and dependencies. We will explore these properties before reviewing the IFPUG Function Point Analysis mapping of DETS to data elements/attributes. Attribute Name

A unique name that summarizes the characteristics being represented. It contains the following components: home (entity/relationship) followed by a period descriptive (adjective of the attribute) followed by a hyphen class (base attribute) Many technologies do not accept spaces. So multiple names are concatenated with hyphens. Example: CLIENT_COMPANY.shipping-address SEMINAR_ENROLLMENT.effectiveness-evaluation

Characteristic

The property of the environment being measured or represented. The name of the entity that has the characteristic is always stated; for example, Shipping-Address: the address to which materials will be shipped to the CLIENT-COMPANY.

Purpose

Asking the question “what is the attribute used for in the business” justifies the attribute. Example: COURSE.Qualification-date Purpose: Used in scheduling refresher sessions

2-22

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Dependencies

The situations where other values of attributes in the model influence or constrain the value of this attribute. For example, COURSE-final grade cannot exist before term-end but must exist upon course completion.

Attribute Keys

Provide the relationship between one entity and another. There are different types of keys in a data model, e.g., primary keys, secondary keys and foreign keys. A Primary key (PK) is the unique id of an entity. Secondary keys (SK) are attributes designed to provide fast access to the information, such as: TEXTBOOK.cost (SK) TEXTBOOK.publisher-name (SK). Secondary keys are not part of the information data model (logical data model) but are used primarily as an aid to access (physical implementation). Foreign keys (FK) are attributes used to represent relationships of one entity to another.

Attribution

The last data modeling concept we must consider before analyzing our DETs is Attribution, which prescribes/describes where the attribute resides, either within the entity or within a relationship. There are some general attribution rules that are followed in data modeling: 1. An attribute is assigned to its single best "home", which is indicated on the characteristic property in the ATTRIBUTE DEFINITION FORM. 2. The unique id (primary key) of an entity will also be attributed to every relationship in which it participates. There are some additional guidelines that are followed when trying to place an attribute in the appropriate entity: 1. If the attribute definition refers to one entity, assign the attribute to that entity. 2. If the attribute definition refers to multiple entities, then create a relationship and assign the attribute to the relationship or the entity where it applies.

January 2010

Function Point Counting Practices Manual

2-23

Logical Files

Part 3 – Counting Practices

Mapping Data Elements to FPA Data Element Types Now that we have reviewed the basics of data elements and attributes from a data modeling perspective, we can relate these concepts to the IFPUG Function Point definitions and rules: Data Modeling Concept Smallest named unit of data that has meaning to the real world Groups of related items which are treated as a unit

Collection of records of a single type

Data Modeling Term Data Item

Relational Database Term Attribute or Column

FPA Term

Record

Row or Tuple

Record Element Type (RET)

File

Table

Logical File (Internal Logical File ILF or External Interface File EIF)

Data Element Type (DET)

FPA Concept

A data element type (DET) is a unique, user recognizable nonrepeated field A record element type (RET) is a user recognizable subgroup of data elements within an ILF or EIF File refers to a logically related group of data and not the physical implementation of those groups of data

Data element types (DETs) A data element type is a unique, user recognizable, non-repeated attribute. The following rules apply when counting DETs in logical files:

2-24

•

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

•

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

•

Count one DET for each attribute required by the user to establish a relationship with another data function

•

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Do not count attributes that exist purely to satisfy a non-functional user requirement and have not been specified by the user. Examples of these nonfunctional attributes are attributes that are a result of a design or implementation consideration. Example: The ORDER_date is counted as a DET on Order since it needs to be maintained to satisfy a user business requirement. However the time and date stamp on each order record is there to satisfy data integrity and data reliability. The technical solution to these quality requirements was to back up the database and be able to restore based on this time and date stamp information. Consequently the time and date stamp would not be counted as a DET.

Miscellaneous Situations The following are examples of counting data element types (DETs). Attributes Attributes that are composed of several related data elements are stored separately. Should the attributes be counted as multiple data elements or a single data element? The DET Rules in Part 1 tell you to “count each user recognizable field”. How do you determine whether it is user recognizable as one thing or multiple things? Review the transactions within the application to determine whether the attribute is treated as one item or more than one. Consider the following items in making a decision: a) If the attribute is always used in its entirety, then it is counted as a single data element (DET). There should be no situations when an individual component of the attribute is used without the others. Based on that usage, the attribute is counted as a single data element. b) If in some situations, only one part of the attribute (e.g., last name) is used, then more than one data element would be counted. Look at the usage of the components within the application to determine how many recognizable pieces exist. It need not be a one or all option. Based on the usage, it might be appropriate to count just two DETs, even though there are actually five physical pieces.

January 2010

Function Point Counting Practices Manual

2-25

Logical Files

Part 3 – Counting Practices

c) Look for the existence of sort or edit requirements and selection criteria. If lists or reports are sorted or filtered by a single component of the attribute, this suggests independence of the components in the user view. Counting Names Name (first name, middle initial, and last name) Many applications are required to keep track of people’s names. Should the name be counted as multiple data elements or a single data element? Review the transactions within the application to determine whether the name is treated as one item or more than one. For example: In Case Studies 1, 2, and 3, look at how the Employee Name is used in the various transactional functions. Does it always use the entire name, or does it sometimes just use one piece? In the Case Studies, the Employee Name is always used in its entirety. There are no screens or reports where a single piece of the name is used without the others. There are also no situations where a portion of the name is used as sort, edit or filter criteria. Its usage within the application suggests that Employee Name is a single data element (DET). Counting Addresses Address (street address, city, state, and zip code) Many applications are required to keep track of addresses. Should the address be counted as multiple data elements or a single data element? Review the transactions within the application to determine whether the address is treated as one item or more than one. For example: In Case Studies 1, 2, and 3, look at how the Location Address is used in the various transactional functions. Do these transactions always reference the entire address, or do they sometimes use just one piece?

2-26

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

In the Case Studies the Address is always used in its entirety. There are no screens or reports where a single piece of the address is used without the others. There is no situation where a portion of the address is used as sort, edit or filter criteria. Its usage within the application suggests that Location Address is a single data element (DET). If there were a location list that allowed the user to list all locations within a particular city, state, or zip code, then more than one data element would be counted. Based on the information provided, it appears that city, state and zip code are recognizable by the user as separate from the address itself. Therefore four DETs would be counted (Street Address, City, State, and Zip Code). Counting Repeating Fields Often applications maintain multiple occurrences of a data element. According to the DET Rules Part 1, count a repeating field only once. After the repeating fields are reduced to a single DET, verify that the business requirements are still being met. Consider the following examples: Example 1: Employee ID

In Case Studies 1, 2, and 3, look at the requirements for Employee Maintenance and the relationship between Employee and Dependent in the Entity-Relationship Diagram (ERD). According to the results of the Case Studies, Employee is a LF that includes Dependent. The logical files for Employee and Dependent would each contain the Employee ID. Applying the “repeating” DET rule, count Employee ID as a single DET for the Employee ILF. Now determine if the business requirements are still met. The requirement was to maintain Dependent as part of the Employee information. Yes, the business requirement is satisfied therefore one DET is counted.

Example 2: Daily Hours Worked

January 2010

A time reporting system typically maintains the number of hours a person works each day. Upon reviewing the data structures, separate Hours Worked are saved for each day of the week (Monday Hours Worked, Tuesday Hours Worked, etc.).

Function Point Counting Practices Manual

2-27

Logical Files

Part 3 – Counting Practices

Applying the “repeating” DET rule, count only Hours Worked. Determine if the business requirements are still met. If the application only keeps track of the Hours Worked, does it meet the business requirement to maintain hours worked each day? No, it does not. In order to meet that requirement, count Day of the Week. The application has the ability to separately track each day’s hours worked (Monday Hours Worked, Tuesday Hours Worked, etc). Therefore two DETs are counted. Counting Status Fields Applications frequently keep track of the current status of data (i.e., Active, Inactive, Pending, Approved, etc). This status is typically updated through various transactions within the application. These status fields may or may not actually be physically visible to the user through the application’s transactions. Consider the following examples: Example 1: Status Inactive

Case Studies 1, 2, and 3 include an indicator of Status. When a job or employee is deleted, the user requirements indicate that any related job assignment should be updated to set the status to “inactive”. Upon review of the job assignment screens throughout the application, the status is never displayed or directly updated on any screen. Despite that lack of visibility, the Status is still counted as a DET for the Job Assignment. The fact that it appears in the Logical Data Model and the User Requirements suggests that it is user recognizable in the Logical File but not in any transaction. Therefore one DET is counted in the ILF.

Example 2: Status Not Counted

2-28

The user requires the ability to delete Employees. The technical team does not want to actually delete the records; therefore, they implemented a status flag on Employee. When the user deletes an Employee, the Status is set to Inactive. The user is unaware of the Status field on Employee. Therefore, the Status field should not be counted as a DET.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Counting System Dates Applications frequently retain system dates associated with their data to reflect the currency of the data. System Dates may have many different names (last updated, last approved, etc.) and are often accompanied by a user ID (last updated by, last approved by). These system dates are typically updated through various transactions within the application. In many cases the system date is being kept for business purposes. The user needs to know when the data was changed or approved. There are also cases where the system date is being kept for technical reasons only. Consider the following examples: Example 1: Effective Date

Case Studies 1, 2, and 3 include a reference to Effective Date. When a job or employee is deleted, the user requirements indicate that any related job assignment should be updated to set the effective date to the current system date. Upon review of the job assignment screens throughout the application, the effective date is never displayed or directly updated on any screen. Despite that lack of visibility, the Effective Date is still counted as a DET for the Job Assignment. The fact that it appears in the Logical Data Model and the User Requirements reference it by name suggests that it is user recognizable. Therefore one DET is counted in the Logical File.

Example 2: Recover-toDate

The Backup/Recovery tool used by the application uses system dates stored on the tables to restore the data to a particular point in time. In this case, the recover-to-date is not user recognizable and should not be counted.

Example 3: Audit Date

The technical team decided they should record the system date and user ID whenever data is changed to resolve any later questions about when or by whom a change was made. In this case, the system date is not user recognizable and should not be counted.

Counting Foreign Keys Applications frequently maintain relationships from one entity to another. In some cases they exist to satisfy data validation requirements, but in other cases they indicate some business interaction between the two entities. The data modeling concept of Attribution is best illustrated by the assignment of foreign keys.

January 2010

Function Point Counting Practices Manual

2-29

Logical Files

Example 1: Location (N):(1)

Part 3 – Counting Practices

Case Studies 1, 2, and 3, include the user requirements for Adding and Updating Employees: “The location must be a valid location in the Fixed Asset System (FAS).” The ERD also reinforces this business requirement by illustrating the relationship between the Employee entity and Location entity. According to the ERD, an Employee can have one Location, and a Location can have many Employees. In this situation, the Location Name should be included in the attributes within the logical and physical tables. Count the Location Name attribute as a data element (DET) for Employee.

Example 2: Cubicle (1):(N)

Consider a variation to the previous example. An employee may have an unlimited number of cubicles. A cubicle can be occupied by no more than one employee at a time. The cubicle ID(s) must be valid as identified in the CUBICLE table. The ERD would again reinforce the business requirement by illustrating the relationship between the CUBICLE entity and the EMPLOYEE entity. According to this ERD, an Employee can have many cubicles, but a Cubicle can be occupied by only one Employee. In this situation, the Employee ID is an attribute in CUBICLE. Employee

Cubicle

Employee ID (PK)

Location

Employee Name

Size

SSN

Employee ID (FK)

Count the foreign key on the many side of the relationship

Note: Not all attributes are depicted in the entities.

The relationship would instead be reflected in the Cubicle table by identifying the Employee that occupies the cubicle. Employee ID is counted as a data element (DET) for Cubicle. Example 3: Cubicle (N):M

2-30

Consider a further variation to the previous example. An employee must have at least one cubicle, but may have an unlimited number of cubicles. A cubicle can be occupied by more than one employee at a time. The Cubicle ID must be valid as identified in Cubicle. The ERD would again reinforce the business requirement by illustrating the relationship between Employee and Cubicle. According to this ERD, an Employee can have many cubicles, and a Cubicle can be occupied by many Employees.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Note: Not all attributes are depicted in the entities.

The relationship would be reflected in the Employee-Cubicle table, which would contain an occurrence for each employee to cubicle relationship. It would include the Employee ID and the Cubicle ID as the primary keys. As explained in Sections “Step 1: Identify Logical Files” and “Step 4: Identify Record Element Types”, Employee Cubicle is not counted as a Logical File nor as a RET. Cubicle ID is counted as a data element (DET) in Employee because it establishes a relationship with the Employee entity and Employee ID is counted as a data element (DET) in Cubicle because it establishes a relationship with the Cubicle entity.

Remarks Identifying the correct number of DETs does not influence the number of logical files, but their complexity only. While this step does influence the functional size to a limited degree, the effect is considerably less than Step 1: Identify Logical Files.

Step 4: Identify Record Element Types The record element type (RET) represents the user's view of coherent subgroups of data within an identified logical file, which has been discussed in the previous Section “Step 1: Identify Logical Files”. Record element types typically correspond to the entities that were grouped into the logical files as discussed in Section “Step 1: Identify Logical Files”. They need to be reviewed closely to ensure that the user would identify them as a logical subgroup and thus counted as a Record Element Type (RET).

January 2010

Function Point Counting Practices Manual

2-31

Logical Files

Part 3 – Counting Practices

Record Element Type Terms and Definitions This chapter looks at the logical data model in 3rd Normal Form and ignores multiple entities created for technical reasons; if you don't have a data model an attempt should be made to (de)normalize the data. The working definitions are based on the data model concepts described in Section “Data Modeling Concepts”. Associative Entity Type

An entity type that contains attributes which further describe a many-to-many relationship between two other entity types, also known as intersecting entities

Attributive Entity Type

An entity type that further describes one or more characteristics of another entity type

Entity Subtype

A subdivision of entity type; inherits all the attributes and relationships of its parent entity type, and may have additional, unique attributes and relationships Mapping Data Modeling terms to Function Point Terminology Data Modeling terms can be mapped to function point analysis as shown in the following matrix:

Data Modeling Concept Groups of related items which are treated as a unit

Collection of records of a single type

2-32

Data Modelin g Term Record

Relational Database Term Row or Tuple

File

Table

FPA Term

Record Element Type (RET)

Logical File (Internal Logical File ILF or External Interface File EIF)

Function Point Counting Practices Manual

FPA Concept

A record element type (RET) is a user recognizable sub-group of data element types within a data function. File refers to a logically related group of data and not the physical implementation of those groups of data

January 2010

Part 3 – Counting Practices

Logical Files

The following table can be applied to further understand the concept of Record Element Types. Entity Relationship Concept Principal data objects about which information is collected (person, place, thing or event); a fundamental item of relevance to the user about which a collection of facts is kept An entity type that contains attributes which further describe relationships between other entities

Entity Relationship Term Entity or Entity Type

Associative Entity Type

An entity type that further describes one or more characteristics of another entity type

Attributive Entity Type

A division of entity type, which inherits all the attributes and relationships of its parent entity type, and may have additional, unique attributes and relationships

Entity Subtype

FPA Term

Logical File

Could be a logical file or a possible Record Element Type (RET); see Section “Analyzing Associative Entities to Determine RETs” for further consideration Possible Record Element Type (RET); see Section “Analyzing Attributive Entities to Determine RETs” for further consideration Possible Record Element Type (RET); see Section “Analyzing Subtypes to Determine RETs” for further consideration

FPA Concept

File refers to a logically related group of data and not the physical implementation of those groups of data; if there are no other subgroups, the logical file is counted with a single Record Element Type (RET) User Recognizable subgroup of data elements within an ILF or EIF can be optional or mandatory

User Recognizable subgroup of data elements within an ILF or EIF can be either optional or mandatory

User Recognizable subgroup of data elements within an ILF or EIF can be either optional or mandatory

Function Point Analysis looks at associative, attributive and subtypes as subgroups of data. These will be explored in the discussion of how to count RETs.

January 2010

Function Point Counting Practices Manual

2-33

Logical Files

Part 3 – Counting Practices

Analyzing Associative Entities to Determine RETs An associative entity is used to associate two or more entities as a way of defining the many-to-many relationship. This type of entity is often created by the data modeler to resolve some of the business rules required to relate two separate entities. There are three possibilities to consider when looking at associative entities. Situation 1

Associative entity is not counted as a RET A registrar has a requirement to manage all students registered for a course and to know the courses that the student has previously taken. Course is an entity, and Student is an entity. The data modeler creates an associative entity called Student Course as an intersection between the two, and this associative entity contains only the keys of each entity.

Student Student Student Student Student

ID (PK) Name Major Grade Point

Student Course Student ID (PK) Course Number (PK)

Course Course Number (PK) Course Title Course Description Credit Hours

The entity Student Course is not considered a RET nor does it count as a separate logical file because it does not contain any additional data elements other than the two primary keys (PK) of the entities that it intersects. Student is a logical file with 1 RET (Student) and Course is a logical file with 1 RET (Course).

2-34

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Situation 2

Logical Files

Associative entity is counted as a RET A registrar has a requirement to identify all students registered for a course. In addition he needs information about the results of the course for the student(s). Course is an entity, and Student is an entity. The data modeler creates an associative entity called Student Course as an intersection between the two, and this associative entity contains the keys of each entity as well as the student course result.

Student Student Student Student Student

ID (PK) Name Major Grade Point

Student Course Student ID (PK) Course Number (PK) Student Course Result

Course Course Number (PK) Course Title Course Description Credit Hours

There are no business rules that require student course to be kept independently; therefore Student Course does not satisfy the rules to be counted as a separate logical file. In this case, the Student Course entity is considered a RET because it contains at least one user recognizable attribute (*) in addition to the two primary keys of the entities that it intersects. (*) In Section “Substep 1.5 Exclude entities that do not contain attributes required by the user”, non-key attributes that are a result of a design or implementation consideration or satisfy a non-functional user requirement are not considered data elements. In order to be counted as a RET, a subgroup must contain one or more unique attributes in addition to the primary keys. Student is a logical file with 2 RETs (Student and Student Course) and Course is a logical file with 2 RETs (Course and Student Course). If the business requirement indicates that the associative entity relationship belongs to only one of the logical files, the RET would be counted only with that logical file.

January 2010

Function Point Counting Practices Manual

2-35

Logical Files

Situation 3

Part 3 – Counting Practices

Associative entity counted as a logical file, single RET An HR department maintains information about Employee, Jobs, and Job Assignments. Job Assignments is required, even if an Employee is no longer associated with the Job or if a Job is no longer a current job available for placement.

Employee Employee ID (PK) Employee Name SSN

Job Assignment Employee ID (PK) Job Number (PK) Date Salary Performance Rating Status

Job Job Number (PK) Job Description

Note: Not all attributes are depicted in the entities.

Although Job Assignment is an associative entity, it is more than a key-to-key mapping between two entities, and it is more than a RET associated with a logical file. If a business rule requires the Job Assignment information to be retained independently, Job Assignment is considered a logical file as described in Section “Identify Logical Files Using Entity (In-)Dependency Method (Substep 1.3b)”. If there are no business rules requiring the Job Assignment information to be retained independently, then this associative entity is counted as in Situation 2 above.

2-36

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Analyzing Attributive Entities to Determine RETs An attributive entity is an entity type that further describes one or more characteristics of another entity type. By definition it is a logical extension of another entity; in Function Point Analysis an attributive entity represents a Record Element Type of that entity. An attributive entity is counted as either a RET of the logical file it is further defining (Situation 1) or as an extension of the logical file (Situation 2). Situation 1

An optional attributive entity An employee may enroll in employee benefits. In our data model Employee is an entity. Employee Benefits is an attributive entity of Employee and contains information about the benefits the employee has decided to carry. Employee Benefits cannot exist without Employee, and is thus logically related.

Employee

Employee Benefits

Employee Benefits is counted as a RET because it is an optional attributive entity. Employee is a logical file with 2 RETs, Employee and Employee Benefits. Situation 2

A mandatory attributive entity A sales system must maintain information about each product and its related price information. Product is an entity. Product Price Information is an attributive entity related to Price containing: previous price, current price, projected future price, and effective dates of the prices. Product Price Information does not exist without Product and is thus logically related.

Product

Product Price Information

Product Price Information is not counted as a RET. Product is a logical file with 1 RET, containing Product and Product Price Information.

January 2010

Function Point Counting Practices Manual

2-37

Logical Files

Part 3 – Counting Practices

Analyzing Subtypes to Determine RETs An entity subtype is a subdivision of entity type. A subtype inherits all the attributes and relationships of its parent entity type, and may have additional, unique attributes and relationships. Data modeling rules state that an entity may have any number of sets of independent subtypes associated with it, which can be optional or mandatory. Each subtype can have only one generic parent. In data modeling, although the parent and subtype are represented as different entities, they are logically part of the same entity. When analyzing subtypes in a data model, look at the required relationship to the 'parent' entity, as shown in the following situations. Situation 1

Subtype that is a subgroup and therefore is counted as a RET An employee must be either a permanent employee or a contract employee, but cannot be both. The common employee data is relevant to all employees and is mandatory. In addition, this common data is inherited by the mandatory subtype entities, permanent and contract.

EMPLOYEE Permanent Employee Contract Employee

When reviewing this data from a function point perspective, two logical subgroups of the Employee logical file are identified:

Permanent employee data includes permanent employee information as well as common employee information.

Contract employee data includes contract employee information as well as common employee information.

In this situation there is one logical file (Employee) with two RETs, permanent employees and contract employees.

2-38

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Situation 2

Logical Files

Subtype that is not a subgroup and therefore is not counted as a RET If there are unique attributes among entity subtypes, give serious thought to whether a separate subgroup really exists that would constitute a record element type (RET). A single optional, unique attribute would not result in a different RET from a user perspective, even if depicted as an entity subtype in a logical data model. The marital status of an Employee may be married or single. If married, the spouse’s name is recorded. Although it may be depicted as a subtype in a data model, the spouse’s name is only an optional attribute within the logical group of data Employee.

EMPLOYEE Married Employee Single Employee

One different attribute in this case does not make a significant difference between married and single employees from a business perspective. Hints

Look at the data model carefully. When in doubt, ask the user the intent of the separate subtypes. The data analyst creates a data model depicting his view of the user's world. In practice, it depends on the user view/business rules whether these entity subtypes are relevant to the user and should be considered as RETs. If there are separate add/update transactions with unique attributes for these entity subtypes, this would be an indication that we may have separate RETs for these entity subtypes.

January 2010

Function Point Counting Practices Manual

2-39

Logical Files

Part 3 – Counting Practices

Miscellaneous Situations If you do not have a data model, look for repeating groups of data. You may encounter some of the following situations. Here are some additional hints for counting. Repeating Groups/Data

Repeating groups are instances of multiple occurrences of the same data, which could be repeated multiple times within one logical file.

Situation 1

Repeating groups counted as RET The Order group of data consists of Order Header and can have multiple instances of Order Line Item. Order Line Item contains more than one unique attribute. Order Header and Order Line Item represent two separate subgroups. We count two RETs for the Order logical file.

Situation 2

Repeating data not counted as a RET One repeating field (DET) would not result in a separate subgroup or RET. For example, an Employee may have several banking account numbers. That would not imply two RETs for Employee ("all data without banking account number" and "banking account numbers").

Remarks

If in doubt, do not count a subgroup of information as a RET. Identifying the correct number of RETs does not influence the number of logical files identified, it influences only the complexity of the logical file. Although this step does influence the functional size, it does so to a lesser degree than identifying logical files in Step 1: Identify Logical Files.

2-40

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Considering Data Element Types and Record Element Types in Conjunction with Logical Files via Entity (In-) Dependence Now that we have discussed Data Element Types and Record Element Types, we expand the table shown in Section “Summary: from Entities to Logical Files via Entity (In-)Dependence” to include DETs and RETs. Type of relationship When this Condition Exists between two entities, A and B (1) : (N) (A and B are independent) If B is entity dependent on A 1 : N If B is entity independent of A If B is entity dependent on A 1 : (N) If B is entity independent of A If A is entity dependent on B (1) : N If A is entity independent of B (1) : (1) (A and B are independent) 1 : 1 (A and B are dependent) If B is entity dependent on A 1 : (1) If B is entity independent of A (N) : (M) (A and B are independent) If B is entity dependent on A N : M If B is entity independent of A If B is entity dependent on A N : (M) If B is entity independent of A

Notes

Legend

January 2010

Then Count as LFs with RETs and DETs as follows: 2 LFs, 1 RET and DETs to each 1 LF, 2 RETs, sum DETs 2 LFs, 1RET and DETs to each 1 LF, 2 RETs, sum DETs 2 LFs, 1 RET and DETs to each 1 LF, 2 RETs, sum DETs 2 LFs, 1RET and DETs to each 2 LFs, 1RET and DETs to each 1 LF, 1 RET, sum DETs 1 LF, 1 or 2 RETs, sum DETs 2 LFs, 1 RET and DETs to each 2 LFs, 1 RET and DETS to each 1 LF, 2 RETs, sum DETs 2 LFs, 1 RET and DETs to each 1 LF, 2 RETs, sum DETs 2 LFs, 1 RET and DETs to each

• • • •

1 RET and DETs to each means: assess both entities on their own Sum DETs means: count all unique, not repeated attributes of the linked entities together Count the foreign key on the many side of the relationships. In some situations more than two entities can also form a logical file; in such a case more than two (2) RETs should be counted. LF = Logical File (ILF or EIF) (..) = optional side of relationship RET = Record Element Type DET = Data Element Type

Function Point Counting Practices Manual

2-41

Logical Files

Part 3 – Counting Practices

Bibliography The following sources were consulted or cited in this chapter. Booch, Grady, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. Reading: Addison-Wesley, 1994. ISBN: 0-20157168-4. NESMA. Definitions and Counting Guidelines for the Application of Function Point Analysis: A Practical Manual, Version 2.2. (NESMA, 2003). ISBN: 978-90-76258-17-1. Note: This manual is also called NESMA Counting Practices Manual. It describes the standard FPA methodology, and many aspects related to the application of FPA. It may be used together with the IFPUG manual. For more information, see the NESMA web site www.nesma.org. Garmus, David, David Herron. Function Point Analysis: Measurement Practices for Successful Software Projects. Boston: Addison-Wesley Information Technology Series, 2001. ISBN: 0-201-69944-3. Martin, James, Carma McClure. Diagramming Techniques for Analyst and Programmers. Englewood Cliffs: Prentice-Hall, Inc., 1985. ISBN: 0-132087944. Modern Language Association of America. MLA Handbook for Writers of Research Papers, Fifth Edition. Boston: Addison Wesley, 1999. Reingruber, Michael C. and William W. Gregory. The Data Modeling Handbook: A Best- Practice Approach to Building Quality Data Models. Canada: John Wiley & Sons, Wiley-QED Publication, 1994. ISBN: 0-47105290-6. Silverman, Len, W. H. Inmon, Kent Graziano. The Data Model Resource Book: A Library of Logical Data Models and Data Warehouse Design. Boston: Addison-Wesley, Inc. Out of Print: AISN: 0-471-15364-8.

2-42

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Logical Files

Simsion, Graeme. Data Modeling Essentials: Analysis, Design, and Innovation. Boston: International Thomson Computer Press, 1994. ISBN: 1850-932877-3. Schuldt, Gary. "Information Modeling for Information Systems Analysts", A workshop at AT&T Bell Laboratories. Holmdel, N.J., May, 1992. Teorey, Toby J. Database Modeling & Design: The Fundamental Principles, Second Edition. San Francisco: Morgan Kaufmann Publishers, Inc., 1994. ISBN: 1-558-60291-1.

January 2010

Function Point Counting Practices Manual

2-43

Logical Files

Part 3 – Counting Practices

This page intentionally left blank.

2-44

Function Point Counting Practices Manual

January 2010

Part 3 Chapter 3

Shared Data Introduction

This chapter provides additional guidelines to aid in identifying external interface files (EIFs) and internal logical files (ILFs) as well as transaction files when two or more applications interact (e.g., guidance, clarification, and direction in counting data that is shared across applications).

Contents

This chapter includes the following sections: Topic

January 2010

Page

Counting Data Shared Between Applications

3- 2

Counting Scenarios – Group 1

3-7

Scenario 1: Read

3-7

Scenario 2: Static Image Copy

3-9

Scenario 3: Image Copy/Load - No Additional Processing

3-11

Scenario 4: Image Copy/Load One Physical Table - No Additional Processing

3-13

Scenario 5: Copy and Merge

3-15

Scenario 6: Screen Scraping

3-17

Counting Scenarios – Group 2

3-18

Scenario 7: Updating the Same Data Store

3-18

Scenario 8: Standard Transaction Data

3-20

Summary

3-22

Function Point Counting Practices Manual

3-1

Shared Data

Part 3 – Counting Practices

Counting Data Shared Between Applications Applications that Share Data

Methods of Sharing Data

Applications that share data with other applications: •

Reference or utilize the data to complete a transaction being processed within the application receiving or accessing the data, or

•

Maintain the internal logical files within the application receiving or accessing the data

Shared data, used by elementary processes within an application to maintain data on an internal logical file or to present data to the user, may be transferred via: •

On-line screens (e.g., screen scraping)

•

Direct access of data files from other applications

•

Transferred files

•

On-line real-time information requests

•

Web applications

In order to correctly analyze these implementations, users need to consider primary intent and have a common understanding of the terms that represent the various implementation techniques. Primary Intent

The concept of primary intent is helpful in the identification of internal logical files and external interface files as it relates to the use of the data within the application being analyzed. Primary intent refers to the most significant or important thing the function is intended to accomplish. The definition of primary intent is “intent that is first in importance.” Therefore, it is important for us in our discussion of each scenario to determine the primary intent. The physical implementation does not affect the primary intent and thus should not influence the analysis.

Definition & Primary Intent (ILF/EIF)

Internal Logical File: An internal logical file (ILF) is a user recognizable group of logically related data or control information maintained within the boundary of the application being measured. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being measured. Note: The term maintain refers to the ability to add, change or delete data through an elementary process. Examples include, but are not limited to, add, change, delete, populate, revise, update, assign, and create.

3-2

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Shared Data

External Interface File: An external interface file (EIF) is a user recognizable group of logically related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application measured. This means an EIF counted for an application must be in an ILF in another application.

Common Terms The following common terms are utilized in this document to describe physical implementation techniques: Term

Copy

File

Image Load

Merge Refresh

Use in Document

IEEE1 definition: (1) To read data from a source, leaving the source data unchanged, and to write the same data elsewhere in a physical form that may differ from that of the source. For example, to copy data from a magnetic disk onto a magnetic tape. (2) The result of a copy process as in above. For example, a copy of a data file. IEEE definition: “… set of related records treated as a unit. For example, a file could consist of a set of invoice records.” An exact replication of another object, file, or table that is usually created through a utility. IEEE definition: “… to copy computer instructions or data from external storage to internal storage …” Multiple files with the same data elements consolidated into a single file. The process of recreating a set of data to make it current with its source.

1

Institute of Electrical and Electronics Engineers (IEEE) Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology

January 2010

Function Point Counting Practices Manual

3-3

Shared Data

Part 3 – Counting Practices

Organization of Counting Scenarios Function point analysis is often based on descriptions from developers of the physical characteristics of an installed application. This chapter will address the physical descriptions a function point analyst frequently encounters to assist in the correct interpretation of many of these application interfaces. This chapter utilizes various scenarios as an aid in analyzing shared data situations. Approach

Symbols Used in Diagram Solution

This chapter uses the following approach in our discussion of shared data: •

Description – A high level statement of the example being discussed.

•

Scenario - An example is presented that often describes a physical activity or transaction regarding files being transferred between two applications; e.g., sharing data.

•

Scenario Diagram - The scenario is depicted graphically, as an aid to map a similar situation or scenario. The arrow in the diagrams reflects the direction of flow of data, not the application initiating the interface.

•

Counting Interpretation - A counting interpretation for the scenario is provided, which includes a discussion of the example and how the example should be counted as well as any assumptions regarding primary intent.

•

Solution Diagram - The solution is depicted graphically.

•

Counting Summary - The data and transactional functions applicable to each application are summarized in a table.

•

FAQs/Variations – If applicable, some common variations of a scenario may be included following the discussion.

The following symbols are found in the diagram solution: 5 above a component type depicts the component is counted for application : above a component type indicates the component would not be counted for the scenario ⇐ in the diagram depicts the direction of flow of data, not the application initiating the interface

3-4

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Scenario Naming Conventions

Shared Data

For consistency, the following naming conventions have been used throughout the scenarios: Term

Description

The source application for the reference/transaction data. The receiving application for the reference/transaction data. An ILF counted in Application A. An EIF counted in Application B which is a subset of the File X data. An ILF counted in Application B. A data transfer file. This file is generated by Application A and read (processed) by Application B. Application A and Application B represent two separate applications, and thus represent two separate boundaries.

Application A Application B File X File X’ (X Prime) File Y File Z

Boundaries

Outline of Scenarios

The following scenarios do not represent a complete list of the various ways shared data is implemented, but they provide guidance on many of the situations encountered. Understanding these examples will facilitate the understanding of additional scenarios that may be encountered. The scenarios focus on situations where the data required to complete elementary processes within Application B is obtained from Application A. Application B is the application being measured. The scenarios are logically divided into two groups, each of which has various implementations:

January 2010

GROUP 1:

The primary intent is for Application B to reference data maintained by Application A. There are two areas which are addressed, functional and non-functional.

Functional

For Functional Reasons (business requirements), applications share data in the following scenarios

Scenario Number

Scenario

Summary Description

1

READ

Application B physically accesses Application A’s data. This example is currently documented in the CPM.

Function Point Counting Practices Manual

3-5

Shared Data

Part 3 – Counting Practices

Scenario Number

Scenario

Summary Description

2

STATIC IMAGE COPY

Application A generates an image copy of a data store, which reflects the current state of the data at a certain time and remains within its boundary.

NonFunctional

Scenario Number

Scenario

Summary Description

3

IMAGE COPY / LOAD, No Processing Logic IMAGE COPY / LOAD, A Subset of an ILF

Application A generates an image copy with no additional processing logic and sends it to Application B; Application B loads the copy with no additional processing logic Application A generates an image copy of a subset (e.g., RET) with no additional processing logic and sends it to Application B. Application B loads the RET with no additional processing logic Data stored in two applications is image copied and merged to form one file that is loaded into a third application. Application B accesses Application A’s screen transactions to reference/obtain data to assist in processing a transaction.

4

5

COPY MERGE “Refresh”

6

SCREEN SCRAPING

GROUP 2

3-6

For Non-Functional Reasons (performance, security, etc.), Application B must use Application A’s data and does so in the following ways

The primary intent is for Application B to maintain its own data from data maintained by Application A.

Scenario Number

Scenario

Summary Description

7

MAINTAIN COMMON DATA STORE

8

STANDARD TRANSACTION DATA

The same data store is maintained by two different applications. This example is currently documented in the Part 4, Chapter 1 Data Function Counting Examples. Transaction data is provided by the source application.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Shared Data

Counting Scenarios – Group 1 In each of scenarios 1 to 6, the primary intent is for one application to reference data maintained by one or more other applications; it may be implemented as follows:

Scenario 1: Read Description

Application B physically accesses Application A’s data to execute a query.

Scenario

A transaction processed by Application B, requires information from a data store maintained within Application A. Application B is responsible for accessing the data in Application A, and Application B maintains the software for that access.

Diagram Application A

Customer Data Logical File

Counting Interpretation

Application B Retrieves Data

Transactional function which validates Customer

Application A: From Application A’s perspective, there is no requirement to send data. The data is available in Application A. No credit is given to Application A for the transaction performed by Application B, although the data file is an ILF for Application A. Application B: From Application B’s perspective, both logically and physically, there is only one data store involved. Application B counts the data store, which resides in Application A as an EIF. Application B also counts that data file as an FTR in the transaction.

January 2010

Function Point Counting Practices Manual

3-7

Shared Data

Solution Diagram

Part 3 – Counting Practices

Application A

Application B Retrieves Data

Customer Data Logical File

EI

Transactional function which validates Customer

EO/EQ

EIF

ILF

Application A’s Customer File

Counting Summary

3-8

Application A Application B

ILF 5

EIF

EI

5

Function Point Counting Practices Manual

EO/EQ

Note Customer is also counted as an FTR in transactional function

January 2010

Part 3 – Counting Practices

Shared Data

Scenario 2: Static Image Copy Description

Application A generates an image copy of an ILF, which reflects the current state of the data at a certain time, and remains within its boundary.

Scenario

In the banking industry, financial transactions are settled daily between all financial institutions. Subsequent customer financial transactions are validated against the customer financial balance as of that settlement. To support that business requirement, Application A periodically makes an image copy of the data from the logical file Customer to Customer prime (or Customer') so that other applications can reference it. Customer' (prime) remains within the boundary of Application A. Differences can occur between the current data in Customer and the data in Customer'. Application B makes use of Customer'.

Diagram Application A

Customer Data Logical File

Counting Interpretation

Application B Retrieves Data

Transactional function which must validate Customer against Customer' (prime)

Application A: From Application A’s perspective, Customer is an internal logical file for Application A. Customer' (prime) is not counted as a separate ILF, nor is it counted as a RET of Customer. Customer' is just a snapshot of Customer at a particular time. Application B: From Application B’s perspective, Customer is an external interface file for Application B and is also counted as an FTR for the transaction in Application B.

January 2010

Function Point Counting Practices Manual

3-9

Shared Data

Solution Diagram

Part 3 – Counting Practices

Application A

Application B Retrieves Data

Customer Data Logical File

EI

EO/EQ

Transactional function which must validate Customer against Customer' (prime)

EIF

ILF

Application A’s Customer File

Counting Summary

3-10

Application A Application B

ILF 5

EIF

EI

5

Function Point Counting Practices Manual

EO/EQ

Note Customer is also counted as an FTR in transactional function

January 2010

Part 3 – Counting Practices

Shared Data

Scenario 3: Image Copy/Load - No Additional Processing Description

Application A generates an image copy with no additional processing logic and sends it to Application B; Application B loads a copy with no additional processing logic

Scenario

Application B requires the ability to access file X in Application A for validation and reference only. Application B requires (e.g., for performance, etc.) that Application A send a complete file to Application B. The existing data store in Application B is "refreshed" each time with the copy

Diagram Application A

Application B Z

File X

Copy/Load

Counting Interpretation

Copy of File X

From Application A’s perspective, this data transfer is a technical solution devised to satisfy the business requirement that Application B should have access, for data retrieval purposes, to the Application A File X. Logically the data store remains in Application A. In this case, copying the data store from one application to another is the solution of a non-functional user requirement (e.g., the data in Application A is not available when it is required by Application B). The primary intent for B is to reference the data that is logically in A. One additional indication would be that the file in Application B is "refreshed" each time with the copy. Also, no processing logic is performed in either Application A or Application B. Transactions - The data transfer transactions: Application A download, and Application B Load, are part of the technical solution and are not counted in either application. In practice, when counting Application A in isolation, it may not be apparent to the Function Point Analyst that this exists to satisfy a non-functional user requirement, and it may be incorrectly counted as an EO/EQ. Neither application counts File Z as a transactional function.

January 2010

Function Point Counting Practices Manual

3-11

Shared Data

Part 3 – Counting Practices

Files - There is only one logical file involved. Application A counts File X as an ILF. Application B counts its copied version of File X as an EIF. Neither application counts File Z as a data function.

Solution Diagram

Application A

EIF/ILF

Application B

Z File X

Copy of File X

Copy/Load

EO

EI EIF

ILF

Application A’s File X

Counting Summary FAQs, Additional Variations

Application A Application B

ILF 5

EIF

EI

EO/EQ

Note

5

Q? What if a logical file in Application A is made up of multiple physical tables and Application A provides individual copies of more than one table to Application B? A: The EIF is identified in the same manner as in the scenario above; only the fields used are counted as DETs. Q? What if you have a partitioned data store? A: It is segmented for performance, but it is still logically one data file; physical implementation

3-12

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Shared Data

Scenario 4: Image Copy/Load One Physical Table - No Additional Processing Description

Application A generates an image copy of a physical table within a logical file of Application A with no additional processing logic and sends it to Application B. Application B loads the physical table without any additional processing logic.

Scenario

Application B requires (e.g., for performance, etc.) the ability to access a portion of File X in Application A for validation and reference only. Application A sends a physical table within a logical file to Application B. The existing view of that physical table in Application B is "refreshed" each time with the copy.

Diagram Application A

Application B Z

File X

File X'

Copy/Load

Counting Interpretation

Since the data is an image copy of Application A's data, the File X' Table is part of the logical File X of Application A. Application B counts File X' (with only the data elements used from the File X' Table) as an EIF. Logically the data store remains in Application A. In this case copying the data store from one application to another is the solution of non-functional user requirements; e.g., the data in Application A is not available when Application B requires it. The primary intent is for Application B to reference the data that logically exists in Application A. Transactions – Since there are no logical transactional functions in propagating or loading the copy, no transactions are counted for either application to support the copying and loading of the shared data. Therefore, Application A does not count the copy to Application B as an EO/EQ, and Application B does not count an EI. One additional indication would be that the file in Application B is "refreshed" each time with the copy. Files - There is only one logical file involved. Application A counts File X as an ILF. Application B counts its copied table of File X' as an EIF.

January 2010

Function Point Counting Practices Manual

3-13

Shared Data

Solution Diagram

Part 3 – Counting Practices

Application A

EIF/ILF

Application B

Z File X

File X'

Copy/Load

EO

EI EIF

ILF

Application A’s File X'

Counting Summary

3-14

Application A Application B

ILF 5

EIF

EI

EO/EQ

Note

5

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Shared Data

Scenario 5: Copy and Merge Description

Data stored in two applications is image copied and merged to form one file that is loaded into a third application. Multiple files with the same data elements are being consolidated into a single file.

Scenario

To avoid the overhead of Application C having to dynamically search the data from both Application A and B, the data is being copied from Application A and Application B and merged into a new data store in Application C. The user requires that the information from Application A and B be refreshed daily for validation or reference purposes only. Unload, Merge and Load utilities are used. There is no business processing logic involved. This is typically a technical solution where two applications have different instances of the same logical data required by a third application.

Diagram Application A

Application C Merge

Application B

Counting Interpretation

January 2010

Logically, the data stores remain in Applications A and B. Merging the data into one data store does not by itself create a new ILF for Application C. Again, the primary intent for the usage of the data in Application C must be evaluated. Since the data is to be used only for reference or validation and it is a complete refresh, it is counted as an EIF. Since there is no additional processing logic, no transactions are counted for any application.

Function Point Counting Practices Manual

3-15

Shared Data

Part 3 – Counting Practices

The data for application C must be evaluated in accordance with 3.4 of Part 1 – Measure Data Functions and Part 3, Chapter 2 - Logical Files. Even though the data comes from two different applications, the data elements are exactly the same (see definition for “merge”). Therefore only a single logical file is identified for Application C as an EIF.

Solution Diagram

EO

ILF Merge

EI

EIF

EO ILF Counting Summary

3-16

Application A Application B Application C

ILF 5 5

EIF

EI

5

Function Point Counting Practices Manual

EO/EQ

Note

Also count as FTR in transactional function

January 2010

Part 3 – Counting Practices

Shared Data

Scenario 6: Screen Scraping Description

Accessing another application's screen transactions to reference/obtain data or to update that application's data.

Scenario

Application B 'reads' the content of an inquiry screen in Application A and uses that data in the processing of a transactional function.

Diagram

Counting Interpretation

Solution Diagram

Application A

Application B

File X Table

Transactional function, which reads data from File X, displayed on the screen in Application A.

Logically, Application B is reading Application A's data. Application A has already counted the data displayed as an EQ/EO (so not counted here), while Application B counts the data as an EIF. From a transaction perspective, Application A is passive and counts nothing extra. For Application B the screen scraping is part of the elementary process of the transaction and is counted as an FTR (EIF), since the data was originally retrieved from Application A’s ILF.

Application A

Application B

EO/EQ

Transactional function, which reads data from File X, displayed on the screen in System A.

File X Table

EO/EQ

ILF

EIF Counting Summary

January 2010

Application A Application B

ILF 5

EIF

EI

EO/EQ

Note

5

Function Point Counting Practices Manual

3-17

Shared Data

Part 3 – Counting Practices

Counting Scenarios – Group 2 In each of scenarios 7 and 8, the primary intent is for Application B to maintain its own data from data maintained by Application A; it may be implemented as follows:

Scenario 7: Updating the Same Data Store Description

The same data store is maintained by two different applications.

Scenario

Both Application A and Application B maintain the same ILF. Each has its own unique view of the data. There are some common data elements, and some that are unique to each application.

Diagram

Boundary Extended Application A

Application B FileX

Counting Interpretation

3-18

An ILF is counted for both applications because each has transactions to maintain it. Application A and B both maintain data in the same ILF. Each application counts only the RETs and DETs maintained, used or referenced by that Application.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Shared Data

Boundary Extended

Solution Diagram

FileX

ILF

Counting Summary

January 2010

Application A Application B

ILF 5 5

EIF

ILF

EI

Function Point Counting Practices Manual

EO/EQ

Note

3-19

Shared Data

Part 3 – Counting Practices

Scenario 8: Standard Transaction Data Description

Transactional data is provided by the source application.

Scenario

Application A produces a transaction file of changes, File Z, that is loaded into Application B. The records are usually of more than one type. Application B processes the input transactions according to the transaction type on the File Z records, prior to updating the records on internal File Y. The DETs on Application A File X, and Application B File Y, are different. For example File X is a Master Material Catalogue while File Y is a local Product List. Processing includes the following transaction types: •

Add

•

Change

•

Delete

This data transfer is a user business requirement. Both Application A and B have a requirement to access a version of the File X however the DETs on the two files are different. Application A sends data related to changes only. Application B reads the records on File Z and based upon the transaction type initiates different logical processing. Diagram Application A

Application B Z

File X

File Y Transaction Data

Counting Interpretation

If every record written by Application A to the File Z is processed in the same way only one EO/EQ is counted. Only when there is different logical processing involved you may have multiple transactional functions (e.g., EO/EQ) within a single file. Application B counts EIs for each unique maintenance function on File Y. The number of Transaction Types on the transaction File Z, usually determines the number of these functions, but this is not necessarily the case. Different logical processing must be demonstrated. There are two files involved. Application A counts File X as an ILF. Application B counts File Y as an ILF. Neither application counts File Z as a logical file.

3-20

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Solution Diagram

Shared Data

Application A

EIF/ILF

Application B

Z File X

File Y Transaction Data

EO/EQ

EI (A,C,D)

ILF

Counting Summary

January 2010

ILF

Application A Application B

ILF 5 5

EIF

EI

EO/EQ 5

Note

5

Function Point Counting Practices Manual

3-21

Shared Data

Part 3 – Counting Practices

Summary Throughout this chapter, the scenarios have focused on the use of the data within the application being measured and the application of the rules of ILF and EIF identification that reference ‘primary intent’. This chapter does not illustrate all possible implementations of data sharing between applications. It does, however, provide enough examples that a Function Point Analyst can consistently apply the identification rules for ILFs and EIFs by focusing on the primary intent for the use of the data and the boundaries of the applications involved in the measurement.

3-22

Function Point Counting Practices Manual

January 2010

Part 3 Chapter 4

Enhancement Projects and Maintenance Activity Introduction

This chapter provides additional guidance for identifying and measuring functional changes to installed applications. It does not address the relationship between the functional size of the enhancement and the effort required to implement that enhancement. For additional perspectives on this topic, the reader is referred to the NESMA publication, “Function Point Analysis for Software Enhancement” [NESMA, 2001], at www.nesma.org. This chapter also discusses the various maintenance and support activities that may occur during the productive life of an application and for which functional size measurement provides a useful basis for estimation and cost reconciliation.

Contents

This chapter includes the following sections: Topic

January 2010

Page

Measuring Enhancement Projects

4-2

Considerations and Hints

4-10

Inputs for Measuring Enhancement Projects

4-12

Procedure

4-13

Enhancement Project Example

4-14

Enhancement versus Maintenance Considerations

4-20

Summary

4-24

Function Point Counting Practices Manual

4-1

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Measuring Enhancement Projects The Enhancement Project Functional Size measures the project’s modifications to the existing installed application that add, change or delete user functions. The changes in functionality might result from new or revised user requirements, statutory/regulatory changes or new users.

Scope and Boundary of an Enhancement Project The Enhancement Project Functional Size includes all functions being added, changed and deleted. The boundary of the application(s) impacted remains the same. The functionality of the application(s) reflects the impact of the functions being added, changed or deleted. There may be more than one application included in the counting scope. If so, multiple boundaries would be identified, resulting in a separate enhancement project functional size for each affected application. If the total size of the enhancement project is required, it is calculated by summing the enhancement project functional size for all applications included in the counting scope.

Measuring Data Functions in Enhancement Projects The additions of new internal logical files or external interface files by an enhancement project are generally easily identified and measured according to rules defined in Part 1. Chapter 6 of Part 2 (Measure Data Functions) and Chapter 2 of Part 3 (Logical Files) contain additional guidance for measuring data functions as well as definitions of related terms. However, consideration should be given to the following: •

If the change involves only the addition of new records to a logical file or new values in an existing attribute within that logical file, there is no justification to count the data function as being changed.

•

If a data function is changed because an attribute is added and that attribute is not used by the application being measured, then there is no change to that application.

•

In order for a data function to be counted as a changed function, the general guideline is that it must be structurally altered (e.g., adding or removing an attribute or changing the characteristics of the attribute). Note: New Help text is often added to the Help data function in support of a new transaction. Since there is no structural change to the Help data function, it would not be counted as changed.

4-2

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

•

If an application is required to use (reference or maintain) an existing attribute that it did not previously use, the related data function is considered changed for that application. This can occur without any physical changes to the file.

•

If new attributes are added to an ILF, look for new or modified transactional functions that maintain the attribute in that ILF to confirm that a change has occurred.

•

If an attribute is added to an ILF that is maintained by two applications and if one application maintains the new attribute but the other only references it, then both applications take credit for the changed ILF. However, the second application will not have any new or changed transactional functions that maintain the attribute in that ILF.

•

If an application neither maintains nor references a new or changed attribute, then it cannot take credit for a changed data function.

•

If a physical file is added by an enhancement project, it does not necessarily result in a new logical file. We first need to determine whether the new physical file is a change to an existing logical file with additional DETs and possibly an additional RET, or a new logical file. See Part 2, Chapter 6 and Part 3, Chapter 2 for additional guidance regarding measuring logical files.

Measuring Transactional Functions in Enhancement Projects The additions of new transactional functions by an enhancement project are generally easily identified and measured according to rules defined in Part 1. Chapter 7 of Part 2 (Measure Transactional Functions) contains additional guidance for measuring transactional functions as well as definitions of related terms. The identification of Transactional Functions that have been changed by adding or removing Data Element Types is obvious. It is not as obvious when the user requirements are for changes in processing logic, as described in Part 1. When processing logic has been altered within an application to meet business requirements, the elementary process that embodies that logic should be identified and counted as being changed. A single change in processing logic does not always affect all related transactions. For example, when an edit or validation change is made to input processing logic and Add, Delete, Update and implied Inquiry transactions exist, then only the Add and Update transactions are counted for the enhancement. Unless there is specific deletion logic change (e.g., referential integrity edit) or query logic change (e.g., selection or retrieval), the Delete and Implied Query transactions will not change.

January 2010

Function Point Counting Practices Manual

4-3

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

1.

2.

3.

4.

In the above diagram: 1. Transaction 1 is modified because an additional DET has been added and is crossing the boundary. 2. Likewise, Transaction 2 where an additional DET is sent across the boundary will be counted as changed. 3. For Transaction 3, a validation routine internal to the application has been changed. Since this is a change to the processing logic within an elementary process, the associated Transaction 3 is counted as being changed. 4. Similarly for Transaction 4 where the previous selection criteria or filter has been modified, the transaction is counted as changed functionality. In some cases, a specific change may impact how multiple transactional functions are processed. Regardless of whether logic changes were physically made in a common routine used by multiple transactions, changed functions should be identified based on the elementary processes that embody that logic. If multiple elementary processes were affected, then count multiple transactional functions. If only a single elementary process was affected, count one transaction as being changed. In all cases, the user requirements and the business view shall be the determining factor. For example, the requirement is to modify the edit on new orders to include a validation for the customer’s past due balance. If there are several different order transactions (Individual, Commercial, Government, etc.) but the edits for only the Commercial order transaction were modified, then only the Commercial order transaction should be counted as changed. Alternatively, if the requirement was to modify all these type of orders, then each separate transaction would be counted as being changed.

4-4

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

Another indication of the transactional functions to be counted would be the coverage of test cases. A single set of test cases would indicate that a single elementary process has been modified. Often the nature of a change is related by the developer, claiming that the one module being changed is used in the production of a large number of reports or extracts, or the processing of many input transactions. All the functions may use the common routine, but only a subset of those functions use the edit that is being changed in that common routine. Only the functions that incorporate the changed processing logic would be counted as changed. The challenge is to properly assess the appropriate level of functional change. The emphasis must be on the business requirements, with the enhancement project functional size reflecting the intent of the user request.

Processing Logic Processing logic is defined as any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function. Those requirements may include the following actions: 1. Validations are performed For example, when adding a new employee to an organization, the employee process validates the employee type DET. •

If a requirement exists to perform a different validation or change the validation in an existing transactional function, the transaction would be counted as changed in the enhancement project functional size.

2. Mathematical formulas and calculations are performed For example, when reporting on all employees within an organization the process includes calculating the total number of salaried employees, hourly employees and all employees.

January 2010

•

If a business requirement exists to modify an existing calculation (e.g., before, the formula was A + B = C and now C = A * B), the transaction that includes that calculation would be counted as changed in the enhancement project functional size.

•

Currently there is a list of employees that is counted as an EQ. The enhancement project requirements state to display summary counts of those employees. The transaction would be identified as changed and the function type would be changed from an EQ to an EO in the enhancement project functional size.

Function Point Counting Practices Manual

4-5

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

3. Equivalent values are converted For example, employee age is converted to an age range group using a table. •

If a business requirement exists to change the functionality to include the ability to convert employee salary into a pay range group, the transaction would be counted as changed in the enhancement project functional size.

4. Data is filtered and selected by using specified criteria to compare multiple sets of data For example, to generate a list of employees by their assignment, an elementary process compares the job number of a job assignment to select and list the appropriate employees with that assignment. •

If a requirement exists to modify the selection criteria or add additional selection criteria, excluding changing or adding values, to an existing transaction (a list of employees now needs to display a list of employees who have been in their assignment less than a year), the transaction would be counted as changed in the enhancement project functional size.

•

If a requirement exists to modify only the value(s) of existing criteria, such as selecting a different department or adding an additional department to a list of departments, then there is no count for changing the transaction.

•

If the requirement is to change the selection criteria from a single department to a list of departments, this would be counted as a change.

•

If a requirement exists to modify the employee search screen to additionally filter on location, this additional filter does not create a new elementary process. It is counted as a changed function in the enhancement project functional size.

5. Conditions are analyzed to determine which are applicable For example, processing logic exercised by the elementary process when an employee is added will depend on whether an employee is paid based on salary or hours worked. The entry of DETs (and the resulting processing logic) based upon a different choice (salary or hourly) in this example is part of one elementary process. •

4-6

If a requirement exists to modify the condition or add additional conditions to an existing transaction, the transaction would be counted as changed in the enhancement project functional size.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

6. One or more ILFs are updated For example, when adding an employee, the elementary process updates the employee ILF to maintain the employee data. •

If a business requirement results in updating an additional ILF or different DETs by an existing transaction, the transaction would be counted as changed in the enhancement project functional size.

7. One or more ILFs or EIFs are referenced For example, when adding an employee, the currency EIF is referenced for the correct US dollar conversion rate to determine an employee’s hourly rate. •

If a business requirement results in referencing additional ILFs, EIFs or DETs in an existing transaction, the affected transaction would be counted as changed in the enhancement project functional size.

8. Data or control information is retrieved For example, to view a list of employees, employee information is retrieved from a data function. •

If the business requirement results in retrieving additional information in an existing transaction, the affected transaction would be counted as changed in the enhancement project functional size.

9. Derived data is created by transforming existing data to create additional data For example, to determine (derive) a patient’s registration number (e.g., SMIJO01), the following data is concatenated:

January 2010

•

the first three letters of the patient’s last name (e.g., SMI for Smith)

•

the first two letters of the patient’s first name (e.g., JO for John)

•

a unique two-digit sequence number (starting with 01)

•

If the business requirement results in changing how the transaction derives the data, the affected transaction would be counted as changed in the enhancement project functional size.

Function Point Counting Practices Manual

4-7

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

10. Behavior of the application is altered For example, the behavior of the elementary process of paying employees is altered when a change is made to pay them every other Friday versus on the 15th and the last day of the month; resulting in 26 pay periods per year vs. 24. •

If the business requirement results in altering the behavior of the system (e.g., in the example above, the transaction is changed so that the pay date parameter affects only hourly employees not all employees), the affected transaction would be counted as changed in the enhancement project functional size.

11. Prepare and present information outside the boundary For example, a list of employees is formatted and displayed for the user. •

When the business requirement results in presenting additional DETs outside the boundary, the affected transaction would be counted as changed in the enhancement project functional size.

•

Changes to literals, format, color or other elements of the physical presentation are not considered changes to the processing logic, and therefore not part of an enhancement project functional size.

•

When the business requirement is to send an existing output file to different or an additional application without a change to any other form of processing logic (e.g., selection criteria, calculations), there is no enhancement project functional size.

•

Rearranging data on a screen, report or file by displaying an existing data element in a new position is not considered a change in processing logic and is not counted for an enhancement.

•

Changes to the characteristics (e.g., length, type, precision, etc.) of an attribute crossing the boundary must have a change to another form of processing logic (e.g., validations, calculations) to be counted.

•

When a new or changed screen function requires additional or modified help, a change to the existing Help function is not counted because there is only new or updated text or values.

12. Capability exists to accept data or control information that enters the boundary of the application For example, a user enters information to add a customer order to the application. •

4-8

When the business requirement results in different DETs that enter the boundary, the affected transaction would be counted as changed in the enhancement project functional size.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

•

When the business requirement is to accept an existing input file from a different or an additional application without changes to any other form of processing logic (e.g., validations, calculations), there is no impact on the enhancement project functional size.

•

Changes to the characteristics (e.g., length, type, precision, etc.) of an attribute crossing the boundary must have changes to another form of processing logic (e.g., validations, calculations) to be counted.

13. Sorting or arranging a set of data. This form of processing logic does not impact the identification of the type or contribute to the uniqueness of an elementary process; i.e., the orientation of the data does not constitute uniqueness For example, list of employees is sorted in either alphabetical or location order. For example, on an order entry screen, the order header information is arranged at the top of the screen, and the order details are placed below. Note: Changes in sort sequence are typically counted. Changes in arrangement by themselves are not typically counted. •

When the business requirement results in changing the existing sort sequence (e.g., user now requests the above referenced list of employees in location order instead of alphabetical order), the affected transaction would be counted as changed in the enhancement project functional size.

•

On an order entry screen, the user requests order header information be placed to the left of the order detail information instead of above. There is no count for this change.

•

The user requests that the Last Name attribute on the Employee Assignment Screen be placed to the left of Middle Initial and First Name. There is no change counted for the re-positioning. If the requirement is also to pre-populate data based on last name as it is entered, then there is a change to another form of processing logic and the Employee Assignment function is counted.

•

The user requests an additional report of the same data (list of employees) sorted by location. A new transaction would not be counted, but a change to the existing transaction would be included in the enhancement project functional size.

One elementary process may include multiple alternatives or occurrences of the above actions. For example: validations, filters, resorts, etc.

January 2010

Function Point Counting Practices Manual

4-9

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Considerations and Hints Many enhancement projects involve changes only in processing logic with no physical changes to inputs, outputs or files (e.g., added or removed attributes). The following are items or questions to discuss with developers in measuring enhancements to installed applications:

Questions to Consider for an Enhancement Project The questions listed below can be used during the interview with the developer or Subject Matter Expert (SME) during functional sizing sessions. Positive responses to the questions listed below indicate possible changes to user functionality. Additional investigation is required to determine whether and how they should affect the functional size. What NEW functionality has been created for the users of the application? •

Have any new permanent user files, databases, tables, entities or objects been developed/added by this project?

•

Is the application now receiving and processing new input transactions or feeds/transaction files that were not previously in production?

•

Have any new screens been built for the users?

•

Are there any new interactions (interfaces) with other applications?

•

Is the application generating new outputs, new reports or new files for another system?

•

Has a new record type been added to an existing transaction file or feed?

•

Have there been any new query processes established for the user?

•

Have any batch processes been added?

What user functionality has been CHANGED/MODIFIED due to user requirements?

4-10

•

Have any existing permanent files, databases or tables had attributes or columns added or removed? Have the characteristics of any existing attributes or columns been modified? Adding new values to an existing attribute or new rows to an existing table does not count.

•

Has any existing processing logic for input screens or inputs received via files sent by users or other applications been modified?

•

Have there been any changes to the actual input screens or the feeds/transaction files from other applications (e.g., new attributes, changes to attributes of existing attributes)?

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

•

Have any existing user reports, output files or screens been modified by adding or removing attributes?

•

For existing outputs, have there been any changes to the processing logic to produce these files, reports or screens?

•

Have any screens for query purposes been modified?

•

Have there been any changes to the edit or selection criteria or filters behind any query screens?

•

Have any batch processes been changed?

What user functionality has been DELETED/REMOVED due to user requirements? •

What user functionality has been deleted or removed from production?

•

Are any existing permanent files no longer required?

•

Has the application stopped accepting an input file from another system or removed a screen previously accessed by a user?

•

Have any reports been removed because the user doesn't require them anymore?

•

Have any output files to another system been eliminated?

•

Has any user query been removed?

•

Have any batch processes been removed?

What Conversion Functionality has been provided? •

Has there been any one-time data processing to cleanup, organize or to populate new attributes as a result of structural modifications to a permanent file?

•

Has there been any requirement to populate any new permanent file?

•

Are there any user requested conversion reports?

What other changes were made to the application for this project? •

This wrap-up question may prompt the Subject Matter Expert or developer to provide additional clues to countable changes.

Summary of Considerations and Hints These guidelines will assist in determining the functionality delivered by the project and its impact on the baseline of the application being measured. The combination of new functionality added, the effects of the changes made to existing functionality and user functionality deleted will be used to size the Enhancement Project as well as to calculate the updated Function Point Baseline for the application.

January 2010

Function Point Counting Practices Manual

4-11

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Inputs for Measuring Enhancement Projects In addition to the documentation identified in Part 2 Chapter 3 Gather Available Documentation, the following should also be provided for an enhancement project: •

Existing Application Functional Size Measurement documentation

•

User Requirements for any changes/modifications to the existing application

•

Existing screen layouts, report layouts and/or batch job data flow diagrams for all affected functions as they were BEFORE the enhancement project

•

Revised screen layouts, report layouts and/or batch job data flow diagrams for all affected functions as they will be AFTER the enhancement project

•

Documentation for all new functions (new reports, outputs, data entry functions or entities) that are to be added to the application as part of the enhancement project

•

Screen layouts, report layouts and/or batch job data flow diagrams for functions that are to be REMOVED from the application as a result of the enhancement project

It is recognized that, in many instances, all of the above documentation may not be available or applicable. The most important source is a knowledgeable application expert and the Requirements documentation. If an application baseline does not exist, care should be given in establishing the boundary and in identifying the logical data and transactional functions.

4-12

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

Procedure The following are suggested steps for performing an enhancement project functional size; however, they may be performed in any order Step 1 2 3 4

5 6

January 2010

Action Gather and review available documentation. Meet with the subject matter expert to discuss changes planned/made. Identify and evaluate added functionality. Identify and evaluate changed functionality: • Determine complexity of the function prior to change (from previous functional size measurement documentation or size as existing prior to change). • Determine complexity of the function after change. Identify and evaluate deleted functionality. Identify and evaluate any conversion or one-time functionality required to implement this enhancement.

Function Point Counting Practices Manual

4-13

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Enhancement Project Example Example

This section shows an example for a sample enhancement project. The requirements for the enhancement project include the following changes: • The user needs to receive an additional report about jobs that includes totals. • Additional DETs are required to add jobs in batch and correct suspended transactions. A reference to security is also added for the "add job" transaction. • The Job Assignment function must now verify that the job type assigned to an employee matches the employee’s classification, which is maintained by the Employee Relations System. • The report of Employees by Assignment Duration must be changed. Instead of showing a count of employees over 12 and 24 months, the report must now show only salaried employees. • The user no longer needs to add a job online; therefore, that functionality is removed

The following paragraphs explain the application functionality measured for Application Functionality the example enhancement project. Functionality is described as added, changed, or deleted. The following table shows the functional complexity for the added Added Functionality functionality measured when the project was completed. Note 1: Providing a new report was an additional external output. Note 2: The ER data referenced by the HR application is identified as an EIF.

Data Functions

RETs

DETs

Functional Complexity

1

2

Low

FTRs

DETs

Functional Complexity

1

15

Low

External Interface File Employee Relations Data

Transactional Functions External Output Job report

4-14

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

The following table shows the functional complexity for the changed Changed Functionality functionality, as the functions will exist after the enhancement project is completed. Note 1: The complexity for adding a job was increased because of the additional file type referenced. The complexity for correcting suspended transactions remained low. Note 2: While an additional File Type Referenced is counted, there is no change in complexity for Adding a Job Assignment because it is already High. Note 3: Although there is a change in the selection criteria and the summation logic, there is no change in complexity of the report.

Transactional Functions

FTRs

DETs

Functional Complexity

External Input Add job information (batch input)

3

8

High

Correct suspended transaction

1

8

Low

Add Job Assignment

4

7

High

3

7

Average

External Output Employees by Assignment Duration

The following table shows the functional complexity for deleted functionality Deleted Functionality identified at the end of the project.

Transactional Functions

FTRs

DETs

Functional Complexity

1

7

Low

External Inputs Add job information (screen input)

January 2010

Function Point Counting Practices Manual

4-15

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Application Contribution to the Functional Size The following paragraphs explain the application functionality contribution to the total functional size. Added Functionality The following table shows the contribution to the functional size for the added functionality identified at the end of the project. Function Type EIF

Functional Complexity 1

Complexity Totals

Low

X5=

Average

X7=

High

X 10 =

Function Types Totals

5

5 EO

1

Low

X4=

Average

X5=

High

X7=

4

4

Changed Functionality The following table shows the contribution to the functional size for the changed functionality as it will exist after the enhancement project is complete. Function Type EI

Functional Complexity 1

2

Complexity Totals

Low

X3=

Average

X4=

High

X6=

Function Types Totals

3

12 15

EO 1

Low

X4=

Average

X5=

High

X7=

5

5

4-16

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

Deleted Functionality The following table shows the contribution to the functional size for the deleted functionality. Function Type

Functional Complexity

EI

1

Complexity Totals

Low

X3=

Average

X4=

High

X6=

Function Types Totals

3

3

Final Calculation Using the complexity and contribution for this example, the enhancement project functional size is shown below. EFP = ADD + CHGA + CFP + DEL where •

EFP is the enhancement project function point count

•

ADD is the size of the functions being added by the enhancement project

•

CHGA is the size of the functions being changed by the enhancement project – as they are / will be after implementation

•

CFP is the size of the conversion functionality

•

DEL is the size of the functions being deleted by the enhancement project

EFP = 9 + 20 + 0 + 3 EFP = 32

January 2010

Function Point Counting Practices Manual

4-17

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Initial Application Functional Size The initial application functional size is shown below. AFP = ADD where •

AFP is the application function point count

•

ADD is the size of the functions to be delivered to the user by the development project (excluding the size of any conversion functionality) or the functionality that exists whenever the application is measured

AFP = 115 Note: Only the size of the application functionality installed for the user is included in the initial application functional size.

4-18

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Enhancement Projects and Maintenance Activity

Application Functional Size After Enhancement The application functional size measurement to reflect enhancements is shown below. AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL) where •

AFPA is the application function point count after the enhancement project

•

AFPB is the application function point count before the enhancement project

•

ADD is the size of the functions being added by the enhancement project

•

CHGA is the size of the functions being changed by the enhancement project – as they are / will be after implementation

•

CHGB is the size of the functions being changed by the enhancement project – as they are / were before the project commenced

•

DEL is the size of the functions being deleted by the enhancement project

AFPA = (115 + 9 + 20) - (18 + 3) AFPA = 123 Some individuals may apply a value adjustment factor (VAF), which considers 14 general system characteristics (GSCs). For guidance in the use of the VAF and GSCs, refer to Appendix C.

January 2010

Function Point Counting Practices Manual

4-19

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Enhancement versus Maintenance Considerations Once an application has been developed and installed, it must then be maintained (modified) in order for it to continue to meet the needs of an everchanging business and technical environment. This maintenance includes a wide range of activities that are performed during this phase of the application life cycle, some of which involve functional changes that are applicable to FPA.

Categories of Maintenance The Institute of Electrical and Electronics Engineers, Inc. (IEEE) defines three categories of maintenance: Adaptive Maintenance: Software maintenance performed to make a computer program usable in a changed environment. Corrective Maintenance: Software maintenance performed to correct faults in hardware or software. Perfective Maintenance: Software maintenance performed to improve the performance, maintainability or other attributes of a computer program. While the body of this chapter has provided Function Point Counting hints and guidelines for enhancements to existing applications, there is no industrywide standard for consistent classification of activities that fall within the above categories. This section provides a framework based on common industry experience from which to evaluate the applicability of FPA in the support of installed applications. The ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) define three categories of maintenance: Adaptive Maintenance

The modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment. Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which a software product must operate. These changes are those that must be made to keep pace with the changing environment. For example, the operating system might be upgraded and some changes may be made to accommodate the new operating system. (ISO/IEC 14764:2006)

Corrective Maintenance

The reactive modification of a software product performed after delivery to correct discovered problems. The modification repairs the software product to satisfy requirements. (ISO/IEC 14764:2006)

4-20

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Perfective Maintenance

Enhancement Projects and Maintenance Activity

Modification of a software product after delivery to detect and correct latent faults in the software product before they are manifested as failures. Perfective maintenance provides enhancements for users, improvement of program documentation, and recoding to improve software performance, maintainability, or other software attributes. Contrast with: adaptive maintenance; corrective maintenance. (ISO/IEC 14764:2006) Functional size measurement quantifies the size of business requirements. In an enhancement environment, it measures the effects of changes to those business requirements. Therefore, functional size measurement is applicable to a subset of adaptive maintenance. This includes the software functionality added, changed or deleted as well as the software functionality provided to convert data and meet other implementation requirements (e.g., conversion reports). It is impractical to provide a complete and comprehensive list of development and support activities. Rather, the following areas are identified with suggestions regarding FPA applicability. It is strongly recommended that each organization develop its own guide with activities, definitions and terminology specific to that organization.

Application Maintenance and Support Activities Since maintenance and support activities are subject to inconsistent reporting, locally developed guidelines should address these areas. The following are some of the more commonly encountered activities, with suggested handling relative to FPA. Maintenance Requests

Regardless of duration or level of work effort required, it is the type of activity that determines how the work is classified. Function Point Analysis should not be used to size perfective or corrective maintenance work. Corrective maintenance should be charged to the development or enhancement project that introduced the defects. Perfective maintenance should not be charged to any development or enhancement projects. There may be a tendency to track some enhancement functionality as maintenance work, but that work should be monitored and reported separately. The usual rationale for inclusion is for either immediacy or expediency. Organizations often provide a fast path for small enhancement requests, usually 40 hours or less, in order to reduce the overhead burden on the project. When business requirements are affected, Function Point Analysis should be applied for the measurement of results.

January 2010

Function Point Counting Practices Manual

4-21

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

If a release contains a mix of adaptive, corrective and/or perfective maintenance requirements, care must be exercised in separation of work effort, since the latter two categories contribute zero function points to the business. While such work effort segregation may be relatively easy during the construction phase, depending on the level of granularity in effort tracking, it is generally more difficult during most final test phases. One possible approach would be an apportionment of the entire release based on proportional content. A project involving only upgrades from one platform, language or technical environment to another, with no change in user functionality, should not be subject to an enhancement functional size measurement. Activity Correction of Production Errors (“break/fix”) Perfective or Preventative Maintenance Platform Upgrades, New System Software Releases Project with both fixes and enhancements On-Demand (Ad Hoc) Requests

No No No Partially

Functionality that is provided to the end user in the form of one-time/ondemand reports and data extracts is certainly countable. The decision to count should be made based on whether the functions will be maintained and the business need that the functional size will meet. It must be noted that this discussion is limited to reports/extracts produced by I/S Development and does not cover user generated Ad Hoc reports or queries. It should be noted that the methodology to produce ad hoc reports is usually not as rigorous as for a full enhancement project. Therefore, care should be taken when comparing the relative costs of such work with those of general enhancement activity. Activity One-time Reports Table Updates Special Job Setup Data Correction Mass Data Changes

4-22

Within Enhancement Counting Scope

Within Enhancement Counting Scope Local Convention No No No Yes – as conversion if associated with a project.

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

End User Support

Enhancement Projects and Maintenance Activity

Any non-project work effort related to activities classified as “not countable” should be charged to a labor classification other than New Development or Enhancement. For Preliminary Estimation or Feasibility Studies, the problem is that user requirements are not yet well defined. Also, a project at either stage is usually not yet funded (and may never be funded). At best, a Rough Order of Magnitude (ROM) function point estimate can be determined, but no quantitative measurements should be applied at this point. Any resulting number is for budget and planning purposes only. General non-project user support activities, such as answering “what-if” questions and helping users, should not be subject to Function Point Analysis. Activity Preliminary Estimation or Feasibility Analysis Answering “What If” questions General Non-Project Client Support Help Desk Support

Conclusion

January 2010

Within Enhancement Counting Scope At best, ROM No No Partially

This chapter is intended only to provide guidance and is not to be interpreted as a set of absolute rules. Exceptions to these scenarios can always be found. Each instance must be evaluated based on the user requirements and business situation. Additionally, each IT organization has its own unique activities and development processes. These should be addressed in a local Function Point Guide, which addresses all facets of Function Point Analysis, including counting assumptions and any unique interpretations of CPM rules.

Function Point Counting Practices Manual

4-23

Enhancement Projects and Maintenance Activity

Part 3 – Counting Practices

Summary While a major portion of IT Application Development resources are usually devoted to supporting or enhancing existing applications, most examples and illustrations within Part 4 are geared toward new development. This chapter provides guidance on what to count and insight into the identification process in an enhancement environment. The first step is to correctly identify those Data and Transactional Functions that have been added, changed or deleted based on user requirements. For modifications, the most frequently overlooked area is change involving only internal processing logic. Part 1 includes definitions of processing logic which are helpful in identifying modifications to transactional functions that should be counted. Lastly, each identified Data and Transactional Function must be counted in accordance with the rules in Part 1. It is also important to segregate the different maintenance and support activities and their associated effort as discussed in the Enhancement Versus Maintenance Considerations Section.

4-24

Function Point Counting Practices Manual

January 2010

Part 3 Chapter 5

Data Conversion Activity Introduction

This section addresses the functionality to be evaluated when there are requirements to migrate or convert data in conjunction with a new development or enhancement project or to move an application to a different platform. Part 4 of the CPM provides other examples of the data functions and transactional functions for data conversion.

Contents

This chapter will discuss the following as illustrations of various conversion scenarios: Topic

January 2010

Page

Conversion Functionality

5-2

Scenario 1: Enhancement Project Data Conversion

5-3

Scenario 2: Data Conversion with EIFs Referenced

5-3

Scenario 3: Assigning Default Values

5-3

What is Not Conversion Functionality

5-4

Summary

5-4

Function Point Counting Practices Manual

5-1

Data Conversion Activity

Part 3 – Counting Practices

Conversion Functionality Conversion of application data is based on the user view of the data. Users identify data requirements based on separate needs such as Employment, Accounting, Customer or Inventory data. The user view of this data encompasses all the attributes associated with the group of data as defined in the application. This user recognizable group of data and the associated data attributes become the basis for a logical group of data that fulfills a specific user requirement. It is this logical file that requires all of its data attributes to be maintained as part of the whole (linked and not independent). Additional attributes could be required because of new or changed business requirements. As part of the enhancement, it might be necessary to convert and populate the data attributes added as part of the enhancement project. The view of the conversion process is based on the original application, the logical files being converted and the data requirements of the new application. The conversion process executes against all data as viewed by the user to create an updated logical file that fulfills specific user requirements for the new/converted application data. Apply the standard EP identification rules to identify the conversion functionality. The elementary process includes any exception reports, error reports, conversion reports or control reports required to ensure the integrity of the data being converted. The new or enhanced application’s ILF(s) are populated by the converted data, and its user requirements dictate what is required from the old application(s) to meet the functional user requirements of the project.

5-2

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Data Conversion Activity

Scenario 1: Enhancement Project Data Conversion The project involves integrating a corporate HR Skills function that one division had previously implemented as a stand-alone application. There is a one-time requirement to capture any existing skills data and populate existing data attributes in an ILF in an existing HR application. The existing skills data to be imported will be counted as an EI. There is a control and error report that is produced to ensure the integrity of the migration. This process will be executed as part of deploying the new functionality. There is one elementary process to initially populate the new data attributes in an ILF of the HR system, including the control and error report. The conversion process will be counted as an EI, which will be included in the Enhancement Project Functional Size but will not be added to the Application Functional Size because it is a one-time process.

Scenario 2: Data Conversion with EIFs Referenced The user has requested that an ILF (or part of an ILF) be populated from an ILF in another application. In this example, validation is required against yet another ILF from a third application. This is specified as a one-time process and the data reference in the third application will not be utilized in the future. The attributes to be loaded serve as an input transaction to populate the receiving ILF and will be counted as an EI. The data referenced in the third application for validation will be counted as an EIF and an additional FTR. The receiving ILF will also be considered as an FTR. Both the EI and the EIF should be included in the measurement for the project but not added to the application functional size.

Scenario 3: Assigning Default Values An enhancement project requires the addition of a DET to an existing ILF. The new DET will be populated with a specific default value. Although the ILF and any modified transaction(s) will be counted as changed, no conversion functionality is counted. No data is crossing the boundary to establish the default value.

January 2010

Function Point Counting Practices Manual

5-3

Data Conversion Activity

Part 3 – Counting Practices

What is Not Conversion Functionality This section describes several instances that are not considered Conversion. •

Do not count software upgrades due to the installation of a revised version of vendor packages as conversion functionality.

•

Do not count the migration of an application to a new platform as conversion functionality.

•

Do not count the conversion of data accomplished via an existing load utility. No functionality was developed to accomplish the conversion.

•

Even if an EIF for the application being measured is changed, there can not be any conversion functionality. Only the application that has counted the data function as an ILF can count conversion functionality.

Summary When an ILF is added or changed, there is a possibility that a conversion process might be required to populate the new ILF or DET(s) in an existing ILF. Part of the analysis is to identify what is crossing the boundary. In the case of new development, the existing data store(s) or ILF(s) of the system(s) being replaced is considered to be crossing the boundary. When an enhancement involves a changed ILF and processing logic is required to populate the new attribute (e.g., validations, logical comparisons, etc.), the existing ILF can be considered as crossing the boundary as an EI. If a new attribute in an ILF is populated with only a default or null value, conversion should not be counted because there is nothing crossing the boundary.

5-4

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Index

Index to Part 3

A Adaptive maintenance definition, 4-20 Added functionality example, 4-14 identification, 4-10 Approach, 3-4 Associative Entity, 2-3, 2-10, 2-34 counted as logical file, 2-36 counted as RET, 2-35 not counted, 2-34 Associative Entity Type, 2-5, 2-32 Attribute keys, 2-23 Foreign key, 2-23 Primary key, 2-23 Secondary key, 2-23 Attribute name, 2-22 Attributes, 2-6, 2-21 Attribution, 2-23 Attributive Entity, 2-37 mandatory, 2-37 optional, 2-37 Attributive Entity Type, 2-6, 2-32 B Business data definition, 1-4 definitions, 1-4 examples, 1-5 logical characteristics, 1-4 physical characteristics, 1-5

January 2010

Business view. See User View C Changed functionality example, 4-15 identification, 4-10 Code data definition, 1-6 examples, 1-7 identifying, 1-10 logical characteristics, 1-7 origins of, 1-8 physical characteristics, 1-7 what it is, 1-10 what it is not, 1-13 Code data types static or constant, 1-11 substitution, 1-11 valid values, 1-12 Concept Entity (in-)dependency, 2-12, 2-15 Optional / Mandatory relationship, 2-12, 2-15 Conversion functionality identification, 4-11 Conversion Functionality, 4-2 Copy definition, 3-3 Corrective maintenance definition, 4-20 D Data Element, 2-4, 2-21

Function Point Counting Practices Manual

i-1

Index

Part 3 – Counting Practices

Example of addresses, 2-26 Example of foreign keys, 2-29 Example of multiple/single attributes, 2-25 Example of names, 2-26 Example of repeating fields, 2-27 Example of status fields, 2-28 Example of system dates, 2-29 user recognizable, 2-25 Data Element Type rules, 2-24 Data item, 2-4 Data types business, 1-4 code, 1-6 reference, 1-5 Definitions adaptive maintenance, 4-20 Associative Entity, 2-3 Associative Entity Type, 2-5 Attributes, 2-6, 2-21 Attributive Entity Type, 2-6 code data, 1-6 copy, 3-3 corrective maintenance, 4-20 Data Element, 2-4, 2-21 Data Element Type, 2-24 Data item, 2-4 Entity, 2-3 Entity Subtype, 2-3, 2-6 Entity Type, 2-3, 2-5 file, 3-3 File, 2-4 File System, 2-4 image, 3-3 load, 3-3 merge, 3-3 Normalization, 2-6 perfective maintenance, 4-20 primary intent, 3-2 Record, 2-4 reference data, 1-5 refresh, 3-3 Relationships, 2-6 Deleted functionality example, 4-15 identification, 4-11 E End user support, 4-23 Enhancement project measuring transactional functions, 4-3 processing logic, 4-5 Enhancement Project Data Conversion, 4-3 measuring data functions, 4-2 Entity, 2-3 not maintained, 2-9

i-2

Entity dependence, 2-12 Entity independence, 2-12 Entity Subtype, 2-6 Entity Subtype, 2-3 Entity Subtype, 2-32 Entity Subtype, 2-38 Entity Subtype counted as RET, 2-38 Entity Subtype not counted, 2-39 Entity Type, 2-3, 2-5 Examples added functionality, 4-14 changed functionality, 4-15 deleted functionality, 4-15 F File, 2-4 definition, 3-3 Files System, 2-4 Functional, 3-5 I Image definition, 3-3 Index files, 2-9 Intersection entity, 2-10 K Key-to-key entity, 2-10 L Load definition, 3-3 Logical files Process for establishing the set of, 2-2 M Maintenance requests, 4-21 Merge definition, 3-3 N Non-key attributes, 2-10 Normalization, 2-6 O On-demand (ad hoc) requests, 4-22 Outline of Scenarios, 3-5 P Perfective maintenance definition, 4-20 Physical data model, 2-9 Primary Intent definition, 3-2 Definitions, 3-2 Process for classifying Logical files, 2-2 Process for identifying Data Element Types, 2-2 Logical files, 2-2 using Elementary Process Method, 2-9 using Entity (In-)Dependency Method, 2-9

Function Point Counting Practices Manual

January 2010

Part 3 – Counting Practices

Index

Record Element Types, 2-2 R Record, 2-4 Reference data definition, 1-5 examples, 1-6 logical characteristics, 1-5 physical characteristics, 1-6 Refresh definition, 3-3 Relational databases, 2-4 Relationships, 2-6 Mandatory 1-1, 1-N, 2-6, 2-14 nature of, 2-14 Optional 1-(N), (1)-(N), (1)-N, 2-6, 2-14 Repeating fields, 2-27 Repeating groups/data counted as RET, 2-40 not counted as RET, 2-40 Row, 2-4 S Scenario 4: Image Copy/Load One Physical Table No Additional Processing Scenarios, 3-13 Scenario Naming Conventions, 3-5 Scenarios Copy and Merge, 3-15

January 2010

Image Copy/Load - No Additional Processing, 311 Read, 3-7 Scenario 4, 3-13 Screen Scraping, 3-17 Standard Transaction Data, 3-20 Static Image Copy, 3-9 Updating the Same Data Store, 3-18 Significance to the business, 2-13 Solution Diagram Scenario 1, 3-8 Scenario 2, 3-10 Scenario 3, 3-12 Scenario 4, 3-14 Scenario 5, 3-16 Scenario 6, 3-17 Scenario 7, 3-19 Scenario 8, 3-21 Subgroup, 2-31 Symbols Used in Diagram Solution, 3-4 T Table, 2-4 Technical, 3-6 Technical attributes, 2-9, 2-24 Tuple, 2-4 U User view, 2-9

Function Point Counting Practices Manual

i-3

Index

Part 3 – Counting Practices

This page intentionally left blank.

i-4

Function Point Counting Practices Manual

January 2010

Part 4 – Examples

This page intentionally left blank.

Part 4 Examples Introduction

Contents

Part 4 provides examples of data functions and transactional functions to illustrate the counting rules from Part 1. The examples provide: •

A description of the data or transactional function

•

The basis for the measurement

•

The tables to be used in applying the counting rules

•

The identification of the functional complexity

•

The contribution to the functional size

Part 4 includes the following sections: Topic

January 2010

Page

Data Function Counting Examples

1-3

ILF Counting Examples

1-7

EIF Counting Examples

1-37

Transactional Function Counting Examples

2-1

Elementary Process Identification Examples

2-7

EI Counting Examples

2-61

EO Counting Examples

2-103

EQ Counting Examples

2-127

Function Point Counting Practices Manual

1-1

This page intentionally left blank

1-2

Function Point Counting Practices Manual

January 2010

Part 4 Chapter 1

Data Function Counting Examples Introduction

This section uses several examples to illustrate procedures for measuring data functions, each of which stands on its own. Note: Each example shows only the requirement specific to the situation being illustrated, although in practice we must evaluate all requirements and their functional impact. This section uses a Human Resources (HR) application along with a Security application and a Mail Distribution application to illustrate procedures to identify and measure data functions. In addition to this section, examples are in the Case Studies which are included in the IFPUG supplementary documentation. Note: The examples in this section and throughout the manual have two purposes: 1. To illustrate how the function point counting rules are applied for a given set of user requirements 2. To allow you to practice using the counting procedures Each counter must:

Contents

•

Analyze the specific user requirements that apply for each project or application being measured, and

•

Count based on those requirements.

This section explains the organization of the examples and includes detailed examples for counting ILFs and EIFs. Topic

January 2010

Page

Data Function Counting Examples

1-3

ILF Counting Examples

1-7

EIF Counting Examples

1-37

Function Point Counting Practices Manual

1-3

Data Function Counting Examples

Part 4 - Examples

Organization of the Counting Examples This section explains how the examples are presented.

Outline of the Organization The following list outlines the sequence of information in the detailed examples. For each example: 1. Data functions are identified. 2. Data functions are classified as either ILFs or EIFs. 3. The RETs and DETs that contribute to the functional complexity are identified and counted.

Diagram of the Organization The following diagram illustrates the organization of the examples.

Example Identify ILFs Count RETs/DETs

Example Identify EIFs Count RETs/DETs

Count for Each Example Each example includes the following components: 1. Basis for the measurement 2. Tables applying the counting rules

1-4

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Diagram of Components

Data Function Counting Examples

The following diagram illustrates the components for each example and the flow of information. Basis for the Measurement

Counting Rules Table Identify ILF or EIF

For Each Identified ILF or EIF, Count RETs and DETs

January 2010

Function Point Counting Practices Manual

1-5

Data Function Counting Examples

Basis for the Measurement

Part 4 - Examples

The basis for the measurement begins each example. As shown in the diagram of components, the measurement may be based on the following components: •

User requirements

•

Data and process models

•

Windows, screens, or reports

Note: All components in the diagram are not included in all examples. In some examples, the requirements stand alone as the basis for the measurement. Other examples include a data or process model, windows, screens, and reports. Counting Rules Table

The analysis to identify functions is presented in a table that lists the counting rules for the function type. The rules are applied to the components that make up the basis for the measurement. The analysis is explained in the table in the column "Does the Rule Apply?". Note: If all the rules apply, the example is counted as an ILF or EIF. The next table shows the rules and explanation for the complexity for each function type identified.

1-6

Function Point Counting Practices Manual

January 2010

ILF Counting Examples Introduction

This section uses a Human Resources (HR) application to illustrate procedures to identify and measure data functions. In addition to this section, further examples are in the Case Studies which are included in the supplementary IFPUG documentation.

Contents

This section includes the following examples: Topic

January 2010

Page

Summary Descriptions of ILF Counting Examples

1-8

Example: Audit Data for Inquiries and Reports

1-9

Example: Report Definition

1-15

Example: Alternate Index

1-20

Example: Shared Application Data

1-21

Example: Different Users/Different Data Views

1-29

Function Point Counting Practices Manual

1-7

ILF Counting Examples

Part 4 - Examples

Summary Descriptions of ILF Counting Examples The examples for ILFs are described in the following table.

1-8

Example

Summary Description

Audit Data

This example shows the analysis and measurement of data that is retained for audit purposes.

1-9

Report Definition

This example shows counting user defined report definitions maintained within an application.

1-15

Alternate Index

This example illustrates the analysis of user requirements for the report definition example that focuses on the requirements for physical implementation.

1-20

Shared Application Data

This example shows counting data that is maintained by more than one application.

1-21

Different Users/Different Data Views

This example shows that two applications can count the same file with different DETs.

1-29

Function Point Counting Practices Manual

Page

January 2010

Part 4 - Examples

ILF Counting Examples

Example: Audit Data for Inquiries and Reports Analysis of the following user security requirements showed a need for audit User Requirements data: 1. Allow or deny user access to each screen in the application. 2. Change a user's access to each screen. 3. Report on any screen security added or changed using the following data: −

Identification of the user who is adding or changing security information

−

The user and screen security that was added or changed

−

The user and screen security images before and after a change was made

−

Date and time the add or change occurred.

4. Capture audit data to monitor and report daily security activity. This requirement was determined when a design was implemented to satisfy the user's screen security requirements. ERD

Legend: Entity Type Attributive Entity Type Optional One-to-Many Relationship

January 2010

Function Point Counting Practices Manual

1-9

ILF Counting Examples

Part 4 - Examples

Data Flow Diagram Report info Request Report User

date, time, user id, Before, after

Screen Screen Security Audit

1.1 Add screen security info Add Screen Security user ID, SS#, access allowed, window ID Screen Screen Security

date, time, user id, before, after

1.3 user id, date, time, before, after

Report Security Changes

change 1.2 screen security Change Screen Security info

Change screen security info

Legend: User or Application

Data Stored Process Flow of Data

1-10

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

ILF Counting Examples

Identify Data Functions Use the Data Function Identification rules to determine whether Screen Security Audit data is a data function. The following table shows the analysis for Screen Security Audit data. Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Screen Security and Screen Security Audit.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

Screen Security and Screen Security Audit are related. Screen Security Audit is dependent upon Screen Security. They are grouped together into a single data function.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

The Screen Security Audit is not counted as a data function on its own because it is dependent upon Screen Security. Screen Security Audit is part of the Screen Security data function.

January 2010

Function Point Counting Practices Manual

1-11

ILF Counting Examples

Step 2

Part 4 - Examples

Classify Data Functions The following table shows the analysis to determine whether the Screen Security information is classified as an ILF. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Screen Security data function is maintained within the application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

Based on the analysis, the Screen Security information is classified as an ILF. Step 3

Count DETs For DETs, look at each attribute associated with the Screen Security ILF and determine whether the DET counting rules apply. The Screen Security ILF includes: • • • • • • •

•

1-12

User ID SS # Window ID Access Allowed Date Change Made Time Change Made Before Image o User ID Before o Window ID Before o Access Allowed Before After Image o User ID After o Window ID After o Access Allowed After

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

ILF Counting Examples

The analysis of the DETs for the Screen Security ILF is shown below:

Step 4

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

User ID, SS #, Window ID, Access Allowed, Date Change Made and Time Change Made.

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

There are no attributes of this type.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

User ID Before, Window ID Before and Access Allowed Before are grouped and counted as Before Image. The same is also done for the After Image attributes.

Count RETs For RETs, identify subgroups based on the RET counting rules.

January 2010

RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Screen Security ILF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

Screen Security Audit is an attributive entity in an optional 1-M relationship. Count an additional RET for Screen Security Audit.

Function Point Counting Practices Manual

1-13

ILF Counting Examples

Part 4 - Examples

The RET and DET totals for Screen Security are shown in the following table. RETs

DETs

• Screen Security • Screen Security Audit

• User ID • SS # • Window ID • Access Allowed • Date Change Made • Time Change Made • Before Image • After Image Total

Total

Step 5

2 RETs

Determine Functional Complexity 2 RETs and 8 DETs

Step 6

Complexity is Low

Determine Functional Size Functional Size of 1 Low ILF

1-14

8 DETs

7 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

ILF Counting Examples

Example: Report Definition The user requires the ability to perform the following activities: User Requirements 1. Enter a report definition which includes − − − −

A unique report identifier A report name Attributes used on the report Calculations to generate the report.

2. Reuse the defined report at any time, changing the definition if necessary. 3. View and print a report using the report definition. 4. Inquire on existing report definitions by report name or report identifier.

January 2010

Function Point Counting Practices Manual

1-15

ILF Counting Examples

Step 1

Part 4 - Examples

Identify Data Functions From the user requirements, report identifier, report name, attributes on the report, and calculations together make up one logical grouping of data for a report definition because they are maintained as a group. The following table shows the analysis to determine whether the report definition information is a data function. See the Case Studies for how the remaining requirements may be counted.

1-16

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Report Definition.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

Report Definition information is not an instance of code data. The entity is used for reference in generating reports, consists of more than just a code and description and is changed as needed by the user.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 2

ILF Counting Examples

Classify Data Functions The following table shows the analysis to determine whether the Report Definition information is classified as an ILF. See the Case Studies for how the remaining requirements may be counted. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Report Definition data function is maintained within the application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

Based on the analysis, the Report Definition information is classified as an ILF.

Step 3

Count DETs For DETs, look at each attribute associated with the Report Definition ILF and determine whether the DET counting rules apply. The Report Definition ILF includes: • • • •

January 2010

Report Identifier Report Name Attributes Calculations

Function Point Counting Practices Manual

1-17

ILF Counting Examples

Part 4 - Examples

The analysis of the DETs for the Screen Security ILF is shown below:

Step 4

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

Report Identifier, Report Name, Attributes, Calculations. Although there are multiple occurrences of both Attributes and Calculations, they are each counted as only one DET.

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

There are no attributes of this type.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

Count RETs For RETs, identify subgroups based on the RET counting rules.

1-18

RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Report Definition ILF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

ILF Counting Examples

The RET and DET totals for report definition are shown in the following table. RETs

DETs

• Report Definition group

• Report Identifier • Report Name • Attributes • Calculations Total

Total

Step 5

1 RET

Determine Functional Complexity 1 RETs and 4 DETs

Step 6

Complexity is Low

Determine Functional Size Functional Size of 1 Low ILF

January 2010

4 DETs

7 FP

Function Point Counting Practices Manual

1-19

ILF Counting Examples

Part 4 - Examples

Example: Alternate Index The user needs to inquire on report definitions using the report name as the User Requirements key to finding the desired definition. To satisfy the user requirement, an alternate index is created using the report name as the key. Step 1

Identify Data Functions The following table shows the summary analysis to determine whether the alternate index is an ILF. Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

No. From the user perspective, this filter function provides the user with specific attributes of the report definitions created that reference the Report Definition ILF. This technical filter, necessary to create the inquiry list, does not constitute a business function on its own.

2.

Exclude entities that are not maintained by any application

Not applicable.

3.

Group related entities that are entity dependent

Not applicable.

4.

Exclude those entities referred to as code data

Not applicable.

5.

Exclude entities that do not contain attributes required by the user

Not applicable.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

Not applicable.

Based on the analysis in the table, the alternate index is not a logical group; therefore, it is not counted as an ILF.

1-20

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

ILF Counting Examples

Example: Shared Application Data The HR user requires the ability to maintain information on each new User Requirements employee. The information that must be maintained by the HR user includes: • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title

* As a result of creating a new employee record, the employee’s anticipated Pension Eligibility Date should be automatically calculated and saved with the other employee information. The Security user requires that a security level be assigned to each new employee. The Security department conducts a background search after each employee is hired and assigns the appropriate organizational security authorization level. This is not application security which determines the access of individual users within the application. The information that must be maintained by the Security user includes: • •

Employee ID Organizational Security Authorization Level

The Security user also requires a report listing the following information:

January 2010

•

Count of Employee IDs

•

Employee Name

•

Employee ID

•

Organizational Security Authorization Level

Function Point Counting Practices Manual

1-21

ILF Counting Examples

Data Flow Diagram

1-22

Part 4 - Examples

The following diagram shows the data flow for this example.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

ILF Counting Examples

Identify Data Functions (for HR application) Determine whether the Employee information is a data function for the HR application. The following table shows the summary analysis.

Step 2

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Classify Data Functions (for HR application) Determine whether the Employee information is classified as an ILF for the HR application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Employee data function is maintained within the HR application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

The analysis shows that the Employee information is an ILF for the HR application.

January 2010

Function Point Counting Practices Manual

1-23

ILF Counting Examples

Step 3

Part 4 - Examples

Count DETs (for HR application) For DETs, look at each attribute associated with the Employee ILF in the HR application and determine whether the DET counting rules apply. The following list includes the attributes for the Employee information: • • • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date Organizational Security Authorization Level

The analysis of the DETs for the Employee ILF in the HR application is shown below:

1-24

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

The following attributes satisfy this rule:

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

All of the attributes are used within the HR application except Organizational Security Authorization Level.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

• • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 4

ILF Counting Examples

Count RETs (for HR application) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Employee ILF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Employee ILF in the HR application are shown in the following table. RETs

DETs

• Employee information group

• Employee ID • Employee Name • Employee Mailing Address • Employee Pay Grade • Employee Job Title • Pension Eligibility Date Total 6 DETs

Total

Step 5

1 RET

Determine Functional Complexity (for HR application) 1 RET and 6 DETs

Step 6

Determine Functional Size (for HR application) Functional Size of 1 Low ILF

January 2010

Complexity is Low

7 FP

Function Point Counting Practices Manual

1-25

ILF Counting Examples

Step 1

Part 4 - Examples

Identify Data Functions (for Security application) Determine whether the Employee information is a data function for the Security application. The following table shows the summary analysis.

Step 2

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Classify Data Functions (for Security application) Determine whether the employee information is classified as an ILF for the Security application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Employee data function is maintained within the Security application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

The analysis shows that the Employee information is also classified as an ILF for the Security application.

1-26

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

ILF Counting Examples

Count DETs (for Security application) For DETs, look at each attribute associated with the employee ILF in the Security application and determine whether the DET counting rules apply. The employee ILF includes: • • • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date Organizational Security Authorization Level

The Analysis of the DETs for the Employee ILF in the Security application is shown below:

January 2010

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

The following attributes satisfy this rule:

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

Only the Employee ID, Employee Name and Organizational Security Authorization Level are used by the Security application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

• • •

Employee ID Employee Name Organizational Security Authorization Level

Function Point Counting Practices Manual

1-27

ILF Counting Examples

Step 4

Part 4 - Examples

Count RETs (for Security application) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Employee ILF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Employee ILF in the Security application are shown in the following table. RETs

DETs

• Employee information group

• • •

Total

Step 5

1 RET

Determine Functional Complexity (for Security application) 1 RET and 3 DETs

Step 6

Complexity is Low

Determine Functional Size (for Security application) Functional Size of 1 Low ILF

1-28

Employee ID Employee Name Organizational Security Authorization Level Total 3 DETs

7 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

ILF Counting Examples

Example: Different Users/Different Data Views The information that must be maintained by the HR user includes: User Requirements • Employee ID • Employee Name • Employee Mailing Address The Employee Mailing Address maintained in the Employee data store consists of Floor, Building Code, Street, City, State and Zip Code; however, the HR application uses Mailing Address as a single attribute. • • •

Employee Pay Grade Employee Job Title Pension Eligibility Date *

* As a result of creating a new employee record, the employee’s anticipated Pension Eligibility Date should be automatically calculated and saved with the other employee information. The HR user requires the ability to produce mailing labels for each employee. The Mail Distribution user requires the ability to maintain the Building Codes for each employee to reflect changes in the recognized codes. The Mail Distribution user also requires the ability to evaluate the population in each site to determine the most efficient process for delivering the internal mail. A report is produced listing the number of employees located on each floor for each building. The information that must be maintained or referenced by the Mail Distribution user includes: • •

•

Employee ID Floor Building Code

Other attributes (e.g., Organizational Security Level) exist within the Employee entity, but they are not referenced or maintained by either the HR application or the Mail Distribution application.

January 2010

Function Point Counting Practices Manual

1-29

ILF Counting Examples

Part 4 - Examples

Data Flow Diagram

The following diagram shows the data flow for this example.

Step 1

Identify Data Functions (for HR application) Determine whether the Employee information is a data function for the HR application. The following table shows the summary analysis.

1-30

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 2

ILF Counting Examples

Classify Data Functions (for HR application) Determine whether the Employee information is classified as an ILF for the HR application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Employee data function is maintained within the HR application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

The analysis shows that the Employee information is an ILF for the HR application. Step 3

Count DETs (for HR application) For DETs, look at each attribute associated with the Employee ILF in the HR application and determine whether the DET counting rules apply. Employee information includes: • • • • • • •

January 2010

Employee ID Employee Name Employee Mailing Address (Employee Mailing Address (Floor, Building Code, Street, City, State & Zip Code) Employee Pay Grade Employee Job Title Pension Eligibility Date Organizational Security Level

Function Point Counting Practices Manual

1-31

ILF Counting Examples

Part 4 - Examples

The analysis of the DETs for the Employee ILF is shown below:

1-32

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

The following attributes satisfy this rule:

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

Only the Employee ID, Employee Name, Employee Mailing Address, Employee Pay Grade, Employee Job Title, and Pension Eligibility Date are used by the HR application. The Organizational Security Level attribute was not counted as a DET, because it is not used by the HR application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

Employee Mailing Address is counted as a single DET.

• • • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date Organizational Security Level

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 4

ILF Counting Examples

Count RETs (for HR application) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Employee ILF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Employee ILF in the HR application are shown in the following table.

Step 5

RETs

DETs

• Employee information group

• • • • • •

Total

Total

1 RET

Complexity is Low

Determine Functional Size (for HR application) Functional Size of 1 Low ILF

January 2010

6 DETs

Determine Functional Complexity (for HR application) 1 RET and 6 DETs

Step 6

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date

7 FP

Function Point Counting Practices Manual

1-33

ILF Counting Examples

Step 1

Part 4 - Examples

Identify Data Functions (for Mail Distribution application) Determine whether the Employee information is a data function for the Mail Distribution application. The following table shows the summary analysis.

Step 2

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Classify Data Functions (for Mail Distribution application) Determine whether the Employee information is classified as an ILF for the Mail Distribution application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Employee data function is maintained within the Mail Distribution application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

The analysis shows that the Employee information is an ILF for the Mail Distribution application.

1-34

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

ILF Counting Examples

Count DETs (for Mail Distribution application) For DETs, look at each attribute associated with the Employee ILF in the Mail Distribution application and determine whether the DET counting rules apply. Employee information includes: • • • • • • •

Employee ID Employee Name Employee Mailing Address (Floor, Building Code, Street, City, State & Zip Code; In the Mail Distribution application Floor and Building Code are used as separate attributes.) Employee Pay Grade Employee Job Title Pension Eligibility Date Organizational Security Level

The analysis of the DETs for the Employee information in the Mail Distribution application is shown below:

January 2010

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

The following attributes satisfy this rule:

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

Only the Employee ID, Floor, and Building Code are used by the Mail Distribution application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type. Although Employee Mailing Address was considered a single attribute in the HR application, the two separate attributes (Floor & Building Code) are counted as separate DETs in the Mail Distribution application.

• • •

Employee ID Floor Building Code

Function Point Counting Practices Manual

1-35

ILF Counting Examples

Step 4

Part 4 - Examples

Count RETs (for Mail Distribution application) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Employee ILF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Employee ILF in the Mail Distribution application are shown in the following table.

Step 5

RETs

DETs

• Employee information group

• • •

Total

Total

1 RET

Complexity is Low

Determine Functional Size (for Mail Distribution application) Functional Size of 1 Low ILF

1-36

3 DETs

Determine Functional Complexity (for Mail Distribution application) 1 RETs and 3 DETs

Step 6

Employee ID Floor Building Code

7 FP

Function Point Counting Practices Manual

January 2010

EIF Counting Examples Introduction

This section uses a Human Resources (HR) application along with a Security application and a Pension application to illustrate procedures used to measure data functions. In addition to this section, further examples are in the Case Studies included in the supplementary IFPUG documentation.

Contents

This section includes the following examples:

January 2010

Topic

Page

Summary Descriptions of EIF Examples

1-38

Example: Referencing Data from Other Applications

1-39

Example: Referencing Data from Another Application

1-43

Example: Providing Data to Other Applications

1-48

Example: Help Application

1-50

Example: Data Conversion

1-58

Example: Transaction Input File

1-60

Example: Different Users/Different User View

1-62

Example: Multiple Data Uses

1-66

Function Point Counting Practices Manual

1-37

EIF Counting Examples

Part 4 - Examples

Summary Descriptions of EIF Examples The examples for EIFs are described in the following table.

1-38

Example

Summary Description

Page

Referencing Data from Other Applications to generate output

This example identifies EIFs for an application that references data maintained by another application. The data is used to generate an external output.

1-39

Referencing Data from Another Application to use as part of an input process

This example also looks at referencing data from another application. This example identifies EIFs for an application that references data maintained by another application to use for an external input.

1-43

Providing Data to Other Applications

This is another example of counting data referenced from a different application.

1-48

Help Application

This is an example of counting a Help facility within the HR application.

1-50

Data Conversion

This is an example of counting when converting to a new application.

1-58

Transaction Input File

This example applies EIF counting rules to a transaction input file processed to add jobs to the Human Resources application.

1-60

Different Users/Different User View

This example shows that the view differs when an EIF is used by multiple applications.

1-62

Multiple Data Uses

This example illustrates multiple uses for the same data.

1-66

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EIF Counting Examples

Example: Referencing Data from Other Applications The user wants the Human Resources System to provide the ability to: User Requirements 1. Enter, inquire, and report employee information 2. Interface with the Fixed Assets System to retrieve location information for each building. The location information includes name and description information. Step 1

Identify Data Functions From the user requirements, there are two groups of information: •

Employee information

•

Location information

The following table shows the summary analysis to determine whether the Employee information is a data function. Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee and Location.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type. Employee and Location are entity independent of each other.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Based on the analysis, Employee and Location are each identified as a data function.

January 2010

Function Point Counting Practices Manual

1-39

EIF Counting Examples

Step 2

Part 4 - Examples

Classify Data Functions (for Employee information) Determine whether the Employee information is classified as an EIF for the HR application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Employee data function is maintained within the application.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

Based on the analysis, the Employee information is not external to the HR application. It is maintained internally; therefore, it is not an EIF. Step 2

Classify Data Functions (for Location information) Determine whether the Location information is classified as an EIF for the HR application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Location data function is not maintained within the HR application.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

The Location data function is referenced, but not maintained, by the HR application for use in employee reporting.

•

Is identified in an ILF in one or more other applications

At first, it is not clear whether Location information is maintained in another application. After asking users, we learn that they enter the information into the Fixed Asset application using a screen. Therefore, the Location information is an ILF for the Fixed Asset application and an EIF for the HR application.

Based on the analysis, the Location information is classified as an EIF for the HR application.

1-40

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EIF Counting Examples

Count DETs (for Location) For DETs, look at each attribute associated with the Location EIF and determine whether the rules apply. The following attributes are referenced from the location EIF: • • •

• • •

Building Code Building Name Building Description • Line 1 • Line 2 • Line 3 City State Country

The following table shows the summary analysis of the DET count.

January 2010

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

Building Code, Building Name, Building Description, City, State and Country. The repeating lines of Building Description are counted as only one DET.

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

There are no attributes of this type.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

Function Point Counting Practices Manual

1-41

EIF Counting Examples

Step 4

Part 4 - Examples

Count RETs (for Location) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Location EIF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Location EIF are shown in the following table. RETs

DETs

•

• • •

Location data

• • • Total

Step 5

1 RET

6 DETs

Complexity is Low

Determine Functional Size (for Location) Functional Size of 1 Low EIF

1-42

Total

Determine Functional Complexity (for Location) 1 RET and 6 DETs

Step 6

Building Code Building Name Building Description (repeating lines) City State Country

5 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EIF Counting Examples

Example: Referencing Data from Another Application The user requires the Human Resources application to provide the following User Requirements capabilities: •

All hourly employees must be paid in United States dollars.

•

When the user adds or changes employee information, the Human Resources application must access the Currency application to retrieve a conversion rate. After retrieving the conversion rate, the HR application converts the employee's local standard hourly rate to a U.S. hourly rate using the following calculation: Standard Hourly Rate = Conversion Rate

Data Model

US Dollar Hourly Rate

The following diagram shows the relationships for this example.

Currency Application

HR Application EMPLOYEE

CONVERSION RATE

SALARIED_EMPL HOURLY_EMPL

DEPENDENT

Legend: Entity Type Attributive Entity Type Entity Subtype Mandatory One-to-Many Relationship Optional One-to-Many Relationship

The Currency Conversion information includes: CURRENCY Conversion_Rate_To_Base_Currency Currency

January 2010

Function Point Counting Practices Manual

1-43

EIF Counting Examples

Step 1

Part 4 - Examples

Identify Data Functions From the requirements, there are two groups of information: •

Currency Conversion information

•

Employee information

The following table shows the summary analysis to determine whether the Currency Conversion information is a data function. Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Currency Conversion, Employee and Dependent.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

Currency Conversion is entity independent of the other entities. Dependent is entity dependent on Employee.

4.

Exclude those entities referred to as code data

Although Currency Conversion data might appear to be an instance of code data, Country Code and Conversion Rate are not substitutable (i.e., are not interchangeable) for each other. Currency Conversion information also changes regularly, so it does not meet the criteria of being essentially static.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Based on the analysis, Currency Conversion and Employee are each identified as a data function. Dependent is not a data function on its own, but is part of the Employee data function.

1-44

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 2

EIF Counting Examples

Classify Data Functions (for Employee) The following table shows the analysis to determine whether the Employee information is classified as an EIF. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

Employee information is maintained by the HR application.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

Classified as an ILF; consequently, no EIFs are identified.

Based on the analysis, the Employee information is not external to the HR application. It is maintained internally; therefore, it is not an EIF.

Step 2

Classify Data Functions (for Currency Conversion) The following table shows the analysis to determine whether the Currency Conversion information is classified as an EIF. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

Currency Conversion is not maintained by the HR application.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

The Currency Conversion data function is referenced by the HR application for use in calculating an employee’s pay.

•

Is identified in an ILF in one or more other applications

Although Currency Conversion data might appear to be an instance of code data, Country Code and Conversion Rate are not substitutable (i.e., are not interchangeable) for each other. Currency Conversion information also changes regularly, so it does not meet the criteria of being essentially static.

Because the Currency application provides the conversion rate for the HR application, the group of Currency Conversion data is an EIF for the HR application.

January 2010

Function Point Counting Practices Manual

1-45

EIF Counting Examples

Step 3

Part 4 - Examples

Count DETs (for Currency Conversion) For DETs, look at each attribute associated with the Currency Conversion EIF and determine whether the rules apply. The following table shows the summary analysis of the DET count.

1-46

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

Conversion Rate, Currency.

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

All attributes are referenced by the HR application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 4

EIF Counting Examples

Count RETs (for Currency Conversion) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Currency Conversion EIF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Currency Conversion information EIF are shown in the following table. RETs

DETs

•

• Conversion Rate • Currency Total

Conversion information

Total

Step 5

1 RET

Determine Functional Complexity (for Currency Conversion) 1 RET and 2 DETs

Step 6

Complexity is Low

Determine Functional Size (for Currency Conversion) Functional Size of 1 Low EIF

January 2010

2 DETs

5 FP

Function Point Counting Practices Manual

1-47

EIF Counting Examples

Part 4 - Examples

Example: Providing Data to Other Applications The user has the following requirements for the Currency application: User Requirements • Maintain conversion rates for other currencies to U.S. dollars. •

Step 1

Provide an interface to enable other applications, such as Human Resources, to retrieve conversion information.

Identify Data Functions For this example, determine whether the Currency Conversion information is a data function for the Currency application. The following table shows the summary analysis.

1-48

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Currency Conversion.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

Although Currency Conversion data might appear to be an instance of code data, Country Code and Conversion Rate are not substitutable (i.e., are not interchangeable) for each other. Currency Conversion information also changes regularly, so it does not meet the criteria of being essentially static.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 2

EIF Counting Examples

Classify Data Functions (for Currency Conversion) The following table shows the analysis to determine whether the Currency Conversion information is classified as an EIF. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Currency application maintains Currency Conversion data via transactions from a wire service.

2.

Classify as an EIF, if it:

Classified as an ILF; consequently, no EIFs are identified.

•

Is referenced, but not maintained, by the application being measured and

•

Is identified in an ILF in one or more other applications

The Currency Conversion information is not external to the Currency application; therefore, it is counted as an ILF rather than an EIF for the Currency application. See the previous example in this chapter to review how referencing Currency Conversion may be counted as an EIF.

January 2010

Function Point Counting Practices Manual

1-49

EIF Counting Examples

Part 4 - Examples

Example: Help Application The user requires the Help system to provide: User Requirements 1. The ability to describe how each window is used to accomplish each business function available on the window. 2. The ability to change window help. 3. The ability to set up a definition, default values, and valid values for each attribute in the Human Resources application. 4. The ability to change field help. 5. The ability for the Human Resources application to retrieve window and field help for display. Window Help and Field Help are maintained independently. An entry may exist in one type of help without existing in the other. Data Flow Diagram

The following diagram illustrates the data flow for this example.

User

2.1 Add window help

Human Resources Application

Add Window Help

WINDOW HELP

changes to window 2.2 help info

window id, help description

Change Window Help

Change window help 2.3 Add field help

window id, field id, description, valid values, default values,

window id field id, description, valid values, default values

FIELD HELP

Add Field Help 2.4 Change field help

Change Field Help

changes to field help info

Legend:

1-50

User or Application

Process

Data Stored

Flow of Data

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EIF Counting Examples

Identify Data Functions From the requirements for the Human Resources (HR) application, there are two groups of data: •

Window Help

•

Field Help

The following table shows the summary analysis to determine whether Window Help and Field Help are data functions for the HR application.

January 2010

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Window Help, Field Help.

2.

Exclude entities that are not maintained by any application

There are no entities of this type.

3.

Group related entities that are entity dependent

Window Help and Field Help are independent of each other. An entry may exist in one entity without existing in the other.

4.

Exclude those entities referred to as code data

Window Help and Field Help consist of more than just code and description attributes, are not used for substitution and store data to support core user activity; consequently, they are not considered code data.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Function Point Counting Practices Manual

1-51

EIF Counting Examples

Step 2

Part 4 - Examples

Classify Data Functions (for Window Help) The following table shows the analysis to determine whether the Window Help information is classified as an EIF. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

Window Help is not maintained by the HR application.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

The HR application references, but does not maintain Window Help.

•

Is identified in an ILF in one or more other applications

The Help application has identified Window Help as an ILF.

Window Help information is an EIF in the HR application because the information is referenced by the HR application. Window Help is maintained in the Help application, where it is counted as an ILF.

1-52

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EIF Counting Examples

Count DETs (for Window Help) For DETs, look at each attribute associated with the window help and use the DET counting rules to count DETs. The attributes for window help include: •

Window Identifier

•

Business Function Description.

The following table shows the DET analysis for window help.

January 2010

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

Window Identifier, Business Function Description.

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

All attributes are referenced by the HR application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

Function Point Counting Practices Manual

1-53

EIF Counting Examples

Step 4

Part 4 - Examples

Count RETs (for Window Help) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for Window Help.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type for either data function.

•

sub-type (other than the first sub-type) and

There are no entities of this type for either data function.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type for either data function.

The RET and DET totals for the Window Help EIF are shown in the following table. RETs

DETs

•

• •

Window Help information

Total

Step 5

1 RET

2 DETs

Complexity is Low

Determine Functional Size (for Window Help) Functional Size of 1 Low EIF

1-54

Total

Determine Functional Complexity (for Window Help) 1 RET and 2 DETs

Step 6

Window Identifier Business Function Description

5 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 2

EIF Counting Examples

Classify Data Functions (for Field Help) The following table shows the summary results of the analysis to determine whether the Field Help is classified as an EIF. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

Field Help is not maintained by the HR application.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

The HR application references, but does not maintain Field Help.

•

Is identified in an ILF in one or more other applications

The Help application has identified Field Help as an ILF.

Field Help information is an EIF in the HR application because the information is retrieved by the HR application. The Field Help information is maintained in the Help application where it is counted as an ILF.

January 2010

Function Point Counting Practices Manual

1-55

EIF Counting Examples

Step 3

Part 4 - Examples

Count DETs (for Field Help) For DETs, look at each attribute associated with field help and use the DET counting rules to count DETs. The following list shows the attributes for Field Help: •

Window Identifier

•

Field Identifier

•

Field Description

•

Default Values

•

Valid Values

The following table shows the DET analysis for Field Help.

1-56

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

Window Identifier, Field Identifier, Field Description, Default Values, Valid Values.

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

All attributes are referenced by the HR application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 4

EIF Counting Examples

Count RETs (for Field Help) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for Field Help.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type for either data function.

•

sub-type (other than the first sub-type) and

There are no entities of this type for either data function.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type for either data function.

The RET and DET totals for the Field Help EIF are shown in the following table. RETs

DETs

•

• Window Identifier • Field Identifier • Field Description • Default Values • Valid Values Total

Field Help information

Total

Step 5

1 RET

Determine Functional Complexity (for Field Help) 1 RET and 5 DETs

Step 6

Complexity is Low

Determine Functional Size (for Field Help) Functional Size of 1 Low EIF

January 2010

5 DETs

5 FP

Function Point Counting Practices Manual

1-57

EIF Counting Examples

Part 4 - Examples

Example: Data Conversion An organization has purchased a new HR application package. The User Requirements organization is required to convert its employee file from its existing HR System to a replacement system. The old system did not provide the capability to maintain employee dependent information. The dependent information is initialized when existing employees are migrated to the new application. Data Model

The following diagram shows the data for the two applications. Old HR Application EMPLOYEE

New HR Application EMPLOYEE

SALARIED_EMPL

SALARIED_EMPL

HOURLY_EMPL

HOURLY_EMPL

DEPENDENT

Legend: Entity Type Attributive Entity Type Entity Subtype Mandatory One-to-Many Relationship Optional One-to-Many Relationship

The Employee file from the old HR application is used to add employees to the new HR application. The Employee file from the old HR application has the primary intent to maintain (i.e., populate) the Employee file in the new application. The Employee file from the old HR application does not meet the primary intent of an EIF which is to hold data referenced through one or more elementary processes.

1-58

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EIF Counting Examples

Identify Data Functions From the user requirements, determine whether the old Employee file is a data function. The following table shows the summary analysis. Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

The old Employee file is not a logical group of data from the user perspective.

2.

Exclude entities that are not maintained by any application

The old Employee file is an output (i.e., extract) from the prior application, rather than a logical file that is maintained.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

The Employee information file is a transaction file of Employee information that is migrated to the new system. The conversion process uses the transaction file to maintain the Employee information after it enters the new HR application. The old Employee file is not a logical group of data from the new HR application user’s perspective. The primary intent of the old Employee file is to serve as an input to the new HR application, not to hold data used for reference by one or more elementary processes of the new HR application; therefore, it is not an EIF. Refer to EI/EO/EQ Counting Examples to see how the old Employee file may be counted as an external input.

January 2010

Function Point Counting Practices Manual

1-59

EIF Counting Examples

Part 4 - Examples

Example: Transaction Input File The user requires the ability to: User Requirements 1. Add, change, delete, inquire, and report on job information online 2. Add and change job information in batch mode. Record Layout

The following diagram shows the record layout for this example for adding and changing job information in batch mode.

123456789101234567890123456789012345678901234567890123456789012345678901234567890

1 2 3 4 5 6 7 9 0

ADD⏐01⏐SRENG⏐SENIOR ENGINEER INFORMATION SYSTEMS ADD⏐02⏐SRENG⏐01⏐STARTS AT PAY GRADE 05 ⏐ ADD⏐02⏐SRENG⏐02⏐OTHER PAY GRADES:06 AND 07 ⏐ CHG⏐01⏐STENG⏐ CHG⏐02⏐STENG⏐02⏐OTHER PAY GRADES:05 AND 06 ⏐

Record Descriptions

⏐04⏐

The following table includes descriptions for each record type. Record

Position

Description

01

1-3

Transaction Type

4-5

Record Type

6-10

Job Number

11-45

Job Name

46-47

Job Pay Grade

1-3

Transaction Type

4-5

Record Type

6-10

Job Number

11-12

Job Description Line Number

13-41

Job Description Lines

02

1-60

⏐05⏐

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EIF Counting Examples

Identify Data Functions From the user requirements, determine whether the transaction file is a data function. The following table shows the summary analysis. Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Yes. Data is grouped into transactions which enter the boundary to maintain the Job ILF.

2.

Exclude entities that are not maintained by any application

The Transaction File is excluded. The transactions entering the boundary to update the Job ILF make up the elementary processes. There is no elementary process to update the transaction file.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

There are no EIFs for this example. Refer to EI/EO/EQ Counting Examples to see the explanation of how an input transaction file may be counted as an external input.

January 2010

Function Point Counting Practices Manual

1-61

EIF Counting Examples

Part 4 - Examples

Example: Different Users/Different User View The HR user requires the ability to maintain information on each new User Requirements employee. The information that must be maintained by the HR user includes: • • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date *

* As a result of creating a new employee record, the employee’s Pension Eligibility Date is automatically calculated and saved with the other employee information. The Pension user requires the ability to generate a list of employees with their anticipated Pension Eligibility date. Other attributes (e.g., Organizational Security Level) exist within the Employee entity, but they are not referenced or maintained by either the HR application or the Mail Distribution application. Data Flow Diagram

The following diagram shows the data flow for this example.

Pension Application

HR Application

User

Employee Info

Create Employee

User Print Request

Emp_Id Emp_Name Mailing Address Pay_Grade Job_Title Pension_Elig_Date

Emp_Name Pension_Elig_Date

Employee

Print Employee Listing

Emp_Id Emp_Name Mailing Address Pay_Grade Job_Title Pension_Elig_Date Security_Level

1-62

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EIF Counting Examples

Identify Data Functions (for Pension application) The following table shows the summary analysis to determine whether the employee information is a data function for the Pension application.

Step 2

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee.

2.

Exclude entities that are not maintained by any application

Employee information is maintained by the HR application. It is not excluded.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Classify Data Functions (for Pension application) The following table shows the summary results of the analysis to determine whether Employee is classified as an EIF for the Pension application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

The Pension application does not maintain the Employee information.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

The Pension application references, but does not maintain Employee data.

•

Is identified in an ILF in one or more other applications

The HR application has identified Employee as an ILF.

The Employee information meets all the requirements for an EIF for the Pension application.

January 2010

Function Point Counting Practices Manual

1-63

EIF Counting Examples

Step 3

Part 4 - Examples

Count DETs (for Pension application) For DETs, look at each attribute associated with the employee EIF for the Pension application. Use the DET counting rules to count DETs. The attributes for the employee information include: • • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date

The following table shows the DET analysis for the Employee EIF for the Pension application.

1-64

Data Function DET Counting Rules

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute maintained in or retrieved from the data function through the execution of all elementary processes within the counting scope

The Employee information includes the following attributes:

2.

Count only those DETs being used by the application being measured when two or more applications maintain and/or reference the same data function

Only the Employee Name and Pension Eligibility Date are recognized by the Pension user. All others are not counted as DETs for the Pension application.

3.

Count one DET for each attribute required by the user to establish a relationship with another data function

There are no attributes of this type.

4.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs; grouping will depend on how the elementary processes use the attributes within the application

There are no attributes of this type.

• • • • • • •

Employee ID Employee Name Employee Mailing Address Employee Pay Grade Employee Job Title Pension Eligibility Date Organizational Security Level

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 4

EIF Counting Examples

Count RETs (for Pension application) For RETs, identify subgroups based on the RET counting rules. RET Counting Rules

Does the Rule Apply?

1.

Count one RET for each data function (i.e., by default, each data function has one sub-group of DETs to be counted as one RET)

Count one RET for the Employee EIF.

2.

Count one additional RET for each of the following additional logical sub-groups of DETs (within the data function) that contains more than one DET: •

associative entity with non-key attributes

There are no entities of this type.

•

sub-type (other than the first sub-type) and

There are no entities of this type.

•

attributive entity, in a relationship other than mandatory 1-1

There are no entities of this type.

The RET and DET totals for the Employee EIF in the Pension application. RETs

DETs

•

• •

Employee information

Total

Step 5

1 RET

2 DETs

Complexity is Low

Determine Functional Size Functional Size of 1 Low EIF

January 2010

Total

Determine Functional Complexity 1 RET and 2 DETs

Step 6

Employee Name Pension Eligibility Date

5 FP

Function Point Counting Practices Manual

1-65

EIF Counting Examples

Part 4 - Examples

Example: Multiple Data Uses The Employee information is maintained by the HR application. User Requirements The HR user requires the ability to generate a listing of all of the employees. The information that must be displayed for each employee includes: • •

Data Flow Diagram

Employee ID Employee Name

The following diagram shows the data flow for this example.

HR Application

User

Employee Info

Create Employee

Emp_Id Emp_Name Mailing Address Pay_Grade Job_Title Pension_Elig_Date

Print Request

Employee

Print Employee Listing

Emp_ID Emp_Name

Emp_Id Emp_Name M ailing Addres s Pay _Grade Jo b_Title Pen sion_Elig_Date Security_ Level

1-66

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EIF Counting Examples

Identify Data Functions The following table shows the summary analysis to determine whether the employee information is a data function for the HR application.

Step 2

Data Function Identification Rules

Does the Rule Apply?

1.

Identify all logically related and user recognizable data or control information within the counting scope

Employee.

2.

Exclude entities that are not maintained by any application

Employee information is maintained by the HR application. It is not excluded.

3.

Group related entities that are entity dependent

There are no entities of this type.

4.

Exclude those entities referred to as code data

There are no entities of this type.

5.

Exclude entities that do not contain attributes required by the user

There are no entities of this type.

6.

Remove associative entities that contain additional attributes not required by the user and associative entities that contain only foreign keys; group foreign key attributes with the primary entities

There are no entities of this type.

Classify Data Functions The following table shows the summary analysis to determine whether the employee information that is used to create the employee listing is also classified as an EIF for the HR application. Data Function Classification Rules

Does the Rule Apply?

1.

Classify as an ILF if the data is maintained by the application being measured

Employee is maintained by the HR application. Classify it as an ILF.

2.

Classify as an EIF, if it: •

Is referenced, but not maintained, by the application being measured and

Classified as an ILF; consequently, no EIFs are identified.

•

Is identified in an ILF in one or more other applications

Not applicable.

The Employee information used for creating the Employee Listing is not an EIF for the HR application.

January 2010

Function Point Counting Practices Manual

1-67

EIF Counting Examples

Part 4 - Examples

This page intentionally left blank

1-68

Function Point Counting Practices Manual

January 2010

Part 4 Chapter 2

Transactional Function Counting Examples Introduction

This section uses a Human Resources (HR) application to illustrate procedures used to functionally size transactional functions. In addition to this section, examples are in the Case Studies included in the supplementary IFPUG documentation. Note: The examples in this section and throughout the manual have two purposes: 1.

To illustrate how the function point counting rules are applied for a given set of user requirements.

2.

To enable you to practice using the counting procedures.

Each counter must:

Contents

•

Analyze the specific user requirements that apply for each project or application being measured, and

•

Count based on those requirements

This section explains the organization of the examples and includes detailed examples for each transactional function. Topic

January 2010

Page

Organization of the Counting Examples

2-2

Overview of Transactional Function Procedures

2-5

Elementary Process Identification Examples

2-7

EI Counting Examples

2-61

EO Counting Examples

2-103

EQ Counting Examples

2-127

Function Point Counting Practices Manual

2-1

Transactional Function Counting Examples

Part 4 - Examples

Organization of the Counting Examples This section explains how the examples are presented.

Outline of the Organization The following list outlines the sequence of information in the detailed examples. For each example: •

The EIs, EOs, and EQs are identified

•

The FTRs and DETs that make up the functional complexity are counted

Diagram of the Organization The following diagram illustrates the organization of the examples.

Example Identify EIs Count FTRs/DETs

Example Identify EOs Count FTRs/DETs

Example Identify EQs Count FTRs/DETs

Count for Each Example Each example includes the following components: • Basis for the count • Tables applying the counting rules

2-2

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Transactional Function Counting Examples

Diagram of Components The following diagram illustrates the components for each example and the flow of information. Basis for the Measurement

Counting Rules Table

January 2010

Function Point Counting Practices Manual

2-3

Transactional Function Counting Examples

Basis for the Count

Part 4 - Examples

The basis for the count begins each example. As shown in the diagram of components, the functional size measurement may be based on the following components included in the examples: •

User requirements

•

Data and process models

•

Windows, screens, or reports

Note: All components in the diagram are not included in all examples. In some examples, the requirements stand alone as the basis for the count. Other examples include a data or process model, windows, screens, and reports. Counting Rules Tables

The analysis to identify functions is presented in a table that lists the counting rules for the function type. The rules are applied to the components that make up the basis for the count. The analysis is explained in the table in the column "Does the Rule Apply?" Note: If all the rules apply, the example is counted as an EI, EO, or EQ. The next tables show the rules and explanation for types that make up the complexity for each function type identified.

2-4

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Transactional Function Counting Examples

Overview of Transactional Function Procedures The process to analyze all the examples follows the process described earlier in this chapter. Steps of the process are concerned with applying the rules to measure transactional functions as defined in Part 1 and include the following: • Identify each Elementary Process (EP) required by the user • Determine unique EPs • Classify each EP as an External Input (EI), External Output (EO), or External Inquiry (EQ) • Count the File Types Referenced (FTRs) for each transactional function • Count the Data Element Types (DETs) for each transactional function • Determine the functional complexity for each transactional function • Determine the functional size of each transactional function

January 2010

Function Point Counting Practices Manual

2-5

Transactional Function Counting Examples

Part 4 - Examples

This page intentionally left blank.

2-6

Function Point Counting Practices Manual

January 2010

Elementary Process Identification Examples Introduction

This section uses several examples to illustrate procedures for identifying elementary processes, each of which stands on its own. Note: Each example shows only the requirement specific to the situation being illustrated, although in practice we must evaluate all requirements and their functional impact. References are occasionally made to related functions that also exist but are not illustrated (e.g., Add Employee vs. Update Employee).

Contents

This section includes the following examples,: Topic

January 2010

See Page

Summary Descriptions of Elementary Process Identification Counting Examples

2-8

Example: New Employee/Dependent Data

2-9

Example: Print a Check/Mark It Paid

2-16

Example: View Job Assignments

2-21

Example: Print Job Assignments/Save Criteria

2-26

Example: Employee/Interview Information

2-31

Example: Employee/License Information

2-36

Example: Batch Employee Data Feed

2-41

Example: Assign Employee to Job

2-47

Example: Similar Elementary Processes

2-56

Function Point Counting Practices Manual

2-7

Elementary Process Identification Examples

Part 4 - Examples

Summary Descriptions of Elementary Process Identification Counting Examples The examples for elementary process identification are described in the following table.

2-8

Example

Summary Description

New Employee/ Dependent Data

This example shows that multiple processes can make up one elementary process.

2-9

Print a Check/ Mark It Paid

This example illustrates the concept of primary intent in an elementary process.

2-16

View Job Assignments

This example shows that entering selection criteria for a report is not an elementary process.

2-21

Print Job Assignments/ Save Criteria

This example shows explicitly saving selection criteria for a later use is a separate elementary process.

2-26

Employee/ Interview Information

This illustrates another example of multiple processes making up one elementary process.

2-31

Employee/ License Information

This is a third example of multiple processes making up one elementary process.

2-36

Batch Employee Data Feed

This example illustrates that producing batch error reports and statistical reports are not separate elementary processes.

2-41

Assign Employee to Job

This example illustrates the evaluation of similar elementary processes to determine whether they are unique.

2-47

Similar Elementary Processes

This example illustrates two similar Elementary Processes that are counted as unique transactions.

2-56

Function Point Counting Practices Manual

Page

January 2010

Part 4 - Examples

Elementary Process Identification Examples

Example: New Employee/Dependent Data If a user adds a new employee, the user is required to enter User Requirements 1. employee setup (basic) data and 2. dependent information if the number of dependents is greater than zero. A transaction file is created during the update of the employee information. This transaction file is sent periodically (e.g., at the end of the day) to the Benefits System. Note: Updating of existing employee information including dependent information is not included in this example. Refer to Case Studies 1-3 for an illustration of counting updates.

January 2010

Function Point Counting Practices Manual

2-9

Elementary Process Identification Examples

Add Employee Without Dependent Information

Determine whether adding the employee information without the associated dependent information is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-10

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Adding an employee is part of the functional user requirements.

•

constitutes a complete transaction

No. The complete transaction includes adding the employee information with the associated dependent information, if the number of dependents is greater than zero. These steps cannot be logically separated.

•

is self-contained and

No. Adding the associated dependent information to the added employee is a subsequent processing step necessary to complete the elementary process.

•

leaves the business of the application being counted in a consistent state

No. Adding the employee without adding the dependent does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the dependent must also be added.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Adding an employee (without adding dependents) does not meet all of the criteria.

Add Employee Without Dependent Information does not meet the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Add Only Dependent Information

Elementary Process Identification Examples

Determine whether adding only the dependent information without the employee information is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Adding a dependent is part of the functional user requirements.

•

constitutes a complete transaction

No. This activity is not a complete transaction because it cannot be executed independent of adding an employee.

•

is self-contained and

No. This activity is not self-contained because it cannot be executed independently of adding an employee.

•

leaves the business of the application being counted in a consistent state

No. Adding the dependent without adding the employee does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, both the employee and the associated dependent must be added.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Adding a dependent (without the applicable employee) does not meet all of the criteria. It is not an elementary process.

Add Only Dependent Information does not meet the requirements of an elementary process. In this example, adding an employee (without adding dependent information) does not meet all of the criteria. Other systems may treat maintenance of dependent information independently from employee.

Function Point Counting Practices Manual

2-11

Elementary Process Identification Examples

Add an Employee with Dependent Information

For an employee who has dependents, determine whether adding the employee information with the associated dependent information is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Adding an employee including dependent is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Together employee and dependent information are used to add an employee to the HR system. These steps cannot be logically separated.

•

is self-contained and

Yes. This activity is meaningful by itself and all necessary information is added to the HR application.

•

leaves the business of the application being counted in a consistent state

Yes. The business is left in a consistent state when the employee is added, including applicable dependents.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Add an Employee with Dependent Information meets all of the above criteria.

Add an Employee with Dependent Information meets the requirements of an elementary process. There could be different implementations of this requirement to add dependent(s) to an employee. For example: •

a data entry field called Number of Dependents on the employee screen that triggers the display of the dependent screen

•

a button that displays the dependent screen

•

a menu item on the employee screen that displays the dependent screen

•

the possibility to enter dependent(s) on the employee screen

Irrespective of the implementation of this requirement, there is still one elementary process, adding employee including dependents. We do not identify separate elementary processes because we have optional data (e.g., Add Employee with dependent, Add Employee without dependent).

2-12

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Determine Unique Elementary Processes

Elementary Process Identification Examples

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

January 2010

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

Yes. Add Employee requires the same set of DETs as Update Employee.

•

Require the same set of FTRs and

Yes. Add Employee requires the same set of FTRs as Update Employee.

•

Require the same set of processing logic to complete the elementary process

No. Add Employee has a different set of processing logic than Update Employee.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

The functional user requirement considers there to be a single function. We do not split Add Employee into two elementary processes (i.e., Add Employee Only, Add Dependent Only).

The Add Employee elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

2-13

Elementary Process Identification Examples

Send Transaction File to Benefits System

Determine whether sending the transactions file to the Benefits System is an additional elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-14

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Sending the transaction file to the Benefits System is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Sending the transaction file to the Benefits System is a complete transaction. It is a logically separate function from the Add Employee function.

•

is self-contained and

Yes. The activity to send the transactions to the Benefits System is self-contained. The Transaction file is sent independently (i.e., at end of day) from the Add Employee function.

•

leaves the business of the application being counted in a consistent state

Yes. After the transactions are sent to the Benefits System, the business of the HR application is in a consistent state. The functional user requirement has been fully satisfied with nothing more to be done.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Send Transaction File to Benefits System meets all of the above criteria.

Send Transaction File to Benefits System meets the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Determine Unique Elementary Processes

Elementary Process Identification Examples

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

January 2010

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. Sending the transaction file to the Benefits System requires different DETs than other identified EPs.

•

Require the same set of FTRs and

Yes. Sending the transaction file to the Benefits System requires the same set of FTRs as Add Employee.

•

Require the same set of processing logic to complete the elementary process

No. Sending the transaction file to the Benefits System has a different set of processing logic than other identified EPs.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

The Send Transaction File to Benefits System elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

2-15

Elementary Process Identification Examples

Part 4 - Examples

Example: Print a Check/Mark It Paid Print a check and, as a result, mark the account as paid. All data printed on User Requirements the check is already stored in the check file. The following diagram shows the data flow for this example.

Print check

Check ILF Check Number Check Amount Recipient Account Paid Indicator Check Date

2-16

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Mark the Account as Paid

Elementary Process Identification Examples

Determine whether marking the account as paid is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Marking the account as paid is part of the functional user requirements.

•

constitutes a complete transaction

No. Marking the account as paid is not a complete transaction, unless the check is also printed. These steps cannot be logically separated.

•

is self-contained and

No. Marking the account as paid without also printing a check is not a self-contained function. The account cannot be marked as paid independently from printing the check.

•

leaves the business of the application being counted in a consistent state

No. Marking the account as paid without printing the check does not leave the business in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, marking the account as paid must occur when printing the check.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Marking the account as paid does not meet all of the criteria. It is not an elementary process.

Mark the Account as Paid does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

2-17

Elementary Process Identification Examples

Print a Check

Determine whether printing a check without marking the account as paid is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-18

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Printing a check is part of the functional user requirements.

•

constitutes a complete transaction

No. Printing a check is not a complete transaction, unless the account is marked as paid. These steps cannot be logically separated.

•

is self-contained and

No. Printing a check is not self-contained until the subsequent step of marking the account as paid has been performed.

•

leaves the business of the application being counted in a consistent state

No. Printing a check without marking the account as paid does not leave the business in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the account must also be marked as paid.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Printing a check does not meet all of the criteria. It is not an elementary process.

Print a Check does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Print a Check and Mark the Account as Paid

Elementary Process Identification Examples

Determine whether printing the check and marking the account as paid is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Printing a check and marking the account as paid is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Printing a check and marking the account as paid is a complete transaction. These steps cannot be logically separated.

•

is self-contained and

Yes. Printing a check and marking the account as paid is self-contained. There are no prior or subsequent steps that need to be performed.

•

leaves the business of the application being counted in a consistent state

Yes. Printing a check and marking the account as paid leaves the business in a consistent state. The functional user requirement has been fully satisfied.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Printing a check and marking the account as paid meets all of the criteria. It is an elementary process.

Print a Check and Mark the Account as Paid meets the requirements for an Elementary Process. The user requirement is to print the check. Marking the field Account Paid Indicator is part of the printing process. Printing and marking together are the smallest unit of activity that is meaningful to the user. The entire process is meaningful to the user, constitutes a complete transaction, is self-contained and leaves the business of the application being counted in a consistent state.

January 2010

Function Point Counting Practices Manual

2-19

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

2-20

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for printing a check and marking it complete is different than that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for printing a check and marking it complete is different than that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for printing a check and marking it complete is different than that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

Marking the account paid is part of the processing logic of printing a check.

The Print a Check and Mark the Account as Paid elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Elementary Process Identification Examples

Example: View Job Assignments View a list of the job assignments within a date range. The user will be able User Requirements to enter the selection criteria. There is no requirement to store the selection criteria once the report has been generated. The following diagram shows the data flow for this example. Assignment Li st Cri teria Employee ID Print Start Date Cancel

End Date

January 2010

Function Point Counting Practices Manual

2-21

Elementary Process Identification Examples

Enter Selection Criteria

Determine whether entering the selection criteria (without viewing the job assignments) is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-22

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Entering the selection is part of the functional user requirements.

•

constitutes a complete transaction

No. Entering the selection criteria (without viewing the job assignments) is not a complete transaction. These steps cannot be logically separated.

•

is self-contained and

No. Entering the selection criteria (without viewing the job assignments) is not selfcontained. Viewing the job assignment list is a subsequent processing step necessary to complete the elementary process.

•

leaves the business of the application being counted in a consistent state

No. Entering the selection criteria (without viewing the job assignments) does not leave the business in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the job assignments list must be viewed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Entering the selection criteria (without viewing the job assignments) does not meet the criteria.

Enter Selection Criteria does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

View Job Assignments

Elementary Process Identification Examples

Determine whether viewing job assignments (without entering the selection criteria) is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Viewing job assignments is part of the functional user requirements.

•

constitutes a complete transaction

No. Viewing job assignments (without entering the selection criteria) cannot be performed without entering the selection criteria. These steps cannot be logically separated.

•

is self-contained and

No. Viewing job assignments (without entering the selection criteria) is not selfcontained. The job assignments cannot be viewed independently from the prior step of entering the selection criteria.

•

leaves the business of the application being counted in a consistent state

No. Viewing job assignments (without entering the selection criteria) does not leave the business in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the selection criteria must also be entered.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Viewing job assignments (without entering the selection criteria) does not meet the criteria.

View Job Assignments (without entering the selection criteria) does not meet the requirements for this elementary process.

Function Point Counting Practices Manual

2-23

Elementary Process Identification Examples

Enter Selection Criteria and View Job Assignments

Determine whether entering the selection criteria and viewing the job assignments is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Entering the selection criteria and viewing job assignments is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Entering the selection criteria and viewing job assignments is a complete transaction. These steps cannot be logically separated.

•

is self-contained and

Yes. Entering the selection criteria and viewing job assignments is a self-contained transaction. There are no prior or subsequent steps that need to be performed.

•

leaves the business of the application being counted in a consistent state

Yes. Entering the selection criteria and viewing job assignments leaves the business in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the selection criteria must be entered and the job assignments viewed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Entering the selection criteria and viewing job assignments meets all of the above criteria.

Enter Selection Criteria and View Job Assignments meets the criteria for an elementary process. Control information is the input side of an EO or EQ. The request specifying what and/or how data is to be retrieved or generated is part of the elementary process to provide the user data and is not an elementary process itself. Entering the selection criterion is not the smallest unit of activity that is meaningful to the user. It is not self-contained because it cannot be performed independently of producing the report. Entering the selection criteria and generating the report together comprise the smallest unit of activity that is meaningful to the user, constitutes a complete transaction, is self-contained and leaves the business of the application being counted in a consistent state.

2-24

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Determine Unique Elementary Processes

Elementary Process Identification Examples

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

January 2010

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for entering selection criteria and viewing assignments is different than that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for entering selection criteria and viewing assignments is different than that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for entering selection criteria and viewing assignments is different than that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

It is necessary to enter the selection criteria in order to view the job assignments.

The Enter Selection Criteria and View Job Assignments elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

2-25

Elementary Process Identification Examples

Part 4 - Examples

Example: Print Job Assignments/Save Criteria Print a job assignment list between a date range. The user will be able to User Requirements enter the selection criteria. There is a requirement to enable the user to save the selection criteria for later use. The following diagram shows the data flow for this example. Assignment Li st Cri teria Print

Employee ID

Save Start Date Cancel

End Date

Job Assignment List

Save Criteria

Report Criteria ILF Userid EmpId Start Date End Date Report ID ...

2-26

P rint Job Assignment List

Date

EmpId

1/13/1997 2/1/1997 2/12/1997

0103 0109 0106

Assignment xxxxxxxxxxx yyyyyyyyyyy zzzzzzzzz zzz

Job Assignment ILF EmpId Assignment Date Assignment

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Enter & Save Selection Criteria

Elementary Process Identification Examples

Determine whether saving the selection criteria (without printing a job assignment list) is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Saving the selection criteria is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Saving the selection criteria is a complete transaction. It is a logically separate function from printing a job assignment list.

•

is self-contained and

Yes. Saving the selection criteria is a selfcontained transaction. It can be performed independently from printing the job assignment list.

•

leaves the business of the application being counted in a consistent state

Yes. Saving the selection criteria leaves the business in a consistent state. The functional user requirement has been fully satisfied with nothing more to be done.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Saving the selection criteria meets all of the above criteria.

Enter & Save Selection Criteria meets the requirements for an elementary process.

Function Point Counting Practices Manual

2-27

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

2-28

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for saving selection criteria is different than that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for saving selection criteria is different than that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for saving selection criteria is different than that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

The Save Selection Criteria elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Print Job Assignments

Elementary Process Identification Examples

Determine whether printing a job assignment list, whether the selection criteria is saved or not, is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Printing a job assignment list is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Printing a job assignment list is a complete transaction. It is a logically separate function from saving the selection criteria.

•

is self-contained and

Yes. Printing a job assignment list is a selfcontained transaction. It can be performed independently of saving the criteria.

•

leaves the business of the application being counted in a consistent state

Yes. Printing a job assignment list leaves the business in a consistent state. The functional user requirement has been fully satisfied with nothing more to be done.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Printing a job assignment list meets all of the above criteria.

Print Job Assignments is an elementary process. The entering of selection criteria is meaningful to the user because the user can explicitly save the criteria. Either printing the report or saving the criteria can be performed independently, and both leave the business in a consistent state. Both processes, storing the selection criteria and generating the report, are meaningful to the user, constitute complete transactions, are self-contained and leave the business of the application in a consistent state. According to the Elementary Process Identification Rules, there are two elementary processes.

January 2010

Function Point Counting Practices Manual

2-29

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

2-30

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for printing a job assignment list is different than that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for printing a job assignment list is different than that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for printing a job assignment list is different than that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

The Print Job Assignments elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Elementary Process Identification Examples

Example: Employee/Interview Information When adding a new employee, in addition to the employee’s personal data User Requirements (i.e., Social Security Number, surname, address, etc.), the employee’s interview details must be entered. The interview information includes the interviewer’s name, the interview date, and the interviewer’s comments. The following diagram shows the data flow for this example. Create Employee Employee SSN

Create

Surname

Cancel

Address

Add Interview Details Interviewer Name

Add

Interview Date

Cancel

Interviewer Comments

Create Employee

Add Interview Details

Employee ILF SSN Surname Address ... Interviewer Name Interview Date Interviewer Comments

January 2010

Function Point Counting Practices Manual

2-31

Elementary Process Identification Examples

Entering the Employee’s Personal Data

Determine whether entering only the employee’s personal information is an Elementary Process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-32

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Entering the employee’s personal data is part of the functional user requirements.

•

constitutes a complete transaction

No. The complete transaction includes entering the employee’s personal data as well as the interview details. These steps cannot be logically separated.

•

is self-contained and

No. Adding the associated interview details is a subsequent step step necessary to complete the elementary process.

•

leaves the business of the application being counted in a consistent state

No. Entering the employee’s personal data without also entering interview details does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the interview details must also be entered.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Entering the employee’s personal data only does not meet all of the criteria.

Entering the Employee’s Personal Data (without entering the interview details) does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Entering Employee’s Interview Details

Elementary Process Identification Examples

Determine if entering only the employee’s interview details is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Entering employee’s interview details is part of the functional user requirements.

•

constitutes a complete transaction

No. The complete transaction includes entering the employee’s personal data as well as the interview details. These steps cannot be logically separated.

•

is self-contained and

No. Entering employee’s interview details only cannot be performed independently of entering interview details.

•

leaves the business of the application being counted in a consistent state

No. Entering employee’s interview details without also entering personal information does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, both the employee’s personal data and the interview details must be entered.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Entering employee’s interview details only does not meet all of the criteria.

Entering Employee’s Interview Details (without the employee’s personal data) does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

2-33

Elementary Process Identification Examples

Entering the Employee’s Personal Data and Interview Details

Determine whether entering the employee’s personal data along with the interview details is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Entering the employee’s personal data and interview details are both part of the functional user requirements.

•

constitutes a complete transaction

Yes. Entering the employee’s personal data and interview details together are a complete transaction. These steps cannot be logically separated.

•

is self-contained and

Yes. Entering the employee’s personal data and interview details together are a selfcontained function. There are no prior or subsequent steps that need to be performed.

•

leaves the business of the application being counted in a consistent state

Yes. Entering an employee’s personal data and interview details leaves the business of the application in a consistent state. To satisfy the functional user requirement, both steps must be performed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Entering the employee’s personal data and interview details meets all of the criteria.

Entering the Employee’s Personal Data and Interview Details meets the criteria for an elementary process. If two input processes are always sequential and dependent (step one and step two are mandatory), then there is one elementary process and one function. A new employee cannot be recorded until both the employee’s personnel data and the employee’s interview details are entered. Entering the personal data or the interview details alone would not be the smallest unit of activity that is meaningful to the user. Entering the Employee’s Personal Data and Interview Details together comprise the smallest unit of activity that is meaningful to the user, constitutes a complete transaction, is self-contained and leaves the business of the application being counted in a consistent state.

2-34

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Determine Unique Elementary Processes

Elementary Process Identification Examples

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

January 2010

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for Entering the Employee’s Personal Data and Interview Details is different from that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for Entering the Employee’s Personal Data and Interview Details is different from that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for Entering the Employee’s Personal Data and Interview Details is different from that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

A new employee cannot be recorded until both the employee’s personal data and the employee’s interview data are entered.

The Entering the Employee’s Personal Data and Interview Details elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

2-35

Elementary Process Identification Examples

Part 4 - Examples

Example: Employee/License Information When adding a new employee, the employee data is entered for Social User Requirements Security Number, name, address, and whether or not the employee has a driver’s license. If the employee does have a driver’s license, a secondary step must be completed to record the employee’s driver’s license number, classification(s), and expiration date. Note: Updating of existing employee information including license information is not included in this example. The following diagram shows the data flow for this example.

Create Employee Employee SSN

Create

Surname

Cancel Driver’s License

Address

Add License Information Driver’s License

Return

License Number Cancel Classification

Yes

Expiration Date

Driver’s License?

Create Employee

Add License Information

No

Employee ILF SSN Surname Address Driver’s License License Number Classification Expiration Date

2-36

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Entering the Employee’s Personal Data

Elementary Process Identification Examples

Determine whether entering only the employee’s personal information is an Elementary Process. The following table show the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Adding an employee is part of the functional user requirements.

•

constitutes a complete transaction

No. The complete transaction includes entering the employee’s personal data as well as the driver’s license (if it exists). These steps cannot be logically separated.

•

is self-contained and

No. Entering the driver’s license (if it exists) is a subsequent processing step necessary to complete the elementary process.

•

leaves the business of the application being counted in a consistent state

No. Entering the employee’s personal data without also entering the driver’s license (if it exists) does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the driver’s license must also be entered (if it exists).

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Entering the employee’s personal data only does not meet all of the criteria.

Entering the Employee’s Personal Data without entering the driver’s license (if it exists) does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

2-37

Elementary Process Identification Examples

Entering the Employee’s License Information

Determine whether entering the driver’s license information without the employee’s personal information is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-38

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Adding license information is part of the functional user requirements.

•

constitutes a complete transaction

No. The complete transaction includes entering the employee’s personal data as well as the driver’s license (if it exists). These steps cannot be logically separated.

•

is self-contained and

No. Entering personal information is a prior processing step necessary to complete the elementary process.

•

leaves the business of the application being counted in a consistent state

No. Adding only license information does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, both personal data and driver’s license (if it exists) must be entered.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Adding only license information does not meet all of the criteria.

Adding License Information (without entering the employee’s personal information) does not meet the requirements for an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Adding Employee and License Information

Elementary Process Identification Examples

Determine whether entering an employee’s personal information together with the associated license information is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Adding an employee and recording the employee license is part of the functional user requirements.

•

constitutes a complete transaction

Yes. The complete transaction includes entering the employee’s personal data as well as the driver’s license (if it exists). These steps cannot be logically separated.

•

is self-contained and

Yes. Adding an employee and recording the employee license is a self-contained function. There are no prior or subsequent steps that must be performed.

•

leaves the business of the application being counted in a consistent state

Yes. Entering an employee’s personal data and driver’s license (if it exists) leaves the business of the application in a consistent state. To satisfy the functional user requirement, both steps must be performed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Adding an employee and recording the employee license meets all of the criteria.

If two input processes are always sequential and dependent, but the second process is optional (but is mandatory if it applies), then there is one elementary process. Adding Employee and License Information is an Elementary Process. If an employee does not have a license, the step “Add License Information” is not relevant. If an employee does have a driver’s license, a secondary screen must be completed to complete the Elementary Process and leave the business of the application in a consistent state.

January 2010

Function Point Counting Practices Manual

2-39

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

2-40

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for Adding Employee and License Information is different from that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for Adding Employee and License Information is different from that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for Adding Employee and License Information is different from that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

If an employee has a driver’s license, a new employee cannot be recorded until both the employee’s personal data and the employee’s license data are entered.

The Entering the Employee’s Personal Data and Interview Details elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Elementary Process Identification Examples

Example: Batch Employee Data Feed A batch feed of new employee data from another application must be User Requirements accepted. The employee data must be validated and saved to the Employee file; an error report is produced containing any identified errors. The HR business office is notified via email with processing summary data. The following diagram shows the data flow for this example.

Empl Feed

HR Application Employee

Error Report

January 2010

Function Point Counting Practices Manual

Email Notification w/Summary Data

2-41

Elementary Process Identification Examples

Process an Employee Data Feed

Determine whether accepting an Employee Data Feed and processing the transactions without reporting errors and summary data is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-42

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Accepting an Employee Data Feed and processing the transactions is part of the functional user requirements.

•

constitutes a complete transaction

No. The complete transaction includes reporting the errors and summary data from the Employee Data Feed. These steps cannot be logically separated.

•

is self-contained and

No. Producing the Error Report and Email Notification are subsequent processing steps necessary to complete the elementary process.

•

leaves the business of the application being counted in a consistent state

No. Processing the Employee Data Feed without producing the Error Report and Email Notification does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the errors and summary data from processing the Employee Data Feed must be reported.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

All of the criteria have not been met.

Accepting the feed and processing the transactions without producing the error report or sending the summary email does not meet the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Produce an Error Report

Elementary Process Identification Examples

Determine whether producing an error report without processing the Employee Data Feed is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Producing the Error Report is part of the functional user requirements.

•

constitutes a complete transaction

No. Producing the Error Report is an integral part of the update process and the errors cannot be determined outside of that process. These steps cannot be logically separated.

•

is self-contained and

No. Producing the Error Report without processing the Employee Data Feed is not a self-contained function. The Error Report cannot be produced independently from processing and validating the Employee Data Feed.

•

leaves the business of the application being counted in a consistent state

No. Producing the Error Report without processing the Employee Data Feed does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the Error Report must be produced from processing and validating the Employee Data Feed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

All of the criteria have not been met.

Producing the Error Report without processing the Employee Data Feed does not meet the requirements of an elementary process.

Function Point Counting Practices Manual

2-43

Elementary Process Identification Examples

Produce an Email Notification

Determine whether producing an Email Notification without processing the Employee Data Feed is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-44

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Producing an Email Notification with summary data is part of the functional user requirements.

•

constitutes a complete transaction

No. Producing an Email Notification is an integral part of the update process and the processing statistics cannot be determined outside of that process. These steps cannot be logically separated.

•

is self-contained and

No. Producing an Email Notification without processing the Employee Data Feed is not a self-contained function. The processing statistics cannot be determined independently from processing the Employee Data Feed.

•

leaves the business of the application being counted in a consistent state

No. Producing the Email Notification without processing the Employee Data Feed does not leave the business of the application in a consistent state. To be in a consistent state, the functional user requirement must be satisfied with nothing more to be done. To satisfy the functional user requirement, the Email Notification must be produced from processing the Employee Data Feed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

All of the criteria have not been met.

Producing the Email Notification without processing the Employee Data Feed does not meet the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Process Employee Data Feed, Produce Error Report and Email Notification

Elementary Process Identification Examples

Determine whether accepting an employee data feed, processing transaction, producing an error report and sending a notification email is an elementary process. The following table shows the analysis.

Identify the Elementary Process 1.

2.

Conclusion

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Processing the Employee Data Feed, producing the Error Report and Email Notification are part of the functional user requirement.

•

constitutes a complete transaction

Yes. Processing the Employee Data Feed, producing the Error Report and Email Notification is a complete transaction. These steps cannot be logically separated.

•

is self-contained and

Yes. Processing the Employee Data Feed, producing the Error Report and Email Notification is a self-contained function.

•

leaves the business of the application being counted in a consistent state

Yes. Processing the Employee Data Feed, producing the Error Report and Email Notification leaves the business of the application in a consistent state. To satisfy the functional user requirement, all steps must be performed to process the Employee Data Feed.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

All of the criteria have been met.

Processing the Employee Data Feed including producing the Error Report and Email Notification together satisfy the functional user requirements. Accepting the Employee Data Feed, processing the transactions, producing the Error Report and Email Notification is one Elementary Process. If the feed is not accepted and the transactions are not processed, the steps “Produce Error report” and “Produce Email Notification” are not relevant. All processing steps must be performed to complete the elementary process and leave the business of the application in a consistent state.

January 2010

Function Point Counting Practices Manual

2-45

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

2-46

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

No. The set of DETs for Processing the Employee Data Feed is different from that of any other EP.

•

Require the same set of FTRs and

No. The set of FTRs for Processing the Employee Data Feed is different from that of any other EP.

•

Require the same set of processing logic to complete the elementary process

No. The set of processing logic for Processing the Employee Data Feed is different from that of any other EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

As was previously discussesd, subdividing an elementary process is not appropriate.

The Processing the Employee Data Feed elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Elementary Process Identification Examples

Example: Assign Employee to Job Assign an employee to a job. Add job assignment information by entering User Requirements the following information for each job and employee: •

Effective Date

•

Salary

•

Performance Rating

To aid in making assignments, the user has requested a list of employee assignments by employee and/or a list of jobs with employees. Employee Assignments List Window

This window shows the list of employees and the jobs assignments for each employee. Human Resources System Employee

Jobs

Assignments

Locations

Reports

Security

Help

Employee Assignments Last Name

First Name

Keller Keller Latta Manship Manship Schmidt -Taylor Smith Smith Waldenson White White

Caroline Nicky Nicky Mark Mark Kathleen David Loretta Pat William William

View

Job RD21379305 RD21379305 RD90379305 RD14379305 RD15379305 RD14379305 RD16379305 RD16379305 RD90379305 RD21379305 RD90379305

A A J J E M W W

New

Edit

Delete

View

Initiates display of data on AE-4 Job Assignment Data

New

Returns blank form on AE- 3 Job Assignment Setup (default data filled in)

Edit

Initiates display of data on AE- 5 Job Assignment Edit

Delete

January 2010

MI

Removes job assignment entry (after confirmation)

Function Point Counting Practices Manual

2-47

Elementary Process Identification Examples

Job Assignment Setup Window

Part 4 - Examples

The next window shows the assignment of an employee to a job (by employee). Human Resources System Employee Jobs Assignments Locations

Reports

Security

Help

Employee Assignments Job Assignment Setup First Name

MI

Last Name J

Mark

Manship

345-67-8901

Social Security Number Main Plant

Loca tion

Bargaining Unit

UFPCA

Job Number Date OK Salary Cancel

Performance Rating

AE-3 Job Assignment Setup Saves new job assignment, returns to AE -1 Employee Assignment List

OK

Ignores data entered, returns to AE -1 Employee Assignment List

Cancel

If the user does not enter data correctly, an error message is shown. Job Assignments List Window

The next window shows a list of jobs and the employee assigned. Human Resources System Employee

Jobs

Assignments

Locations

Reports

Security

Help

Job Assignments Job ID

Last Name

First Name

RD14379305 RD14379305 RD15379305 RD16379305 RD16379305 RD21379305 RD21379305 RD21379305 RD90379305 RD90379305 RD90379305

Manship Schmidt-Taylor Manship Smith Smith Keller Latta White Latta Waldenson White

Mark Kathleen Mark David Loretta Caroline Nicky William Nicky Pat William

View

New

MI J J E M A W A W

Edit

Delete

AJ-1 Job Assignment List View

Initiates display of data on AJ-4 Employee Assignment Data

New

Returns blank form on AJ-3 Employee Assignment Setup (default data filled in)

Edit

Initiates display of data on AJ-5 Employee Assignment Edit

Delete

2-48

Removes employee job assignment entry (after confirmation)

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Employee Assignment Setup Window

Elementary Process Identification Examples

The next window shows the assignment of an employee to a job (by job). Human Resources System Employee Jobs Assignments

Locations

Reports

Security

Help

Job Assignments Employee Assignment Setup RD14379305

May Issue - Print Text

Last Name First Name Middle Initial Social Security Location

-

Bargaining Unit

Date

OK

Salary

Cancel

Performance Rating AJ-3 Employee Assignment Setup OK

Saves new employee assignment

Cancel

Ignores data entered, returns to AJ-1 Job Assignment List

If the user does not enter data correctly, an error message is shown.

January 2010

Function Point Counting Practices Manual

2-49

Elementary Process Identification Examples

Employee Assignments List

Determine whether Listing Employee Assignments is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-50

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Listing Employee Assignments is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Listing Employee Assignments is a complete transaction. This is a logically independent function.

•

is self-contained and

Yes. Listing Employee Assignments is a self-contained function. Listing Employee Assignments is performed independently from assigning an employee to a job.

•

leaves the business of the application being counted in a consistent state

Yes. Listing Employee Assignments leaves the business of the application in a consistent state. The functional user requirement has been fully satisfied with nothing more to be done.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Listing Employee Assignments meets all of the criteria.

Listing Employee Assignments meets the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Assign Employee to Job (by Employee)

Elementary Process Identification Examples

Determine whether Assigning Employee to Job (by Employee) is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Assigning Employee to Job (by Employee) is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Assigning Employee to Job (by Employee) is a complete transaction. This is a logically independent function.

•

is self-contained and

Yes. Assigning Employee to Job (by Employee) is a self-contained function. Assigning Employee to Job (by Employee) is performed independently from Listing Employee Assignments.

•

leaves the business of the application being counted in a consistent state

Yes. Assigning Employee to Job (by Employee) leaves the business of the application in a consistent state. The functional user requirement has been fully satisfied with nothing more to be done.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Assigning Employee to Job (by Employee) meets all of the criteria.

Assigning Employee to Job (by Employee) meets the requirements of an elementary process.

Function Point Counting Practices Manual

2-51

Elementary Process Identification Examples

Job Assignments List

Determine whether Listing Job Assignments is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

2-52

Part 4 - Examples

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Listing Job Assignments is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Listing Job Assignments is a complete transaction. This is a logically independent function.

•

is self-contained and

Yes. Listing Job Assignments is a selfcontained function. Listing Job Assignments is performed independently from assigning an employee to a job.

•

leaves the business of the application being counted in a consistent state

Yes. Listing Job Assignments leaves the business of the application in a consistent state. The functional user requirement has been fully satisfied with nothing more to be done.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Listing Job Assignments meets all of the criteria.

Listing Job Assignments meets the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Assign Employee to Job (by Job)

Elementary Process Identification Examples

Determine whether Assigning Employee to Job (by Job) is an elementary process. The following table shows the analysis. Identify the Elementary Process 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. Assigning Employee to Job (by Job) is part of the functional user requirements.

•

constitutes a complete transaction

Yes. Assigning Employee to Job (by Job) is a complete transaction. This is a logically independent function.

•

is self-contained and

Yes. Assigning Employee to Job (by Job) is a self-contained function. Assigning Employee to Job (by Job) is performed independently from Listing Job Assignments.

•

leaves the business of the application being counted in a consistent state

Yes. Assigning Employee to Job (by Job) leaves the business of the application in a consistent state.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

Assigning Employee to Job (by Job) meets all of the criteria. The functional user requirement has been fully satisfied with nothing more to be done.

Assigning an Assigning Employee to Job (by Job) meets the requirements of an elementary process.

Function Point Counting Practices Manual

2-53

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the Listing Employee Assignments and Listing Job Assignments elementary processes are unique. Determine Unique Elementary Processes 1.

2.

Conclusion

2-54

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

Yes. The set of DETs for Listing Employee Assignments is the same as the set of DETs for Listing Job Assignments.

•

Require the same set of FTRs and

Yes. The set of FTRs for Listing Employee Assignments is the same as the set of FTRs for Listing Job Assignments.

•

Require the same set of processing logic to complete the elementary process

Yes. The set of processing logic for Listing Employee Assignments is the same as the set of processing logic Listing Job Assignments. The only difference between them is the arrangement of the fields and the sort sequence of the rows. As stated in the Forms of Processing Logic, differences in the arrangement or sorting does not constitute a unique EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

Listing Employee Assignments and/or Listing Job Assignments is a single unique elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Determine Unique Elementary Processes

Elementary Process Identification Examples

The following table shows the analysis to determine whether the Assigning Employee to Job (by Employee) and Assigning Employee to Job (by Job) elementary processes are unique. Determine Unique Elementary Processes 1.

2.

Conclusion

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

Yes. The set of DETs for Assigning Employee to Job (by Employee) is the same as the set of DETs for Assigning Employee to Job (by Job).

•

Require the same set of FTRs and

Yes. The set of FTRs for Assigning Employee to Job (by Employee) is the same as the set of FTRs for Assigning Employee to Job (by Job).

•

Require the same set of processing logic to complete the elementary process

Yes. The set of processing logic for Assigning Employee to Job (by Employee) is the same as the set of processing logic Assigning Employee to Job (by Job). The only difference between them is the arrangement of the attributes on the screen. As stated in the Forms of Processing Logic, differences in the arrangement of attributes does not constitute a unique EP.

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

Two unique elementary process are identified: •

Listing Assignments (by Employee) and/or Listing Assignments (by Job)

•

Assigning Employee to Job (by Employee) and/or Assigning Employee to Job (by Job)

When two similar elementary processes are compared and it is determined that they contain the same set of DETs, FTRs and Processing Logic, they are identified as a single unique elementary process.

January 2010

Function Point Counting Practices Manual

2-55

Elementary Process Identification Examples

Part 4 - Examples

Example: Similar Elementary Processes The user of employee information requires two reports that are very similar. User Requirements One report will include employee emails and will be distributed to the remote staff that is required to communicate via email instead of phone. See report examples for details of each report. All of the data on the reports come from the same logical file except for the email address that comes from a different logical file that is maintained within the same application. Employee Listing (With Email Address)

Employee Listing

Employee Listing (Without Email Address)

Employee Listing

2-56

ID # 894253 999524 125896

ID # 894253 999524 125896

Name Jay Smith Mel Dunn Val Jones

Name Jay Smith Mel Dunn Val Jones

Home Phone 888-555-1212 777-258-489 555-678-6892

Home Phone 888-555-1212 777-258-489 555-678-6892

Work Phone 999-666-0202 999-125-3589 999-258-4789

Location Plant A Plant B Plant C

Work Phone 999-666-0202 999-125-3589 999-258-4789

Location Plant A Plant B Plant C

Function Point Counting Practices Manual

Email Address [email protected] [email protected] [email protected]

January 2010

Part 4 - Examples

Employee Listing (Without Email Address)

Elementary Process Identification Examples

Determine whether the Employee Listing (Without Email Address) is an elementary process. The following table shows the analysis. Elementary Process Counting Rules 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. The Employee Listing (Without Email Address) is a functional user requirement.

•

constitutes a complete transaction

Yes. The Employee Listing (Without Email Address) is a complete transaction satisfying a group of users.

•

is self-contained and

Yes. The Employee Listing (Without Email Address) is meaningful by itself.

•

leaves the business of the application being counted in a consistent state

Yes. The business is left in a consistent state when the Employee Listing (Without Email Address) is created.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

The Employee Listing (Without Email Address) meets all of the above criteria.

The Employee Listing (Without Email Address) meets the requirements of an elementary process.

Function Point Counting Practices Manual

2-57

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

2-58

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

Yes. Employee Listing (Without Email Address) requires a different set of DETs than Employee Listing (With Email Address).

•

Require the same set of FTRs and

Yes. Employee Listing (Without Email Address) requires a different set of FTRs than Employee Listing (With Email Address).

•

Require the same set of processing logic to complete the elementary process

Yes. Employee Listing (Without Email Address) has a different set of processing logic than Employee Listing (With Email Address).

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

The Employee Listing (Without Email Address) elementary process is unique from all other identified elementary processes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Employee Listing (With Email Address)

Elementary Process Identification Examples

Determine whether the Employee Listing (With Email Address) is an elementary process. The following table shows the analysis. Elementary Process Counting Rules 1.

2.

Conclusion

January 2010

Does the Rule Apply?

Compose and/or decompose the Functional User Requirements into the smallest unit of activity, which satisfies all of the following: •

is meaningful to the user

Yes. The Employee Listing (With Email Address) is a functional user requirement.

•

constitutes a complete transaction

Yes. The Employee Listing (With Email Address) is a complete transaction satisfying a group of users.

•

is self-contained and

Yes. The Employee Listing (With Email Address) is meaningful by itself.

•

leaves the business of the application being counted in a consistent state

Yes. The business is left in a consistent state when the Employee Listing (With Email Address) is created.

Identify an elementary process for each unit of activity identified that meets all of the above criteria

The Employee Listing (With Email Address) meets all of the above criteria.

The Employee Listing (With Email Address) meets the requirements of an elementary process.

Function Point Counting Practices Manual

2-59

Elementary Process Identification Examples

Determine Unique Elementary Processes

The following table shows the analysis to determine whether the elementary process is unique.

Determine Unique Elementary Processes 1.

2.

Conclusion

Part 4 - Examples

Does the Rule Apply?

When compared to an Elementary Process (EP) already identified, count two similar EPs as the same Elementary Process if they: •

Require the same set of DETs and

Yes. Employee Listing (With Email Address) requires a different set of DETs than Employee Listing (Without Email Address).

•

Require the same set of FTRs and

Yes. Employee Listing (With Email Address) requires a different set of FTRs than Employee Listing (Without Email Address).

•

Require the same set of processing logic to complete the elementary process

Yes. Employee Listing (With Email Address) has a different set of processing logic than Employee Listing (Without Email Address).

Do not split an elementary process with multiple forms of processing logic into multiple elementary processes

There is nothing to split.

The Employee Listing (With Email Address) elementary process is unique from all other identified elementary processes. Two processes are determined to meet the criteria of an elementary process, then compared to each other to determine if they contain different DETs, FTRs or Processing Logic. When the two elementary processes are compared and it is determined that they contain different DETs, FTRs or Processing Logic, they are identified as separate elementary processes if they are specified as distinct functional user requirements by the user. Two unique elementary process are identified:

2-60

•

Listing Employees (Without Email Address) and

•

Listing Employees (With Email Address)

Function Point Counting Practices Manual

January 2010

EI Counting Examples Introduction

This section uses a Human Resources (HR) application to illustrate procedures to count external inputs. In addition to this section, examples are in the Case Studies.

Contents

This section includes the following examples: Topic

January 2010

Page

Summary Descriptions of EI Counting Examples

2-62

Example: Report Control Information

2-63

Example: Screen Input

2-67

Example: Batch with Multiple EIs and Duplicate EIs

2-70

Example: Correcting Suspended Transactions

2-73

Example: EI with Multiple File Types Referenced

2-76

Example: Data Conversion

2-80

Example: Referencing Data from Another Application

2-83

Example: EI with Screen Output - 1

2-85

Example: EI with Screen Output - 2

2-88

Example: EI with Attributes Retrieved from an EIF

2-91

Example: EI Delete

2-97

Example: Add Window Security

2-100

Function Point Counting Practices Manual

2-61

EI Counting Examples

Part 4 - Examples

Summary Descriptions of EI Counting Examples The examples for external inputs are listed and described in the following table.

2-62

Example

Summary Description

Page

Report Control Information

This example looks at control information used for reporting.

2-63

Screen Input

This example illustrates counting an online add transaction via a screen.

2-67

Batch with Multiple EIs and Duplicate EIs

This example shows counting a transaction file with multiple types or formatted record types.

2-70

Correcting Suspended Transactions

This example illustrates counting making corrections to jobs suspended to a file during batch processing of adding or changing jobs.

2-73

EI with Multiple File Types Referenced

This example illustrates using a data flow diagram to count an external input that references multiple files.

2-76

Data Conversion

This example illustrates counting the process of converting a group of data to a new format with additional data elements.

2-80

Referencing Data from Another Application

This example looks at why an external interface file (discussed in Part 2,Chapter 6) is not counted as an external input.

2-83

EI with Screen Output –1

This example illustrates an EI with a calculated field that is displayed.

2-85

EI with Screen Output –2

This example illustrates an EI with a calculated field and embedded EQs.

2-88

EI with Attributes Retrieved from an EIF

This example illustrates an EI with attributes retrieved from an EIF that do not cross the boundary.

2-91

EI Delete

This example illustrates counting DETs for a delete transaction.

2-97

Add Window Security

This example illustrates counting functionality to maintain application security.

2-100

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: Report Control Information The user requires the ability to control how and where assignment reports are User Requirements printed. The following list shows the specific user requirements for generating the report: 1. Control the following aspects of report processing: •

Sort sequence

•

Printer port

•

Output format (i.e., microfiche and/or paper)

2. Save the job assignment reporting controls. 3. Make and save changes. 4. Send a message to confirm that the controls for the assignment reports have been added or changed, and that the report is being generated. Note: This example shows only the requirement to add the group of assignment report control information. The Case Studies illustrate counting the entire user requirement.

Example Window

The following Job Assignments Report window is used to Establish Controls for Reporting Job Assignments. Human Resources System Employee

Jobs

Assignments

Locations

Help

Job Asssignments Report Sort 3

Job ID

2

Employee Number

1

Employee

Ident ify with 1, 2 & 3 Print er Port ( ) LPT ( ) LPT OK

( ) LPT

Cancel G enerate Microf iche Copy

Restore

Generate Paper Copy

JR-1 Job Assignments Report OK

January 2010

Processes report

Cancel

Returns to pull down m enu

Restore

Restores previous value s

Function Point Counting Practices Manual

2-63

EI Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes.

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. The data entering the boundary will eventually be used as control data. It is business data stored on the Report Control ILF.

•

altering the behavior of the application

No.

It includes processing logic to accept data or control information that enters the boundary of the application

Yes. Report Control information enters the boundary.

Conclusion

Establish Controls for Reporting Job Assignments is one EI.

Step 4

Count File Types Referenced (FTRs)

2-64

FTR Counting Rule

Does the Rule Apply?

1.

The Report Control ILF is maintained and read. It is counted only once.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

January 2010

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Sort Sequence, Printer Port, Output Format.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

User Message.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

OK button.

4.

Do not count the following items as DETs: •

literals such as report titles, screen or panel identifiers, column headings and attribute titles

None of the screen literals are counted.

•

application generated stamps such as date and time attributes

There are no items of this type.

•

paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’

There are no items of this type.

•

navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents

There are no items of this type.

•

attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary

There are no items of this type.

•

attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary

There are no items of this type.

Function Point Counting Practices Manual

2-65

EI Counting Examples

Step 6

Part 4 - Examples

Determine Functional Complexity 1 FTR and 5 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EI

2-66

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: Screen Input The user requires the ability to: User Requirements • Add job information online

Example Screen

•

Generate an error message and highlight incorrect fields so that the error may be corrected online

•

Save job information added

The following Job Data screen is used to Add a New Job.

Action:_

7=Prior

8=Following

9=Save Job Data

Job number:

RD15379305

Job name:

May Issue - Print Covers

Pay grade:

JRNY05A

Line No Job Description 01 Print Covers 4-Up, Lacquer Finish. ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ F1=Help Enter:

F7=Scroll up

F8=Scroll down

returns to calling screen.

Action 7: shows prior job data, if present.

F12=Cancel F1:

shows screen or field level help.

F7:

scrolls up 10 job description lines.

Action 8: shows following job data, if present.

F8:

scrolls down 10 job description lines.

Action 9: saves entered job data.

F12:

returns to calling screen.

January 2010

Function Point Counting Practices Manual

2-67

EI Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Conclusion

Yes.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. The Job ILF is maintained.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Yes. Job information enters the boundary in order to maintain the Job ILF.

Add a New Job is one EI. Refer to the Case Studies to see how the change and delete requirements and associated screens are counted.

Step 4

2-68

Count File Types Referenced (FTRs) FTR Counting Rule

Does the Rule Apply?

1.

The Job ILF is maintained and read, but it is counted only once.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Job Number, Job Name, Job Pay Grade, Job Description (Repeated). Job Description Line Number exists for technical reasons only and should not be counted as a DET.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

Error Messages.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Add Action key.

4.

Do not count the following items as DETs: •

literals

Literals such as “Job number” are not counted.

•

application generated stamps

There are no items of this type.

•

paging variables

There are no items of this type.

•

navigation

F7 and F8.

•

attributes generated without exiting the boundary and

There are no items of this type.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are no items of this type.

Determine Functional Complexity 1 FTR and 6 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EI

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-69

EI Counting Examples

Part 4 - Examples

Example: Batch with Multiple EIs and Duplicate EIs The user requires the ability to: User Requirements • Add job information in batch mode •

Change job information in batch mode

Note: The focus of this example is adding a job in batch mode. The previous example looked at the online mode. The Case Studies illustrate counting all user requirements for adding jobs in both online and batch modes. Construction It was decided that during the batch process, any jobs not successfully Requirements updated would error into a suspense file, which will be separately maintained. (See next example) Record Layout

The following diagram shows the record layout for this example.

123456789101234567890123456789012345678901234567890123456789012345678901234567890 1 2 3 4 5 6 7 8 9 0

ADD⏐01⏐SRENG⏐SENIOR ENGINEER INFORMATION SYSTEMS ADD⏐02⏐SRENG⏐01⏐STARTS AT PAY GRADE 05 ⏐ ADD⏐02⏐SRENG⏐02⏐OTHER PAY GRADES:06 AND 07 ⏐ CHG⏐01⏐STENG⏐ CHG⏐02⏐STENG⏐02⏐OTHER PAY GRADES:05 AND 06 ⏐

Record Descriptions

⏐04⏐

The following table includes descriptions for each record type.

Record

Position

Description

01

1-3

Transaction type

4-5

Record type

6-10

Job number

11-45

Job name

46-47

Job pay grade

1-3

Transaction type

4-5

Record type

6-10

Job number

11-12

Description line number

13-41

Description line

02

2-70

⏐05⏐

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Where Record Types are:

Step 1

01

Add record for a new job

02

Add record for descriptions of a new job

Identify the Elementary Process – Transaction Type 01 Does the Transactional Function meet the requirements of an Elementary Process?

Step 1

Identify the Elementary Process – Transaction Type 02 Does the Transactional Function meet the requirements of an Elementary Process?

Step 1

Yes. The Add a Job Batch function (Transaction Type 1+2) is similar to the Add a Job Online function in the previous example. The Add a Job Batch function maintains an additional ILF (Suspended Job) that the online function does not.

Classify each Elementary Process – Transaction Type 1 + 2 EI Counting Rules 1.

2.

January 2010

Yes. Job and description are meaningful to the user.

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

No. A description cannot exist without the job it is describing. The data would be inconsistent.

Identify the Elementary Process – Transaction Type 1 + 2 Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

No. A job without a description is not meaningful to the user.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Add Job has the primary intent to maintain the Job ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Yes. Add Job includes processing logic to accept Job information.

Function Point Counting Practices Manual

2-71

EI Counting Examples

Part 4 - Examples

Conclusion

Add a Job (Transaction Type 1 + 2) is one EI.

Step 4

Count File Types Referenced (FTRs)

Step 5

Step 6

FTR Counting Rule

Does the Rule Apply?

1.

The Job ILF is maintained and read, but it is counted only once. The Suspended Job ILF is maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Job Number, Job Name, Job Pay Grade, Job Description (Line Repeated).

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

Not Applicable. Errors are recorded in a Suspense File.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Transaction Type.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 2 FTR and 5 DETs

Step 7

Complexity is Average

Determine Functional Size Functional Size of 1 Average EI

2-72

Transaction Type and Job Description Line Number exist for technical reasons and are not counted as a DET.

4 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: Correcting Suspended Transactions It was decided that during the batch process that any jobs not successfully User Requirements updated would be saved to a suspense file. The user requires a screen to access and edit the transactions that are incorrect. Note: The focus of this example is only the requirement to correct suspended transactions. The Case Studies illustrate counting the entire user requirement. Data Flow Diagram

The following diagram shows the data flow for this example. 2.7 View Suspended Job

suspended job information

2.7 Update Suspended Job transaction type, job name, job#, pay grade, description

transaction type, job name, job#, pay grade, description

job suspense information

2.7 Delete Suspended Job

job suspense information

JOB SUSPENSE

transaction type, job# 2.2.2 PAY GRADE

Add Pay Grade pay grade info pay grade, pay grade descr

pay grade info

2.1.2

2.7 User

List Pay Grades

Add Job Batch

transaction type, job name, job#, pay grade, description invalid job information

valid job information

JOB SUSPENSE

Job List (w ithout totals): job name, job # 2.2.3

JOB job information valid job information

invalid job information

List Jobs (without totals ) Job List (with totals ): job name, job #, pay grade, descr, total jobs

2.7

2.5

Update Job Batch transaction type, job name, job#, pay grade, description

User

pay grade list

job information

List Jobs (w ith totals)

Legend:

January 2010

User or Application

Process

Data Stored

Flow of Data

Function Point Counting Practices Manual

2-73

EI Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes.

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Correcting Suspended Job Transaction has the primary intent to maintain the Suspended Job ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Yes. Add Job includes processing logic to accept Job information.

Conclusion

Correcting Suspended Job Transaction is one EI.

Step 4

Count File Types Referenced (FTRs)

2-74

FTR Counting Rule

Does the Rule Apply?

1.

The Suspended Job ILF is maintained and referenced, but it is counted only once.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Transaction Type, Job Number, Job Name, Job Pay Grade, Job Description Line (Repeated).

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are no messages.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Enter key.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 6 DETs

Step 7

Complexity is Low

Determine Functional Size Functional Size of 1 Low EI

January 2010

The Record Type and Job Description Line Number exist for technical reasons and are, therefore, not counted. All other fields are user recognizable.

3 FP

Function Point Counting Practices Manual

2-75

EI Counting Examples

Part 4 - Examples

Example: EI with Multiple File Types Referenced The user requires the ability to Add Job Assignments. User Requirements Note: The focus of this example is only the requirement to add job assignments. The Case Studies illustrate counting the entire user requirement. Example Window

The following diagram shows an example of the window to add job assignments.

Human Resources System Employee

Jobs

Assignments

Locations

Reports

Security

Help

Employee Assignments Job Assignment Setup First Name

MI

Mark

J

Social Security Number

Manship

345-67-8901

Location Main Plant Job Number

Last Name

Bargaining Unit RD15379305

UFPCA

May Issue – Print Covers

Date OK Salary Performance Rating

Cancel

AE-3 Job Assignment Setup OK Cancel

2-76

Saves new job assignment, returns to AE-1 Employee Assignment List Ignores data entered, returns to AE-1 Employee Assignment List

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Data Flow Diagram

The following diagram shows the data flow for the job assignment process.

3.8 SCR HELP

Process Screen Level Help

screen id, screen name, description

screen id, screen name, description 3.1 name, ssn, location, bargain unit, job#, date, salary, perf rating, job name (display only )

error and confirmation messages

Assign Employee to Job

job assignment info

ssn JOB job#, job name

EMPLOYEE / DEPENDENT

job#, job name JOB ASSGNMT job assignment info

3.2

ssn

Transfer Employee

name, ssn, location, bargain unit, job#, date, salary, perf rating, job name (display only )

error and confirmation messages

3.3

ssn, job# User

error and confirmation messages User

Delete Job Assignment

effective date, status inactive

JOB ASSGNMT EMPLOYEE / DEPENDENT

name, location, bargain unit ssn, job#

job assignment info

JOB

job name

3.4 Inquire Job Assignment name, ssn, location, bargain unit, job#, job name, salary, effectiv e date, perf rating

Legend:

January 2010

User or Application

Process

Data Stored

Flow of Data

Function Point Counting Practices Manual

2-77

EI Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes.

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Add Job Assignments has the primary intent to maintain the Job Assignment ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Conclusion

Add Job Assignments is one EI.

Step 4

Count File Types Referenced (FTRs)

Yes. Add Job Assignment includes processing logic to accept Job Assignment information.

FTR Counting Rule

Does the Rule Apply?

1.

The Employee ILF is read to ensure the employee exists.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

The Job ILF is read to ensure the job exists. The Job Assignment ILF is maintained and read, but it is only counted once.

2-78

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Employee Name, Social Security Number, Location, Bargaining Unit, Job Number, Job Name, Effective Date, Salary, Performance Rating.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

Error Messages.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

OK button.

4.

Do not count the following items as DETs: •

literals

Literals such as “Job number” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 3 FTRs and 11 DETs

Step 7

Complexity is High

Determine Functional Size Functional Size of 1 High EI

January 2010

The screen depicts the Employee Name field as three physical fields, although the data flow diagram depicts it as a single element. Based upon review of the application functionality, the Employee Name is always used in its entirety. There are no screens or reports where a single piece of the name is used without the others. It is counted as a single DET.

6 FP

Function Point Counting Practices Manual

2-79

EI Counting Examples

Part 4 - Examples

Example: Data Conversion The user has purchased a new HR application package. The user requires User Requirements the ability to Convert Employee Information by migrating existing employee information (Name, Social Security Number, Number of dependents, Type code, Supervisory level, Standard hourly rate, Collective bargaining unit number, and Location name) to the new application. The old system did not let the user maintain employee dependent's information. The dependent's information can be created after existing employees are migrated to the new application. Note: Part 3 , Chapter 5 (Data Conversion Activity) explains how data conversion is measured. Data Diagrams

The following diagram shows the data for the old and new applications. Old HR Application EMPLOYEE

New HR Application EMPLOYEE

SALARIED_EMPL

SALARIED_EMPL

HOURLY_EMPL

HOURLY_EMPL

DEPENDENT

Legend: Entity Type Attributive Entity Type Entity Subtype Mandatory One-to-Many Relationship Optional One-to-Many Relationship

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

2-80

Yes.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 2

EI Counting Examples

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. The Employee ILF is maintained.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Yes. Data from the employee file of the old HR application crosses the boundary.

Conclusion

Convert Employee Information is one EI.

Step 4

Count File Types Referenced (FTRs)

January 2010

FTR Counting Rule

Does the Rule Apply?

1.

The Employee ILF is maintained and read, but it is counted only once.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-81

EI Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Name, Social Security Number, Number of Dependents, Type Code, Supervisory Level, Standard Hourly Rate, Collective Bargaining Unit Number, Location Name.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 8 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EI

2-82

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: Referencing Data from Another Application The user requires the Human Resources application to provide the following User Requirements capabilities: •

All hourly employees must be paid in U.S. Dollars.

•

When adding or changing employee information, the Human Resources application must access the Currency application to retrieve a currency conversion rate. After retrieving the currency conversion rate, the HR application converts the employee's local standard hourly rate to a U.S. hourly rate using the following calculation: Standard Hourly Rate = U.S. Dollar Hourly Rate Currency Conv. Rt.

Data Diagram

The following diagram shows the relationship for this example.

HR Application

Currency Application

EMPLOYEE CONVERSION RATE

SALARIED_EMPL HOURLY_EMPL

DEPENDENT

Legend: Entity Type Attributive Entity Type Entity Subtype Mandatory One-to-Many Relationship Optional One-to-Many Relationship

January 2010

Function Point Counting Practices Manual

2-83

EI Counting Examples

Currency Conversion Information

Part 4 - Examples

The currency conversion information includes CURRENCY • Conversion_Rate_To_Base_Currency • Currency

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Conclusion

2-84

No. Referencing the data is only meaningful when associated with adding an employee.

There is not an EI for the retrieval of currency conversion information. Refer to the EIF counting examples in the Data Function Counting Examples to see why currency conversion information may be counted as an EIF when adding or changing employee information. Adding and Changing Employee information are counted as EIs.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: EI with Screen Output - 1 The user requires the ability to Enter a Sales Transaction for a customer. The User Requirements cost of each item is to be shown, and the transaction total must be displayed for review before the information is saved. If any errors occur, appropriate error messages are displayed. Example Screen

The following sales transaction screen is a simplification to illustrate how output fields are counted. The user enters the customer name and transaction date. As each item and quantity required is entered, the system calculates and displays the costs as shown.

Sales Transaction Customer Name: __________________________________________ Transaction Date: ________

Item __________________________ __________________________ __________________________ __________________________ __________________________ __________________________

Qty _____ _____ _____ _____ _____ _____

Item Cost $____.__ $____.__ $____.__ $____.__ $____.__ $____.__

Item Total Cost $____.__ $____.__ $____.__ $____.__ $____.__ $____.__

Sub Total $____.__ Sales Tax $____.__ Total $____.__ F1=Save

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

January 2010

Yes.

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

2-85

EI Counting Examples

Step 3

Part 4 - Examples

Classify each Elementary Process EI Counting Rules 1.

2.

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Entering a Sales Transaction has the primary intent to maintain the Sales Transaction ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Conclusion

Enter a Sales Transaction is one EI.

Step 4

Count File Types Referenced (FTRs)

2-86

Does the Rule Apply?

Yes. Entering a Sales Transaction includes processing logic to accept sales information.

FTR Counting Rule

Does the Rule Apply?

1.

The Sales Transaction ILF is read and maintained, but is counted only once.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

The following input DETs are counted: Customer Name Transaction Date Item (repeated) Quantity (repeated) The following output DETs are counted: Item Cost (repeated) Item Total Cost (repeated) Transaction Sub Total Sales Tax Transaction Total

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

Error Messages.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

F1 key.

4.

Do not count the following items as DETs: •

literals

Literals such as “Item” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 11 DETs

Step 7

Determine Functional Size Functional Size of 1 Average EI

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-87

EI Counting Examples

Part 4 - Examples

Example: EI with Screen Output - 2 The user requires the ability to Assign a Job to an employee. In order to User Requirements select an employee and job, the user requires the ability to reference the employee and job files using 2 drop down lists. The employee list is required to show the employee number and name. The jobs list is required to show the job number and its description. The number of employees assigned to the job is to be displayed after the record is saved. In the event of an error, an appropriate message is displayed.

Example Screen

The following Job Assignment screen is a simplification to illustrate how output fields are counted. The user selects the employee from a drop down list showing the employee name and employee number. On selection, the system needs the employee number for the assignment. The user selects the job from a dropdown list showing the job number and its description. The system needs the job number for the assignment. When the assignment is saved, the system determines the number of employees and displays it to the user.

Human Resources System Employees

Jobs

Assignments

Locations

Help

Job Assignment

Employee Number Job Number

1290 0100

Assignment Date

12/12/1998

1290 James, R.W 0100 Apply Lacquer

Save Total Number of Employees assigned to this Job

3

The list boxes for Jobs and Employees are EQs and are not analyzed in this example.

2-88

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EI Counting Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Assign a Job has the primary intent to maintain the Job Assignment ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Conclusion

Assign a Job is one EI.

Step 4

Count File Types Referenced (FTRs)

January 2010

Yes.

Yes. Assign a Job includes processing logic to accept Job Assignment information.

FTR Counting Rule

Does the Rule Apply?

1.

The Job Assignment ILF is maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

The Employee and Job ILFs are not counted as FTRs, as they are part of separate EQs.

Function Point Counting Practices Manual

2-89

EI Counting Examples

Step 5

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

The following input DETs are counted: Employee Number Job Number Assignment Date

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

The following output DETs are counted: Employees Assigned To Job The Employee Name and Job Name DETs in the dropdowns are not counted as DETs, as they are part of separate EQs.

Step 6

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

A message is returned in the event of an error.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There is only one way the function can be invoked, via the Save button.

4.

Do not count the following items as DETs: •

literals

Literals such as “Job Number” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 6 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EI

2-90

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: EI with Attributes Retrieved from an EIF The user requires the ability to Add an Employee by entering: User Requirements • Employee information

Example Screens

•

Salary or hourly rate information

•

Dependent’s information

•

The location must be a valid location in the Fixed Asset System (FAS).

•

The hourly rate is converted to U.S. Dollars; the currency data is accessed from the Currency System in order to convert a standard hourly rate in U.S. Dollars based upon the currency of the employee

The following are examples of the windows to add an employee.

Human Resources System Employee Jobs Assignments

Locations

Reports

Security

Help

Employee Setup Last Name First Name Middle Initial Social Security Number Number of Dependents Location

Main Office

New Supervisor Level New Bargaining Unit OK

Salary Type ( ) Hourly ( ) Salaried

Cancel

EN-1 Employee Setup New Supervisor Level New Bargaining Unit OK

Cancel

January 2010

Navigates to SL-1 Supervisor Level Navigates to BU-1 Bargaining Unit Navigates to next screen: • EN-2H, if hourly salary type is selected • EN-2S, if salaried salary type is selected Goes back to pull down menu

Function Point Counting Practices Manual

2-91

EI Counting Examples

Part 4 - Examples

Human Resources System Employee Jobs Assignments

Locations

Reports

Security

Help

Employee Setup Last Name First Name Middle Initial

Salaried Employee Setup First Line Manager

Supervisor Level

OK Cancel Dependents

EN-2S Employee Setup: Salary OK

Saves new employee data and returns refreshed EN-1 Employee Setup

Cancel Dependents

Returns to EN-1 Employee Setup (no data saved) Navigates to EN-3 Employee Dependent Setup (data on EN-2S Employee Setup salary is kept in memory)

Human Resources System Employee Jobs Assignments

Locations

Reports

Security

Help

Employee Setup Last Name First Name Middle Initial

Hourly Employee Setup Hourly Rate Bargaining Unit UFPCA

OK Cancel Dependents

EN-2H Employee Setup: Hourly OK

Saves new employee data and returns refreshed EN-1 Employee Setup

Cancel Dependents

2-92

Returns to EN-1 Employee Setup (no data saved) Navigates to EN-3 Employee Dependent Setup (data on EN-2H Employee Setup Hourly is kept in memory)

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Human Resources System Employee Jobs Assignments

Locations

Reports

Security

Help

Employee Setup Salaried Employee Data Dependent Setup Last Name First Name Middle Initial OK Social Security Number Cancel

Birth Date

More Dependents

EN-3 Employee Dependent Setup OK

Saves new dependent data and returns to EN-1 Employee Setup

Cancel

Returns to EN-2H Employee Setup Hourly or EN-2S Employee Setup Salary (no data saved)

More Dependents Accepts dependent data and returns refreshed EN-3 Employee Dependent Setup

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

January 2010

Yes.

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

2-93

EI Counting Examples

Step 3

Part 4 - Examples

Classify each Elementary Process EI Counting Rules 1.

2.

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Add an Employee has the primary intent to maintain the Employee ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Conclusion

Add an Employee is one EI.

Step 4

Count File Types Referenced (FTRs)

2-94

Does the Rule Apply?

Yes. Add an Employee includes processing logic to accept Employee information.

FTR Counting Rule

Does the Rule Apply?

1.

The Employee ILF is maintained. The Currency and Location EIFs are referenced.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Name (Last Name, First Name, Middle Initial), Social Security Number, Number of Dependents, Location, Salary Type, Supervisor Level, Hourly Rate, Bargaining Unit, Dependent Name (Last Name, First Name, Middle Initial), Dependent Social Security Number, Dependent Birth Date.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

The screen depicts the Employee Name field as three physical fields. Based upon review of the application functionality, the Employee Name is always used in its entirety. There are no screens or reports where a single piece of the name is used without the others. The same is also true of the Dependent Name. The Employee Name and Dependent Name are each counted as a single DET.

January 2010

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

A message is returned in the event of an error.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

OK button.

4.

Do not count the following items as DETs: •

literals

Literals such as “Last Name” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

US Hourly Rate is calculated, but it does not exit the boundary.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

Conversion Rate To Base Currency is retrieved from the Currency EIF in order to calculate the US Hourly Rate, but does not exit the boundary.

Function Point Counting Practices Manual

2-95

EI Counting Examples

Step 6

Part 4 - Examples

Determine Functional Complexity 3 FTR and 13 DETs

Step 7

Determine Functional Size Functional Size of 1 High EI

2-96

Complexity is High

6 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EI Counting Examples

Example: EI Delete The user requires the ability to Delete an Employee. User Requirements Delete all information about an individual employee. When deleting an employee currently assigned to a job, update the job assignment to set the status to inactive. • Generate error messages and highlight incorrect fields if the fields do not pass edits. Five (5) error messages and one (1) confirmation message are included for the employee information delete transaction. • When deleting an employee, update Status Inactive with an “X” and put the system date in Effective Date for each associated Job Assignment. Example Window

The following is an example of the window used to delete an employee.

Human Resources System Employee Jobs Assignments

Locations

Reports Security

Help

Employee Edit MI

First Name

Last Name Schmidt-Taylor

Kathleen

SSN Location Salary Type Dependents

456- 78-9012

OK

Main Office

Cancel

Salaried

Restore

4

Delete

New Supervisor Level

Salary Data

New Bargaining Unit

Dependents

EE2 – Employee Edit OK

January 2010

Dependents

Delete Saves changes- made, returns to EE -1 Employee List

Cancel

Ignores changes, returns to EE -1 Employee List

Salary Data

Restore

Restores prior values

Dependents

New Supervisor Level

Navigates to SL -1 Supervisor Level

New Bargaining Unit

Navigates to BU -1 Bargaining Unit

Asks for confirmation, then deletes employee record & associated dependent records Navigates to: EE-3S Employee Salary, if value is “Salaried” EE-3H Employee Hourly, if value is “Hourly” Causes list on EI-4 Dependent List to display

Function Point Counting Practices Manual

2-97

EI Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. Delete an Employee has the primary intent to maintain the Employee ILF.

•

altering the behavior of the application

No. The behavior of the application is not altered.

It includes processing logic to accept data or control information that enters the boundary of the application

Conclusion

Delete an Employee is one EI.

Step 4

Count File Types Referenced (FTRs)

2-98

Yes.

Yes. Delete an Employee includes processing logic to accept Employee information.

FTR Counting Rule

Does the Rule Apply?

1.

The Job Assignment ILF is maintained. The Employee ILF is both referenced and maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EI Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Social Security Number. All other attributes on the screen are part of the inquiry that preceeds the Delete. They are not counted as DETs for the Delete.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

A message is returned in the event of an error.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Delete button.

4.

Do not count the following items as DETs: •

literals

Literals such as “SSN” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

The Status Inactive attribute is updated, but does not exit the boundary. It is not counted.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 2 FTR and 3 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EI

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-99

EI Counting Examples

Part 4 - Examples

Example: Add Window Security The requirement for manage security was added during the Construction User Requirements phase. The user wants to add, change, delete and inquire on Human Resources System security information. The add functionality is illustrated below. Add window security information by entering • User Identifier •

Windows for Job Assignment, Job, Employee, Location and Report Generator functions

•

User Security for those functions (i.e., access or no access)

Generate error messages and highlight incorrect fields if the fields do not pass edits. Two (2) error messages and one (1) confirmation message are included for the security information add transaction. Add Window Security Screen

The following illustration shows the window to add window security.

Human Resources System Employee Jobs Assignments

Locations

Reports

Security

Help

HR Window Security Setup User Id Job

Job Assignment Setup Inquiry (Job) Inquiry (Employee) Edit Reports

Employee

Setup Inquiry Edit Reports

Setup Inquiry Edit Reports

Location

Report Generator Definition

Review

Define

OK

Edit Inquiry

Cancel

SW-1 HR Window Security Setup OK Cancel

Commit changes, return to to Human Resources System main menu Return to Human Resources System main menu

The boxes in the illustration above represent Window IDs.

2-100

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EI Counting Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes. No other elementary process performs this function.

Classify each Elementary Process EI Counting Rules 1.

2.

Conclusion

Yes.

Does the Rule Apply?

It has a primary intent of either: •

maintaining one or more ILFs or

Yes. The Window Security ILF is maintained.

•

altering the behavior of the application

No. The behavior of the application is not altered. The behavior of the application will be altered by controlling the functionality that the user can perform when they logon.

It includes processing logic to accept data or control information that enters the boundary of the application

Yes. Window Security information enters the boundary in order to maintain the Window Security ILF.

Add Window Security is one EI. Refer to the Case Studies to see how the change and delete requirements and associated screens are counted.

Step 4

January 2010

Count File Types Referenced (FTRs) FTR Counting Rule

Does the Rule Apply?

1.

The Window Security ILF is maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-101

EI Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

User Identifier, Windows, User Security.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

Error Messages.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

OK Action key.

4.

Do not count the following items as DETs: •

literals

Literals such as “User Id” are not counted.

•

application generated stamps

There are no items of this type.

•

paging variables

There are no items of this type.

•

navigation

There are no items of this type.

•

attributes generated without exiting the boundary and

There are no items of this type.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are no items of this type.

Determine Functional Complexity 1 FTR and 5 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EI

2-102

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

EO Counting Examples Introduction

This section uses a Human Resources (HR) application to illustrate procedures used to count external outputs. In addition to this section, examples are in the Case Studies included in supplemental IFPUG documentation.

Contents

This section includes following examples: Topic

January 2010

Page

Summary Descriptions of EO Counting Examples

2-104

Example: Hard Copy Report Output

2-105

Example: Online Reporting

2-108

Example: Transaction Sent to Another Application

2-111

Example: Error/Confirmation Messages

2-113

Example: Performance Review Notification

2-114

Example: EO Triggered without Data Entering the Boundary

2-117

Example: Primary Intent of an EO

2-120

Example: EO Transaction File

2-123

Function Point Counting Practices Manual

2-103

EO Counting Examples

Part 4 - Examples

Summary Descriptions of EO Counting Examples The examples for EOs are described in the following table.

2-104

Example

Summary Description

Page

Hard Copy Report Output

This example illustrates counting a hard copy report.

2-105

Online Reporting

This example shows the count for an online report.

2-108

Transaction Sent to Another Application

This example illustrates a transaction generated by one application and sent to another application.

2-111

Error/Confirmation Message

This example shows that error or confirmation messages are not counted as external outputs.

2-113

Performance Review Notification

This example illustrates a notification based upon a calculation.

2-114

EO Triggered without Data Entering the Boundary

This example illustrates the concept that an EO can be triggered without data entering the boundary.

2-117

Primary Intent of an EO

This example illustrates that an EO can update a file.

2-120

EO Transaction File

This example illustrates the existence of calculations determines that the elementary process is an EO and not an EQ.

2-123

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EO Counting Examples

Example: Hard Copy Report Output The user of the Human Resources System requires a listing of employee job User Requirements assignments. The report is generated by retrieving: • An assignment from the job assignment ILF • Additional information from the employee and job ILFs The report control ILF is referenced to determine how to generate the report.

Example Report

The following Job with Employees Report lists jobs and the employees assigned to them.

HRS006

Human Resource System Jobs with Employees

Job Number 9999

Page 1 Date 99.99.99

Job Name xxxxxxxxxx

Employee SSN Employee Name xxx-xx-xxxx xxxxxxxxxxxxxxx xxx-xx-xxxx xxxxxxxxxxxxxxx xxx-xx-xxxx xxxxxxxxxxxxxxx

9999

xxxxxxxxxx

xxx-xx-xxxx

xxxxxxxxxxxxxxx

9999

xxxxxxxxxx

xxx-xx-xxxx xxx-xx-xxxx

xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx

Total Jobs 9999

January 2010

Function Point Counting Practices Manual

2-105

EO Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes.

Yes. No other elementary process performs this function.

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. The Jobs with Employees report has the primary intent to present information to the user.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

Yes. The total number of jobs is considered both calculated and derived.

•

one or more ILFs are updated

No. An ILF is not updated.

•

derived data is created or

Yes. The total number of jobs is considered both calculated and derived.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

Conclusion

The Job with Employees Report is one EO.

Step 4

Count File Types Referenced (FTRs) FTR Counting Rule

Does the Rule Apply?

1.

The following ILFs are read:

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

• • • •

2-106

Employee Job Job Assignment Report Control

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EO Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Job Number, Job Name, Employee SSN, Employee Name and Total Jobs are reported. Count each only once.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none.

4.

Do not count the following items as DETs: •

literals such as report titles, screen or panel identifiers, column headings and attribute titles

Report identifiers, report titles and column headings are not counted.

•

application generated stamps such as date and time attributes

The report date is not counted.

•

paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’

The page number is not counted.

•

navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents

There are none.

•

attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary

There are none.

•

attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary

There are none.

Determine Functional Complexity 4 FTRs and 5 DETs

Step 7

Determine Functional Size Functional Size of 1 Average EO

January 2010

Complexity is Average

5 FP

Function Point Counting Practices Manual

2-107

EO Counting Examples

Part 4 - Examples

Example: Online Reporting The user requires a report of employees in descending sequence by the User Requirements duration of their current job assignments. This report is displayed online and contains calculated/derived data (for example, the job assignment duration). Example Screen

The following Employees by Assignment Duration screen layout lists employees by duration.

.

EMPLOYEES BY ASSIGNMENT DURATION

Rows 1 to 18 of 1,316 Employee SSN xxx-xx-xxxx xxx-xx-xxxx

MM/DD/YY

Employee Name

Job Number

Job Name

Assignment Duration

xxxxxxxxxx xxxxxxxxxx

9999 9999

xxxxxxxxxx xxxxxxxxxx

99 mos. 99 mos.

Employees over 24 mos. 9999 Employees over 12 mos. 9999

F1=Help F7=Scroll up F8=Scroll down F16=End

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

2-108

Yes.

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EO Counting Examples

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. Employees By Assignment Duration report has the primary intent to present information to the user.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

Yes. Three calculated fields are considered both calculated and derived.

•

one or more ILFs are updated

No. An ILF is not updated.

•

derived data is created or

Yes. Three calculated fields are considered both calculated and derived.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

Conclusion

The Employees by Assignment Duration report is one EO.

Step 4

Count File Types Referenced (FTRs)

January 2010

FTR Counting Rule

Does the Rule Apply?

1.

The Employee, Job and Job Assignment ILFs are read. No ILFs are maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-109

EO Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Employee SSN, Employee Name, Job Number, Job Name and Assignment Duration are repeated. Count each only once.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

A function key is used to display the online report.

4.

Do not count the following items as DETs: •

literals

Literals such as “Employee SSN” are not counted.

•

application generated stamps

The report date is not counted.

•

paging variables

“Rows 1 to 18” are not counted.

•

navigation

F7 and F8 are not counted.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 3 FTRs and 8 DETs

Step 7

Complexity is Average

Determine Functional Size Functional Size of 1 Average EO

2-110

Number of employees over 24 mos. and over 12 mos.

5 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EO Counting Examples

Example: Transaction Sent to Another Application When the Human Resources System adds employee dependent data, the user User Requirements requires that this Dependent File be sent to the Benefits application to keep benefits records consistent. This information is sent to Benefits daily. Construction If dependent data is added, that information is formatted properly on the Requirements output transaction file. When implementing a solution, it was decided to include a header and trailer record with the benefits information. These records are used by Benefits to ensure that nothing technically was incorrect when transmitting the file. Example Record Layout

The following employee dependent record layout contains information about dependent additions and changes.

123456789101234567890123456789012345678901234567890123456789012345678901234567890 1 H⏐FILE NAME ⏐DATE 2 D⏐EMP SSN ⏐DEP SSN 3 T⏐TOT. REC ⏐ 4 5 6 7 9 0

Field Descriptions

⏐ ⏐DEPENDENT NAME

The following table includes descriptions for each field on the record. Record Type

Position

Description

Header

1

Record type H

2-13

File name

14-19

Date created

1

Record type D

2-10

Employee social security number

11-19

Dependent social security number

20-39

Dependent name

40-45

Dependent birth date

1

Record type T

2-10

Total number of records

Dependent

Trailer

January 2010

⏐BDAY⏐

Function Point Counting Practices Manual

2-111

EO Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process - Header Does the Transactional Function meet the requirements of an Elementary Process?

Step 1

Identify the Elementary Process - Trailer Does the Transactional Function meet the requirements of an Elementary Process?

Step 1

Conclusion

2-112

Yes. The dependent section of the transaction file satisfies the requirements for an EP.

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

No. The trailer contains no user meaningful data.

Identify the Elementary Process - Dependent Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

No. The header contains no user meaningful data.

Yes. No other elementary process performs this function.

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. The Dependent file has the primary intent to present information to the user.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

No. Calculations are not performed.

•

one or more ILFs are updated

No. An ILF is not updated.

•

derived data is created or

No. Derived data is not created.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

The Dependent File does not qualify as an EO; it would be counted as an EQ (not analyzed here).

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EO Counting Examples

Example: Error/Confirmation Messages Users require message feedback when job information is maintained. More User Requirements specifically, users require messages to indicate any edit or validation errors or to indicate that the process completed successfully. Example Screen

Action:_

The following Job screen shows a confirmation message (bottom of screen).

7=Prior

8=Following Job Data

Job number:

RD15379305

Job name:

May Issue - Print Covers

Pay grade:

JRNY05A

Line No Job Description 01 Print Covers 4-Up, Lacquer Finish. ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ ________________________________________________________________ F1=Help F7=Scroll up F8=Scroll down Processing Completed Successfully

F12=Cancel

Enter: returns to calling screen. F12: returns to calling screen. F1: shows screen or field level help. Action 7: shows prior job data, if present. F7: scrolls up 10 job description lines. Action 8: shows following job data, if present. F8: scrolls down 10 job description lines.

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

January 2010

No. The output of an error message is not a self-contained function. It is an output DET on the Add Job EI.

Function Point Counting Practices Manual

2-113

EO Counting Examples

Part 4 - Examples

Example: Performance Review Notification The user requires automatic notification when an employee has completed User Requirements 12 months in a job assignment. This indicates that a performance review should be completed. Example Window

The following Performance Review Notification window describes the notification message.

Performance Review Notification

As of Date: xx/xx/xx Employee: xxx-xx-xxxx

x_________________x

Has completed 12 months in assignment: Job: xxxx

x_______________________x

And should be scheduled for a performance review immediately.

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

2-114

Yes.

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EO Counting Examples

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. Performance Review Notification has the primary intent to present information to the user.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

Yes. The 12 month completion date is calculated.

•

one or more ILFs are updated

No. An ILF is not updated.

•

derived data is created or

No. Derived data is not created.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

Conclusion

The Performance Review Notification is one EO.

Step 4

Count File Types Referenced (FTRs)

January 2010

FTR Counting Rule

Does the Rule Apply?

1.

Employee, Job and Job Assignment ILFs are read.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-115

EO Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

As of Date, Employee Social Security Number, Employee Name, Job Number, Job Name.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none.

4.

Do not count the following items as DETs: •

literals

Literals such as “Employee” are not counted.

•

application generated stamps

The report date and time are not counted.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 3 FTR and 5 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EO

2-116

Complexity is Low

4 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EO Counting Examples

Example: EO Triggered without Data Entering the Boundary User Requirement:

Data Model

Users require that the application print the Weekly Employee Report automatically every Sunday night at 11:00 p.m. The report contains details for each employee plus a total of the employees. The following diagram shows the data flow for this example.

Weekly Employee Report Name Brown, B. D’Souza, M. Edwards, R. Fischer, J. Garmus, D. Marthaler, V. Russac, J. Thomas, P. Timp, A.

Print Weekly Employee Report

Employee ILF SSN Name Location

Step 1

Total Employees: 9

Yes.

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

January 2010

Macomb New Plymouth Freehold Palm Coast Orange Park Clarkston Green Cove Springs Fareham Hampshire Utrecht

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Location

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

2-117

EO Counting Examples

Step 3

Part 4 - Examples

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. The Weekly Employee Report has the primary intent to present information to the user.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

Yes. Total Employees is a calculated field.

•

one or more ILFs are updated

No. An ILF is not updated.

•

derived data is created or

Yes. The report contains a calculated field.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

Conclusion

The Weekly Employee Report is one EO.

Step 4

Count File Types Referenced (FTRs)

2-118

FTR Counting Rule

Does the Rule Apply?

1.

The Employee ILF is read. No ILFs are maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EO Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Name, Location, Total Employees.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none.

4.

Do not count the following items as DETs: •

literals

Literals such as “Name” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 3 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EO

January 2010

Complexity is Low

4 FP

Function Point Counting Practices Manual

2-119

EO Counting Examples

Part 4 - Examples

Example: Primary Intent of an EO Print a Check and, as a result, mark the account as paid. All data printed on User Requirements the check was already stored in the check file. The following diagram shows the data flow for this example.

Print check

Check ILF Check Number Check Amount Recipient Account Paid Indicator Check Date

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

2-120

Yes.

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EO Counting Examples

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. The primary intent is to print a check. The maintenance of the ILF is secondary.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

No. Calculations are not performed.

•

one or more ILFs are updated

Yes. The Check ILF is updated.

•

derived data is created or

No. Derived data is not created.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

Conclusion

Print a Check is one EO.

Step 4

Count File Types Referenced (FTRs)

January 2010

FTR Counting Rule

Does the Rule Apply?

1.

The Check ILF is read and maintained, but is only counted once.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-121

EO Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Check Number, Check Amount, Recipient, Check Date.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There is a date printed on the check, but it represents user recognizable data and is counted.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

The Account Paid Indicator is not counted as it does not cross the boundary.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 4 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EO

2-122

Complexity is Low

4 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EO Counting Examples

Example: EO Transaction File At the end of the month, generate a Monthly Check File and send it to User Requirements Application B. The check numbers, check dates, and check amounts are included on the file with a computed count of the checks processed and the total amount of all of the checks printed for the month. The number of checks printed and total dollar amount for all checks printed are used by the Application B users to provide banking reports. Data Model

The following diagram shows the data flow for this example. Application B

Application A

Generate Monthly Check File

Monthly Check File Check number Check Amount Check Date

Check ILF

Month No. of Checks Printed Total $ for all checks

Check Number Check Amount Check Date

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

January 2010

Yes.

Yes. There is no other elementary process that performs this function.

Function Point Counting Practices Manual

2-123

EO Counting Examples

Step 3

Part 4 - Examples

Classify each Elementary Process EO Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and

Yes. The primary intent is to generate a transaction file.

2.

It includes at least one of the following forms of processing logic: •

mathematical calculations are performed

Yes. The file includes two calculated fields.

•

one or more ILFs are updated

No. An ILF is not updated.

•

derived data is created or

Yes. The file includes two calculated fields.

•

the behavior of the application is altered

No. The behavior of the application is not altered.

Conclusion

The Monthly Check File is one EO.

Step 4

Count File Types Referenced (FTRs)

2-124

FTR Counting Rule

Does the Rule Apply?

1.

The Check ILF is read. There are no ILFs maintained.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EO Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Check Number, Check Amount, Check Date, Month, No. of checks printed, Total $ for all checks.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 6 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EO

January 2010

Complexity is Low

4 FP

Function Point Counting Practices Manual

2-125

EO Counting Examples

Part 4 - Examples

This page intentionally left blank.

2-126

Function Point Counting Practices Manual

January 2010

EQ Counting Examples Introduction

This section uses a Human Resources (HR) application to illustrate procedures to count external inquiries. In addition to this section, examples are in the Case Studies included in the supplemental IFPUG documentation.

Contents

This section includes the following examples: Topic

January 2010

Page

Summary Descriptions of EQ Counting Examples

2-128

Example: Application Menus

2-129

Example: List of Retrieved Data

2-131

Example: Drop-Down List Box

2-136

Example: Field Level Help–First Occurrence

2-140

Example: Field Level Help–Second Occurrence

2-143

Example: Implied Inquiry

2-145

Example: EQ Triggered without Data Entering the Boundary

2-149

Example: Data Sent to Another Application

2-152

Example: Additional Help Functionality

2-155

Example: Security Logon

2-159

Function Point Counting Practices Manual

2-127

EQ Counting Examples

Part 4 - Examples

Summary Descriptions of EQ Counting Examples The examples for EQs are listed and described in the following table.

2-128

Example

Summary Description

Page

Application Menus

This example shows that navigational menus or other navigational aids are not counted as EQs.

2-129

List of Retrieved Data

This example illustrates the count for a list.

2-131

Drop-Down List Box

This example illustrates counting a drop-down list.

2-136

Field Level Help–First Occurrence

This example illustrates that field level help is counted for the first occurrence.

2-140

Field Level Help–Second Occurrence

This example illustrates that a second instance of field level help is not counted.

2-143

Implied Inquiry

This example illustrates counting an inquiry that is not explicitly stated but it is implied.

2-145

EQ Triggered without Data Entering the Boundary

This example illustrates counting data retrieval and display triggered internally by time.

2-149

Data Sent to Another Application

This example illustrates counting data sent to another application via a file.

2-152

Additional Help Functionality

This example illustrates counting additional help functionality.

2-155

Security Logon

This example illustrates counting the logon function.

2-159

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: Application Menus The Human Resources application requires navigation menus and aids. User Requirements Example Windows

The following diagram shows the Employee drop-down menu on the Human Resources System main menu. This is the input request.

Human Resources System Employee

Jobs Assignments

Locations

Rpt Man

Security

Help

New Review Edit Report

January 2010

Function Point Counting Practices Manual

2-129

EQ Counting Examples

Part 4 - Examples

When the user selects New on the Employee drop-down menu, the following empty Employee Setup window is displayed. Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee Setup Last Name First Name Middle Initial Social Security Number Number of Dependents Location

Main Office

Currency Location OK

Salary Type ( ) Hourly ( ) Salaried

Cancel

EN-1 Employee Setup Cancel OK

Step 1

Goes back to pull down menu Navigates to next screen: • EN-2H Employee Setup Hourly, if hourly salary type is selected • EN-2S Employee Setup Salary, if salaried salary type is selected

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Conclusion

2-130

No. Menus exist to satisfy navigational requirements rather than functional user requirements.

Menus do not satisfy the requirements of an elementary process.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: List of Retrieved Data The user has the following requirements: User Requirements • View a List of Employees sorted by Last Name, First Name and Middle Initial. This example focuses on viewing a list of employees in the Human Resources application. Data Flow Diagram

The following diagram shows the data flow for this example.

User ssn, name, type, supv_cd, hr_rate, bu_#, dep_ssn, dep_name, dep_birth, loc_name

access allowed

1.4

ssn

Inquire Employee empl info

access allowed

1.5 EMPL/DEP

empl info

Inquire List of Employees

Employee Security

Employee List ssn, name, type, sal_type

Review Request

Legend:

January 2010

User or Application

Process

Data Stored

Flow of Data

Function Point Counting Practices Manual

2-131

EQ Counting Examples

Example Windows

Part 4 - Examples

The following diagram shows the drop-down menu for employee. The Review field and the enter key make up the input side of this example. Human Resources System Employee

Jobs Assignments

Locations

Rpt Man

Security

Help

New Review Edit Report

When the user selects Review on the Employee drop-down menu, the following window displays with a list of employees. Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee List Last Name

First Name

Keller

Caroline

Latta

Nicky

Manship

Mark

Schmidt-Taylor

Kathleen

Smith

David

Smith

Loretta

View

MI

Social Security

Salary Type

123-45-6789

Salaried

A

234-56-7890

Hourly

J

345-67-8901

Hourly

456-78-9012

Salaried

E

567-89-0123

Hourly

M

678-90-1234

Salaried

Dependents

Cancel

EI-1 Employee List View Dependents Cancel

2-132

Initiates display of data on EI-2 Review Employee Data Initiates list displayed on EI-4 Dependent List Returns to pull down menu

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 1

EQ Counting Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes. No other elementary process performs this function.

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. The primary intent is to present information to the user.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Employee ILF.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Conclusion

The List of Employees is one EQ.

Step 4

Count File Types Referenced (FTRs)

January 2010

Yes.

FTR Counting Rule

Does the Rule Apply?

1.

The Employee ILF is read. An EQ cannot maintain an ILF by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-133

EQ Counting Examples

Step 5

2-134

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

The following are repeated, they are counted only once. Last Name, First Name, MI, SSN, Salary Type.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Yes. The Review field/enter key initiates the action.

4.

Do not count the following items as DETs:

The list is sorted using individual elements of the name (i.e., Last Name, First Name, MI). As a result, the individual elements of the Name are user-recognizable.

•

literals such as report titles, screen or panel identifiers, column headings and attribute titles

Screen and column headers are not counted.

•

application generated stamps such as date and time attributes

There are none.

•

paging variables, page numbers and positioning information; e.g., ‘Rows 37 to 54 of 211’

There are none.

•

navigation aids such as the ability to navigate within a list using “previous”, “next”, “first”, “last” and their graphical equivalents

The scroll bar is not counted.

•

attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary

There are none.

•

attributes retrieved or referenced from an ILF or EIF for participation in the processing without exiting the boundary

There are none.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 6

EQ Counting Examples

Determine Functional Complexity 1 FTR and 6 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EQ

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-135

EQ Counting Examples

Part 4 - Examples

Example: Drop-Down List Box The user requires the ability to view a List of Bargaining Units added to the User Requirements Human Resources System by a user. Example Windows

The following diagram shows the Hourly Employee Data window with the Bargaining Unit field. Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee List Employee Data J

Mark

Manship

345-67-8901

Hourly Employee Data

Hourly Rate Bargaining Unit

Dependents

EI-3H Hourly Employee Data with Bargaining Unit Dependents

2-136

Presents list on EI-4 Dependent List

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

When the user selects the arrow, the following drop-down list box appears. Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee List Employee Data Manship

J

Mark

345-67-8901

Hourly Employee Data

Hourly Rate Bargaining Unit

Dependents UPFCA L841 CPLG

EI-3H Hourly Employee Data with Bargaining Unit Dependents

Step 1

Presents list on EI-4 Dependent List

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

January 2010

Yes.

Yes. There is no other elementary process that peforms this function.

Function Point Counting Practices Manual

2-137

EQ Counting Examples

Step 3

Part 4 - Examples

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. The primary intent is to present information to the user.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Bargaining Unit ILF. The Bargaining Unit ILF contains numerous attributes about a Bargaining Unit.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Conclusion

The List of Bargaining Units is one EQ.

Step 4

Count File Types Referenced (FTRs)

2-138

FTR Counting Rule

Does the Rule Apply?

1.

The Bargaining Unit ILF is read. An EQ cannot maintain an ILF, by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EQ Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Bargaining Unit.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Yes. The down arrow activates the listbox.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 2 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EQ

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-139

EQ Counting Examples

Part 4 - Examples

Example: Field Level Help–First Occurrence During construction of the Human Resources System, a requirement for User Requirements online field level help was added. Help information is maintained by a separate application. The Help information is referenced by the Human Resources, Currency, Fixed Assets, and Benefits applications. Example Windows

The following diagram shows the Employee Data window.

Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee List Employee Data J

Mark

Manship

345-67-8901

Hourly Employee Data

Hourly Rate Dependents

Bargaining Unit

EI-3H Hourly Employee Data Dependents

Presents list on EI-4 Dependent List

When the user presses F1 while the cursor is on the hourly rate field, a box displays the help text as shown in the following diagram.

2-140

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Hourly Rate The amount an employee is paid for each hour of work completed. This information must be provided for each hourly employee. Valid Values: Any hourly amount is acceptable. Default Values: This field does not have default values.

Hourly Rate Bargaining Unit

Dependents

EI-3H Hourly Rate Dependents

Step 1

Presents list on EI-4 Dependent List

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Conclusion

January 2010

Yes.

Yes. No other elementary process performs this function.

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. Field Help has the primary intent to present information to the user.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Help EIF.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Field Level Help is one EQ.

Function Point Counting Practices Manual

2-141

EQ Counting Examples

Step 4

Step 5

Step 6

Part 4 - Examples

Count File Types Referenced (FTRs) FTR Counting Rule

Does the Rule Apply?

1.

The Help EIF is read. An EQ cannot maintain an ILF by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Window ID, Field ID, Help Message, Default Value, Valid Values.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Yes. The F1 key.

4.

Do not count the following items as DETs: •

literals

Literals such as “Valid Values” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 6 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EQ

2-142

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: Field Level Help–Second Occurrence During construction of the Human Resources System, a requirement for User Requirements online field level help was added. The online help is for the add, delete, and change processes for the Human Resources information. Help information is maintained by a separate application. The Help information is referenced by the Human Resources, Currency, Fixed Assets, and Benefits applications. Example Windows

The following diagram shows the Employee Data window.

Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee List Employee Data J

Mark

Manship

345-67-8901

Hourly Employee Data

Hourly Rate Bargaining Unit

Dependents

EI-3H Hourly Employee Data Dependents

Presents list on EI-4 Dependent List

The user places the cursor on the field for which help is desired, and presses F1 to view help about that field. Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

January 2010

Yes.

Function Point Counting Practices Manual

2-143

EQ Counting Examples

Step 2

Part 4 - Examples

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Conclusion

2-144

No. This function performs the same function as that depicted in the prior example. The DETs, FTRs and processing logic for this function are the same as the prior example. It is not counted again.

The Second Occurrence of Field Level Help is not a unique elementary process and is not counted as an EQ.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: Implied Inquiry The user requires the ability to view assignment information when editing User Requirements job assignment information. Although it is not explicitly stated, it is implied that Job Assignment Information must be retrieved before it can be changed. Example Windows

The following diagram shows the Job Assignment Edit window with only the employee name and job number. Human Resources System Employee

Jobs

Assignments

Locations

Rpt Man

Security

Help

Employee Assignments Job Assignment Edit Mark

Manship

J 345-67-8901 Main Plant

Job Number Date

UFPCA RD15379305

May Issue - Print Covers OK

03/27/93

Cancel Salary Performance Rating

17.28 Satisfactory

Restore Delete

AE-5 OK

Commits changes, returns to AE-1

Cancel

Ignores changes, returns to AE-1

Restore

Restores prior values

Delete

January 2010

Asks for confirmation, then deletes job assignment

Function Point Counting Practices Manual

2-145

EQ Counting Examples

Part 4 - Examples

When the user enters employee name and job number, the job information appears as shown in the following diagram.

Human Resources System Employee Jobs

Assignments

Locations

Rpt Man

Security

Help

Employee Assignments Job Assignment Edit Mark

Manship

J 345-67-8901 Main Plant

Job Number Date

UFPCA May Issue - Print Covers

RD15379305

OK

03/27/93

Cancel Salary Performance Rating

17.28 Restore Satisfactory

Delete

AE-5 OK

Commits changes, returns to AE-1

Cancel

Ignores changes, returns to AE-1

Restore

Restores prior values

Delete

Step 1

Asks for confirmation, then deletes job assignment

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

2-146

Yes.

Yes. We have not counted any other elementary process that performs this function. If a direct inquiry also exists, it would be considered a duplicate and would not be counted again.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EQ Counting Examples

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. Job Assignment Implied Inquiry has the primary intent to present information to the user.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Job Assignment, Employee, and Job ILFs.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Conclusion

Job Assignment Implied Inquiry is one EQ.

Step 4

Count File Types Referenced (FTRs)

January 2010

FTR Counting Rule

Does the Rule Apply?

1.

The Job Assignment, Employee, and Job ILFs is read. An EQ cannot maintain an ILF by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-147

EQ Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Name, SSN, Location, Bargaining Unit, Job Number, Job Name, Effective Date, Salary, and Performance Rating.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Yes. The command key.

4.

Do not count the following items as DETs: •

literals

Literals such as the screen title are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 3 FTRs and 10 DETs

Step 7

Determine Functional Size Functional Size of 1 Average EQ

Conclusion

2-148

Complexity is Average

4 FP

The Job Assignment Implied Inquiry is a unique elementary process and is counted as an EQ. If a direct inquiry also exists, it would be considered a duplicate and would not be counted again.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: EQ Triggered without Data Entering the Boundary The user requires that the application print the Monthly Membership Report User Requirements automatically every month. The following diagram shows the data flow for this example.

Monthly Membership Report

Print Monthly Membership Report

Name

City

Country

Angel, A. Boxer, B. Nair, J. Alfonzo, F. Batista, M. Man Bae, C.

Milwaukee London Chennai Rome Rio De Janeiro Seoul

USA UK India Italy Brazil Korea

Membership ILF Member ID Name City Country

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

January 2010

Yes.

Yes. No other elementary process performs this function.

Function Point Counting Practices Manual

2-149

EQ Counting Examples

Step 3

Part 4 - Examples

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. The Monthly Membership Report has the primary intent to present information ot the user.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Membership ILF.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Conclusion

The Monthly Membership Report is one EQ. In this example, the transaction is triggered by a time event within the boundary.

Step 4

Count File Types Referenced (FTRs)

2-150

FTR Counting Rule

Does the Rule Apply?

1.

The Membership ILF is read. An EQ cannot maintain an ILF, by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EQ Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Name, City, Country.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none. The function is performed automatically every month.

4.

Do not count the following items as DETs: •

literals

Literals such as “Name” are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 3 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EQ

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-151

EQ Counting Examples

Part 4 - Examples

Example: Data Sent to Another Application At the end of each day, send a Daily Check File to Application B listing the User Requirements check numbers, the amount and date of each check printed for the day. The following diagram shows the data flow for this example. Application B

Application A

Generate Daily Check File

Daily Check File Check Number Check Amount Check Date

Check ILF Check Number Check Amount ...

Step 1

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

2-152

Yes.

Yes. There is no other elementary process that performs this function.

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 3

EQ Counting Examples

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. The Daily Check file has the primary intent to present information. In this case, the user is Application B.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Check ILF.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Conclusion

The Daily Check File is one EQ.

Step 4

Count File Types Referenced (FTRs)

January 2010

FTR Counting Rule

Does the Rule Apply?

1.

The Check ILF is read. An EQ cannot maintain an ILF, by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

2-153

EQ Counting Examples

Step 5

Step 6

Part 4 - Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Check Number, Check Amount, Check Date.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

There are none. The function is performed automatically every month.

4.

Do not count the following items as DETs: •

literals

There are none.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity 1 FTR and 3 DETs

Step 7

Determine Functional Size Functional Size of 1 Low EQ

2-154

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: Additional Help Functionality During construction of the Human Resources System, a requirement for User Requirements additional help functionality was added. Help information is maintained by a separate application. The Help information is referenced by the Human Resources, Currency, Fixed Assets, and Benefits applications. Counting Process

The following diagram shows the Employee Data window.

Human Resources System Employee Jobs Assignments

Locations

Rpt Man

Security

Help

Employee List Employee Data J

Mark

Manship

345-67-8901

Hourly Employee Data

Hourly Rate Dependents

Bargaining Unit

EI-3H Hourly Employee Data Dependents

Presents list on EI-4 Dependent List

When the user selects the Help function at the top of any Window, three choices become available: Window, Search and About.

January 2010

Function Point Counting Practices Manual

2-155

EQ Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes, Window, Search and About appear to perform three independent functions.

Yes. No other elementary process performs these functions. These functions are counted only once within an application.

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. Window, Search and About all have the primary intent to present information to the user.

•

Window Data is retrieved from the Help EIF based upon the current Window.

references a data function to retrieve data or control information and

Search enables the user to enter a topic and retrieve Topic Data from the Help EIF. About is retrieving hard-coded static data not maintained in the Help EIF. Therefore it does not meet the definition of an EQ. •

Conclusion

does not satisfy the criteria to be classified as an EO

Yes. They perform no calculations, create no derived data and do not update any ILFs.

Window Help is one EQ and the Search capability is one EQ. About Help is not counted because it is not maintained through an elementary process. It is important to ensure that you do not count Static Help. Popular environments, especially web applications, frequently contain static help. It is also important to ensure that the boundaries are correctly assessed. Help functionality is often provided by an external application, such as RoboHelp, which provides all of the help functionality (i.e., maintenance, storage and display of help). In this instance, no functionality is credited to the application about which the help pertains. Window Help and Search Help are each analyzed separately below.

2-156

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 4

Step 5

Step 6

EQ Counting Examples

Count File Types Referenced (FTRs) for Window Help FTR Counting Rule

Does the Rule Apply?

1.

The Help EIF is read. An EQ cannot maintain an ILF by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Count Data Element Types (DETs) for Window Help DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Window ID, Window Description (text only).

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Yes. Selection from the Help Menu.

4.

Do not count the following items as DETs: •

literals

Literals such as screen labels are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity for Window Help 1 FTR and 3 DETs

Step 7

Determine Functional Size for Window Help Functional Size of 1 Low EQ

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-157

EQ Counting Examples

Step 4

Step 5

Step 6

Part 4 - Examples

Count File Types Referenced (FTRs) for Search Capability FTR Counting Rule

Does the Rule Apply?

1.

The Help EIF is read. An EQ cannot maintain an ILF by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Count Data Element Types (DETs) for Search Capability DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

Application ID, Topic Entered, Help Message(s) Returned.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

There are none.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Yes. Selection from the Help Menu.

4.

Do not count the following items as DETs: •

literals

Literals such as screen labels are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity for Search Capability 1 FTR and 4 DETs

Step 7

Determine Functional Size for Search Capability Functional Size of 1 Low EQ

2-158

Complexity is Low

3 FP

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

EQ Counting Examples

Example: Security Logon The user wants a logon function to control window security. The User Requirements functionality is illustrated below. The logon function requires the entry of the following fields: • User Identifier • User Password When the user logs on, the Security file is read to validate the user identifier and password as well as to determine the windows the user can access and maintain. Generate error messages and highlight incorrect fields if the fields do not pass edits. Two (2) error messages and one (1) confirmation message are included for the security logon transaction. Security Logon Screen

The following illustration shows the window to logon to the system. Human Resources System Security Logon

User ID Password

The user presses enter after all information is entered. The User ID and Password are validated and logically all user access is assigned.

January 2010

Function Point Counting Practices Manual

2-159

EQ Counting Examples

Step 1

Part 4 - Examples

Identify the Elementary Process Does the Transactional Function meet the requirements of an Elementary Process?

Step 2

Determine whether the Elementary Process is unique Is the Transactional Function unique from other elementary processes?

Step 3

Yes.

Yes. No other elementary process performs this function.

Classify each Elementary Process EQ Counting Rules

Does the Rule Apply?

1.

It has the primary intent of presenting information to the user, and it:

Yes. The primary intent is to present information to the user.

•

references a data function to retrieve data or control information and

Yes. Data is retrieved from the Security ILF.

•

does not satisfy the criteria to be classified as an EO

Yes. It performs no calculations, creates no derived data and does not update any ILFs.

Conclusion

The Security Logon is one EQ.

Step 4

Count File Types Referenced (FTRs) for Search Capability

2-160

FTR Counting Rule

Does the Rule Apply?

1.

The Security ILF is read. An EQ cannot maintain an ILF by definition.

One FTR shall be counted for each unique data function that is accessed (read from and/or written to) by the transactional function

Function Point Counting Practices Manual

January 2010

Part 4 - Examples

Step 5

Step 6

EQ Counting Examples

Count Data Element Types (DETs) DET Counting Rule

Does the Rule Apply?

1.

Count one DET for each unique user recognizable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function

User ID, Password.

2.

Count only one DET per transactional function for the ability to send an application response message even if there are multiple messages

Error and Confirmation Messages.

3.

Count only one DET per transactional function for the ability to initiate action(s) even if there are multiple means to do so

Enter key.

4.

Do not count the following items as DETs: •

literals

Literals such as screen labels are not counted.

•

application generated stamps

There are none.

•

paging variables

There are none.

•

navigation

There are none.

•

attributes generated without exiting the boundary and

There are none.

•

attributes retrieved or referenced from an ILF or EIF without exiting the boundary

There are none.

Determine Functional Complexity for Search Capability 1 FTR and 4 DETs

Step 7

Determine Functional Size for Search Capability Functional Size of 1 Low EQ

January 2010

Complexity is Low

3 FP

Function Point Counting Practices Manual

2-161

EQ Counting Examples

Part 4 - Examples

This page intentionally left blank.

2-162

Function Point Counting Practices Manual

January 2010

Part 4 – Examples

Index

Index to Part 4 A Alternate index example, 1-20 Application menus counting example, 2-129 B Batch with multiple and duplicate EIs, 2-70 C Control information for reporting, 2-63 Conversion data model, 1-43 Conversion information, 1-43 Converting data to a new format with additional data elements, 2-80 D Data conversion, 1-58, 2-80 Data conversion data model, 1-58 Diagrams components in EI/EO/EQ Counting Examples, 2-3 components in ILF/EIF Counting Examples, 1-5 conversion data model, 1-43 data conversion data model, 1-58 Employee Data for field help input side of inquiry, 2-143 Job Assignments Data window, 2-76 Job Data input screen, 2-67 menu for input side of inquiry, 2-129 online reporting screen, 2-108 organization of EI/EO/EQ Counting Examples, 2-2 record layout transaction input file example, 1-60 E EI with multiple file types referenced, 2-76 EI/EO/EQ Counting Examples, 2-2 Employee Data field help, 2-143

January 2010

Examples alternate index, 1-20 application menus, 2-129 batch with multiple and duplicate EIs, 2-70 control information, 2-63 conversion information, 1-43 converting data to a new format, 2-80 data conversion, 1-58, 2-80 data flow diagram to count referenced to multiple files, 2-76 EI with multiple file types referenced, 2-76 field-level help, 1-50 hard copy report, 2-105 Help application, 1-50 online add transaction, 2-67 providing data to other applications, 1-48 references to multiple files, 2-76 referencing data from another application, 1-43, 283 referencing data from other applications, 1-39 report output, 2-105 screen input, 2-67 summary descriptions of external inputs examples, 2-62 summary descriptions of external output examples, 2-104 transaction with formatted record types, 2-70 transaction with multiple types, 2-70 window help, 1-50 External inputs batch with multiple and duplicate EIs, 2-70 control information, 2-63 data conversion example, 2-80

Function Point Counting Practices Manual

i-1

Index

Part 4 – Examples

EI with multiple file types referenced, 2-76 screen input example, 2-67 External inquiries application menus example, 2-129 External interface files conversion information, 1-43 data conversion example, 1-58 data referenced in other applications, 1-39 field-level help, 1-50 Help application example, 1-50 providing data to other applications, 1-48 referencing data from another applicaiton, 2-83 referencing data from another application, 1-43 referencing data from other applications, 1-39 window help, 1-50 External outputs report output example, 2-105 F Field-level help, 1-50 Formatted record types, 2-70 H Hard copy report, 2-105 Help application, 1-50 Human Resources System window, 2-129 I Internal logical files alternate index example, 1-20 summary descriptions of examples, 1-8, 2-8 J Job Assignments Data window, 2-76 M Manual organization of EI/EO/EQ Counting Examples, 2-2 organization of ILF/EIF Counting Examples, 1-4 Multiple types, 2-70

i-2

N New format with additional data elements, 2-80 O Online add transaction via a screen, 2-67 Online reporting screen, 2-108 Organization. See Manual EI/EO/EQ Counting Examples, 2-2 P Providing data to other applications, 1-48 R Record layout for input file transaction, 1-60 Record types, 2-70 Referenced to multiple files, 2-76 Referencing data from another application, 1-43, 283 Referencing data from other applications, 1-39 Report output example, 2-105 Reports hard copy, 2-105 S Screen input, 2-67 Screens Employees by Assignment Duration, 2-108 online reporting, 2-108 Summary description of external input examples, 262 Summary description of external outputs examples, 2-104 Summary descriptions of ILF examples, 1-8, 2-8 T Transaction with formatted record types, 2-70 Transaction with multiple types, 2-70 W Window help, 1-50 Windows field help, 2-143

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

This page intentionally left blank.

Part 5 Appendix A

Appendix A: Functional Size Calculation Table Introduction

Appendix A includes a table to facilitate measuring functional size.

Contents

This appendix includes the following table: Topic Functional Size Calculation Table

January 2010

Function Point Counting Practices Manual

Page A-2

A-1

Appendix A: Functional Size Calculation Table

Part 5 – Appendices and Glossary

Functional Size Calculation Table The following table is provided to facilitate the calculation of the contribution to the functional size. Function Type

Functional Complexity

ILF

Low

X7=

Average

X 10 =

High

X 15 =

Low

X5=

Average

X7=

High

X 10 =

Low

X3=

Average

X4=

High

X6=

Low

X3=

Average

X4=

High

X6=

Low

X4=

Average

X5=

High

X7=

EIF

EI

EQ

EO

Complexity Totals

Function Types Totals

Total Functional Size

A-2

Function Point Counting Practices Manual

January 2010

Part 5 Appendix B

Appendix B: The Change from Previous Version Introduction

This appendix includes information about the changes and enhancements included in CPM 4.3, the decision making process, and recommendations to users of the new manual.

Contents

This chapter includes the following: Topic

January 2010

Page

Introduction

B-2

Major Structural Change Areas in CPM 4.3

B-3

Version Control

B-3

Overview of Changes

B-4

Background

B-11

The Impact Study

B-11

Conversion from CPM 4.2 to 4.3

B-11

Impact on 4.2.1 Users Changing to 4.3

B-12

Recommendations

B-12

Function Point Counting Practices Manual

B-1

Appendix B: The Change from Previous Version

Part 5 – Appendices and Glossary

Introduction Since the release of IFPUG Counting Practices Manual (CPM) 4.2 in 2004, the Counting Practices Committee (CPC) has created a new version of Part 1 (rules) to replace ISO Standard (ISO 20926:2004); i.e., IFPUG CPM 4.1 Unadjusted. The creation of the new ISO Standard required changes to the text in the remaining parts (the implementation guide) to retain consistency. When revising the CPM, the CPC process is as follows: 1. The issue is submitted to the CPC by the membership. 2. The issue is assigned to CPC members for research. 3. The CPC reviews and discusses the issue. 4. The CPC presents the proposed solution to the membership. 5. An impact study is initiated. 6. The final decision is made. 7. The IFPUG membership is informed of the decision through MetricViews and IFPUG conference presentations. 8. Changes become effective in a new CPM. 9. Case Studies are revised to reflect the new CPM.

B-2

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix B: The Change from Previous Version

Major Structural Change Areas in CPM 4.3 The major structural change areas in CPM 4.3 are: • Replace existing Part 1 with the new ISO Standard (ISO/IEC 20926:2010) • Created The Bridge - Applying the IFPUG Functional Size Measurement Method (now Part 2) which provides guidance in applying the process and rules as defined in the ISO Standard (now Part 1) • Amend the remaining parts to be consistent with the revised Part 1 • Counting Practices (Part 3) • Examples (Part 4) • Appendices and Glossary (Part 5)

Version Control The CPC has chosen to name this version of the IFPUG CPM 4.3 rather than 4.2.2 or 5.0 for two reasons: • A version of 4.2.2 would suggest some corrected typos only; version 4.3 draws more attention to the rewrite of part 1. • A version of 5.0 would suggest a major change of the rules. CPM 4.3 is still an evolution of the Albrecht methodology that forms the basis of all previous IFPUG CPMs. It provides further clarification of the previous version.

January 2010

Function Point Counting Practices Manual

B-3

Appendix B: The Change from Previous Version

Part 5 – Appendices and Glossary

Overview of Changes In addition to replacing the existing Part 1 with the ISO Standard, other minor clarifications have been included in CPM 4.3. To facilitate users who wish to align their existing CPM written in a foreign language, all changes have been listed below.

Part 1: Process and Rules In order for the IFPUG Implementation Guide to be compliant with the revised ISO FSM Standard (ISO/IEC 14143-1:2007), some of the terminology had to be revised. The rules and guidelines are essentially unchanged; however, the sequence of actions and the wording has changed slightly. It is not expected that functional sizes would change. All chapters in Part 1 (now Part 2) include wording changes, additional examples and guidance in order to be consistent and comply with the updated ISO FSM Standard, which was released in 2007 and is now Part 1. The GSCs and Value Adjustment Factor have been removed from this Part and are included in the appendices in order to comply with the ISO FSM Standard, which does not recognize them to be part of the FSM. Additional details are indicated by chapter below. Part 1, Chapter 1: Introduction The title of this chapter has changed to “The Bridge - Applying the IFPUG Functional Size Measurement Method”. Chapter 1 contains only an introduction; the changes reflect the contents of the remaining chapters in the new Part 2. Part 1, Chapter 2: Overview of Function Point Analysis The title of this chapter has changed to “IFPUG FSM Method Overview”. There are extensive wording changes in order to be consistent and comply with the updated ISO FSM Standard. The following definitions and rules have been slightly reworded: The procedural diagram and guidelines in this chapter have been changed to reflect that the first step in the function point counting procedure is to gather the available documentation, in accordance with the ISO FSM Standard. The functional size now represents a size of the software derived by quantifying the functional user requirements replacing the term “unadjusted function points”. Any discussion of “unadjusted” or “adjusted” is now included in the appendices in order to comply with the ISO FSM Standard, which does not recognize the GSCs or VAF to be part of the FSM. Part 1, Chapter 3: User View The title of this chapter has changed to “Gather Available Documentation”. This chapter presents the concept of the user’s role and the approach to sizing during the life cycle of an application; however, virtually all the chapter is unchanged except for the title.

B-4

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix B: The Change from Previous Version

Part 1, Chapter 4: Determine Type of Count The title of this chapter has changed to “Determine Type of Count”. Revised wording has been provided for the definitions of development project function point count, enhancement project function point count and application function point count to be consistent and comply with the updated ISO FSM Standard. Part 1, Chapter 5: Identify Counting Scope and Application Boundary The title of this chapter has changed to “Determine the Counting Scope and Boundary and Identify Functional User Requirements”. There are some minor wording changes to be consistent and comply with the updated ISO FSM Standard, but the great majority of the chapter is unchanged. Part 1, Chapter 6: Count Data Functions The title of this chapter has changed to “Measure Data Functions” to reflect that the rules are actually contained in the new Part 1 and to reflect that this chapter provides implementation guidance for measuring data functions. The rules contained are repeated from Part 1 to make it easier to utilize and to avoid a requirement to flip back and forth between parts. Part 1, Chapter 7: Count Transactional Functions The title of this chapter has changed to “Measure Transactional Functions” to reflect that the rules are actually contained in the new Part 1 and to reflect that this chapter provides implementation guidance for measuring transactional functions. Just as in Chapter 6, the rules contained are repeated from Part 1 to make it easier to utilize and to avoid a requirement to flip back and forth between parts. Specific items include: • Additional guidance and clarification on the FSM rules for elementary processes • Simplified DET and FTR rules Part 1, Chapter 8: Determine Value Adjustment Factor The entire content of this chapter has been moved to Appendix C in order to align the Implementation Guide with the IFPUG FSM which does not include the GSCs and VAF. Part 1, Chapter 9: Calculate Adjusted Function Point Count The formulas previously contained in this chapter have been moved to Appendix C and Part 3 Chapter 4 Enhancement and Maintenance Activity in order to align the Implementation Guide with the IFPUG FSM which does not include the GSCs and VAF.

January 2010

Function Point Counting Practices Manual

B-5

Appendix B: The Change from Previous Version

Part 5 – Appendices and Glossary

Part 2: Counting Practices All chapters in Part 2 (now Part 3) include slight wording changes in order to be consistent with the reorganization of Part 1 and/or to comply with the updated ISO FSM Standard. A new chapter (Chapter 5) was added to provide insight into counting Data Conversion Activity. Additional details are indicated by chapter below. Part 2, Chapter 1: Code Data IFPUG FPA is compliant with this ISO FSM Standard. The decision to not count Code Data and to create the Code Data chapter in Part 2 of CPM 4.2 originated from the requirements in the ISO FSM Standard (ISO/IEC 14143-1:1998) to not count technical and quality requirements. In 2007 ISO released a new version of the FSM Standard (ISO/IEC 14143-1:2007). Consequently, the Code Data chapter needed to be updated to reflect wording changes in the ISO FSM Standard. There are no changes in rules or guidance in this chapter, but there are slight wording changes to comply with the updated ISO FSM Standard. • Added the ISO definition of Functional Size • Updated the definition of Functional User Requirements • Replaced the terms Quality Requirements and Technical Requirements by the ISO term NonFunctional User Requirements and included the ISO definition for this concept • The section Methodology has been slightly reworded to reflect the changes in the step “Identify Logical Files” in Chapter 2: Logical Files below Part 2, Chapter 2: Logical Files This chapter was created in CPM 4.2 to provide counting practices and additional guidance in identifying and assessing the Logical Files. In CPM 4.3, Part 1 has been replaced by the updated IFPUG FPA ISO Standard Some changes to the ISO FSM Standard have a (minor) consequence for the Logical Files chapter: • In the process of identifying Logical Files, the previous step 1 (“Filter Out Code Data Before Assessing Logical Files”) has now become a part of step 1 “Identify Logical Files”, which is a more appropriate place • Furthermore, the previous step 2 (“Identify Logical Files and Classify”) has been decomposed into two steps “1. Identify Logical Files” and “2. Classify Logical Files” • Steps 3 and 4 (identifying RETs and DETs) have been interchanged • The substeps of step 1 have been better visualized by effectively naming them substeps These changes in structure have some (minor) consequences for the structure of the Logical Files chapter.

B-6

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix B: The Change from Previous Version

This is especially true for the interchanging of the steps Identifying DETs and Identifying RETs. That made it necessary to interchange the pages related to these steps. It was also necessary to combine the tables “Considering Record Element Types in Conjunction with Logical Files via Entity (In-)Dependence” (CPM 4.2, page 2-34) and “Considering Data Element Types in Conjunction with Logical Files via Entity (In-)Dependence” (CPM 4.2, page 2-46) into one new table “Considering Data Element Types and Record Element Type below in Conjunction with Logical Files via Entity (In-)Dependence” There are slight wording changes to comply with the updated ISO FSM Standard (ISO/IEC 14143-1:2007) as explained in more detail in the section above, dedicated to Part 2, Chapter 1 Code Data. Quality Requirements and Technical Requirements were replaced by the new ISO term NonFunctional User Requirements. None of these changes in structure and wording are expected to have any influence in the outcome of any counts. Part 2, Chapter 3: Shared Data This chapter was created in CPM 4.2 to provide counting practices and additional guidance in identifying and assessing data shared between applications. The only changes to this chapter were two references to other parts of the CPM which are now different. Part 2, Chapter 4: Enhancement Projects and Maintenance Activities This chapter was created in CPM 4.2 to provide counting practices and additional guidance in applying function point analysis to post development activities. The enhancement project count, first introduced in Part 1, Chapter 9 of CPM 4.1, is now covered entirely (including applicable formulas) in this chapter. In addition to updates for references to other parts of the CPM, the definitions and primary examples for each of the forms of processing logic were set to be consistent with those in the new Part 2. Terms were also made consistent with Parts 1 and 2 such as changing “field” to “attribute”. Specific changes to the Processing Logic section in this chapter include the following: 3. Equivalent Values: Changed the example in response to IFPUG Bulletin Board comments. 4. Data Filtering: Modified existing example to exclude counting a change involving only the substitution or addition of values and added three new examples in response to IFPUG Bulletin Board comments. 11. Prepare and present information outside the boundary: Added three new examples to reflect CPC responses to IFPUG Bulletin Board comments.

January 2010

Function Point Counting Practices Manual

B-7

Appendix B: The Change from Previous Version

Part 5 – Appendices and Glossary

12. Accept information entering the boundary: Added two new examples to reflect CPC responses to IFPUG Bulletin Board comments. 13. Sorting: Added two new examples to reflect CPC responses to IFPUG Bulletin Board comments. In Considerations and Hints, we added discussion regarding deleted functions and moved the hints on GSCs to Appendix C where the optional GSCs and VAF are covered. In the Enhancement vs. Maintenance section, any reference to GSCs has been prefaced with “optional”. Part 2, Chapter 5: Data Conversion Activity (new chapter) This new chapter addresses the functionality to be evaluated when there are requirements to migrate or convert data in conjunction with a new development or enhancement project or to move an application to a different platform. Part 4 of the CPM provides other examples of the data functions and of transactional functions for data conversion.

Part 3: Examples All chapters in Part 3 (now Part 4) included revisions to the rule boxes throughout this section to be consistent with wording changes in the data function, elementary process and transactional function rules. Additional details are indicated by chapter below. Part 3, Chapter 1: Data Function Counting Examples • ILF Example: Audit Data for Inquiries and Reports – Removed references to Employee Security Maintenance from the Data Flow Diagram because it was confusing and wasn’t properly explained • ILF Example: Report Definition – Expanded upon explanation, addressing why Report Definition is not an instance of code data • ILF Example: Shared Application Data – Clarified the example to make it clear that the security described in this example is not application security (i.e., determining what the user can access within the application) • EIF Example: Providing Data to Other Applications – Expanded upon explanation, addressing why Currency Conversion is not an instance of code data • EIF Example: Help Application – Expanded upon explanation, addressing why Help is not an instance of code data; also explained why Window Help and Field Help are separate data functions Part 3, Chapter 2: Transactional Function Counting Examples • EP Example: New Employee/Dependent Data – Expanded upon explanation, addressing why sending the file to the Benefits System is a separate elementary process • EP Example: Batch Employee Data Feed – This new example illustrates that producing batch error reports and statistical reports are not separate elementary processes • EP Example: Assign Employee to Job - This new example illustrates the evaluation of similar elementary processes to determine whether they are unique

B-8

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

• • • • • • • • •

Appendix B: The Change from Previous Version

EP Example: Assign Employee to Job - This new example illustrates two similar Elementary Processes that are counted as unique transactions EI Example: EI with Attributes Retrieved from an EIF – This new example illustrates an EI with attributes retrieved from an EIF that do not cross the boundary EI Example: EI Delete – This new example illustrates counting DETs for a delete transaction EI Example: Add Window Security – This new example illustrates counting functionality to maintain application security EO Example: EO Triggered without Data Entering the Boundary – Renamed this example to eliminate confusion EQ Example: EQ Triggered without Data Entering the Boundary – Renamed this example to eliminate confusion EQ Example: Additional Help Functionality – This new example illustrates counting additional help functionality EQ Example: Security for User Access – This new example illustrates treatment of application security EQ Example: Application Logon – This new example illustrates counting the logon function

Part 4: Appendices and Glossary All chapters in Part 4 (now Part 5) included revisions. Details are indicated by chapter below. Part 4, Appendix A: Calculation Tables Minor wording changes to eliminate use of the term unadjusted. Part 4, Appendix B: The Change from Previous Version This new chapter includes the following: • The major functional change areas in CPM 4.3 • Version control information • An overview of the changes by chapter • The background of the change process • The impact study process • The impact of the changes on 4.3 users • Conversion from CPM 4.2.1 to 4.3 • Recommendations for users changing from 4.2.1 to 4.3 Part 4, Appendix C: Reader Request Form The Reader Request Form was eliminated. Readers can suggest changes by sending an email to the CPC ([email protected]). Appendix C title was changed to Adjusted Functional Size and now contains guidance on applying the General Systems Characteristics and Value Adjustment Factor. It contains all formulas which use the GSCs and VAF.

January 2010

Function Point Counting Practices Manual

B-9

Appendix B: The Change from Previous Version

Part 5 – Appendices and Glossary

Part 4, Glossary The following new terms have been added to the glossary: • • • • • • • • •

Adjusted application functional size (aAFP) Adjusted application functional size after enhancement projects (aAFPA) Adjusted development project functional size (aDFP) Adjusted enhancement project functional size (aEFP) Application functional size Arranging Base functional component Boundary Boundary of the application

• •

Consistent state Development project functional size

•

Enhancement project functional size

•

Functional size

• • • • •

Meaningful Primary Intent Self-contained Sorting Unadjusted functional size

The following terms have been revised in the glossary: • • • • • • • • • • • • • • • • • • •

Adaptive maintenance Adjusted function point count (AFP) * Application Application boundary Application function point count Contribution Control information Conversion functionality Corrective maintenance Counting Scope Derived data Development * Development project function point count (DFP) Enhancement * Enhancement project function point count (EFP) Entity Dependence Entity Independence File system File type referenced (FTR)

• • • • • • • • • • • • • • • • • •

Functional complexity Functional user requirements Function point (FP) Function point analysis Function point count Function type Maintained * Maintenance Multiple sites GSC Perfective maintenance Purpose of the Count Record element type (RET) Technical attribute Transactional functions Unadjusted function point count (UFP) User User recognizable User view

* Denotes entries where the term name was changed (e.g., Adjusted function point count (AFP) became adjusted functional size).

B-10

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix B: The Change from Previous Version

Background The CPC internal decision making process is governed by a set of CPM characteristics (meta rules) selected and voted on by the IFPUG board and the CPC. Those guiding principles in order of importance are: 1. It should be possible to model the correlation of software size (derived using the CPM) with other attributes (e.g., effort, defects, cost, etc.). 2. The CPM contains a consistent set of rules. 3. Function Point Analysis results are consistent between different counters using the CPM. 4. The CPM provides rules on how to size a functional need that is defined and agreed upon by user(s) and IT. 5. Function Point Analysis results using the CPM can be a contributing factor in estimation. 6. The CPM is an Albrecht based method. 7. Function Point Analysis using the CPM is easy. 8. Function Point Analysis using the CPM is fast.

The Impact Study The IFPUG function point analysis (FPA) process and rules are concise and easy to use. To reflect that, and to make the Counting Practices Manual (CPM) even more attractive as a reference manual, the Counting Practices Committee (CPC) restructured CPM 4.3 to comply with ISO formatting Standards. Besides that, release 4.3 contains minor modifications and provides new examples, clarification and enhanced interpretations for existing rules that will further increase inter-counter consistency. To measure the effectiveness of this new version an impact study was performed by 44 Certified Function Point Specialists who had no direct connection with the Counting Practices Committee. These volunteers were asked to count a case study using both CPM 4.2.1 and CPM 4.3. Their results were identical using both versions. These participants counted projects that they had performed under the CPM 4.2.1 rules using the new CPM 4.3. In total over 100 counts including a mix of development, application, enhancement and conversion were considered. The resulting conversion factor was found to be 1.0; i.e., no difference.

Conversion from CPM 4.2 to 4.3 Since existing practices vary, each organization must analyze its own practices to determine how it is impacted. Some organizations may find a conversion factor that is applicable across their portfolio. Others may find that the conversion factor varies across different types of systems, and in some cases systems will need to be recounted.

January 2010

Function Point Counting Practices Manual

B-11

Appendix B: The Change from Previous Version

Part 5 – Appendices and Glossary

Impact on 4.2.1 Users Changing to 4.3 Although an additional certification will not be required for counters for CPM 4.3, the certification tests will be updated for conformance to 4.3.

Recommendations The CPC recommends the following actions for users switching from CPM 4.2 to 4.3: • Update all in-house developed training materials for conformance. • Ensure all counters within your organization have been appropriately trained in the differences between 4.2 and 4.3. • Check all vendor offered training materials for version certification. • Notify anyone in your organization involved with functional size measurements of the change and make the new manual available to them. • Review all counting tools for your users, both automated and manual, for IFPUG 4.3 version certification, if applicable, and modifications to conform to 4.3 counting rules. • If providing services based upon Function Points, ensure the contract wording is reviewed to determine which version of the CPM manual will be used; amend as necessary. • Specify on the documentation for each functional size measurement performed, and with the results, which version of the CPM was used. • Make sure to specify which version of the IFPUG CPM was used for counting when submitting data for benchmarking either to your own benchmark database, the IFPUG Benchmarking committee, or ISBSG. • Update all internal guidelines and other local documents related to 4.2 to version 4.3.

B-12

Function Point Counting Practices Manual

January 2010

Part 5 Appendix C

Appendix C: Adjusted Functional Size Introduction

This chapter explains the General Systems Characteristics (GSCs) and Value Adjustment Factor (VAF). Note: Applying the GSCs, calculating the VAF, and calculating the adjusted functional size is not included in the IFPUG FSM and is considered optional in the IFPUG CPM. However when reporting the functional size that is measured using the IFPUG Method, the size reported is that derived prior to any adjustment. The reported size is in units of FPs. When using sizes reported from other sources, first determine if they have been ‘adjusted’ or are they ‘unadjusted’. Failure to do so could result in errors when comparing or using the two sets of results. Always denote whether the functional size being reported is ‘adjusted’ (aFP) or ‘unadjusted’ (FP).

Contents

This chapter includes the following sections: Topic

January 2010

Page

Steps for Calculating Adjusted Functional Size

C-3

Value Adjustment Factor Determination

C-4

Guidelines to Determine Degree of Influence for GSCs

C-6

Value Adjustment Factor Calculation Table

C-31

Adjusted Development Project Function Point (aDFP)

C-32

Formula: Adjusted Development Project Functional Size (aDFP)

C-32

Example: Adjusted Development Project Functional Size (aDFP)

C-33

Function Point Counting Practices Manual

C-1

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Topic

C-2

Page

Adjusted Enhancement Project Functional Size (aEFP)

C-37

Formula: Adjusted Enhancement Project Functional Size (aEFP)

C-38

Example: Adjusted Enhancement Project Functional Size (aEFP)

C-39

Adjusted Application Functional Size (aAFP)

C-43

Formula: Initial Adjusted Application Functional Size (aAFP)

C-43

Formula: Adjusted Application Functional Size After Enhancement Projects (aAFPA)

C-44

Example: Application Count

C-45

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Steps for Calculating Adjusted Functional Size The following list includes the function point analysis steps introduced in Part 1, extended to provide adjusted functional size. Step

Action

1

Determine the functional size using the rules in Part 1 and the implementation guidance in Part 2.

2

Determine the value adjustment factor in accordance with the guidance in this appendix.

3

Calculate the adjusted functional size in accordance with the formulas in this appendix.

The remainder of this chapter presents the General System Characteristics, the resulting Value Adjustment Factor followed by the formulas to calculate the Adjusted Functional Size. Example calculations are included for each of the three types of function points counts:

January 2010

•

Development project

•

Enhancement project

•

Application

Function Point Counting Practices Manual

C-3

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Value Adjustment Factor Determination The value adjustment factor (VAF) is based on 14 general system characteristics (GSCs) that rate the general functionality of the application being measured. Each characteristic has associated descriptions that help determine the degree of influence of that characteristic. The degree of influence for each characteristic ranges on a scale of zero to five, from no influence to strong influence. The 14 general system characteristics are summarized into the value adjustment factor. When applied, the value adjustment factor adjusts the unadjusted functional size +/-35 percent to produce the adjusted functional size.

Procedures to Determine the VAF The following steps outline the procedures to determine the value adjustment factor. Step 1

Action Evaluate each of the 14 general system characteristics on a scale from zero to five to determine the degree of influence (DI).

2

Add the degrees of influence for all 14 general system characteristics to produce the total degree of influence (TDI).

3

Insert the TDI into the following equation to produce the value adjustment factor. VAF = (TDI * 0.01) + 0.65 For example, the following value adjustment factor is calculated if there are three degrees of influence for each of the 14 GSC descriptions (3*14). VAF = (42 * 0.01) + 0.65 VAF = 1.07

A table to facilitate the calculation is included in this Appendix.

C-4

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

General System Characteristics The general system characteristics are a set of 14 questions that evaluate the overall complexity of the application. The 14 general system characteristics are: 1. Data Communications 2. Distributed Data Processing 3. Performance 4. Heavily Used Configuration 5. Transaction Rate 6. On-line Data Entry 7. End-User Efficiency 8. On-line Update 9. Complex Processing 10. Reusability 11. Installation Ease 12. Operational Ease 13. Multiple Sites 14. Facilitate Change

January 2010

Function Point Counting Practices Manual

C-5

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Degrees of Influence Based on the stated user requirements, each general system characteristic (GSC) must be evaluated in terms of its degree of influence (DI) on a scale of zero to five. Score as 0 1 2 3 4 5

System Influence Not present or no influence Incidental influence Moderate influence Average influence Significant influence Strong influence throughout

Guidelines to Determine Degree of Influence for GSCs Each of the following general system characteristic descriptions includes guidelines to determine the degree of influence. Each guideline contains a definition of the GSC, rules for determining the score, and, in situations where the rule needs further clarification, hints have been provided to help apply the rules consistently across all platforms. Hints are not intended to cover all situations but are meant to provide additional guidance in determining the appropriate score.

C-6

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

1. Data Communications Definition

Data Communications describes the degree to which the application communicates directly with the processor. The data and control information used in the application are sent or received over communication facilities. Devices connected locally to the control unit are considered to use communication facilities. Protocol is a set of conventions that permit the transfer or exchange of information between two systems or devices. All data communication links require some type of protocol.

Score

Hints

Score As 0

Application is pure batch processing or a stand-alone application.

1

Application is batch but has remote data entry or remote printing.

2

Application is batch but has remote data entry and remote printing.

3

Application includes on-line data collection or TP (teleprocessing) front end to a batch process or query system.

4

Application is more than a front-end, but supports only one type of TP communications.

5

Application is more than a front-end, and supports more than one type of TP communications protocol.

Protocol examples include FTP, dial-up, Token Ring, Ethernet, SNA, TCP/IP, IPX/SPX, HTTP, XML, WAP, NTP, ICQ, and NETBEUI. This list should not be considered exhaustive. Hints to Rules 1 and 2

January 2010

Descriptions to Determine Degree of Influence

•

Remote devices might include a 3270 terminal connected to a mainframe computer that allows only simple edits (numeric vs. alpha), or printers connected via parallel port (the user can specify where to direct the output).

•

The entry of data does not involve reading or writing directly to an ILF. Data are entered on-line, but the transactions are stored in a temporary file for batch update of ILF(s) at a later time.

Function Point Counting Practices Manual

C-7

Appendix C: Adjusted Functional Size

Hints to Rule 3

Hints to Rule 4

Hints to Rule 5

Typically

C-8

Part 5 – Appendices and Glossary

•

Simple business rules and minimal edits (e.g., alpha/numeric, range check, required data, etc.) may be performed. When this data is eventually processed by the application, additional edits are performed.

•

The entry of data does not involve reading or writing directly to an ILF. Data are entered on-line, but the transactions are stored in a temporary file for batch update of ILF(s) at a later time.

•

Data for the application is collected and may directly update ILF(s) or be stored for future processing using an input device, which performs edits based on business rules.

•

Only one communication protocol is used. Typically, when this data is processed by the application, no further edits are required.

•

The entry of data involves reading or writing to an ILF.

•

For example, client-server data entry or Internet data entry, but not both.

•

Same as 4, however, data collection is performed using multiple telecommunication protocols.

•

For example, client-server data entry and Internet data entry of the same transaction.

•

Batch applications receive a score of 0 to 3.

•

On-line applications receive a score of 4.

•

Web-based applications receive a score of 4 or 5.

•

Real-time, telecommunication, or process control systems receive a score of 4 or 5.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

2. Distributed Data Processing Definition

Distributed Data Processing describes the degree to which the application transfers data among physical components of the application. Distributed data or processing functions are a characteristic of the application within the boundary.

Score

Hints

January 2010

Score As

Descriptions To Determine Degree of Influence

0

Data is not transferred or processed on another component of the system.

1

Data is prepared for transfer, then is transferred and processed on another component of the system, for user processing.

2

Data is prepared for transfer, then is transferred and processed on another component of the system, not for user processing.

3

Distributed processing and data transfer are on-line and in one direction only.

4

Distributed processing and data transfer are on-line and in both directions.

5

Distributed processing and data transfer are on-line and are dynamically performed on the most appropriate component of the system.

Distributed data processing by definition is not an application that is contained on a central processor, which sends data to other applications. In a distributed environment, the application is viewed as requiring multiple components (hardware) on which certain processing or data resides. A knowledgeable user would usually recognize this configuration. Hints to Rule 0

•

Presentation, processing, and I/O components are all in the same place (i.e., stand-alone applications).

Hints to Rule 1

•

Application downloads data to a user’s client machine, so the user can use Excel or other reporting tools to prepare graphs and perform other analysis.

•

Process that transfers data from mainframe to an external component for user processing. This transfer is performed using a simple protocol such as FTP.

•

Transferred to a user for processing.

Function Point Counting Practices Manual

C-9

Appendix C: Adjusted Functional Size

Hints to Rule 2

Hints to Rule 3

Hints to Rule 4

Hints to Rule 5

Typically

C-10

Part 5 – Appendices and Glossary

•

Process that transfers data from mainframe to mid-tier. For example, processing with SAS-PC.

•

Application sends data to client or server. This data is then processed or used to produce reports, etc. No data or confirmation is sent back to the client or server.

•

Transferred to a component for processing.

•

Data is sent between client and server in one direction only. This data is then processed or used to produce reports, etc. by the receiving application. This data typically includes transactions that update an ILF on the client or server.

•

For example – client-server or web-enabled applications.

•

Data is sent between client and server in either direction. This data is then processed or used to produce reports, etc. by the receiving application. This data typically includes transactions that update an ILF on the client or server.

•

For example - client-server or web-enabled applications.

•

The application runs under an operating system that automatically handles the allocation between components, however, the use of the operating system did not influence the design and implementation of the application.

•

The developer must consider special application software that looks at multiple processors and runs the application on a specific type of processor. This is invisible to the user.

•

The application runs under an operating system that automatically handles the dynamic allocation between components, and the use of the operating system specifically influenced the design and implementation of the application.

•

Many applications, including legacy applications, receive a score of 0.

•

Primitive distributed applications that include batch applications in which data is not transferred on-line receive a score of 1 to 2.

•

Client-server or web-based applications receive a score of 3 to 4.

•

It is uncommon to score 5.

•

There must be multiple servers or processors, each of which would be selected dynamically on the basis of its real-time availability to score 5.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

3. Performance Definition

Performance describes the degree to which response time and throughput performance considerations influenced the application development. Application performance objectives, stated or approved (or implied) by the user, in either response or throughput, influence (or will influence) the design, development, installation, and support of the application. Score As

Score

Hints

January 2010

Descriptions To Determine Degree of Influence

0

No special performance requirements were stated by the user.

1

Performance and design requirements were stated and reviewed but no special actions were required.

2

Response time or throughput is critical during peak hours. No special design for CPU utilization was required. Processing deadline is for the next business cycle.

3

Response time or throughput is critical during all business hours. No special design for CPU utilization was required. Processing deadline requirements with interfacing systems are constraining.

4

In addition, stated user performance requirements are stringent enough to require performance analysis tasks in the design phase.

5

In addition, performance analysis tools were used in the design, development, and/or implementation phases to meet the stated user performance requirements.

•

GSCs 3, 4 and 5 are somewhat related. For this GSC, think in terms of "How fast can we make the application go and how much did/does that impact the design, development, and/or implementation?"

•

The users may require real time access to their data, stating or implying standards for response time and throughput capacity.

•

Response time typically relates to interactive processing; throughput relates to batch processing.

Function Point Counting Practices Manual

C-11

Appendix C: Adjusted Functional Size

Typically

C-12

Part 5 – Appendices and Glossary

•

Batch applications receive a score of 0 to 4.

•

On-line (including interactive client-server or web-enabled) applications receive a score of 0 to 4.

•

Web-based applications receive a score of 4 or 5.

•

Most MIS on-line systems receive a score of 2.

•

Real-time, telecommunication, or process control systems receive a score of 0 to 5.

•

A score of 5 requires the use of performance analysis tools.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

4. Heavily Used Configuration Definition

Heavily Used Configuration describes the degree to which computer resource restrictions influenced the development of the application. A heavily used operational configuration may require special considerations when designing the application. For example, the user wants to run the application on existing or committed equipment that will be heavily used.

Score

Hints

Examples

January 2010

Score As

Descriptions To Determine Degree of Influence

0

No explicit or implicit operational restrictions are included.

1

Operational restrictions do exist, but are less restrictive than a typical application. No special effort is needed to meet the restrictions.

2

Operational restrictions do exist, but are typical for an application. Special effort through controllers or control programs is needed to meet the restrictions.

3

Stated operational restrictions require special constraints on one piece of the application in the central processor or a dedicated processor.

4

Stated operational restrictions require special constraints on the entire application in the central processor or a dedicated processor.

5

In addition, there are special constraints on the application in the distributed components of the system.

•

GSCs 3, 4 and 5 are somewhat related.

•

For this GSC think in terms of "How much does the infrastructure influence the design?"

Examples of operational restrictions may include the following (not an exhaustive list): •

This question indicates that the application must run on a computer that is under-powered and can not adequately handle the new or changed functionality and that somehow the developers can overcome this by developing the application differently.

•

More than one application accessing the same data can create operational restrictions.

•

Application competing for the same resource and technologies with the potential deadlocks must be tuned and constrained to avoid performance degradation.

Function Point Counting Practices Manual

C-13

Appendix C: Adjusted Functional Size

Typically

C-14

Part 5 – Appendices and Glossary

•

Most applications receive a score of 2.

•

Client-server, web-enabled, real-time, telecommunication or process control systems receive a score of 3 to 5, but then you would need either a dedicated processor or multiple processors processing the same transactions and searching for the most expeditious means of processing.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

5. Transaction Rate Definition

Transaction Rate describes the degree to which the rate of business transactions influenced the development of the application. The transaction rate is high, and it influences the design, development, installation, and support of the application. Users may require what they regard as normal response time even during times of peak volume.

Score

Score As 0

No peak transaction period is anticipated.

1

Low transaction rates have minimal effect on the design, development, and installation phases. Average transaction rates have some effect on the design, development, and installation phases.

2

Hints

Typically

January 2010

Descriptions To Determine Degree of Influence

3

High transaction rates affect the design, development, and/or installation phases.

4

High transaction rate(s) stated by the user in the application requirements or service level agreements are high enough to require performance analysis tasks in the design, development, and/or installation phases.

5

High transaction rate(s) stated by the user in the application requirements or service level agreements are high enough to require performance analysis tasks and, in addition, require the use of performance analysis tools in the design, development, and/or installation phases.

•

GSCs 3, 4 and 5 are somewhat related. For this GSC think in terms of "How many transactions can be processed by the application in a given period of time?"

•

Often this score is the same as the score for GSC 3 because transaction rates often influence performance requirements.

•

Batch applications receive a score of 0 to 3.

•

On-line (including interactive client-server or web-enabled) applications receive a score of 0 to 4.

•

Real-time, telecommunication, or process control systems receive a score of 0 to 5.

•

A score of 5 requires the use of performance analysis tools.

Function Point Counting Practices Manual

C-15

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

6. On-line Data Entry Definition

On-line Data Entry describes the degree to which data is entered or retrieved through interactive transactions. On-line User Interface for data entry, control functions, reports, and queries are provided in the application. Score As

Score

Hints

Typically

C-16

Descriptions To Determine Degree of Influence

0

All transactions are processed in batch mode.

1

1% to 7% of transactions are interactive.

2

8% to 15% of transactions are interactive.

3

16% to 23% of transactions are interactive.

4

24% to 30% of transactions are interactive.

5

More than 30% of transactions are interactive.

•

This refers to types of transactions not volumes.

•

For example, if an application has 45 EIs, EOs, and EQs, what percent of the EIs, EOs, and EQs are accomplished via on-line transactions.

•

Batch applications receive a score of 0 to 1.

•

On-line, real-time, telecommunication, or process control systems receive a score of 5.

•

Most contemporary on-line (including interactive client-server or webenabled) applications receive a score of 5.

•

Batch systems with on-line features may have a lot of batch transactions, but there must be at least 71 percent batch to receive a score of less than 5.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

7. End-User Efficiency Definition

End-User Efficiency describes the degree of consideration for human factors and ease of use for the user of the application measured. The on-line functions provided emphasize a design for user efficiency (human factor/user friendliness). The design includes:

January 2010

•

Navigational aids (e.g., function keys, jumps, dynamically generated menus, hyper-links)

•

Menus

•

On-line help and documents

•

Automated cursor movement

•

Scrolling

•

Remote printing (via on-line transmissions)

•

Pre-assigned function keys (e.g., clear screen, request help, clone screen)

•

Batch jobs submitted from on-line transactions

•

Drop down List box

•

Heavy use of reverse video, highlighting, colors, underlining, and other indicators

•

Hard-copy documentation of on-line transactions (e.g., screen print)

•

Mouse interface

•

Pop-up windows

•

Templates and/or defaults

•

Bilingual support (supports two languages: count as four items)

•

Multi-lingual support (supports more than two languages: count as six items)

Function Point Counting Practices Manual

C-17

Appendix C: Adjusted Functional Size

Score As

Score

Hints

Typically

C-18

Part 5 – Appendices and Glossary

Descriptions To Determine Degree of Influence

0

None of the above.

1

One to three of the above.

2

Four to five of the above.

3

Six or more of the above, but there are no specific user requirements related to efficiency.

4

Six or more of the above, and stated requirements for user efficiency are strong enough to require design tasks for human factors to be included.

5

Six or more of the above, and stated requirements for user efficiency are strong enough to require use of special tools and processes in order to demonstrate that the objectives have been achieved.

•

Use a convention of a score of 4 whenever the application is deployed in a GUI environment (unless it scores 5).

•

Usually only software environments that prepare applications for massmarket or non-technical users score 5, and only if they have ergonomics specialists and/or usability studies as part of their process.

•

Pure batch applications receive a score of 0.

•

Character mode user interface receive a score of 1 or possibly a 2.

•

GUI user interface to be used for low volume transactions receive a score of 3.

•

GUI user interface to be used for high volume transactions and most Web Intranet user interfaces receive a score of 4 (requires design tasks for human factors).

•

Web Internet user interfaces receive a score of 5 (requires special tools and processes to demonstrate that the objectives have been achieved).

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

8. On-line Update Definition

On-line Update describes the degree to which internal logical files are updated on-line. The application provides on-line update for the internal logical files. Score As

Score

Hints

Typically

January 2010

Descriptions To Determine Degree of Influence

0

None.

1

On-line update of one to three control files is included. Volume of updating is low and recovery is easy.

2

On-line update of four or more control files is included. Volume of updating is low and recovery is easy.

3

On-line update of major internal logical files is included.

4

In addition, protection against data loss is essential and has been specially designed and programmed in the system.

5

In addition, high volumes bring cost considerations into the recovery process. Highly automated recovery procedures with minimum human intervention are included.

•

On-line update usually requires a keyed file or database.

•

Automatic recovery provided by the operating system counts if it impacts the application.

•

Pure batch applications receive a score of 0.

•

On-line updates of files that modify the way an application processes or validates data receive a score of 1 or 2.

•

On-line updates of user persistent data receive a score of 3.

•

MIS applications receive a score of 3 or less.

•

Most GUI type applications receive a score of 3 or above.

•

Applications which use programmed recovery such as SQL roll back and commit receive a score of 4. Operational/routine backup is not considered protection against data loss.

•

Applications required to recover data, reboot, or perform other selfcontained functions in the event of a system error receive a score of 5. Recovery may require a human to press enter or perform some other minimal function to initiate this process.

Function Point Counting Practices Manual

C-19

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

9. Complex Processing Definition

Score

Hints

C-20

Complex processing describes the degree to which processing logic influenced the development of the application. The following components are present: •

Sensitive control and/or application-specific security processing.

•

Extensive logical processing.

•

Extensive mathematical processing.

•

Much exception processing, resulting in incomplete transactions that must be processed again.

•

Complex processing to handle multiple input/output possibilities.

Score As

Descriptions To Determine Degree of Influence

0

None of the above.

1

Any one of the above.

2

Any two of the above.

3

Any three of the above.

4

Any four of the above.

5

All five of the above.

•

Sensitive control or security process (e.g., individual users would have different access authority to screens where they could view and/or change data) may include special audit processing (audit data would be captured whenever data was viewed and/or changed and reported).

•

Application-specific security processing may include internally developed security processing or use of purchased security packages.

•

Extensive logical processing is Boolean logic (use of ‘AND’, ‘OR’) of greater than average difficulty or a minimum of 4 nested conditional (IF, CASE) statements. Extensive logical processing does not occur in most MIS applications.

•

Extensive mathematical processing is arithmetic that is beyond the capability of a 4-function calculator (add, subtract, multiply, divide). This is usually not present in most MIS applications. However, an engineering application may qualify.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Hints

Typically

January 2010

Appendix C: Adjusted Functional Size

•

Exception processing includes incomplete ATM transactions caused by TP interruption, missing data values, failed validations, or cycle redundancy checks which can be used to recreate lost pieces of data.

•

Multiple input/output possibilities include multi-media, device independence, voice, OCR reading, barcode reading, retinal scanning, and Breathalyzer analysis.

Scoring is not platform dependent.

Function Point Counting Practices Manual

C-21

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

10. Reusability Definition

Reusability describes the degree to which the application and the code in the application have been specifically designed, developed, and supported to be usable in other applications.

Score

Score As 0 1 2 3 4 5

Hints

Hints for Rule 1

Descriptions To Determine Degree of Influence No reusable code. Reusable code is used within the application. Less than 10% of the application code developed is intended for use in more than one application. Ten percent (10%) or more of the application code developed is intended for use in more than one application. The application was specifically packaged and/or documented to ease reuse, and the application is customized at the source code level. The application was specifically packaged and/or documented to ease reuse, and the application is customized for use by means of user parameter maintenance. • •

Hints for Rule 2

•

•

Hints for Rule 5

•

• •

Typically

C-22

A score of 1 is awarded for reusing code regardless of where it was developed. Code developed specifically for reuse within the application and used more than once within the application counts as well as code retrieved from a central library and available for general use. To score 2 or more, the code must be developed for use in more then one application, stored and managed in a central library and be available for general use. Code from one application that is cut and pasted into another application is not considered reuse. The reusable code would be supported by documentation that enables and eases the reuse. Examples of applications customized through use of parameters include PeopleSoft and SAP and would generally receive a score of 5. Reused code may be slightly modified in the receiving application. Examples of reuse include objects or other static code maintained in an object/code library.

Scoring is not platform dependent.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

11. Installation Ease Definition

Installation Ease describes the degree to which conversion from previous environments influenced the development of the application. Conversion and installation ease are characteristics of the application. A conversion and installation plans and/or conversion tools were provided and tested during the system test phase. Score As

Score

Hints

•

•

January 2010

Descriptions To Determine Degree of Influence

0

No special considerations were stated by the user, and no special setup is required for installation.

1

No special considerations were stated by the user, but special setup is required for installation.

2

Conversion and installation requirements were stated by the user, and conversion and installation guides were provided and tested. The impact of conversion on the project is not considered to be important.

3

Conversion and installation requirements were stated by the user, and conversion and installation guides were provided and tested. The impact of conversion on the project is considered to be important.

4

In addition to 2 above, automated conversion and installation tools were provided and tested.

5

In addition to 3 above, automated conversion and installation tools were provided and tested.

Conversion and installation includes converting pre-existing data into new data files, loading files with actual data, or developing special installation software, such as porting. Purchased or developed software must be used in order to take credit for installation and conversion.

Hint for Rule 1

•

Most business applications require some special setup to install the application and receive a score of 1.

Hint for Rule 2

•

If the application has conversion and installation requirements and installation guides were provided, and providing these functions and guides were not on the critical path of the project, score a 2.

Hint for Rule 3

•

If the application has conversion and installation requirements and installation guides were provided, and providing these functions and guides were on the critical path of the project, score a 3.

Function Point Counting Practices Manual

C-23

Appendix C: Adjusted Functional Size

Hint for Rules 4 and 5

Typically

C-24

Part 5 – Appendices and Glossary

•

If the application has conversion and installation requirements and can be installed with no external intervention, score a 4 or 5, depending on the other requirements for the scoring of 2 and 3.

Scoring is not platform dependent.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

12. Operational Ease Definition

Operational Ease describes the degree to which the application attends to operational aspects, such as start-up, back-up, and recovery processes. Operational ease is a characteristic of the application. The application minimizes the need for manual activities, such as tape mounts, paper handling, and direct on-location manual intervention.

Score

Score As 0 1-4

5

Hints

January 2010

Descriptions To Determine Degree of Influence No special operational considerations other than the normal back-up procedures were stated by the user. One, some, or all of the following items apply to the application. Select all that apply. Each item has a point value of one, except as noted otherwise. •

Start-up, back-up, and recovery processes were provided, but human intervention is required.

•

Start-up, back-up, and recovery processes were provided, but no human intervention is required (count as two items)

•

The application minimizes the need for tape mounts and/or remote data access requiring human intervention.

•

The application minimizes the need for paper handling.

The application is designed for unattended operation. Unattended operation means no human intervention is required to operate the system other than to start up or shut down the application. Automatic error recovery is a feature of the application.

Hint to Rule 1-4a

•

Application has the ability to perform start-up, back-up, and recovery; however, human response is required to initiate the function.

Hint to Rule 1-4b

•

Application has the ability to perform start-up, back-up, and recovery; and no human response is required to initiate the function.

Hint to Rule 1-4c

•

The application minimizes the need to access data that is not immediately available.

•

This may include importing data from a distributed processor to the local processor prior to execution to eliminate access delays.

Function Point Counting Practices Manual

C-25

Appendix C: Adjusted Functional Size

Hint to Rule 1-4d

Hint to Rule 5

Typically

C-26

Part 5 – Appendices and Glossary

•

The application has been designed to provide the user with data in a condensed format or via a media other than paper.

•

This could include elimination of detailed printed information or access to on-line reports, inquiries, microfiche, CD, or other such media.

•

A score of 5 is assigned to an application that runs and recovers automatically from errors, on its own – an unattended operation.

•

Unattended operation may include unmanned satellite, nuclear reactor, or air traffic control.

Scoring is not platform dependent.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

13. Multiple Sites Definition

Multiple Sites describes the degree to which the application has been developed for different hardware and software environments.

Score

Score As

Hints

0

The needs of only one installation site were considered in the design.

1

The needs of more than one installation site were considered in the design, and the application is designed to operate only under identical hardware and software environments.

2

The needs of more than one installation site were considered in the design, and the application is designed to operate only under similar hardware and/or software environments.

3

The needs of more than one installation site were considered in the design, and the application is designed to operate under different hardware and/or software environments.

4

Documentation and support plans are provided and tested to support the application at multiple installation sites and the application is as described by 2.

5

Documentation and support plans are provided and tested to support the application at multiple installation sites and the application is as described by 3.

The term multiple sites is a logical term and is not necessarily physical. There can be multiple sites within the same physical location. The determining factor is based upon the needs of the various installations. •

Most mainframe applications would probably score 0.

•

However, if an application is installed on multiple mainframe computers with significantly different configurations or different operating systems, it would receive a score of greater than 0.

Hints for Rule 1

•

For example, Windows NT on hardware with exactly the same configuration.

Hints for Rule 2

•

For example, Windows 95, 98 and NT on hardware with a similar configuration.

•

Variations could include different memory sizes, various storage capability, different processor speeds, and different printer types.

Hints for Rule 0

January 2010

Descriptions To Determine Degree of Influence

Function Point Counting Practices Manual

C-27

Appendix C: Adjusted Functional Size

Hints for Rule 3

Typically

C-28

Part 5 – Appendices and Glossary

•

For example, Windows, OS X, UNIX, Linux, and VOS3 on different types of hardware.

•

Differences could include Intel based PC, MAC, Tandem, Sun, and AS400.

Scoring is dependent on the number of different platforms.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

14. Facilitate Change Definition

Facilitate Change describes the degree to which the application has been developed for easy modification of processing logic or data structure. The following characteristics can apply for the application: A. Flexible Query 1. Flexible query and report facility is provided that can handle simple requests. (count as 1 item) 2. Flexible query and report facility is provided that can handle requests of average complexity. (count as 2 items) 3. Flexible query and report facility is provided that can handle complex requests. (count as 3 items) B. Business Control Data 1. Business control data is kept in tables that are maintained by the user with on-line interactive processes, but changes take effect only on the next business cycle. (count as 1 item) 2. Business control data is kept in tables that are maintained by the user with on-line interactive processes, and the changes take effect immediately. (count as 2 items)

Score

Hints

January 2010

Score As

Descriptions To Determine Degree of Influence

0

None of the above.

1

A total of one item from above.

2

A total of two items from above.

3

A total of three items from above.

4

A total of four items from above.

5

A total of five items from above.

Flexible Query and Reporting: •

A flexible query and reporting facility means more than a list of choices in a ‘canned’ query or report.

•

It is the ability of the user to control the data, data source, sequence and format of their query or report request.

Function Point Counting Practices Manual

C-29

Appendix C: Adjusted Functional Size

Hints

Part 5 – Appendices and Glossary

•

It means freedom to design screen layout, horizontal and vertical sorting, data item display formats, selection criteria for both files and data items.

•

It includes true user programming for inquiries and is sometimes referred to as ad hoc query or reporting.

•

Using filters which control the amount of data viewed or printed in a fixed format is not considered to be a flexible query and report facility.

•

Query and/or report writer capability is often provided by languages such as SQL or Focus or by some of the more dynamic ad hoc reporting tools (e.g., Crystal Reports).

Hint for Rule A1

•

Simple requests may include and/or logic applied to only one internal logical file.

Hint for Rule A2

•

Requests of average complexity may include and/or logic applied to more than one internal logical file.

Hint for Rule A3

•

Complex requests may include and/or logic combinations on one or more internal logic files.

Business Control Data:

Typically

C-30

•

Business Control Data (Reference Data) is stored to support the business rules for the maintenance of the Business Data; e.g., in a payroll application it would be the data stored on the government tax rates for each wage scale and the date the tax rate became effective.

•

See Part 2, Code Data for additional information.

Scoring is not platform dependent.

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Value Adjustment Factor Calculation Table The following table is provided to facilitate the calculation of the value adjustment factor. General System Characteristics (GSCs) 1.

Data Communications

2.

Distributed Data Processing

3.

Performance

4.

Heavily Used Configuration

5.

Transaction Rate

6.

On-line Data Entry

7.

End-User Efficiency

8.

On-line Update

9.

Complex Processing

Degree of Influence (DI) 0 - 5

10. Reusability 11. Installation Ease 12. Operational Ease 13. Multiple Sites 14. Facilitate Change Total Degree of Influence (TDI) Value Adjustment Factor (VAF) VAF = (TDI * 0.01) + 0.65

January 2010

Function Point Counting Practices Manual

C-31

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Adjusted Development Project Function Point (aDFP) Application Functionality Application functionality consists of functions used after software installation to satisfy the ongoing business needs of the user.

Conversion Functionality Conversion functionality consists of functions provided only at installation to convert data and/or provide other user-specified conversion requirements, such as special conversion reports. For example, if a Human Resources (HR) software application was in use and a new HR application is installed, the users may require that information about employees be converted and loaded into the new application. The userspecified conversion requirement is to transfer the current employee data into the new HR system.

Application Value Adjustment Factor The value adjustment factor is determined by using the 14 general system characteristics to rate the application functional complexity.

Formula: Adjusted Development Project Functional Size (aDFP) Use the following formula to calculate the adjusted development project functional size. aDFP = DFP * VAF Where: aDFP is the adjusted development project functional size DFP is the development project functional size (DFP = ADD + CFP; see Part 1) VAF is the value adjustment factor Note: After software installation, the application functional size is calculated using components of the development project functional size.

C-32

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Example: Adjusted Development Project Functional Size (aDFP) This section shows an example of a development project. The project includes both application and conversion functionality. Note: The following is meant to be only an example and is not specifically related to other sections of this manual. All related functionality may not be included (e.g., there may be missing functions). Application Functionality The following tables show the application functionality measured for a development project. Data Functions

RETs

DETs

Functional Complexity

Internal Logical Files •

Job information

2

5

Low

•

Suspended jobs

2

6

Low

•

Report definition

1

4

Low

•

Employee information

1

6

Low

External Interface Files

January 2010

•

Location information

1

6

Low

•

Conversion information

1

2

Low

•

Window help information

1

2

Low

•

Field help information

1

5

Low

Function Point Counting Practices Manual

C-33

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

FTRs

DETs

Functional Complexity

Assignment report definition

1

5

Low

Add job information (screen input)

1

7

Low

Add job information (batch input)

2

6

Average

Correct suspended jobs

1

7

Low

Employee job assignment

3

7

High

EI with screen output –1

2

11

Average

EI with screen output –2

1

6

Low

External Outputs Jobs with employees report

4

5

Average

Employees by assignment duration report

3

7

Average

Performance review notification

3

4

Low

Weekly employees report

1

3

Low

Printed check

1

3

Low

Check transaction file

1

4

Low

List of retrieved data

1

4

Low

Bargaining Unit

1

2

Low

Field level help

1

6

Low

Weekly membership report

1

3

Low

Daily check file

1

2

Low

Transactional Functions External Inputs

External Inquiries

Conversion Functionality The following table shows the conversion functionality for the development project.

Transactional Function

FTRs

DETs

Functional Complexity

1

11

Low

External Input Employee migration

C-34

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Application Contribution to the Functional Size The following table shows the contribution to the unadjusted functional size.

Function Type ILFs

Functional Complexity

Complexity Totals

4

Low

X7=

28

0

Average

X 10 =

0

0

High

X 15 =

0

Function Type Totals

28 EIFs

4

Low

X5=

20

0

Average

X7=

0

0

High

X 10 =

0 20

EIs

4

Low

X3=

12

2

Average

X4=

8

1

High

X6=

6 26

EOs

4

Low

X 4=

16

2

Average

X5=

10

0

High

X7=

0 26

EQs

5

Low

X 3=

15

0

Average

X4=

0

0

High

X 6=

0 15

ADD 115

January 2010

Function Point Counting Practices Manual

C-35

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Conversion Contribution to the Functional Size The following table shows the contribution of the conversion functionality to the functional size.

Function Type EIs

Functional Complexity

Complexity Totals

1

Low

X3=

3

0

Average

X4=

0

0

High

X6=

0

Function Type Totals

CFP 3

Final Calculation Using the complexity and contribution counts for this example, the adjusted development project size is shown below. The value adjustment factor for this example is 1.05. aDFP = (ADD + CFP) * VAF aDFP = (115 + 3) * 1.05 aDFP = 123.9 or 124

C-36

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Adjusted Enhancement Project Functional Size (aEFP) The adjusted enhancement project functional size consists of three components: •

Application functionality included in the user requirements for the project

•

Conversion functionality included in the user requirements for the project

•

Application value adjustment factor

Enhancement Project GSC Considerations The optional 14 General System Characteristics (GSCs), defined in this appendix, should be reviewed for change. Small enhancements do not normally require such a review. Examples of changes that may indicate a need to review the GSCs include: •

Addition of on-line functions to a batch application

•

Increased transaction volumes and/or degraded response times now requiring performance design and testing activities

•

Additional usability features requested

•

Addition of a Web interface to an existing on-line application

•

Addition of a new communication protocol to an existing application

Application Functionality Application functionality consists of: •

Function points identified from the functionality that is added by the enhancements

•

Function points measured because existing functionality is changed during the enhancement project

•

Function points measured for functionality deleted during the enhancement project

Conversion Functionality The conversion functionality consists of function points delivered because of any conversion functionality required by the user.

January 2010

Function Point Counting Practices Manual

C-37

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Value Adjustment Factor The two value adjustment factors are the: •

Application value adjustment factor before the enhancement project begins

•

Application value adjustment factor after the enhancement project is complete

Formula: Adjusted Enhancement Project Functional Size (aEFP) Use the following formula to calculate the adjusted enhancement project functional size. Note: Data conversion requirements are included in this calculation. aEFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) Where: aEFP is the adjusted enhancement project functional size ADD is the size of the functions being added by the enhancement project CHGA is the size of the functions being changed by the enhancement project – as they are / will be after implementation CFP is the size of the conversion functionality VAFA is the value adjustment factor of the application after the enhancement project is complete DEL is the size of the functions being deleted by the enhancement project VAFB is the value adjustment factor of the application before the enhancement project begins Note: When an enhancement project is installed, the application functional size must be updated to reflect changes in the application's functionality.

C-38

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Example: Adjusted Enhancement Project Functional Size (aEFP) This section shows an example for a sample enhancement project. The requirements for the enhancement project include the following changes: •

The user no longer needs to add a job online, therefore, that functionality is to be or was removed.

•

The user needs to receive an additional report about jobs that includes totals.

•

Additional DETs are required to add jobs in batch and correct suspended transactions. A reference to government security clearances (an additional FTR) is also added for the add job transaction.

Application Functionality The following paragraphs explain the application functionality counted for the example enhancement project. Functionality is described as added, changed, or deleted. Added Functionality

The following table shows the functional complexity for the added functionality that is measured when the project was completed. Note: Providing a new report was an additional external output.

Transactional Functions

FTRs

DETs

Functional Complexity

1

15

Low

External Output Job report Changed Functionality

The following table shows the functional complexity for the changed functionality, as the functions will exist after the enhancement project is completed. Note: The complexity for adding a job was increased because of the additional file type referenced. The complexity for correcting suspended transactions remained low.

January 2010

Function Point Counting Practices Manual

C-39

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

After

Transactional Functions

FTRs

DETs

Functional Complexity

External Input Add job information (batch input)

3

8

High

Correct suspended transaction

1

8

Low

Transactional Functions

FTRs

DETs

Functional Complexity

External Input Add job information (batch input)

2

6

Average

Correct suspended transaction

1

7

Low

Before

Deleted Functionality

The following table shows the functional complexity for deleted functionality identified at the end of the project.

C-40

Transactional Functions

FTRs

DETs

Functional Complexity

External Inputs Add job information (screen input)

1

7

Low

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Application Contribution to the Functional Size The following paragraphs explain the application functionality contribution to the total unadjusted functional size. Added Functionality

The following table shows the contribution to the functional size for the added functionality identified at the end of the project. Function Type EOs

Functional Complexity

Complexity Totals

1

Low

X 4=

4

0

Average

X5=

0

0

High

X7=

0

Function Type Totals

ADD 4

Changed Functionality

The following table shows the contribution to the functional size for the changed functionality as it will exist after the enhancement project is complete. After Function Type EIs

Functional Complexity

Complexity Totals

1

Low

X3=

3

0

Average

X4=

0

1

High

X6=

6

Function Type Totals

CHGA 9

Before Function Type EIs

Functional Complexity

Complexity Totals

1

Low

X3=

3

1

Average

X4=

4

0

High

X6=

0

Function Type Totals

CHGB 7

January 2010

Function Point Counting Practices Manual

C-41

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Deleted Functionality

The following table shows the contribution to the functional size for the deleted functionality.

Function Type EIs

Functional Complexity

Complexity Totals

1

Low

X3=

3

0

Average

X4=

0

0

High

X6=

0

Function Type Totals

DEL 3

Final Calculation The application value adjustment factor was 1.05 before the project began. The value adjustment factor remained the same after the project was completed. Using the complexity and contribution counts for this example, the adjusted enhancement project functional size is shown below. aEFP = [(ADD + CHGA + CFP) * VAFA] + (DEL* VAFB) aEFP = [(4 + 9 + 0) * 1.05] + (3 * 1.05) aEFP = 16.8 or 17

C-42

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Adjusted Application Functional Size (aAFP) This section provides the formulas to calculate the adjusted application functional size. There are two variations of this formula: •

Formula to establish the initial adjusted functional size for an application

•

Formula to re-establish the adjusted functional size for an application after an enhancement project has changed the application functionality

Formula: Initial Adjusted Application Functional Size (aAFP) Use the formula in this section to establish the initial adjusted functional size for an application. Initially, the user is receiving new functionality. There are no changes to the existing functionality or deletions of obsolete or unneeded functionality. The adjusted application functional size does not include conversion requirements. aAFP = ADD * VAF Where: aAFP is the initial adjusted application functional size ADD is the size of the functions by the development project to be delivered to the user or the functionality that exists whenever the application is measured. VAF is the value adjustment factor of the application.

January 2010

Function Point Counting Practices Manual

C-43

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

Formula: Adjusted Application Functional Size After Enhancement Projects (aAFPA) When an enhancement project is installed, the existing application functional size must be updated to reflect modifications to the application. The functionality for the application can be altered in one or more ways: •

Added (new) functionality increases the size of the application

•

Changed functionality increases, decreases, or has no effect on the size of the application

•

Deleted functionality decreases the application size

•

Changes to the value adjustment factor increase or decrease the application size

Note: Because conversion functionality does not affect the adjusted application functional size, any conversion functionality associated with an enhancement project is omitted entirely from the adjusted application functional size calculation. Use the following formula to calculate the adjusted application functional size after an enhancement project: aAFPA = [(AFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA Where: aAFPA is the adjusted application functional size after the enhancement project AFPB is the application functional size before the enhancement project begins ADD is the size of the functions being added by the enhancement project. CHGA is the size of the functions being changed by the enhancement project – as they are / will be after implementation CHGB is the size of the functions being changed by the enhancement project – as they are / were before the project commenced DEL is the size of the functions being deleted by the enhancement project. VAFA is the value adjustment factor of the application after the enhancement project is complete.

C-44

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

Appendix C: Adjusted Functional Size

Note: If the AFPB is unavailable, it can be calculated using the formula AFPB = aAFPB/VAFB; where aAFPB is the adjusted application functional size before the enhancement project and VAFB is the value adjustment factor of the application before the enhancement project.

Example: Application Count This section shows an example for the initial adjusted functional size and the adjusted functional size that reflects an enhancement project. Numbers for these functional size measurements are from the application example earlier in this appendix. Initial Adjusted Application Functional Size (aAFP) The initial adjusted application functional size is shown below. The value adjustment factor is 1.05. aAFP = ADD * VAF aAFP = 115 * 1.05 aAFP = 120.75 or 121 Note: Only the size of the application functionality installed for the user is included in the initial size. Adjusted Application Functional Size After (aAFPA) The adjusted application project functional size to reflect enhancements is shown below. The value adjustment factor is 1.05. aAFPA = [(AFPB + ADD + CHGA) - (CHGB + DEL)]* VAFA aAFPA = [(115 + 4 + 9) - (7 + 3)]* 1.05 aAFPA = 123.9 or 124

January 2010

Function Point Counting Practices Manual

C-45

Appendix C: Adjusted Functional Size

Part 5 – Appendices and Glossary

This page intentionally left blank.

C-46

Function Point Counting Practices Manual

January 2010

Part 5 IFPUG Glossary

IFPUG Glossary This is a comprehensive glossary of terms used across IFPUG publications.

Adaptive maintenance. The modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment. Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which a software product must operate. These changes are those that must be made to keep pace with the changing environment. For example, the operating system might be upgraded and some changes may be made to accommodate the new operating system. (ISO/IEC 14764:2006) Adjusted functional size. The adjusted functional size is the result of the unadjusted functional size multiplied by the value adjustment factor. The adjusted functional size is calculated using a specific formula for development project, enhancement project, and application, which is illustrated in Appendix C. Adjusted application functional size (aAFP). See Appendix C for the formula. Adjusted application functional size after enhancement projects (aAFPA). See Appendix C for the formula. Adjusted development project functional size (aDFP). See Appendix C for the formula. Adjusted enhancement project functional size (aEFP). See Appendix C for the formula. Albrecht 1984. Original document of the function point concept, written by Allan J. Albrecht in November 1984. Also known as "313" from its document number.

January 2010

Application. An application is a cohesive collection of automated procedures and data supporting a business objective; it consists of one or more components, modules, or subsystems. Application area. A general term for a grouping of applications that handle a specific business area. It corresponds to an administrative level for management purposes. Application area level. The management level responsible for managing maintenance activities as well as new development or major enhancement projects for one or more applications. Application boundary. See Boundary. Application functional size. An application’s functional size is a measure of the functionality that an application provides to the user, determined by the application function point count by the activity of applying the IFPUG Functional Size Measurement (FSM) Method. See Part 1, Section 5.8 for the formula. Application function point count. Activity of applying the IFPUG Functional Size Measurement (FSM) Method to measure the functional size of an application. Application manager. A person responsible for managing projects and support activities for one or more application areas. Arranging. The activity of sequencing attributes in a transactional function. Asset. (1) A capital asset of the enterprise. (2) An advantage or resource.

Function Point Counting Practices Manual

G-1

IFPUG Glossary

Part 5 – Appendices and Glossary

Associative entity type. An entity type that contains attributes which further describe a many-tomany relationship between two other entity types. Attribute. See Project/application attribute and Data attribute. Attributive entity type. An entity type that further describes one or more characteristics of another entity type. Base functional component (BFC) . Elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes. (ISO/IEC 14143-1:2007) ILFs, EIFs, EIs, EOs, EQs are types of BFCs. Baseline function point count. See Application function point count. Boundary. The boundary is a conceptual interface between the software under study and its users. Boundary of application. See Boundary. Budget. A planned sequence of expenditures over time with monetary costs assigned to specific tasks or jobs. Often used also to refer to work effort as well as, or instead of, money. Business data. May also be referred to as Core User Data or Business Objects. This type of data reflects the information needed to be stored and retrieved by the functional area addressed by the application. Business Data usually represents a significant percentage of the entities identified. Capital expenditure. A form of spending in which an enterprise trades money (capital) for acquisition of tangible objects such as furniture, computers, and the like. Code data. The user does not always directly specify Code Data, sometimes referred to as List Data or Translation Data. In other cases it is identified by the developer in response to one or more technical requirements of the user. Code Data provides a list of valid values that a descriptive attribute may have. Typically the attributes of the Code Data are Code, Description and/or other ‘standard’ attributes describing the code; e.g., standard abbreviation, effective date, termination date, audit trail data, etc.

Copy. (1) To read data from a source, leaving the source data unchanged, and to write the same data elsewhere in a physical form that may differ from that of the source. For example, to copy data from a magnetic disk onto a magnetic tape. (2) The result of a copy process as in above. For example, a copy of a data file. (IEEE) Complex processing GSC. One of the 14 general system characteristics describing the degree to which processing logic influences the development of the application. Consistent state. The point at which processing has been fully executed; the functional user requirement has been satisfied and there is nothing more to be done. Contribution. The function type's (ILF, EIF, EI, EO, EQ) contribution to the functional size. Control information. Control Information is data that influences an elementary process by specifying what, when or how data is to be processed. Conversion functionality. Transactional or data functions provided to convert data and/or provide other user specified conversion requirements. Corporate executive level. The management level responsible for the enterprise, including the Board of Directors. Corrective maintenance. The reactive modification of a software product performed after delivery to correct discovered problems. The modification repairs the software product to satisfy requirements. (ISO/IEC 14764:2006) Counting Practices Committee (CPC). The working committee that maintains the IFPUG Counting Practices Manual. Counting scope. The counting scope defines the set of Functional User Requirements to be included in the function point count. Data attribute. A characteristic of an entity. Data attributes are generally analogous to data element types (DETs). Also known as field. Data communications GSC. One of the 14 general system characteristics describing the degree to which the application communicates directly with the processor. Data element type (DET). A data element type is a unique, user recognizable, non-repeated attribute.

G-2

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

IFPUG Glossary

Data entity. See Entity. Data function. A data function represents functionality provided to the user to meet internal and external data storage requirements. A data function is either an internal logical file or an external interface file. Defect. A problem which, if not corrected, could cause an application to either fail or to produce incorrect results. The absence of functionality that was specified or required is also considered a defect. Defect removal. See Repair. Degree of influence (DI). A numerical indicator of the amount of impact of each of the 14 general system characteristics, ranging from zero to five. These indicators are used to compute the value adjustment factor. Delivery rate. The productivity measure for creating or enhancing an application. It is expressed by the Project Function Points divided by the Work Effort for the development or enhancement project. Derived data. Data created as a result of processing that involves steps, other than or in addition to, direct retrieval and validation of information from data functions. Development project. A development project is a project to develop and deliver the first release of a software application. Development project functional size. The development project functional size is a measure of the functionality provided to the users with the first release of the software, as measured by the development project function point count by the activity of applying the IFPUG Functional Size Measurement (FSM) Method. See Part 1, Section 5.8 for the formula. Development project function point count. The activity of applying the IFPUG Functional Size Measurement (FSM) Method to measure the functional size of a development project. Distributed data processing GSC. One of the 14 general system characteristics describing the degree to which the application transfers data among physical components of the application. Effectiveness. Producing the intended or desired result. Efficiency. Producing a result with a minimum of extraneous or redundant effort.

January 2010

Elementary process (EP). An elementary process is the smallest unit of activity that is meaningful to the user. End-user efficiency GSC. One of the 14 general system characteristics describing the degree of consideration for human factors and ease of use for the user of the application measured. Enhancement project. An enhancement project is a project to develop and deliver adaptive maintenance. Enhancement project functional size. The enhancement project functional size is a measure of the functionality added, changed or deleted at the completion of an enhancement project, as measured by the enhancement project function point count by the activity of applying the IFPUG Functional Size Measurement (FSM) Method. See Part 1, Section 5.8 for the formula. Enhancement project function point count. The activity of applying the IFPUG Functional Size Measurement (FSM) Method to measure of the functional size of an enhancement project. Entity (or entity type). A fundamental thing of relevance to the user, about which a collection of facts is kept. An association between entities that contains attributes is itself an entity. Entity dependent. An entity that is not meaningful or is not significant to the business, in and of itself without the presence of other entities such that •

an occurrence of entity X must be linked to an occurrence of entity Y

•

the deletion of an occurrence of entity Y results in the deletion of all related occurrences of entity X.

Entity independent. An entity that is meaningful or significant to the business, in and of itself without the presence of other entities. Entity subtype. A subdivision of entity type. A subtype inherits all the attributes and relationships of its parent entity type, and may have additional, unique attributes and relationships. External input (EI). An external input (EI) is an elementary process that processes data or control information sent from outside the boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.

Function Point Counting Practices Manual

G-3

IFPUG Glossary

Part 5 – Appendices and Glossary

External inquiry (EQ). An external inquiry (EQ) is an elementary process that sends data or control information outside the boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information. The processing logic contains no mathematical formula or calculation, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered.

First normal form. Result of a normalization process that transforms groups of data so they have a unique identifier, one or more attributes, and no repeating attributes.

External interface file (EIF). An external interface file (EIF) is a user recognizable group of logically related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application measured. This means an EIF counted for an application must be in an ILF in another application.

Functional complexity. The specific complexity rating assigned to a function using the rules as defined within this International Standard.

External output (EO). An external output (EO) is an elementary process that sends data or control information outside the application’s boundary and includes additional processing beyond that of an external inquiry. The primary intent of an external output is to present information to a user through processing logic other than or in addition to the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs, and/or alter the behavior of the system. Facilitate change GSC. One of the 14 general system characteristics describing the degree to which the application has been developed for easy modification of processing logic or data structure. Field. See Data attribute. File. For data functions, a logically related group of data, not the physical implementation of those groups of data. File system. Is composed of records and data attributes. File type referenced (FTR). A file type referenced is a data function read and/or maintained by a transactional function.

Foreign key. Data in an ILF or EIF that exists because the user requires a relationship with another ILF or EIF. Function. The features or capabilities of an application as seen by the user.

Functional size. Size of the software derived by quantifying the functional user requirements. (ISO 14143-1:2007) Functional user requirements. A sub-set of the user requirements specifying what the software shall do in terms of tasks and services. (ISO 14143-1:2007) Functionality. See Function. Function point (FP). The unit of measure for functional size as defined within the IFPUG Functional Size Measurement (FSM) Method. Function point analysis. The method for measuring functional size as defined within the IFPUG Functional Size Measurement (FSM) Method. Function point count. The activity of applying the rules within the IFPUG Functional Size Measurement (FSM) Method to measure the functional size of an application or project. NOTE: There are three types of function point counts: application, development project and enhancement project. Function type. The five base functional components identified in the IFPUG Functional Size Measurement (FSM) Method. NOTE: The five function types are: External Input, External Output, External Inquiry, Internal Logical File and External Interface File. Also known as Base functional component. General system characteristics (GSCs). The general system characteristics are a set of 14 questions that evaluate the overall complexity of the application. Heavily used configuration GSC. One of the 14 general system characteristics describing the degree to which computer resource restrictions influenced the development of the application. IBM CIS & A Guideline 313. See Albrecht 1984.

G-4

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

IFPUG Glossary

IFPUG. The International Function Point Users Group is a membership governed, non-profit organization committed to promoting and supporting function point analysis and other software measurement techniques.

Measure. As a noun, a number that assigns relative value. Some examples may include volume, height, function points, or work effort. As a verb, to ascertain or appraise by comparing to a standard.

Image. An exact replication of another object, file, or table that is usually created through a utility.

Measurement. Assigning relative value. Usually, in the improvement process, measures gained from this activity are combined to form metrics.

Installation ease GSC. One of the 14 general system characteristics describing the degree to which conversion from previous environments influenced the development of the application.

Media/Medium. A channel of communication or information, for example, a report issued on paper or in microfiche.

Installed function point count. See Application function point count.

Merge. Multiple files with the same data elements consolidated into a single file. (IEEE)

Internal logical file (ILF). An internal logical file (ILF) is a user recognizable group of logically related data or control information maintained within the boundary of the application being measured. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being measured.

Metric. There is no single universal definition of a metric. In the context of this document, a metric is a combination of two or more measures or attributes. Examples include (1) defect density (defects per function point) and (2) delivery rates (function points per hour).

Load. To copy computer instructions or data from external storage to internal storage. (IEEE) Logical file. See Data function. Maintain. The term maintain refers to the ability to add, change or delete data through an elementary process. Maintenance. The effort to keep an application performing according to its specifications, generally without changing its functionality (or functional size). Maintenance includes repair, minor enhancement, conversion, user support and preventive maintenance activities. Activities include defect removal (see repair), hardware or software upgrades (see conversion), optimization or quality improvement (see preventive maintenance), and user support. Maintenance (support) rate. The productivity measure for maintaining an application. It is expressed as the Work Effort by category of maintenance divided by 1000 Application Function Points in a period of time. Mandatory subgroup. One of the two types of subgroups for record element types (RETs). Mandatory subgroups mean the user must use one of the subgroups during an elementary process that creates an instance of the data. Meaningful. Is user recognizable and satisfies a Functional User Requirement.

January 2010

Multiple sites GSC. One of the 14 general system characteristics describing the degree to which the application has been developed for different hardware and software environments. NESMA. The Netherlands Software Metrics Association (www.nesma.org). A membership governed, non-profit organization in the Netherlands, committed to promoting and supporting function point analysis and other software measurement methods. Normalization. The process by which any data structure can be transformed by a database designer into a set of normalized relations that have no repeating groups. Online data entry GSC. One of the 14 general system characteristics describing the degree to which data is entered or retrieved through interactive transactions. Online update GSC. One of the 14 general system characteristics describing the degree to which internal logical files are updated online. Operational ease GSC. One of the 14 general system characteristics describing the degree to which the application attends to operational aspects, such as, start-up, back-up, and recovery processes. Optional subgroup. Optional subgroups are those that the user has the option of using one or none of the subgroups during an elementary process that adds or creates an instance or the data.

Function Point Counting Practices Manual

G-5

IFPUG Glossary

Part 5 – Appendices and Glossary

Organization level. The management level or levels responsible for managing one or more data processing or information systems organizations. Perfective maintenance. Modification of a software product after delivery to detect and correct latent faults in the software product before they are manifested as failures. Perfective maintenance provides enhancements for users, improvement of program documentation, and recoding to improve software performance, maintainability, or other software attributes. Contrast with: adaptive maintenance; corrective maintenance. (ISO/IEC 14764:2006) Performance GSC. One of the 14 general system characteristics describing the degree to which response time and throughput performance considerations influenced the application development. Preventive maintenance. Changes to hardware or software performed to prevent future defects or failures. For example, restructuring programs or data to improve maintainability or to prevent defects. Primary intent. Intent that is first in importance. Process measures. Information captured about the development process. Processing logic. Any of the requirements specifically requested by the user to complete an elementary process such as validations, algorithms or calculations and reading or maintaining a data function. Product measures. Information captured about the developed software application. Productivity. The ratio of work product to work effort. See also Delivery rate. Project. A collection of work tasks with a time frame and a work product to be delivered. Project/application attribute. Characteristics of a project or an application that may have a significant impact on productivity. Examples include hardware platform, personnel experience, tools, and methodology. The project/application attribute is used to categorize project data during analysis. Project leader. A person who manages or leads projects. May be a synonym for Project Manager.

G-6

Project level. The management level responsible for managing individual new development or major enhancement projects. Project manager. A person who manages one or more projects or groups of projects. Purpose of the count. The reason for performing the function point count. Quality. Quality includes: conformity to user expectations, conformity to user requirements, customer satisfaction, reliability, level of defects present. Context and policy will decide the best definition for a given situation. Quality requirements. Any requirements relating to software quality as defined in ISO/IEC 9126:1991. Ratio. In the context of this document, ratio is defined as the result of dividing one measured quantity by another. Record. A group of related items that is treated as a unit. Record element type (RET). A record element type (RET) is a user recognizable sub-group of data element types within a data function. RECUP. Acronym for Repair/Enhancement/ Conversion/User support/Prevention. See also Maintenance (support) rate. Reference data. This type of data is stored to support the business rules for the maintenance of the Business Data; e.g., in a payroll application it would be the data stored on the government tax rates for each wage scale and the date the tax rate became effective. Reference Data usually represents a small percentage of entities identified. Refresh. The process of recreating a set of data to make it current with its source. Relationship. An association of interest between two entities. A relationship does not have attributes and does not count as a RET when counting function points. Release. A delivered version of an application which may include all or part of an application. Repair. The correction of defects that have resulted from errors in external design, internal design, or code. Examples are missing functions that do not result in application failure (external design error) or errors resulting in a stop-run situation (code error).

Function Point Counting Practices Manual

January 2010

Part 5 – Appendices and Glossary

IFPUG Glossary

Reusability GSC. One of the 14 general system characteristics describing the degree to which the application and the code in the application have been specifically designed, developed, and supported to be usable in other applications. Scope creep/gallop. Additional functionality that was not specified in the original requirements, but is identified as the scope is being clarified and the functions defined. Second normal form. Result of a normalization process that transforms groups of data so that each non-key attribute depends on the key attribute(s) of the group of data and all parts of the key attribute(s). Self-contained. No prior or subsequent processing steps are needed to initiate or complete the functional user requirement(s). Software Engineering Institute (SEI) Maturity. The ability of an organization to achieve a controlled and measured process as the foundation for continued improvement (Humphrey). The level of experience of an organization or project with a particular tool, resource, technique, or methodology. Sorting. The activity of sequencing of rows or records in a transactional function.

Transaction rate GSC. One of the 14 general system characteristics describing the degree to which the rate of business transactions influenced the development of the application. Trend. A time analysis showing repeated occurrences of a particular measure or metric. Unadjusted functional size. See Functional size. Unadjusted function point count (UFP). See Function point count. User. A user is any person or thing that communicates or interacts with the software at any time. User recognizable. The term user recognizable refers to requirements for processes and/or data that are agreed upon, and understood by, both the user(s) and software developer(s). User view. A user view is the Functional User Requirements as perceived by the user. Value adjustment factor (VAF). The factor that indicates the general functionality provided to the user of the application. The VAF is calculated based on an assessment of the 14 general system characteristics (GSCs) for an application.

System. See Application.

Work effort. Labor resources required for the production of a specified output. Here referring to the effort required to develop or maintain an application. Labor resources are usually expressed as work hours.

Technical attribute. Non-functional attribute that is a result of a design or implementation consideration.

Work product. The product that is created by information systems work, here the result of a software development effort.

Technical requirements. Requirements are related to the technology and environment, for the development, maintenance, support and execution of the software.

313. See Albrecht 1984.

Subtypes. See Entity subtypes. Support. See Maintenance.

Third normal form. Result of a normalization process that transforms groups of data so that each non-key attribute does not depend on any other non-key attribute. Total degree of influence (TDI). The sum of the degrees of influence for the fourteen GSCs. Transactional function. A transactional function is an elementary process that provides functionality to the user to process data. A transactional function is an external input, external output, or external inquiry. Transaction. See Transactional function.

January 2010

Function Point Counting Practices Manual

G-7

IFPUG Glossary

Part 5 – Appendices and Glossary

This page intentionally left blank.

G-8

Function Point Counting Practices Manual

January 2010