Functional Size Measurement for Web Applications

Transcription

1 Functional Size Measurement for Web Applications Silvia Abrahão Valencia University of Technology, Spain

2 Contents Part I Introduction Why measure? Software Metrics Why measure software size? Functional Size Measurement (FSM) History ISO Standards for FSM Function Point Analysis (FPA) Functional Size Measurement for the Web Silvia Abrahão,

3 Contents Part II OOmFPWeb: A FSM method for Web Applications Foundations Measurement Process Identifying the Application Boundary and the Measurement Scope Measuring Data Candidate Functions Measuring Transactional Candidate Functions Determining the Complexity for each function Determining the Functional Size of the Web Application Silvia Abrahão,

4 Part I Introduction: Why Measure? If you cant measure it, you cant manage it Tom DeMarco 1 ¹ Tom DeMarco, Controlling Software Projects, Yourdon Press, Silvia Abrahão,

5 Introduction: Software Metrics Software Metrics Size Effort Cost Quality Hour $ Defect Changes Syntatic Hybrid Semantic Halstead Reifer 3D Size Complexity Function Point Analysis LOC McCabe Silvia Abrahão,

6 Introduction: Why Measure Software Size? To normalize other measures... Estimation How long will it take to develop this system? How much will it cost? Productivity How productive are the development team? Silvia Abrahão,

7 Software Size Software Size SYNTATIC Programs, source lines of code (SLOC) Technical Size: Developer view No method for normalizing across languages It is measured in the detailed project or when the project is finished SEMANTIC Functional requirements from the user point of view Logical Size: User View It is measured in early stages of the development lifecycle Provide a consistent measure among various projects and organizations Silvia Abrahão,

8 unctional Size Measurement (FSM): History Silvia Abrahão,

9 tandards for FSM ISO/IEC Series of standards that provide a framework in which a new FSM method can be developed, tested and refined. It is composed by the following five parts: Part 1: Definition of concepts Part 2: Conformance evaluation of software sizing methods to ISO/IEC :1998 Part 3: Verification of a functional size measurement method Part 4: Functional size measurement reference model Part 5: Determination of functional domains for use with functional size measurement. Silvia Abrahão,

10 tandards for FSM FSM methods used in industry approved by ISO The following FSM methods are ISO standards: It is composed by the following five parts: IFPUG FPA (ISO/IEC 20926) Mark II FPA (ISO/IEC 20968) COSMIC-FPP (ISO/IEC 19761) NESMA FPA (ISO/IEC 24570) Silvia Abrahão,

11 The most widely used FSM method unction Point Analysis (FPA) by International Function Point Users Group External Inputs Aplicativo External Input External Interface Files (EIFs) Determine the type of count Identify Boundary Count the Data function types Count the Transactional function types Determine the Complexity for each function type (low, average, high) Determine the unadjusted functional size Determine the value adjustment factor (based on 14 general caracteristics of system) Determine the adjusted functional size External Outputs External Inquiry Internal Logical Files (ILFs) External Output External Inquiry Other Systems Silvia Abrahão,

12 Functional Size Measurement for the Web But... How about FSM for Web applications? The FSM methods used in industry (mainly Function Points Analysis date from a pre-web era. None of the ISO-standardized FSM methods were designed taking the particular features of Web applications into account. Silvia Abrahão,

13 urrent Status of the Web (Cutter Consortium) Many business are moved to the Web: 196 million new sites in 5 years Web-based Applications delivered didn't have required functionality (53%) Delivered Web Applications met business needs only 16% of the time Project exceeded budget (63%) Deliverables were of poor quality (52%) One of the major issues facing Web development is the lack of appropriate metrics for estimating WebApps (effort, time, productivity, cost, etc.). Silvia Abrahão,

14 Functional Size Measurement for the Web Some approaches have been proposed in the literature: Internet Points, Web Objects (Reifer, 2000) Web-Points (Charismatek, 2000) Internet Points (Cost Xpert Group, 2001) Problems: They apply measurement to the final software product They focus on the estimation of static Web Sites High level of dependence on implementation technology (counting html or xml files, scripts, multimedia files, etc.) Silvia Abrahão,

15 Functional Size Measurement for the Web What is needed is An implementation-independent FSM method that is based on the user-defined requirements captured in the conceptual model of the Web application. Silvia Abrahão,

16 Part II OOmFPWeb: A FSM Method for Web Applications E <<view>> Shopping_Cart subtotal purchase() * [H ] <<view>> Item price quantity <<Context>> Shopping_Cart name [Album_Details] Navigational Model <<view>> Internaut name <<view>> <<Context>> AlbumRent title description Presentation: Master-Detail pattern Cardinality: 1 Internaut <<Context>> Home <<Context>> Cars You can measure the functional size of Web applications from OOWS conceptual models Silvia Abrahão,

17 OOmFPWeb: Main Characteristics It is based on the FPA proposed by IFPUG (Counting Practices Manual, release 4.1) Size measurement is made early in the development life cycle (problem space level) The measurement process is embedded in the conceptual modeling phase of a model-driven approach for Web application development. It measure complex Web applications (static, dynamic, presentation and navigation features) Silvia Abrahão,

18 OOmFPWeb: Measurement Procedure Silvia Abrahão,

19 OOmFPWeb: Measurement Process Given a conceptual schema CS produced in the OOWS conceptual modeling phase, OOmFPWeb is calculated as follows: Where, OOmFPWeb = OOmFP D + OOmFP T OOmFP D is the size related to the data logical functions, and OOmFP T is the size related to the transactional logical functions. Silvia Abrahão,

20 OOmFPWeb: Measurement Process The measurement process according to the following steps: 1. The Object Model is analyzed to determine the application boundary and the measuring scope. 2. The Object Model is used for measuring the data functions (OOmFP D ). 3. The Object, Navigational and Presentation Models are used for measuring the transactional functions (OOmFP T ). 4. Levels of complexity for functions are translated into values using IFPUG tables. 5. The sum of values produces the functional size of a Web application (non-adjusted OOmFPWeb). Silvia Abrahão,

21 STEP 1. Identifying the Measurement Scope and the Application Boundary The measurement scope limits which functionality will be measured in a particular measurement (a sub-set). It can include in OOmFPWeb: A complete Web application, tacking into account all Navigational Maps and Agents. A Navigational Map for a specific agent (measures the functionality for a given user type) A Navigational Context The first one is applied in a new development whereas the latter ones in the restructuring phase of a WebApp (e.g. adaptive or corrective maintenance) Silvia Abrahão,

22 STEP 1. Identifying the Measurement Scope and the Application Boundary The application boundary indicates the border between the project or application being measured, and the external applications or user domain. Identification rule: External Inquiries (EQs) Application Boundary Measured WebApp EIs EOs External WebApp Agents External Outputs (EOs) External Intputs (EIs) Internal Logical Files (ILFs) DB Business Logic EQs External WebApp A WebApp is a group of logically related functions that fulfill specific business requirements. Silvia Abrahão,

23 STEP 1. Identifying the Measurement Scope and the Application Boundary The application boundary is identified by applying the following rules: Accept each agent as a user of the application. The boundary corresponds to all navigational maps existing in a Navigational Model (the navigational contexts inherited by users are measured only once!). Silvia Abrahão,

24 STEP 2. Measuring Data Functions In FPA the Data Functions represent the functionality provided to the user to meet internal (ILFs) and external (EIFs) data requirements. Measuring Data Functions Identification of ILFs Identification of EIFs Determination of the Complexity Silvia Abrahão,

25 STEP 2. Measuring Data Functions Internal Logical File (ILF) FPA: is a user identifiable group of logically related data or control information maintained within the boundary of the application. OOmFP: is a class with an associated agent. A class encapsulates a set of data items (attributes) representing the state of the objects in each class. Silvia Abrahão,

26 STEP 2. Measuring Data Functions External Interface File (EIF) FPA: is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. OOmFP: is a legacy view is defined as a filter placed on a class by a preexisting software system. Silvia Abrahão,

27 STEP 2. Measuring Data Functions The complexity of a data function is determined by: DET (Data Element Type): unique userrecognizable, non-repeated fields. RET (Record Element Type): user-recognizable subgroups of data contained within an ILF or EIF. Silvia Abrahão,

28 Determining the Complexity of Classes OOmFP ILF DETsc, Measurement Rules for DETs of a Class: 1 DET for each data-valued attribute of the class 1 DET for each attribute in the Identification Function (IF)1 of a class or legacy view referenced in a univalued aggregation relationship. 1 DET for each attribute in the IF of the superclasses of a class. Measurement Rules for RETs of a Class: 1 RET for the class 1 RET for each multivalued aggregation relationship (class or legacy view). 1 A class can have 0 or N Identification Functions (IF) that are specified by indicating the constant attributes that define it. Silvia Abrahão, c MO RETs c

29 Determining the Complexity of Classes OOmFP ILF DETsc, RETs c DETs RETs 1 = 2 to 5 morethan 6 1 to to morethan Where the complexity is: Low=7, Average=10, High=15 Silvia Abrahão,

30 Measuring Classes Measuring classes with aggregation relationship. The Identification Function (IF) of the Country class is made up of the countryname and id_country attributes. The class City is identified by id_name Country (ILF) DETs = 2 (attributes) RETs = 2 (class) + 1 (multivalued aggr. relationship) [Low Complexity = 7 UFP] Silvia Abrahão, City (ILF) DETs = 4 2 (attributes) +2 (IF/univalued aggr. relationship) RETs = 1 (Class) [Low Complexity = 7 UFP]

31 Measuring Classes Measuring classes with inheritance and aggregation relationships. The identification function (IF) of the class Person is made up of the attributes id_dni and Fullname. The class Car is identified by id_car. Person (ILF) DETs = 3 ( attributes ) RETs = 2 ( class + multivalued aggr.) [Low complexity = 7 UFP] Car (ILF) DETs = 3 ( 1 attribute + 2 univalued aggr. ) RETs = 1 (class) [Low complexity = 7 UFP] Silvia Abrahão, Estudiante (ILF) DETs = 4 ( 2 attributes + 2 FI univalued aggr. ) RETs = 1 ( class ) [Low complexity = 7 UFP]

32 Determining the Complexity of Legacy View vl MO OOmFP EIF DETsvl, Measurement Rules for DETs of a Legacy View: RETs 1 DET for each data-valued (non-derived) attribute of the legacy view 1 DET for each attribute in the IF the class related to by a univalued aggregation relationship vl Measurement Rules for RETs of a Legacy View: 1 RET for the legacy View 1 RET for each multivalued aggregation relationship with a class Silvia Abrahão,

33 etermining the Complexity of Legacy View OOmFP EIF DETs vl, RETs vl DETs RETs 1 = 2 a 5 morethan6 1 to to morethan Where the complexity is: Low= 5, Average=7, High=10 Silvia Abrahão,

34 Measuring Legacy Views Rate (EIF) [Low complexity = 7 UFP] Silvia Abrahão,

35 STEP 3. Measuring Transactional Functions In FPA the transactional functions represent the functionality provided to the user to process data. There are three function types: External Inputs (EIs), External Outputs (EOs), or External Inquiries (EIs). Measuring Transactional Functions Identification of EIs Identification of EOs Identification of EQs Determination of Complexity Silvia Abrahão,

36 STEP 3. Measuring Transactional Functions External Inputs (EIs) FPA: is a transaction must have processing logic that is unique and represents the smallest unit of activity that is meaningful to the business user. OOmFP: is a service that represents a unit of functional logic contained within an object. We identify one EI for each service (class or legacy view) that is activated for an agent. Silvia Abrahão,

37 STEP 3. Measuring Transactional Functions Hints for identifying EIs: An event or transaction are measured only once (in the class in which they are declared), even if they are inherited by several subclasses. Shared events must measured only once (in any class in which they are declared ). Reject event or transactions that are not activated for no client class. Silvia Abrahão,

38 Determining the Complexity of Services Se determina la complejidad por la cantidad de: DET (Data Element Type) a unique user recognizable, non-repeated field. FTR (File Type Referenced) subgroup of logical data referenced/maintained by a transactional function. Silvia Abrahão,

39 Determining the Complexity of a Service Measurement Rules for DETs of a Class Service: 1 DET for each data-valued argument of the service 1 DET for the capability of the application to send messages 1 DET for the action (Accept/Cancel) of the service execution. s MO OOmFP EI DETss, FTRs s Measurement Rules for FTRs of a Class Service: 1 FTR for the class in which the service is declared. 1 FTR for each new class referenced in the object-valued argument of the service (only if it is different of the class service). If integrity constraints are defined, count one FTR for new class referenced in the formula. If the service is a transaction, count one FTR for each class referenced in the transaction formula. Silvia Abrahão,

40 Determining the Complexity of a Service Measurement Rules for FTRs of a Class Service (cont): If a specialization by condition is defined, count one FTR for each new class accessed in the specialization formula If a specialization by event is defined (carrier/liberator event), count one FTR for each new class for which the event is a carrier/liberator. 1 FTR for each new class referenced in the formula of a control condition, defined in the State Transition Diagram. 1 FTR for each new class referenced in the formula of a trigger, defined in the Interaction Diagram. 1 FTR for each new class referenced in the formula of a precondition, defined in the State Transition Diagram. s MO OOmFP EI DETss, FTRs s Silvia Abrahão,

41 etermining the Complexity of Services OOmFP EI DETss, FTRs s DETs FTRs 0 a 1 = 2 a 3 morethan 4 1 to to morethan Where the complexity is: Low=3, Average=4, High=6 Silvia Abrahão,

42 Measuring Class Services createperson (EI) [Low complexity = 3 UFP] register (EI) [Low complexity = 3 UFP] Silvia Abrahão,

43 STEP 3. Measuring Transactional Functions External Inquiries (EQs) FPA: retrieval data to send outside the system boundary. The intent is to present information to a user retrieving data from ILFs or EIFs. The processing logic contains no calculations and creates no derived data. OOmFPWeb: It is an unique Navigational Context defined in the Navigational Model. The intent is to present information to the user without altering the system behaviour. Silvia Abrahão,

44 Determining the Complexity of Navigational Contexts Se determina la complejidad por la cantidad de: DET (Data Element Type) a unique user recognizable, non-repeated field. FTR (File Type Referenced) subgroup of logical data referenced/maintained by a transactional function. Silvia Abrahão,

45 Determining the Complexity of a Navigational Context Measurement Rules for DETs of Navigational Context (Navigation perspective): 1 DET for each attribute of the navigational classes 1DET for each contextual dependency relationship 2 DETs for each context relationship 1 DET for each service defined in the navigational classes 1 DET for each service link associated to a service 1 DET for each attribute defined in the formula of a population filter. 1 DET for each attribute defined in the formula of a information access filter 1 DET for each attribute defined in the formula of an index Silvia Abrahão, w x= 1 z y= 1 OOmFP ncontext xy

46 Determining the Complexity of a Navigational Context Measurement Rules for DETs of Navigational Context (Presentation perspective): 4DETsfor each sequential access mode to data blocks (previousnext-first-last). 5 DETs for each random access mode to data blocks (previousnext-first-last-num). 1 DET for the cardinality (dynamic) 1 DET for each ordering criteria of the navigational context 1 DET for the ability to specify an action to be taken 1 DET for the application capacity of presenting messages (error, control, etc.) w x= 1 z y= 1 OOmFP ncontext xy Silvia Abrahão,

47 Determining the Complexity of a Navigational Context Measurement Rules for FTRs of Navigational Context: 1 FTR for each navigational class 1 FTR for each new class referenced in the population filter formula 1 FTR for each new class referenced in the information access filter formula 1 FTR for each new class referenced in the index formula w x= 1 z y= 1 OOmFP ncontext xy Silvia Abrahão,

48 Determining the Complexity of a Navigational Context Hints for Measure Navigational Contexts: If a access mode is defined in conjunction with a cardinallity pattern the measurement is as follow: A sequential access mode with a static cardinallity pattern, count only 4 DETs. A sequential access mode with a dynamic cardinallity pattern, count 5 DETs. A random access mode with a static cardinallity pattern, count 5 DETs. A random access mode with a dynamic cardinallity pattern, count 6 DETs. w x= 1 z y= 1 OOmFP ncontext xy Silvia Abrahão,

49 etermining the Complexity of Navigationa ontexts OOmFP EI DETss, FTRs s DETs FTRs 0 a 1 = 2 a 3 morethan 4 1 to to morethan Where the complexity is: Low=3, Average=4, High=6 Silvia Abrahão,

50 Measuring Navigational Contexts Suppose that we need provide an indexed access to the Albums context using the attribute tittle. The following index is defined: ATTRIBUTE INDEX Album_title ATTRIBUTES title, price, photo LINK ATTRIBUTE title Albums (EQ) DETs = 7 FTRs = 2 [Average complexity = 4 UFP] Then, one more DET is added to the measurement of the context Albums due to the attribute photo. Silvia Abrahão,

51 Measuring Navigational Contexts Album_Track Navigational Context Measurement (EQ): DETs = 18 3 attributes (title, price, name) + 4 by context relationships + 1 link attribute + 1 service (purchase) + 1 service link (ShoppingCart in purchase) + 2 ordering criteria (name, price) + 4 sequential access mode with static cardinallity + 1 application ability to offer actions + 1 application capability to present messages FTRs = 2 2 due to the navigational classes Album and Track Silvia Abrahão, [Average complexity = 4 UFP]

52 Step 5. Determining thefunctional size of the Web application Project Name: Measurement Type: Logical Functions Complexity Total Low Average High Class (ILFs) x 7 = 0 x10 = 0 x 15 = 0 0 Legacy Views (EIFs) x 5 = 0 x 7 = 0 x 10 = 0 0 Services (EIs) x 3 = 0 x 4 = 0 x 6 = 0 0 Navigational Contexts (EQs) x 3 = 0 x 4 = 0 x 6 = 0 0 Tamaño Funcional (sin ajustar): 0 Silvia Abrahão,

53 Thank you for your attention!!! Silvia Abrahão,