1.
DHS ‒ PROGRESS TOWARD USING FUNCTIONS POINTS TO ESTIMATE AGILE DEVELOPMENT PROGRAMS
Glen B. Alleman and Thomas J. Coonce
“Determining the size of system functionality and measuring the performance of
project teams is the basis of successful projects.” [1]
1.0 ‒ Background of Cost Estimating Agile IT Systems at DHS
As DHS embraces 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 at DHS, 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.) producing 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 deal with 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 valid for Simple FP as well, starting from the
ISBSG productivity data base.
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 expectations of project cost
and duration and to measure themselves against improvement goals and the
industry. [5]
1
“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

2.
2.0 ‒ Assessment of Selected Concept of Operations (ConOps)
Software sizing, using Agile development, starts with a Concept of Operations (ConOps). A
CONOPS is the 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 form the point of
view of the individuals using the system. Our work examined several ConOps. It was not the
intent to formally assess these ConOps against specific guidance, but the framework for a good
ConOps is provided in a later section of this report.
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:
Attributes Needed for Success
ConOps EI EO EQ ILF EIF
CBP ITDS
A Process flow
oriented
ConOps using
swim lanes and
IDEF0 notation
Inputs
described in
process flow
diagrams with
narratives of
data content
Outputs
described in
process flow
diagrams with
narratives of
data content
Queries labeled
in process flow
diagrams
Files named
with connection
to Inputs,
Outputs, and
Queries
Files named
with connection
to Inputs,
Outputs, and
Queries
SEVP Aug 3 Inputs listed at
high level, but
no connection
to processes
Outputs listed
at high level,
but no
connection to
processes
No queries
listed
No file names
listed
No file names
listed
SEVP Aug 16 Inputs listed at
high level, but
no connection
to processes
Outputs listed
at high level,
but no
connection to
processes
No queries
listed
No file names
listed
No file names
listed
DHS Geospatial
Capabilities
Based approach
with systems,
roles, process
flow and data
flow
Process flow diagrams for each
data type connected to process
systems.
Best practices for each data type
assigned to each scenario for each
stakeholder.
Graphic
examples of
data retrieval
No file names
listed
No file names
listed

3.
Attributes Needed for Success
CBP Predator B
Heavily
redacted, but
contains
process models
for operations
of the vehicle
and
connections to
external
systems
Ground and flight data defined
with connections to Near, Mis, and
Far Term operational capabilities
and their systems – payloads, data
links OP Tempo, airspace access,
Collision Avoidance and ATC
Management
No queries
listed
No file names
listed
No file names
listed
3.0 ‒ Conditions for Successful Use of Function Points [6]
Several conditions must exist for Function Point Analysis and Simple Function Point measurement
to be successful. These conditions start with the properly formed Concept of Operations
(ConOps) that must provide the following information 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 (FTR's) there is derived information
that has been derived from the (ILF's)
§ 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 ILF's 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.
6
“Simple Function Point Functional Size Measurement Method: Reference Manual, SiFP-01.00-RM-EN-01.01,
March 2014.

4.
4.0 ‒ Moving Toward Successful Estimating of Agile DHS Programs
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 for 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, calculations based in internal or external data
5. Inquiries ‒ search and retrieval of internal or external data
The range of values for each element is determined by the number of data elements involved.
Since the Agile paradigm does not provide detailed information, a range of value can be used
Low
Most
Likely
High
Internal Data 7 10 15
External Fata 5 7 10
Inputs 3 4 6
Outputs 4 5 7
Inquiries 3 4 6
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 provide schools and sponsors with unique identity.
§ 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 ‒ unique identify data needed to make decision of candidate’s approval
§ Inquiries – unique identify, biographical information, dependent information

5.
The Story description in this example ConOps is likely too simple for use in estimating 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 arrive at the unadjusted function point (UFP).
§ Apply the value adjustment factor (VAF) to arrive at the adjusted function point (AFP).
5.0 ‒ Conditions for Success Starts with a Well Formed Concept of Operations [7]
The Concept of Operations is a Systems Engineering document. The DHS Sample Template and
Guidance for the Concept of Operations provides guidance for developing the ConOps. A good
Concept of Operations:
§ Contains the goals, objectives, system components and stakeholders are identified.
§ Captures the Systems Requirements in the form of functions are detailed. These are
documented in section 3.0.
§ 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.
§ The existing system (manual or automated) the user wants to replace.
§ Justification for a new or modified system (including restrictions on that system).
§ A description of the proposed system.
§ Scenarios highlighting use of the system in the user's environment including internal and
external factors.
6.0 ‒ Next Steps
§ Train, support, and mentor the development of credible Concept of Operations for the
sample program.
§ Using the ConOps, Select the sample program to make a cost estimate based on IFPUG
Function Point Analysis or SiFP analysis.
§ Start a repository of data from prior program’s to calibrate FPA database.
7
DHS Acquisition Instruction/Guidebook #102-01-001: Appendix F, located at
https://dau.gdit.com/aqn201a/pdfs/APPENDIX%20F_CONOPS.pdf

6.
7.0 ‒ References
Here are a small set of guidance and examples of making estimates of Agile software
development using Function Points. The Simple Function Point site has guidance as well as Case
Studies that can be the starting point for the Next Steps.
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. Progress 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.