4. 11/30/2009 4 Introduction FPA Counting Practices (Definition:FPA is a method to break systems into smaller components, so they can be better understood and analyzed) Project Managers, Software Architects and above.
6. 11/30/2009 6 Overview System & Application Boundary EI EQ EO Outside App Boundary ILF EIF
7. 11/30/2009 7 EI 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 maintain an internal logical file.
8. 11/30/2009 8 EQ External Inquiry (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 or maintain any FTR’s (Internal Logical Files or External Interface Files) and the output side does not contain derived data.
9. 11/30/2009 9 EO External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. These reports and files are created from information contained in one or more internal logical files and external interface files.
10. 11/30/2009 10 ILF & EIF Internal Logical Files (ILF) - a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Inputs. Maintained is the process of modifying data (adding, changed and deleting) via an elementary process (via an External Input). 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 boundary and is maintained by another applications external inputs. The external interface file is an internal logical file for another application
12. 11/30/2009 12 RET & FTR & DET Record Element Type (RET): A RET is user recognizable sub group of data elements within an ILF or an EIF. It is best to look at logical groupings of data to help identify them. File Type Referenced (FTR): A FTR is a file type referenced by a transaction. An FTR must also be an Internal Logical File (ILF) or External Interface File (EIF). Data Element Type (DET): A DET is a unique user recognizable, non-recursive (non-repetitive) field. A DET is information that is dynamic and not static.
13. 11/30/2009 13 Weight Factors Type of Complexity of Components Component Low Average High Total External Inputs ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ External Outputs ___ x 4 = ___ ___ x 5 = ___ ___ x 7 = ___ External Inquiries ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ Internal Logical Files ___ x 7 = ___ ___ x 10 = ___ ___ x 15 = ___ External Interface Files ___ x 5 = ___ ___ x 7 = ___ ___ x 10 = ___ Total Number of Unadjusted Function Points _____
14. 11/30/2009 14 VAF (0-5) The value adjustment factor (VAF) is based on 14 general system characteristics (GSC’s) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics.
15. 11/30/2009 15 VAF (0-5) General System Characteristic Brief Description 1. Data communications How many communication facilities are there to aid in the transfer or exchange of information with the application or system? 2. Distributed data processing How are distributed data and processing functions handled? 3. Performance Did the user require response time or throughput? 4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed? 5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.? 6. On-Line data entry What percentage of the information is entered On-Line? 7. End-user efficiency Was the application designed for end-user efficiency? 8. On-Line update How many ILF’s are updated by On-Line transaction? 9. Complex processing Does the application have extensive logical or mathematical processing? 10. Reusability Was the application developed to meet one or many user’s needs? 11. Installation ease How difficult is conversion and installation? 12. Operational ease How effective and/or automated are start-up, back up, and recovery procedures? 13. Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? 14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change?
18. Architecture World ‘09 Use Cases Business use Case Business level functionality, which can be sub divided into multiple or single use cases. Technical Use Case An independent behavior which can’t be further sub divided into any form.
19. Architecture World ‘09 Use Case Analytics Actors Identification Humans are always a complex actor System Actor Use case to use case interaction actors Identification of Primary and Alternate Flow Identification of interaction with number of tables by a Use case.
20. Architecture World ‘09 Complexity Definition Human Actors are always complex System Actors are as follows 0-5 Simple 6 onwards Complex Use Case Complexity 0-5 Simple ( Flow / Tables) 6-10 Medium ( Flow / Tables) 11 onwards Complex (Flow/Tables)
24. Architecture World ‘09 ESB/SOA Decomposition SOA/ESB hierarchical decomposition can help in identifying the primary components and processes Functional Requirements termed as Business Factors (BFCT) Non- Functional Requirements termed as Technical factors (TF)
25. Architecture World ‘09 Business Factor (BFCT) Definition: The components which represents the business requirements and transactions in terms of:- Process Process consists of set of business processes workflows Services ESB provides the routing and connectivity through services, hence services are the real backbone and defined as business services Integration ESB provides a comprehensive persistent framework for integration of applications
26. Architecture World ‘09 Business Factor: Process (BFCT-P) Process: The process factor is decomposed and are following:- Business Service Workflow (BSW) BSW can further be decomposed into Sequential (BSW-S) Parallel (BSW-P) Implementation service Workflow (ISW) ISW can further be decomposed into Sequential (ISW-S) Parallel (ISW-P)
44. Architecture World ‘09 Business Factor: Integration (BFCT-I) Integration: Integration herein defined as relation among applications under consideration Application Type Product based (IA-P) Open Specification : Simple Proprietary : Medium Legacy : Complex Customer developed (IA-C) Open specification : Simple Proprietary : Medium Legacy : Complex Integration Type Adapter based or services already in place (IS-A) 0-5 : Simple 6-10 :Medium 10 + :Complex Customized services to be developed (IS-D) Number of tables and fields define the complexity DET :RET Defines the complexity
46. Architecture World ‘09 Technical Factors (TF) Definition: These are Non-functional requirements of any ESB integration. Most of the time applications take control of these factors:- Routing Versioning Transformation Messaging Response Time Distributed Orchestration Protocol Transactions AAA
47. Architecture World ‘09 Technical Factors (TF) These technical factors have degrees of influence between (0-5) and this has to be set to 3 at abinitio to make degree of influence as a multiple of 1, which means no impact on size. As these are set to a max of 5 the maximum percentile impact would be 15 % TF =(DI*.01)+0.70 Keeping DI at low impacted multiplier is due to the tools availability to cater these requirements.
52. 37 Characteristics Layers: hierachical set of layer with client/server relationships. Peer-to-peer communication Boundary boundary lies between layers items are inside or outside boundary Software users Always outside boundary humans, software, devices, adjacent layers Functional User Requirement (FUR) Only Functionality from User point of view no quality or performance requirements
53. 38 General Principles The software to be mapped and measured is fed by input and produces useful output to the users manipulates pieces of information designated as data groups which consist of data attributes
54. 39 Sub-process types = data movement types sub-processes USERS Entry Exit Manipulation Read Write STORAGEDATA GROUPS
55. 40 COSMIC FFP Measurement Phase Measurement function: each instance of a sub-process is assigned a numerical quantity Unit of Measurement: 1 Cfsu (Cosmic Functional Size Unit) is equivalent to 1 data movement at the sub-process level Additivity: The size of a functional process is the sum of the measurements of its sub-process. The Size of a piece of software is the sum of the sizes of its functional processes Sub-unit of measure: If necessary, a sub-unit of measurement can be defined (example: movement of a single data-attribute)
56. 41 Measurement Phase: Rules & Method Aggregation of results Size(layeri)= S size(entriesi)+ S size(exitsi) + S size(readsi) +S size(writesi) Size(change(layeri))= S size(added sub-processes)+ S size(modified sub-processes) + S size(deleted sub-processes)
57. 42 COSMIC FFP-example Add Customer 4 User entry ENTRY 1 Test for existing name READ 1 Display error message EXIT 1 Store customer data WRITE 1 Change Customer Data 8 User entry ENTRY 1 Retrieve Customer Data READ 1 Display error message EXIT 1 Display Cust data EXIT 1 Enter changed data Entry 1 Store modified Data WRITE 1 Retrieve item data (FK) READ 1 Store item data (FK) WRITE 1
58. 43 COSMIC FFP-example Delete Customer 5 User entry ENTRY 1 Retrieve Customer Data READ 1 Display error message EXIT 1 Retrieve item data (FK) READ 1 Remove customer WRITE 1 Receive Payment 4 User entry ENTRY 1 Retrieve Customer Data READ 1 Display error message EXIT 1 Store data WRITE 1
59. 44 COSMIC FFP-example Deposit Item 6 User entry ENTRY 1 Retrieve Customer Data READ 1 Retrieve item data READ 1 Retrieve place data READ 1 Display error message EXIT 1 Store item data WRITE 1 Retrieve Item 6 User entry ENTRY 1 Retrieve Customer Data READ 1 Retrieve item data READ 1 Display error message EXIT 1 Update customer record WRITE 1 Remove item WRITE 1
60. 45 COSMIC FFP-example Add Place 4 Change Place Data 8 Delete Place 5 Print customer Item List 5 Print Bill 5 Print stored item list 3 Query customers 4 Query customer's items 5 Query Places 4 Query stored items 5 = 81
63. 48 Prodcutivity Relationships 7.5 FP for Java/DotNet = 10 Hrs for UCP = 10*1.65* Cosmic FFP Count ESB/SOA Productivity = 4 Min to 8 Max Depends on Tool ERP = 4 to 6 Span = 4 to 13
64. 49 Points to Poinder Number of Test Cases = 1.2 * FP Size FP Size = Line of Logical code / Benchm,arked Lines/Technology Search input and Generate report is counted in one entity Count cannot be repeated Number or EI =Number of EQ 0.5 Number of EI= Number of EO = Number of ILF Estimations fails at EIF VAF has %age imapct NFR are equally important that requirements