functional size measurement - oomfpweb - upvusers.dsic.upv.es/~sabrahao/fsm/oomfpweb-slides.pdf ·...

Functional Size Measurement forWeb Applications

Silvia AbrahãoValencia University of Technology, Spain

[email protected]

© 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


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


“If you cant

measure it, you

cant manage it”Tom DeMarco1

¹ Tom DeMarco, Controlling Software Projects, Yourdon Press, 1982.

Introduction: Why Measure?

Part I


Software Metrics

Size Effort Cost Quality

SyntaticHybrid

Semantic

Hour$

Defect Changes

Size Complexity

McCabeLOC

HalsteadReifer

3D

Function Point Analysis

Introduction: Software Metrics


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?


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


Functional Size Measurement (FSM): History


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.


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)


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


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.


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)


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



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.



“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 ]


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


OOmFPWeb: Measurement Procedure


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 +=


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


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)


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.



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!).



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


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.



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.



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.



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 ,


Where the complexity is:

Low=7, Average=10, High=15

=

1515106151075210771

515020191

,

thanmoreto

thanmoretoto

RETsDETsOOmFP

RETsDETs

ccILF

Determining the Complexity of 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

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]


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)


Person (ILF)DETs = 3

( attributes )RETs = 2

( class + multivaluedaggr.)


Measuring Classes


∑∈

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


=

1010761075527551

515020191

,

thanmorea

thanmoretoto

RETsDETsOOmFP

RETsDETs

vlvlEIF


Low= 5, Average=7, High=10

Determining the Complexity of Legacy View


Measuring Legacy Views

Rate (EIF)[Low complexity = 7 UFP]


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


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.



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.



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


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


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


=

66446433243310

2019651

,

thanmoreaa

thanmoretoto

FTRsDETsOOmFP

FTRsDETs

ssEI



Determining the Complexity of Services


Measuring Class Services

createPerson (EI)[Low complexity = 3 UFP]

register (EI)[Low complexity = 3 UFP]


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.



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


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


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


∑∑==

z

ynContext

w

xyx

OOmFP11


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


∑∑==

z

ynContext

w

xyx

OOmFP11


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.


∑∑==

z

ynContext

w

xyx

OOmFP11


=

66446433243310

2019651

,

thanmoreaa

thanmoretoto

FTRsDETsOOmFP

FTRsDETs

ssEI



Determining the Complexity of Navigational Contexts


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]


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]


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


Thank you for your attention!!!

functional size measurement - oomfpweb - upvusers.dsic.upv.es/~sabrahao/fsm/oomfpweb-slides.pdf ·...

Documents