e metrics - isbsg · separation of presentation (front-end) and processing (back-end) functions...
Post on 04-Feb-2021
2 Views
Preview:
TRANSCRIPT
-
© 2020 NTT DATA Corporation
Information Type:
Company Name: NTT DATA Italia S.p.A
Information Owner:
Measuring microservice architectures and cloud applicationsFunction Point Analysis and SNAP applied to contemporary architectures
CONFIDENTIAL
August 2020
NTTDATA Italia
Ena
ble
r‘S
OF
TW
AR
E M
ET
RIC
S’
Marcello Sgamma
-
2© 2020 NTT DATA Corporation
I. Evolution of application architectures
II. What is a boundary?
III. Measuring Service Oriented architectures
IV. Measuring microservice architectures
V. Application contexts in cloud enviroments
VI. Functional measurement in the cloud
VII. Conclusions
AGENDA
Ch
am
pio
ns ‘S
OF
TW
AR
E M
ET
RIC
S’
-
© 2020 NTT DATA Corporation 3
Evolution of architectures
-
© 2020 NTT DATA Corporation 4
Boundary definition
Defining a «loose» boundary prevents a correct measure of software complexityand value
On the other side, with too many boundaries FP count may increase too much(basically because of multiple counting of data functions) thus underminingmeasurement precision.
Granularity of Base Functional size Components (BFC)
Data functions (ILF, EIF): functional modeling of data functions should settlebetween the detailed level of DB tables structure and the abstraction level of high level business entities, keeping into account user perception. E.g.: Relation and extension tables are usually RETs of some ILF/EIF
Transaction functions or Elementary Processes (EI, EQ, EO): The smallest units of activity that are meaningful to the user(s); they must be
autonomous and leave the system in a consistent state Their primary intent mark their differences E.g.: different steps of a workflow may be portions of a single EP
Critical activities when measuring applications
-
© 2020 NTT DATA Corporation 5
When measuring advanced contemporary architectures, we need to
identify a software measurement approach that:
May pay for higher development costs
Without losing logical correctness of functional measurement
Basic principles:
Defining boundaries which correctly represent business needs
Identifying EPs with a granularity coherent with business needs
Measuring evolution
-
© 2020 NTT DATA Corporation 6
The boundary is a conceptual interface between the software under study and its
users.
Also referred to as application boundary, it defines what is external to the application;
indicates the border between the software being measured and the user;
acts as a ‘membrane’ through which data processed by transactions passes into and out from
the application;
encloses the logical data maintained by the application;
assists in identifying the logical data referenced by but not maintained within this application ;
is dependent on the user’s external business view of the application. It is
independent of technical and/or implementation considerations .
The boundary is determined based on the user's view . The focus is on what the
user can understand and describe.
The boundary between related applications is based on separate functional areas as
seen by the user, not on technical considerations.
[CPM 4.3.1, part 2, pp. 5-4, 5-5]
Boundaries in Function Point Analysis
-
© 2020 NTT DATA Corporation 7
From the theoretical point of
view, technological evolution
should not influence
functional measurement for
an application.
When defining the same
boundary and identifying the
same user functions within an
application, functional
measurement cannot change.
Evolution of architectures
could be a technical aspect,
unless…
-
© 2020 NTT DATA Corporation 8
In parallel with evolution of architectures, also user requirement have evolved, digging
from the functional level into technical and technological aspects.
Architectural and technological aspects, which formerly were designers responsibility
and suppliers assets (and therefore where out of scope for FPA, as technical ways to
deliver a function), have started to appear in bids and contracts:
• Initially service-oriented applications (SOA), allowing component reuse and reducing
development and maintenance costs
• Then microservice architectures, which add to stated SOA advantages higher
scalability and flexibility in technical constraints
Therefore we are facing a change in:
• Level of acknowledgement of application functions
• User view of the application
User requirements evolution
-
© 2020 NTT DATA Corporation 9
Typical situations can be:
Separation of presentation (Front-End) and
processing (Back-End) functions
Multi-channel and multi-supplier Front-End
Back-End environement with heterogeneous
technologies and suppliers
Therefore boundaries must be re-defined, for both
actors’ advantage, even if for different reasons
And even measurement granularity can change…
Measuring SOA
-
© 2020 NTT DATA Corporation 10
«monolithic» measurement
SOA example
2 disposal functions sharing user status checks
SOA measurement
Service 1
activation
Description Oper. Type Compl. FP
Service 1 activation ADD EI Avg 4
Service 2 activation ADD EI Avg 4
Total 8
User status
query
Service 2
activation
User status
query
Description Oper. Type Compl. FP
Service 1 activation ADD EI Avg 4
Service 2 activation ADD EI Avg 4
User status query ADD EQ Avg 4
Total 12
Service 1
activation
Service 2
activation
User status
query
-
© 2020 NTT DATA Corporation 11
When measuring a SOA architecture, an accurate and correct definition of boundaries
is fundamental. Where «correct» means:
Methodologically correct: if existence of a BE environment and of one or more FE
environments is stated and organic to business needs, it can’t be ignored, just
because of boundary definition
Correct with respect to business view: 3-tier implementation (presentation,
business logic, and DB) for an application is nowadays not enough to define a
boundary between presentation and business logic
Acknowledgement of FE and BE boundaries brings decomposition of any user function
into two EPs: one in the FE boundary and one in the BE one
Business logic decomposition into services may lead to identification of more EPs
than the classic approach, as a consequence of user’s awareness of component
services.
Measuring a Service Oriented Architecture
-
© 2020 NTT DATA Corporation 12
Each component service within a microservice
architecture may be developed, deployed, managed and
scaled without influence on other component services.
Services should not share any code or implementation
with other services.
Persistent data for a microservice, which actually are
part of its implementation, should be private and
segregated within the microservice.
Any communication between microservices occurs
through well defined APIs.
Therefore:
Migrating from SOA to microservices, some new
Elementary Processes may be identified.
Data functions should be segregated and associated to
microservices
Measuring a microservice architecture
-
© 2020 NTT DATA Corporation 13
Microservice example
2 disposal functions sharing user status checks
Microservice-boundary measurement
Description Oper. Type Compl. FP
Service 1 activation ADD EI Avg 4
Service 2 activation ADD EI Avg 4
User status query ADD EQ Avg 4
Total 12
Disposal actions
Microservice
User status
Microservice
User status
query
Service 1
activation
Service 2
activation
Single boundary measurement
Description Oper. Type Compl. FP
Service 1 activation ADD EI Avg 4
Service 2 activation ADD EI Avg 4
User status query ADD EQ Avg 4
Total 12
Disposal actions
Microservice
User status
Microservice
User status
query
Service 1
activation
Service 2
activation
-
© 2020 NTT DATA Corporation 14
Microservice example (with shared data functions)
2 disposal functions sharing user status checks
Microservice-boundary measurement
Disposal actions
Microservice
User status
Microservice
User status
query
Service 1
activation
Service 2
activation
Single boundary measurement
Disposal actions
Microservice
User status
Microservice
User status
query
Service 1
activation
Service 2
activation
Descrizione Oper. Tipo Compl. FP
Service 1 activation ADD EI Avg 4
Service 2 activation ADD EI Avg 4
User status query ADD EQ Avg 4
Customers ADD ILF Low 7
Totale 19
CustomersCustomers
Descrizione Oper. Tipo Compl. FP
Service 1 activation ADD EI Avg 4
Service 2 activation ADD EI Avg 4
User status query ADD EQ Avg 4
Customers ADD ILF Low 7
Customers@DispAct ADD EIF Low 5
Totale 24
-
© 2020 NTT DATA Corporation 15
There are three basic principles for microservice design:
Single purpose: Each service should entirely cover a single purpose.
Loose coupling: Services are unaware of other services. Communication between
services should occur only through public interfaces.
High level cohesion: Each service contains all related behaviours and data.
As a consequence of data segregation (cohesion), considering multiple boundaries in a
microservice architecture should have mimimum impact on measurement, as data
functions should be partitioned at microservice level.
Furthermore, simple application of correct guidelines for microservice design should
enforce a correct identification of BFCs with a granularity level appropriate for a correct
functional measurement:
Data functions: taken from data structures read/modified by each microservice
Elementary Processes: each distinct operation of each microservice
Therefore, from the methodological point of view, the best choice seems defining a
boundary for each microservice. But reality is ofeten somewhat different from theory…
Measuring a microservice architecture
-
© 2020 NTT DATA Corporation 16
Application contexts in a cloud environement
The 3 main cloud service
models (IaaS, PaaS and SaaS)
often cohexist in complex cloud
architectures.
FPA principles and measument
may apply also to cloud
environments, with obvious
different cost values applied to
different service models.
In the cloud, fee-based pricing
is used for FP measured
services.
-
© 2020 NTT DATA Corporation 17
Pricing a cloud application
-
© 2020 NTT DATA Corporation 18
Application context:
Informative and dispositive app
designed in microservices and
developed on cloud platform
HEROKU.
Structure: 45 operations, with
41 new, grouped in 10
microservices.
External interfaces: 24
services from legacy systems
may be invoked by operations.
Microservices measurement example (clean PaaS solution)
Microservice Operationsauthentication-service 6bill-service 4dispositive-service 2feintegration-service 5other-service 3profile-service 4pushnotification-service 4supply-service 5utility-service 7version-service 1
41
-
© 2020 NTT DATA Corporation 19
Context: ILFs within the
application and EIFs
corresponding to legacy methods
are clearly indentified
Single boundary measurement
BFC L M H Tot
EI 5 4 7 16
EQ 7 8 9 24
EO 1 1
ILF 20 20
EIF 24 24
-
© 2020 NTT DATA Corporation 20
BFC L M H Tot
EI 5 4 7 16
EQ 7 8 9 24
EO 1 1
ILF 22 22
EIF 47 47
Context: EPs are the same; we
count 2 more ILFs (shared
between microservices), and
replication of EIFs due to poor
segregation
Microservice-boundary measurement
-
© 2020 NTT DATA Corporation 21
Single boundary
FPs from EPs: 187 FPs from data: 256 FPs in total: 443
Comparing measurements
Microservice boundaries
FPs from EPs: 187 FPs from data: 389 FPs in total: 576
We note that
EPs do not change, as expected in a microservice architecture There is an increase of 50% in FPs coming from data functions (about
30% of application size) due to poor data segregation By grouping microservices in congruent «service contexts», driven by
domain knowledge and data sharing, a better funcional modeling (and measure) could be obtained
-
© 2020 NTT DATA Corporation 22
Application context: ServiceNow suite in HR application, interfacing
customer’s legacy systems.
Scope: redefinition of 3 internal workflows, in term of user stories.
Sw impacts:
Modification of native steps within the ServiceNow workflow addinginterface with legacy systems
Definition of new specific workflow steps Definition of new data structures and modification of existing ones
Sizing: using classic FPA is OK for measuring complexity (and effort).
Measuring in mixed PaaS/SaaS context: example 1
-
© 2020 NTT DATA Corporation 23
Application context : ServiceNow suitein IT operation context.
Scope: custumization of a trouble ticketing system to meet customer’s
needs.
SW Impacts:
Custom data entity added to suite data model (a new dimension for tickets’context)
Configuration of suite functionalities
Sizing:
Almost no functional impacts (1 ILF, some modified web form). Most of activities in data loading, product configuration and graphics need for non-functional sizing (maybe SNAP?)
Measuring in mixed PaaS/SaaS context: example 2
-
© 2020 NTT DATA Corporation 24
Guidelines for microservice measurement obviously apply also when microservices are
deployed in the cloud. Some additional advices may be:
Apply methodology when defining purpose and scope of measurement
Boundaries and pricing rates are key aspects
Some tips for boundary definition in microservice contexts:
The microservice approach eases Elementary Processes identification and makes them almost independent from boundary definition
A single boundary could not model correctly the higher complexity needed for design and development of a microservice solution
Microservice boundaries in situations with poor data segregation may lead to excess measurement
Grouping microservices based on data sharing could be a more suitable approach, when agreed with the customer view.
Some advices for measuring the cloud
-
© 2020 NTT DATA Corporation 25
Business functions measurements should be grouped for
Business functions to be customized Business functions to be configured Business functions to be developed
FPA is (the only methodology) valid in all cloud service models, but there is wide
variability in pricing rates (and few experiences too…).
In SaaS contexts, where most activities are configuration activities or anyway
answer non-functional requirements, a measurement methodology for non-
functional user requirements should be adopted. IFPUG SNAP is still young and
lacks widespread application, but could help to size complexity and estimate efforts
Some advices for measuring the cloud
-
© 2020 NTT DATA Corporation
Ch
am
pio
ns ‘S
OF
TW
AR
E M
ET
RIC
S’
-
27© 2020 NTT DATA Corporation
http://www.ifpug.org/Metric Views/MVBuglione.pdf
EFFORT DI PROGETTO UNA VISIONE GLOBALE
Come poter valutare e stimare effort e costi PRIMA
di realizzare il software?
http://www.ifpug.org/Metric%20Views/MVBuglione.pdf
top related