Successfully reported this slideshow.
Your SlideShare is downloading. ×

DHS - Using functions points to estimate agile development programs (v2)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
DHS ‒ PROGRESS TOWARD USING FUNCTIONS POINTS TO ESTIMATE AGILE DEVELOPMENT PROGRAMS
Glen B. Alleman and Thomas J. Coonce
“...
2.0 ‒ Assessment of Selected Concept of Operations (ConOps)
Software sizing, using Agile development, starts with a Concep...
Attributes Needed for Success
CBP Predator B
Heavily
redacted, but
contains
process models
for operations
of the vehicle
a...
Advertisement
Upcoming SlideShare
Heliotropic Abundance
Heliotropic Abundance
Loading in …3
×

Check these out next

1 of 6 Ad

More Related Content

Slideshows for you (20)

Similar to DHS - Using functions points to estimate agile development programs (v2) (20)

Advertisement

More from Glen Alleman (20)

Recently uploaded (20)

Advertisement

DHS - Using functions points to estimate agile development programs (v2)

  1. 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. 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. 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. 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. 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. 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.

×