boundary or not boundary? that’s the (asset) question! · boundary on a module for cots systems...

http://itconfidence2015.wordpress.com

Boundary or not Boundary?

3°International Conference on

IT Data collection, Analysis and Benchmarking

Florence (Italy) - October 19, 2015

That’s the (asset) question!

Luigi Buglione, Ph.D. Process Improvement & Measurement Specialist

Industry & Services Business Unit

Engineering Ing.Inf. SpA

http://www.gufpi-isma.org/

2 IT Confidence 2015 – October 19, 2015 http://itconfidence2015.wordpress.com

Boundary or not... Goals of the presentation

G1. Define what a boundary means today and its goal in IFPUG FPA, from Albrecht’s studies on, considering how new architectural design is dealt with in current software systems

G2. Come back to FPA definition and observe typical business cases from experience on the field

G3. Propose a common-sense solution matching business and technical viewpoint with the user’s viewpoint, as described in the CPM


Agenda

• Introduction

– What is a boundary?

• Background Info

– Some principles from FPA history…

– Boundary rules – IFPUG FPA CPM v4.3

• The Problem

– What could it arise?

– Some basic questions…

– Examples

• Analysis & solution

– Coming back to reading the CPM

– IFPUG FPA Counting Process

– Some (implicit/inner) traces

• Some conclusions

• Lessons learned

• Q & A

Boundary or not...


Q1: how many flats do you see in the picture on the right?

Q2: how many rooms in the flat?

Q3: could each room be arranged in a different way (furnitures, temperature, etc.)?

Q4: and if you were the ‘builder’, how much cement would you need for bulding (or not) the walls separating the rooms? Same quantity of resources or not?

Boundary or not... Introduction


Agenda

• Introduction


• Background Info



• The Problem



– Examples






• Lessons learned

• Q & A

Boundary or not...


Background info Some principles from FPA history...

Source:

• Albrecht A., Measuring Application Development Productivity, Proceedings of the IBM Applications Development Symp., Monterey, CA (USA), Oct.14-

17, 1979, URL: http://goo.gl/7r33X

•Albrecht A. & Gaffney J.E., Software Functions, Source Lines of Code, and Development Effort Prediction: A Software Science Validation, IEEE

Transactions on Software Engineering, vol. 9, no. 6, Nov. 1983, URL: http://goo.gl/FpNav

• The first Albrecht’s 1979 study Technology environment at that period was

(mostly) based on mainframes, with Cobol, CICS and DB2

About boundaries, it was supposed to ‘have ‘a’ boundary, not more: the ‘system’ was the ‘project, thus one solely boundary.

• The second Albrecht’s 1983-84 study and more... 1981: the first IBM PC ‘80s: first mid-range computers and more

attention to architectures ‘90s-Y2K: SOA architectures (multi-tier)

• Some principles FPA elements were proposed in order to

maintain a proportionality between a functional size and its related effort (those ratio is the so-called ‘productivity’)

The ‘user’ view was (and still is) the reference viewpoint for determining those elements, included where to place the boundary

http://goo.gl/7r33X

http://goo.gl/FpNav


Background info IFPUG FPA CPM v4.3 - Purpose, Counting Scope

Source: IFPUG, Function Point Counting Practice Manual, release 4.3.1, January 2010 – Part 2, Chapter 5; Glossary

• Purpose of the Count Conducted to provide an answer to a business

question. It is the business question that determines the purpose

It determines the type of FP count and the scope of the required count to obtain the answer to the business problem under investigation

Thus, it influences the positioning of the boundary between the software under review and the surrounding software (e.g. the users may decide to consider a module as a separate application)

• Counting Scope

It defines the set of FURs to be included in the FP count a (sub)set of the software being sized Identifies which functions will be included in the

functional size measurement could include more than one application

Application: «a cohesive collection of automated procedures and data supporting a business objective; it consists of one or more components, modules, or subsystems»

http://www.ifpug.org/



Background info

Source: IFPUG, Function Point Counting Practice Manual, release 4.3.1, January 2010 – Part 2, Chapter 5

• Boundary Conceptual interface between the software under

study and its user(s) 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 processes

by transactions pass into/out from the application (e.g. Web Services between layers in a multi-tier system)

Is dependent from the user’s external business view of the application

Is independent of technical and/or implementation consideration

• CPM v4.3 - new sentences from v4.2

Try to place the boundary from a business perspective rather than based on technical or physical considerations.

Important the boundary is placed with care, since all data crossing the boundary can potentially be included in the scope of the count ( influencing the functional size)

IFPUG FPA CPM v4.3 - Boundary




Background info


• Hints to Help Identify Counting Scope When identifying the scope of the installed/baseline

functional size, include ALL the functions currently in production and used by the users

• Hints to Help Identify Boundaries

Use the system external specs or get a system flow chart and draw a boundary around it to highlight which parts are internal/external to the application

Look at how groups of data are being maintained Identify functional areas by assigning ownership of

certain types of analysis objects Look at associated measurement data such as:

Effort Cost Defects

Boundaries for FPA and other measurement data should be the same

IFPUG FPA CPM v4.3 – Hints to help...




Agenda

• Introduction


• Background Info



• The Problem



– Examples






• Lessons learned

• Q & A

Boundary or not...


The Problem What could it arise?


• A literal application of CPM rules (till CPM v4.2) for FPA counts can lead to: “technical/physical considerations” if currently often be mislead as

something the business isn’t aware of, determining a lower number of FPs than the needed effort for producing/working on that block of functionalities is it possible to manage a system architecture without an agreement from the customer’s management?

Another impact can be seen from an Asset Management viewpoint, having a reduced amount of FPs than the real number of worked functionalities, reflected also by lower economic value in the Software Owner’s balance sheet a modified process cannot be classified as CHGA/DEL if it hasn’t ever being previously included in the functional baseline for that system (e.g. Web services exchanging data between layers)

From CPM v4.3.1, the ‘user’ can be also a system, not only a human it’s a common-sense and shared practice to place the boundary on a module for COTS systems such as SAP (each module is a subsystem defining a separate boundary)

The practical results could be to do not respect the aforementioned ‘proportionality’ factor from the productivity value (few FPs, many man/days)...that’s a business (not a technical) problem!




The Problem Some basic questions...

Source: IFPUG, Function Point Counting Practice Manual, release 4.3.1, January 2010

• Some (basic) questions: Q1: How many boundaries from a business viewpoint would you count with

IFPUG FPA? A layer in a SOA-architecture can be a boundary? When? Q2: Is an apparent single boundary or should it be considered as different

ones, even if from a technological viewpoint the (apparently) final saving action is only one?

Q3: Is it respected a proportionality principle between the functional size and effort measured both for estimation and asset management purposes?

Q4: in terms of benchmarking, should it be correct to sum sizes and efforts coming from different programming languages (PLs), DBs and (possibly) providers working on each layer?



The Problem (Two) possible scenarios

Some questions:

• how many boundaries (and FP) for Scenario#1and #2?

• Same effort/size or not?

• What about enhancement on a single piece of the architecture in the ‘middle’

of the architectural design?

• Is it really a ‘technical solution’ or is it a ‘business requirement’?

• Scenario #1

1 single

provider

• Scenario #2

More

providers


The Problem UML Sequence Diagrams

Some questions:

• how many boundaries (and FP) for Scenario#1and #2?

• Same effort/size or not?

• What about enhancement on a single piece of the architecture in the ‘middle’

of the architectural design?

• Is it really a ‘technical solution’ or is it a ‘business requirement’?

Each (sub)system:

• typically defines a

boundary

• Is owned by a

different actor


Agenda

• Introduction


• Background Info



• The Problem



– Examples






• Lessons learned

• Q & A

Boundary or not...


Analysis & Solution Some thoughts reading the CPM...

• Coming back to reading the CPM... In 1979 and ‘80s the ‘system’ was the ‘project’ and such technological environment led

to easily determine the boundary with each system

Nowadays the new way to work on IT systems cannot be seen as ‘technical consideration’ but a requirement from a customer (the so-called ‘business’) asking to a provider to consider such constraint when being engaged on a dev/enhancement project (e.g. SOA architectures, multi-layered systems)

Tip(s) of the problem [potential symptoms]:

an apparent too low productivity (too much effort and very few FPs)

A variable number of FPs counted according to the number of assigned providers for such job(s)

Difficulty to maintain in the functional baseline a ‘functionality’ never inserted before as an ADD

CPM states that ‘the boundary is dependent from the user’s external business view of the application and Is independent of technical and/or implementation consideration” [CPM v4.3.1, Part 2, p.5-4]

But...are we sure that sequence of EPs is a ‘technical requirement’ and not a ‘business requirement’?

Source: IFPUG, Function Point Counting Practice Manual, release 4.3.1, January 2010




• IFPUG FPA Counting Process Why?

Properly maintain the functional baseline for a system, feeding it with the real number of worked functional size units (fsu) also for sizing & estimating purposes in benchmarking activity when improving effort/cost forecasts

How? Analyze in critical manner the initial gathered documentation

decomposing the (apparent) single boundary into several boundaries (“divide-et-impera” principle) and run different counts, according to the customer initial URs whether they would satisfy a functional business purpose

the attention point would be in the FPA counting process steps #1-2

furthermore, step #1 is the “sliding door” for eventually splitting the unique boundary into several ones




• Some (implicit/inner) traces... Functionalities (EP/LF) apparently ‘inner’ to the system and managed in an

enhancement project couldn’t be (ac)counted in a functional baseline evidence from FURs/spec’s that this is a business requirement from customer and not a technical requirement proposed and apply solely from the ‘producer’ of the software for implicitly improving performances, but it’s a decision shared between parts Functionalities not trepassing the boundary cannot be accounted for FPA rules, not allowing

to formally modify such functionality in a next EFP count because never introduced before in the baseline. Two choices: (a) to consider them as ‘non-functional’ ones (see IFPUG SNAP, sub-char 1.4 ‘Internal Data Movement’) or (b) to define more detailed boundaries when a change in the ownership or in the technological characteristics (PLs, DB, etc...) occurs

Often a clear architectural design when gathering the documentation is not required/provided an oversimplification is consider a unique boundary for a system, but analyzing URs more in detail, more detailed boundaries could arise (info about the ‘web services’ or ‘multiple tiers’ could be omitted because seen as a technical detail and not an explicit req from the user) The ‘new’ sentences on page 5-4 before the picture and the hints on page 5-6 should be read

with care then such UR is a business one explicitly required/discussed between parts, it cannot be considered as a ‘technical consideration’ proposed and run by a provider without approval

A UML sequence diagrams typical defines the system actors each actor defines a (sub)system and each flow can be counted as an EP exchaging/storing data Also in this case, there would be several data groups possibly to be maintained during the

step of a workflow what happened and when, determining a functional update of such ILF/RET (not ‘code data’)

...



Agenda

• Introduction


• Background Info



• The Problem



– Examples






• Lessons learned

• Q & A

Boundary or not...


Boundary or not... Some Conclusions....

... Some possible tips Analyze the productivity levels for system logical ‘blocks’ where apparently too low,

it could be the symptom of some requirements as seen by the users to collapse more boundaries into an (apparently) unique one, involving more sub-systems (or modules) but generating issues also from an asset management viewpoint for such baselines.

FPA is a ‘logical analysis’ where each boundary should define the intended set of functionalities from business requirements as perceived by the users the key point is to analyze in detail URs in order to properly analyze a system architecture, in particular if there is evidence of a multi-tier environment (‘divide-et-impera’ principle)

Classify projects into the organizational projects’ historical database (PHD) separating different layers for a project as separated projects or it could help in dealing separately those kind of systems determining the right nominal productivity for each layer, according to its own functional size and related effort level

A further element always from IFPUG is the new SNAP methodology (APM v2.3), designed to be the companion for FPA for improving estimates, while sizing with NFRs what isn’t covered from FPA rules [SNAP APM v2.3, App B-2]

An optimist will tell you the glass is half-full; the pessimist, half-empty; and the engineer will tell you the

glass is twice the size it needs to be (Unknown)


Agenda

• Introduction


• Background Info



• The Problem



– Examples






• Lessons learned

• Q & A

Boundary or not...


Lessons Learned...

URL: www.dilbert.com

Boundary or not...

URL: http://goo.gl/bWIy4O

http://www.dilbert.com/





http://goo.gl/bWIy4O








Q & A

Thanks for your attention!

Grazie per la vostra attenzione!

Boundary or not...


Contact Data Boundary or not...

Luigi

Buglione GUFPI-ISMA / Engineering Ing. Inf.

[email protected]

[email protected]

http://www.eng.it/

boundary or not boundary? that’s the (asset) question! · boundary on a module for cots systems...

Documents