Using Function Points to Estimate Agile Development Programs

Determining the size of system functionality and measuring the performance of project teams is the basis of successful projects. [1]

A Case Study of Cost Estimating Agile IT Systems at the Department of Homeland Security (DHS)

As federal agencies embraced the Agile software framework, the development teams describe the functionality of the desired system in the form of Features and Stories rather than the traditional Software Requirements Specification. [2] As Agile Software Development becomes the basis of system development, estimating the cost and duration of these systems becomes problematic.

The traditional approach of detailed functional user requirements (in terms of elementary fields, logical files, references to files, etc.) produces a measurement of the business value of an application and the cost to achieve that Value. These detailed requirements are no longer available in Agile development. In the traditional Function Point measurement methods, the International Function Point User Group (IFPUG) and Common Software Measurement International Consortium (COSMIC) approaches can be applied to produce an estimate.

Producing traditional estimates with IFPUG methods can be costly and time-consuming and require high levels of knowledge and experience for those making the estimates.

In Software Intensive System of Systems (SISoS) [3] implemented in a multi-tier environment, complexity is created by combinations of integrated systems, real-time applications, and embedded systems. The original Function Point Analysis was not designed to address these development approaches.

Simple Function Point (SiFP) [4] is an Agile approach to Function Point Analysis based on two Basic Functional Components (BFCs) compliant with the IFPUG standard. All the resources and contractual frameworks developed for IFPUG are also valid for Simple FP, starting from the ISBSG productivity database.

Estimation and project metrics based on functional sizing are good practices, regardless of the delivery framework used ? Agile or Traditional. They allow the project team to provide the business with realistic project cost and duration expectations and measure themselves against improvement goals and the industry. [1]

Assessment of Selected Concept of Operations (ConOps)

Software sizing, using Agile development, starts with a Concept of Operations (ConOps). A CONOPS is a high-level description of the actions to be taken in the pursuit of mission accomplishment.

A well-formed ConOps describes the characteristics of the proposed system from the point of view of the individuals using the system. Our work examined several ConOps. It was not intended to assess these ConOps against specific guidance formally. Still, the framework for a good ConOps is provided in a later section of this report from the Department of Homeland Security.

1. ?“Customs and Border Protection International Trade Data System Concept of Operations,” Public Version 1.3, September 2010.
2. “The Student and Exchange Visitor Program: Operational Requirements Document for the Student and Exchange Visitor Information System Modernization,” August 3, 2016.
3. “The Student and Exchange Visitor Program: Concept of Operations for the Student and Exchange Visitor Information System Modernization,” August 16, 2016.
4. “Concept of Operations (CONOPS), Version 1.2, Next-Generation Incident Command System (NICS),” 17 August 2016
5. ?“Homeland Security Geospatial Concept of Operations (GeoCONOPS), Quick Start Guide.
6. “Concept of Operations of CBP’s Predator B Unmanned Aircraft System, FY 2010 Report to Congress, June 29, 2010.

The framework in §3.0 is applied to each of these ConOps and summarized here:

Condition for SUccess Use of Function Points [6]

Several conditions must exist to succeed for Function Point Analysis and Simple Function Point measurement. These conditions start with the properly formed Concept of Operations (ConOps) that must provide the following information to develop the Function Point Model:

• External Inputs (EI) ? is an elementary process in which data crosses the boundary from outside to inside.?This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files.?The data can be either control information or business information.?If the data is control information, it does not have to update an internal logical file.
• External Output (EO) ? An elementary process in which derived data passes across the boundary from inside to outside. An EO may update an Internal Logic File ?(ILF).?The data creates reports or output files sent to other applications.?These reports and files are created from one or more internal logical files and external interface file.?The following graphic represents on EO with 2 File Type References (FTRs) there is derived information that has been derived from the (ILFs)
• External Inquiries (EQ) ? An elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files.?The input process does not update any Internal Logical Files, and the output side does not contain derived data. The graphic below represents an EQ with two ILFs and no derived data.
• Internal Logical Files (ILF) ? A User-identifiable group of related data maintained within the application. This is logic in the form of fixed data managed by the application through the use of External Input (EI).
• External Interface Files (EIF) ? A user-identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application.

Moving Toward Successful Estimating of Agile

With the guidelines for developing a properly formed Concept of Operations, deploying a Function Point Analysis process using Simple Function Point measurement. Functional User Requirements (FUR) identify the functional processes. These processes are a set of sub-processes that are either movements or manipulations of data.

The SiFP method provides advantages to DHS, over traditional Function Point Analysis and other means of estimating software cost:

• Easy to apply
• Easy to learn
• Less subject to interpretation
• Less prone to manipulation by developers
• Easier to keep aligned with the evolutions of the operational system
• Immediately convertible from IFPUG Function Point Analysis systems

The first step in deploying Function Point estimate for agile programs is derived from Simple Function Point analysis. There are five elements of the Agile approach.

1. Internal Data ? managed by the Application
2. External Data ? referenced by the application but managed by some other application.
3. Inputs ? add, change, update, delete internal data
4. Outputs ? reports and calculations based on internal or external data
5. Inquiries ? search and retrieval of internal or external data

The number of data elements involved determines the range of values for each element. Since the Agile paradigm does not provide detailed information, a range of values can be used.

These values can be applied to the User Stories developed from the Features developed from the Agile Product Roadmap and Release Plan of the project.

A sample User Story from ConOps number 3 listed in Section 2.0 ? Concept of Operations Examined:

Create and maintain nonimmigrant biographical and dependent information in user accounts that give schools and sponsors unique identities.

• Internal Data ? data structures for compliance with DHS data reporting
• External Data ? nonimmigrant biographical data and dependent data
• Inputs ? entry of biographical and dependent data
• Outputs ? uniquely identified data needed to decide on the candidate’s approval
• Inquiries – unique identify, biographical information, dependent information

The Story description in this example ConOps is likely too simple to estimate the work using Function Points (or any other method).

The ConOps needs to describe the needed Features in the following steps:

• Identify the application boundary ? what boundaries does this story interact with?
• Identify the functional requirements and logical transactions.
• Identify the processing components or entities of all logical transactions.
• Identify the input and output components for each logical transaction.
• Calculate the logical transaction size to determine the unadjusted function point (UFP).
• Apply the value adjustment factor (VAF) to arrive at the adjusted function point (AFP).

Conditions for Success Start with a Well Formed Concept of Operations (ConOps) [7]

The Concept of Operations is a Systems Engineering document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system. Examples include business requirements specifications or stakeholders. A Sample Template and Guidance for the Concept of Operations Development and an example for Customs and Border Protections' Predator B.

A good Concept of Operations:

• Contains the goals, objectives, and system components and identifies the stakeholders.
• Captures the Systems Requirements in the form of functions.
• Provides end-to-end traceability between operational needs and captured source requirements.
• Establishes a high-level basis for requirements that supports the system over its life cycle.
• Establishes a high-level basis for test planning and system-level test requirements.
• Supports the generation of operational analysis models (use cases) to test the interfaces.
• Provides the basis for computation of system capacity.
• Validates and discover implicit requirements.

There are four major components of the ConOps.

1. The existing system (manual or automated) the user wants to replace.
2. Justification for a new or modified system (including restrictions on that system).
3. A description of the proposed system.
4. Scenarios highlighting the use of the system in the user's environment, including internal and external factors.

Next Steps

Train, support, and mentor the development of a credible Concept of Operations for the sample program.

Using the ConOps, Select the sample program to estimate the cost based on IFPUG Function Point Analysis or SiFP analysis.

Start a repository of data from prior programs to calibrate the FPA database.

References

Here are a few guidelines and examples of estimating Agile software development using Function Points. The Simple Function Point site has guidance and Case Studies, which can be the Next Steps' starting point.

1. Software Project Effort Estimation: Foundations and Best Practice Guidelines for Success, Adam Trendowicz and Ross Jeffery, Springer, 2016.
2. “Using Function Points in Agile Projects,” Célio Santana, Fabiana Leoneo, Alexandre Vasconcelos, and Cristine Gusm?o, Lecture Notes in Business Information Processing, May 2011.
3. “From Story Points to COSMIC Function Points in Agile Software Development – A Six Sigma perspective,” Thomas Fehlmann and Luca Santillo, MetriKon 2010, COSMIC.
4. “Incorporating Vital Factors in Agile Estimation through Algorithmic Method,” S. Bhalerao and Maya Ingle, International Journal of Computer Science and Applications, 2009 Technomathematics Research Foundation, Vol. 6, No. 1, pp. 85 – 97.
5. “Developing Operational Requirements: A Guide to the Cost-Effective and Efficient Communication of Needs,” Version 2.0, November 2008, Editor: Thomas A. Cellucci, Department of Homeland Security.
6. “Guideline for Sizing Agile Projects with COSMIC,” Sylvie Trudel and Luigi Buglione, IWSM/MetriKon 2010.
7. “Improving the User Story Agile Technique Using the INVEST Criteria,” Luigi Buglione and Alain Abran, 2013 Joint Conference of the 23nd International Workshop on Software Measurement (IWSM) and the Eighth International Conference on Software Process and Product Measurement (Mensura), Ankara, Turkey, 2013.
8. ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method
9. “Simple Function Point: A New Functional Size Measurement Method Fully Compliant with IFPUG 4.x,” Roberto Meli, Proceedings 8th Software Measurement European Forum, Rome 2011.
10. “Simple Function Point Functional Size Measurement Methods: Reference Manual, SiFP-01.00-RM-EN-01.01, 2014
11. “Function Points and Agile ? Hand in Hand,” Amol Kumar Keote, Accenture India Delivery Centre, 2010.
12. Appendix B: DHS Systems Engineering Life Cycle (SELC), Part 1, Version 2.0, September 2010, Acquisition Program Management Division (APMD) and Office of Chief Information Office.
13. “Simple Function Point: A New Functional Size Measurement Method Fully Compliable with IFPUG FP, 2011.
14. “Simple Function Point Functional Size Measurement Methods: Measurement Examples,” SiFP-01.00-EX-EN-01.01.
15. Progressive Function Points Analysis: Advanced Estimation Techniques for IT Projects, Ruben Gerad Mathew and Anna Bandura, CreateSpace Independent Publishing 10 September 2014.
16. Function Point Analysis: Measurement Practices for Successful Software Projects, David Garmus and David Herron, Addison-Wesley, 2000.
17. "But Wait, There's More: Using Simple Function Point Analysis for your Cost, Schedule, & Performance Needs," Joint Software and IT Cost Forum, September 16, 2020.
18. Estimating and Managing Agile Projects at DHS, DHS Cost Analysis Stakeholder Working Group, Thomas J. Coonce and Glen B. Alleman.
19. From Product Roadmap to Needed Capabilities to Release Plan, to Feature Breakdown Structure, to Credibile Estimates, DHS Cost Analysis Stakeholder Working Group, Thomas Coonce and Glen Alleman

Footnotes

[1]?DHS Acquisition Instruction/Guidebook #102-01-001: Appendix F, located at https://dau.gdit.com/aqn201a/pdfs/APPENDIX%20F_CONOPS.pdf “Implementing an Estimating Process,” Tom Dekkers, Software Estimation Series, Galorath

[2] “Developing Operational Requirements: A Guide to the Cost-Effecrtive and Efficient Communication of Needs,” Version 2.0, Department of Homeland Security, November 2008.

[3] ISO/IEC/IEEE 42010:2011, Systems and Software Engineering ? Architecture Description

[4] “Simple Function Point Size Measurement Method Reference Manual,” SiFP-01.00-RM-EN-01.01, 2014

[5] “Is Function Point Analysis Valuable in an Agile Environment?” Tony Manno, DCG Blog, January 4, 2016

[6] “Simple Function Point Functional Size Measurement Method: Reference Manual, SiFP-01.00-RM-EN-01.01, March 2014.