Functional Size Measurement forWeb Applications
Silvia AbrahãoValencia University of Technology, Spain
© Silvia Abrahão, 2004. 2
Contents
Part IIntroduction
Why measure?Software MetricsWhy measure software size?
Functional Size Measurement (FSM)HistoryISO Standards for FSMFunction Point Analysis (FPA)Functional Size Measurement for the Web
© Silvia Abrahão, 2004. 3
Contents
Part IIOOmFPWeb: A FSM method for Web Applications
Foundations
Measurement ProcessIdentifying 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, 2004. 4
“If you cant
measure it, you
cant manage it”Tom DeMarco1
¹ Tom DeMarco, Controlling Software Projects, Yourdon Press, 1982.
Introduction: Why Measure?
Part I
© Silvia Abrahão, 2004. 5
Software Metrics
Size Effort Cost Quality
SyntaticHybrid
Semantic
Hour$
Defect Changes
Size Complexity
McCabeLOC
HalsteadReifer
3D
Function Point Analysis
Introduction: Software Metrics
© Silvia Abrahão, 2004. 6
To normalize other measures...
EstimationHow long will it take to develop this system?How much will it cost?
ProductivityHow productive are the development team?
Introduction: Why Measure Software Size?
© Silvia Abrahão, 2004. 7
Software SizeSoftware Size
Programs, source lines of code (SLOC)
Functional requirements from the user point of view
Technical Size: Developer viewNo method for normalizing across
languagesIt is measured in the detailed project or
when the project is finished
Logical Size: User ViewIt is measured in early stages of the
development lifecycleProvide a consistent measure among
various projects and organizations
SYN
TATI
CSE
MA
NTI
C
Software Size
© Silvia Abrahão, 2004. 9
Standards for FSM
ISO/IEC 14143
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 conceptsPart 2: Conformance evaluation of software sizing methods to ISO/IEC 14143-1:1998Part 3: Verification of a functional size measurement methodPart 4: Functional size measurement reference modelPart 5: Determination of functional domains for use with functional size measurement.
© Silvia Abrahão, 2004. 10
Standards 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, 2004. 11
The most widely used FSM method
Function Point Analysis (FPA)by International Function Point Users Grouphttp://www.ifpug.org
Determine the type of countIdentify BoundaryCount the Data function typesCount the Transactional function typesDetermine the Complexity for each functiontype (low, average, high)Determine the unadjusted functional sizeDetermine the value adjustment factor (based on 14 general caracteristics ofsystem)Determine the adjusted functional size
AplicativoExternal Inputs
External Outputs
External Inquiry
OtherSystems
Internal LogicalFiles (ILFs)
ExternalInterface
Files (EIFs)
External Inquiry
External Output
External Input
© Silvia Abrahão, 2004. 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, 2004. 13
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 appropriatemetrics for estimating WebApps (effort, time, productivity, cost, etc.).
Current Status of the Web (Cutter Consortium)
© Silvia Abrahão, 2004. 14
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.)
Functional Size Measurement for the Web
© Silvia Abrahão, 2004. 15
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.
Functional Size Measurement for the Web
© Silvia Abrahão, 2004. 16
“You can measure the
functional size of
Web applications
from OOWS
conceptual models”
OOmFPWeb: A FSM Method for Web Applications
Part II
Internaut
<<Context>>Home
<<Context>>Cars
<<Context>>Rent
Navigational Model
<<Context>>Shopping_Cart
Presentation: Master-Detail pattern Cardinality: 1
E
Internautname
<<view>>
[Album_Details]
Item price
<<view>>
quantity
Albumtitle
<<view>>
description
name
Shopping_Cart subtotal
<<view>>
purchase() * [H ]
© Silvia Abrahão, 2004. 17
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)
OOmFPWeb: Main Characteristics
© Silvia Abrahão, 2004. 19
OOmFPWeb: Measurement Process
Given a conceptual schema CS produced in the OOWS
conceptual modeling phase, OOmFPWeb is calculated as
follows:
Where,
OOmFPD is the size related to the data logical functions, and
OOmFPT is the size related to the transactional logical functions.
TD OOmFPOOmFPOOmFPWeb +=
© Silvia Abrahão, 2004. 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
(OOmFPD).
3. The Object, Navigational and Presentation Models are used for
measuring the transactional functions (OOmFPT).
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, 2004. 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, 2004. 22
The application boundary indicates the border between the project or application being measured, and the external applications or user domain. Identification rule:
External WebApp
Measured WebApp
DBExternal WebApp
BusinessLogic
Application Boundary
Agents
External Outputs(EOs)
External Inquiries
(EQs)
Internal Logical Files (ILFs)
EOs
EIs
EQsExternal Intputs (EIs)
A WebApp is a group of logically related functions that fulfillspecific business requirements.
STEP 1. Identifying the Measurement Scope and the Application Boundary
© Silvia Abrahão, 2004. 23
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!).
STEP 1. Identifying the Measurement Scope and the Application Boundary
© Silvia Abrahão, 2004. 24
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 ILFsDetermination ofthe Complexity
STEP 2. Measuring Data Functions
Identification of EIFs
© Silvia Abrahão, 2004. 25
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.
STEP 2. Measuring Data Functions
© Silvia Abrahão, 2004. 26
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.
STEP 2. Measuring Data Functions
© Silvia Abrahão, 2004. 27
The complexity of a data function is determined by:
DET (Data Element Type): unique user-
recognizable, non-repeated fields.
RET (Record Element Type): user-recognizable
subgroups of data contained within an ILF or EIF.
STEP 2. Measuring Data Functions
© Silvia Abrahão, 2004. 28
1 A class can have 0 or N Identification Functions (IF) that are specified by indicating the constant attributes that define it.
Determining the Complexity of Classes
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 aggregationrelationship.
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 class1 RET for each multivalued aggregation relationship (class or legacy view).
∑∈
MOcccILF RETsDETsOOmFP ,
© Silvia Abrahão, 2004. 29
Where the complexity is:
Low=7, Average=10, High=15
=
1515106151075210771
515020191
,
thanmoreto
thanmoretoto
RETsDETsOOmFP
RETsDETs
ccILF
Determining the Complexity of Classes
© Silvia Abrahão, 2004. 30
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
Measuring Classes
Country (ILF)DETs = 2
(attributes)RETs = 2
(class) + 1 (multivalued aggr. relationship)[Low Complexity = 7 UFP]
City (ILF)DETs = 4
2 (attributes) +2 (IF/univalued aggr. relationship)RETs = 1
(Class)[Low Complexity = 7 UFP]
© Silvia Abrahão, 2004. 31
Measuring classes with inheritance and aggregation relationships.The identification function (IF) of the class Person is made up of theattributes id_DNI and Fullname. The class Car is identified by id_Car.
Estudiante (ILF)DETs = 4
( 2 attributes + 2 FI univalued aggr. )
RETs = 1( class )
[Low complexity = 7 UFP]
Car (ILF)DETs = 3
( 1 attribute + 2 IF univalued aggr. )
RETs = 1(class)
[Low complexity = 7 UFP]
Person (ILF)DETs = 3
( attributes )RETs = 2
( class + multivaluedaggr.)
[Low complexity = 7 UFP]
Measuring Classes
© Silvia Abrahão, 2004. 32
∑∈
MOvlvlvlEIF RETsDETsOOmFP ,
Determining the Complexity of Legacy View
Measurement Rules for DETs of a Legacy View: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
Measurement Rules for RETs of a Legacy View:1 RET for the legacy View1 RET for each multivalued aggregation relationship with a class
© Silvia Abrahão, 2004. 33
=
1010761075527551
515020191
,
thanmorea
thanmoretoto
RETsDETsOOmFP
RETsDETs
vlvlEIF
Where the complexity is:
Low= 5, Average=7, High=10
Determining the Complexity of Legacy View
© Silvia Abrahão, 2004. 35
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).
MeasuringTransactionalFunctions
Identification of EIs
Determination ofComplexity
STEP 3. Measuring Transactional Functions
Identification of EOs
Identification of EQs
© Silvia Abrahão, 2004. 36
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.
STEP 3. Measuring Transactional Functions
© Silvia Abrahão, 2004. 37
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.
STEP 3. Measuring Transactional Functions
© Silvia Abrahão, 2004. 38
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.
Determining the Complexity of Services
© Silvia Abrahão, 2004. 39
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.
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.
∑∈
MOs
ssEI FTRsDETsOOmFP ,
Determining the Complexity of a Service
© Silvia Abrahão, 2004. 40
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 controlcondition, 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.
∑∈
MOs
ssEI FTRsDETsOOmFP ,
Determining the Complexity of a Service
© Silvia Abrahão, 2004. 41
=
66446433243310
2019651
,
thanmoreaa
thanmoretoto
FTRsDETsOOmFP
FTRsDETs
ssEI
Where the complexity is:
Low=3, Average=4, High=6
Determining the Complexity of Services
© Silvia Abrahão, 2004. 42
Measuring Class Services
createPerson (EI)[Low complexity = 3 UFP]
register (EI)[Low complexity = 3 UFP]
© Silvia Abrahão, 2004. 43
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 Contextdefined in the Navigational Model. The intent is to present information to the user without altering the system behaviour.
STEP 3. Measuring Transactional Functions
© Silvia Abrahão, 2004. 44
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.
Determining the Complexity of Navigational Contexts
© Silvia Abrahão, 2004. 45
Measurement Rules for DETs of Navigational Context (Navigation perspective):
1 DET for each attribute of the navigational classes
1 DET 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 populationfilter.
1 DET for each attribute defined in the formula of a informationaccess filter
1 DET for each attribute defined in the formula of an index
Determining the Complexity of a Navigational Context
∑∑==
z
ynContext
w
xyx
OOmFP11
© Silvia Abrahão, 2004. 46
Measurement Rules for DETs of Navigational Context (Presentation perspective):
4 DETs for each sequential access mode to data blocks (previous-next-first-last).
5 DETs for each random access mode to data blocks (previous-next-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.)
Determining the Complexity of a Navigational Context
∑∑==
z
ynContext
w
xyx
OOmFP11
© Silvia Abrahão, 2004. 47
Measurement Rules for FTRs of Navigational Context:1 FTR for each navigational class
1 FTR for each new class referenced in the population filterformula
1 FTR for each new class referenced in the information accessfilter formula
1 FTR for each new class referenced in the index formula
Determining the Complexity of a Navigational Context
∑∑==
z
ynContext
w
xyx
OOmFP11
© Silvia Abrahão, 2004. 48
Hints for Measure Navigational Contexts:If a access mode is defined in conjunction with a cardinallitypattern 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.
Determining the Complexity of a Navigational Context
∑∑==
z
ynContext
w
xyx
OOmFP11
© Silvia Abrahão, 2004. 49
=
66446433243310
2019651
,
thanmoreaa
thanmoretoto
FTRsDETsOOmFP
FTRsDETs
ssEI
Where the complexity is:
Low=3, Average=4, High=6
Determining the Complexity of Navigational Contexts
© Silvia Abrahão, 2004. 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_titleATTRIBUTES title, price, photoLINK ATTRIBUTE title
Then, one more DET is added to the measurement of the context Albums due to the attribute photo.
Albums (EQ)DETs = 7FTRs = 2[Average complexity = 4 UFP]
© Silvia Abrahão, 2004. 51
Measuring Navigational Contexts
Album_Track Navigational ContextMeasurement (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 accessmode with static cardinallity + 1 application ability to offeractions + 1 applicationcapability to present messages
FTRs = 22 due to the navigational classes Album
and Track
[Average complexity = 4 UFP]
© Silvia Abrahão, 2004. 52
Step 5. Determining thefunctional size of the Web application
Project Name:
Measurement Type:
Logical Functions Total
Class (ILFs) x 7 = 0 x10 = 0 x 15 = 0 0Legacy Views (EIFs) x 5 = 0 x 7 = 0 x 10 = 0 0Services (EIs) x 3 = 0 x 4 = 0 x 6 = 0 0Navigational Contexts (EQs) x 3 = 0 x 4 = 0 x 6 = 0 0
Tamaño Funcional (sin ajustar): 0
HighAverageLowComplexity
Top Related