Program

ISMA12 – Overall Program (May 3-5)

ISMA12_Conf Structure_v03


ISMA12 will include the following activities:

 

  • Workshops (May 3, 4) – valid each for 3 PDUs (Technical)
  • IFPUG CSP Exam (May 4, h11.00/13.15) – Registrations closed
  • IFPUG Board meets the Italian Community (May 4, afternoon – h 14.30/15.30) – Free event
  • GUFPI-ISMA Meeting (May 4, afternoon – h 15.45/16.45) – GUFPI-ISMA Members only
  • MAIN meeting (May 4, afternoon – h 17.00/18.00) – Free event as observers
  • Social Dinner (May 4, evening – h 19.00/21.00) – Pommidoro restaurant (by reservation)
  • ISMA12 (Conference) (May 5, h 09.30/17.00) – valid for 1 CEC IFPUG (CEP) and 5 PDUs (3 Technical, 2 Strategy)

 

Conference Day (May 5) (alphabetical order)

Cronigramma_v03

 

  • T.BarbieriLeveraging Enterprise Architectural Standards for Automated Function Point Analysis in Agile/ADM Processes
    “Software Factories” dealing with massive amounts of code produced by external vendors with Agile processes (ADM) need to implement a QA approach with well-defined SLAs, if possible in an automated way. Leveraging current ORM/MVC  standards using Object-Oriented Technical Specifications for counting purposes allows to include Functional Size in Agile Measurements, which is not captured by Agile approaches like Ideal Days, Velocity, Story Points. We propose a mapping for Counting Practices between IFPUG CPM FPA and Java Enterprise JPA 2.1 and JSF 2.1, two de-facto standards for ORM and MVC in Enterprise Architectures. This mapping could allow automatic sizing and provide a stable metric for SLAs. We present early result of a code-inspection plug-in for SonarQube, which can be leveraged to analyse code and reverse-engineer a functional sizing measurement.
  • T.Ben-Cnaan, C.GreenC.Symons, L.SantilloAccounting for Non-functional and Project requirements: COSMIC and IFPUG developments
    The tasks of measuring performance of a set of software projects, of developing performance benchmarks and of estimating effort for future projects can only be achieved by gathering consistent data on the requirements for the software products, on the functional, non-functional and project’s requirements and constraints for the software projects and on the actual outcomes. The COSMIC and IFPUG organizations have long-established methods of measuring the size of the functional requirements for the software product. But the problems of gathering consistent data on the non-functional requirements and on the project requirements and constraints suffer from a lack of clear definitions and of consistent terminology and standards across these activities. Views differ on how to measure non-functional requirements. Although COSMIC and IFPUG have tackled these problems in different ways, they collaborated in the area of creating a Glossary of terms for non-functional requirements and for project requirements and constraints. The presentation will describe the work that was done together, why the glossary is important, what it contains, and the COSMIC and IFPUG approaches to the sizing of non-functional requirements.
  • R.FernandezSoftware Rates vs Cost per Function Point, Productivity and Quality
    During the last three years, LEDAmc has been analyzing the relationship between the Software Rates and the cost per Function Point using its own database of more than 18.000 Software Development Projects. Leaning on a statistical demonstration, the main conclusion reached in the previous studies was that excessive pressure on software rates destroys the concept of software rates in outsourcing processes. LEDA’s database is growing continuously with statistical data of projects from several of the most important IT Companies in Spain, allowing LEDAmc to show in this third study the behavior of the Software Quality related with its Productivity in real scenarios.
  • P.FerrariRisk and AFP Measurement in a digital transformation program, Allianz Italia use case
    One of the most relevant Italian financial institution will explain his experience in preventing operational risks in a big digital transformation project where its core business assets has been totally rebuilt. They will also illustrates how they setup the contextual measurement of the functional size, with AFP, for the whole digital portfolio, in order to measure the baseline size and the vendors’ productivity.
  • G.LanzaFUR and NFR: two sides of the same coin
    In the software world one important issue has been: how can forecast the cost of developing software products? The answer is theoretically quite simple:  measuring them! In the sixties the software products were developed in assembler language, they were standalone programs and there was no interaction between them. It was a simple world!  In the seventies the progress brought to more complex systems, and to the need of modelling data and to analyze better the FUR, so Alan Albrecht and his stuff give us Function Point!
    Nowadays we’re talking of Web Services, Internet Of Things, Open Data, Big Data and so on, the software products architecture are becoming more more complex and the only FUR are not  sufficient any more to evaluate the developing software process. In this context NFR are always becoming more and more important, and in some cases there are fundamental to price a product! How can we measure them? IFPUG  SNAP (Software Non Functional Assessment Process) is a way to answer this. The complexity of ICT World today highlight us that this is not a simple process and that the variables that have to take into account are many and very often not clear! It’s typical of a wise people to face many questions, it’s typical of a stupid people to pretend all the answers. This presentation face to these questions:

    • How can we distinguish FUR by NFR?
    • How can Snap Point can coexist with Function Point?
    • How can Snap Point help the PM in governing the project?
    • Can all the activities in developing software be measured?
    • NFR and quality: does a correlation exist?

    But the main question is: how does this presentation answer these questions?

  • L.Lavazza, S.Morasca, Some considerations on Function Points (as a measure)
    Researchers and practitioners have discussed and criticized several aspects of the definition of Function Points (FP), including “what do FP actually measure,” the scale of FP, and the additivity of the functional sizes of different BFC Types.In this presentation, we do not aim at discussing the theoretical aspects of the definition of FP. Instead, we show that the concepts and practices used in Function Point Analysis are commonly used in other areas and disciplines, where they are widely accepted. An example, illustrating the problem of assessing the value of an apartment is presented. It is highlighted that the value of the apartment and its sale price are different concepts. It is shown that the value and sale price are affected by both characteristics of the apartment and factors that depend on the environment.The construction of statistical models for the value and the sale price is briefly discussed. Finally, it is shown that the concept (hence, the measure and the assessment process) of an apartment value is very similar to the concept of functional size of a software application. Similarly, the apartment sale price is similar to the software development cost, as the two values are estimated via very similar processes and statistical models. It is thus possible to conclude that in practice Function Points are defined and used like other practically useful measures, which are hardly subject to theoretical discussions and criticisms from theoretical.
  • R.MeliA Management viewpoint on Software Measurement
    In the world of economical goods, software is a very peculiar entity because of its immaterial nature and because of the related production processes. Despite the “engineering” tag often associated to them, software is still produced like a craftwork in most real business organizations. Consequently, software measurement, outside the academic world, is not a truly formal discipline. Most of the useful software measurement methods depend on quite subjective dimensions. Approximate approaches are often preferred to rigorous approaches and “better” is preferred to “best”. Managers are interested into software measures that could demonstrate to give a valuable contribution to the software governance process. In the Manager’s perspective, software measurement is a mean not a goal: a good estimate is better than a perfect measure. They do not fall in love with methods and are not interested in the beauty or rigor of models. They only like models that “work” for business governance. Some of the measurement characteristics that are liked are: cheapness, timeliness with respect to managerial needs, adaptability to evolving environments, precocity, reliability, scalability, flexibility, usability, learnability, comparability, robustness. The presentation  will explore many aspects related to software measurement from the management perspective, pointing out myths and assumptions that are produced by a too technical or theoretical attitude.

The case study presents an application of IFPUG FPA in the Energy / Utilities domain about systems using multi-component architectures. Several aspects and guidelines applied will be discussed (e.g. counting of web services (WS), macrofunzionalità and reuse), as well as lessons learned.

Advertisements