IWSM 2018 Forums Sizing Sizing – FPA Change factors in Nesma FPA

This topic contains 5 replies, has 3 voices, and was last updated by  Leandro Kirsch 3 years, 6 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #6485

    Leandro Kirsch
    Participant

    Here in IT Brazil market there is a concept of Change Factor that is used for several and big companies that is stated by all that is NESMA rule. I’ve recently got associated and could read the FPA manual and I did not find any reference to that.

    Here a summary of those change factors and formulas:

    Change factors in Nesma FPA

    Is that really sourced by NESMA? I’ve impression that might be part of NESMA FPA prior to be ISO standard, but that is only a guess from my side (and possible incorrect…)

    Can some help me with that?

    Thanks in advance,
    Leandro Kirsch

    #6488

    Frank Vogelezang
    Keymaster

    Leandro,

    These formulas do come from a Nesma source, but as you have observed correctly, they do not come from the Nesma standard. They come from a guide FPA for Software Enhancement, or APF para Melhoria de Software in Portuguese. This alternative approach was designed to allow for one productivity figure for both newly built software and enhancements to existing software. Since this is a mix of size and productivity (according to the ISO/IEC 14143 definitions) this approach cannot be part of the Nesma standard, for functional size. It is a popular extension to the Nesma and IFPUG standard and documented use is described in the Netherlands, Brazil and South Korea. Whether it really is an improvement of the use of the standard way of sizing enhancements is a longstanding debate within the Nesma community. I wrote an article about it that has been published as best paper at the 2014 IWSM Mensura conference: The Added Value of Enhancement Function Points – An Empirical Evaluation. As far as I am aware this is the only documented comparison between the standard approach and the alternative approach.

    Hope this helps.

    #7524

    Leandro Kirsch
    Participant

    Hello Frank,

    Sorry for long no response I was enjoying my long annual leave and end year parties! I wish you a happy 2016!

    After reading documents you mentioned as listed below:
    FPA for Software Enhancement EN v2.2.1
    APF para Melhoria de Software PT v2.2.1
    2014 IWSM Mensura – The Added Value of Enhancement Function Points – An Empirical Evaluation

    I come up with few conclusions of the FPA for Software Enhancement Guide that I’d like your or appropriate board members opinion:
    1. These guidelines ignore at all the concept of Record Element Type for the impact factor when analysing the Data Functions;
    2. As mentioned in Disclaimer section (1.6) NESMA advises these guidelines require research and practical use and has not been yet validated scientifically;
    3. As mentioned several times, standard FPA count should either be provided or done prior to use those guidelines and others prerequisites also defined and should be taken in consideration;
    4.These guidelines have been elaborated by NESMA however using as base all the information provided by NESMA and IFPUG in both FPA ISO Standards (24570 and 20926 respectively) ;
    5. Although based on the mentioned Standards I would state if IFPUG rules have been used for development project count the same rules should be used for the enhancement project count; on the other hand if NESMA rules have been used for development project count the same rules should be used for the enhancement project count;
    6. The usage of IFPUG rules in the development project count and the NESMA rules in the enhancement project count or vice-versa should not be encourage. My main concern when using different rules in different counts is that although minor in a whole development project count, for an enhancement project count those can be significant. E.g. NESMA and IFPUG diverge in External Inquiry and Outputs definitions and if a given enhancement project has majority of impact onto those kind of functions maybe EFP might be quite different than expected;
    7. In section 5 – Budgeting Enhancement it is advised that in general EFP (Enhancement) and TFP (Testing) productivity hours differ from the hours per function point when using standard FPA method.
    8. In the Empiric evaluation shared in 2014 IWSM based on the Apex enhancement it seems the variations using standard FPA units were smaller than using EFP method and then in that context Standard FPA seems to be more reliable than EFP.

    Interested to listen other NESMA members thoughts about above my comments.
    Leandro Kirsch

    #7527

    Frank Vogelezang
    Keymaster

    Leandro,

    Thank you for your observations. Here are a few of the answers I can give with certainty.

    2. As far as I am aware my 2014 IWSM article is the only known scientific validation of the Enhancement FPA.

    3. The regular FPA is indeed the basis to perform Enhancement FPA

    4. You can use this approach with IFPUG FPA as basis. From what I have heard about the application of this approach this is quite common in countries that are more familiar with IFPUG than Nesma as base FPA metric.

    8. I have never experienced a real advantage of the Enhancement FPA method over the use of the standard enhancement approach of IFPUG or Nesma. The dataset that I presented in the 2014 IWSM paper seems to support that experience, although the statistics are not a firm rejection of the approach.

    Hope this helps.

    #7528

    Ton Dekkers
    Participant

    Leandro, First some history. Although I’,m “officially” involved in EFPA later, the basis is set at the time I was working for a Dutch Bank in the early 90’s . There was always a discussion about application of FPA in enhancements. Especially management that had to approve the budget challenged the number of FP: how could a simple change have the same FP as new development? Although for budgeting purposes the productivity was adjusted. Nevertheless the bank asked me to develop something that would better fit to their perception. I used the FPA principles: if DET, RET, FTR determine the complexity of a function , changes of these elements might be a good measure to identify the complexity of the change. In my original approach I had 4 categories (and I still prefer to use those)- Simple change , average, change, compex change and test only. My formulas are using the number of changes, not the percentile. In my “research” for the bank (based on 5 projects) I came up with a matrix similar to the ones in EFPA only with absolute numbers and based on Nesma FPA 1.0 (not ISO at that time). The “calculated” factors 0.27, 0.47 and 0.72 are changed to 0.25, 0.50 and 0.75 also to get away from the perception that this approach is accurate. Anyway the bank was happy with the approach and it worked pretty well in that period with the IT activities within that organization.
    It’s then picked up by a Nesma working group and they created the original document. This is adjusted to Nesma 2.2 later with me as editor.
    The origin of EFP is still the ISO approach. Determine the number of FP based on the chosen standard (Nesma or IFPUG). Use the the Change Factor to determine (consistent) the complexity of the change. If your base is IFPUG, use IFPUG rules to determine the change. Keep also the rules consistent.
    “Ignoring” the RET is something from history. At the time of origin of the Nesma approach, RET not equal 1 was quite rare. To keep the approach simple, this was not that relevant to incorporate.
    Because of the lack of scientific evidence and the possible conflict of the compliance with ISO the disclaimer was added in the 2.2.1. release.
    I assume the main reason that EFPA is used, it’s more meeting the perception of especially non-FPA experts. And after all these years I experience it still as useful to identify the complexity of the change.
    Ton Dekkers

    #7530

    Leandro Kirsch
    Participant

    Many thanks both for fast and detailed reply.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.