IWSM 2018 Forums Sizing Sizing – FPA FPA counting of web-services

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #4731
    Ilie Boarescu
    Participant

    I’m writing to you in regards to the method we should use when counting FPA in projects that use web-services. Maybe you can help me with some insight.
    I will describe two hypothetical scenarios in order to explain the situation.

    1. Standard scenario – no web services

    Requirements:
    The user must be able to create, view and edit Product information. In this situation we would count:

    Transaction Type Complexity Function points
    Product ILF Low 7
    Create Product EI Average 4
    View product EQ Average 4
    Edit product EI Average 4
    Total 19

    2. Our scenario – web services must be used

    Requirements:
    The user must be able to create, view and edit Product information.
    The data about the product is stored in another application. The application to be developed must send and retrieve data via web-services.

    In this situation, we can consider that the second application that stores the Product information is a second user.
    We count a transaction for every set of data that crosses the boundary of the application.

    Transaction Type Complexity Function points
    Create Product EI Average 4
    Request: Create product EQ Average 4
    Reply: Create product EI Average 4
    View product details EQ Average 4
    Request: Product details EQ Average 4
    Reply: Product details EI Average 4
    Update product details EI Average 4
    Request: Update product details EQ Average 4
    Reply: Update product details EI Average 4
    Total 36

    Is this approach correct? What kind of experience do you have with this kind of situations?

    #4913
    Martin Jacobs
    Participant

    Hello Ilie,

    I treat a situation like this as noted below.

    • Point of departure: Nesma FPA.

    Standard scenario
    Here we have one system and one system boundary to consider. Count this as stated.

    Web services
    Here we have two systems and two system boundaries to consider (we do not consider possible ESB as independent system in between for this example).

    Systems:
    • Frontend (FE) for the end user
    • Backend (BE) for the data storage

    The FE sends messages to BE and receives messages from the BE. The web services handle the messages and are part of the FE. The FE can be considered as a user of the BE (the FE has the lead).
    System to be counted is the FE, assumption is that the BE exists and doesn’t change.

    Based on this we can state that:
    • The FE has no ILFs, they are in the BE.
    • The web services do not have their own boundary.
    • BE: nothing to count.
    • To count: only the FE including the web services.

    So in the FE we are looking for transactional functions. A transactional function is a unique, elementary function from user point of view. Take into consideration that the messages to and from the BE are not elementary. They are part of the user transactions.

    So we count:
    • Create Product EI Average 4
    • View product EQ Average 4
    • Edit product EI Average 4
    Total 12
    In your 2. Our scenario, you also don’t count for the second application, as you consider it as a user. So you consider the messages from that user as unique, elementary functions. According to Nesma definitions (e.g. 7.1) they are not elementary however, so they should not be counted.

    If the BE does change, then messages and/or ILFs should be counted, for this BE, still not for the FE.

    Hope this helps!

    Regards,
    Martin Jacobs
    QSM Europe

    #5222
    EdwinvanGorp
    Participant

    Hello Ilie,

    This is not an easy question to answer.

    First of all: With FPA you measure the size of the functionality that an application provides to a user (Nesma guidelines; v2.1; section 3.1.2).

    Now, let’s add a third scenario.
    Requirements:
    The user must be able to create, view and edit product information.
    The data about the product is stored in another application, directly by the application that needs to be measured.

    In scenario 1, you have an application with the size of 19 FP.
    In scenario 3, the application does exactly the same from the end users point of view (the user that must be able to create, view and edit product information). So, in both scenario’s this user is offered the exact same functionality. This means that the size of the functionality (from the end users point of view) in both scenarios should be the same (in this case: 19 FP).

    Now my question is: what is, logically, the difference between your scenario 2 and my scenario 3?
    The webservices mentioned are part of the first application and are able to store and edit the data directly in the logical file, so there is no difference at all. And that means that the functional size of the first application is still 19 FP, whether it uses webservices or not (websevices are a technical implementation of the required functionality).
    Or, to put it differently, the requirements that the end user has do not change when you decide to use webservices to meet these requirements.

    #9279

    So Martin and Edwin,What to count for developing of the webservices in the backend BE?

    Let’s say that the BE allready has the product tables in place, but don’t have the webservices for providing the functionality to support Front End?
    For this the BE will get 3 webservices:
    * CreateProduct
    * GetProduct
    * UpdateProduct

    What to count for that functionality?

    #15978
    SueHannan
    Participant

    Hi, please tell me in Scenario 3, is the application being sized own the product file? Then in that case I can see the sizing to be the same. However, if the product file is owned by an application outside the system being counted it would be considered an EIF and therefore change the size.

    I clearly see though how scenario 1 and 2 in the first conversation would result in the same 19 FP’s assuming the product file is owned by the application being sized.

    Now, let’s ask this question, what if the web service is referencing a file outside the boundary like in the case of google maps, then would we keep everything the same except instead of an ILF it would be an EIF?

    #15979
    Frank Vogelezang
    Keymaster

    In scenario 3, as proposed by Edwin, the webservices are part of the application to be counted. I have no issue with the count.

    Alexander’s reply refers to something that I see quite often, that is that the back-end system is offering webservices to handle requests on the data. When these services must be built in the back-end system they will be counted similar to scenario 3.

    The functional size of a front-end system will not change, whether the webservices are available or not. The functionality that must be provided to the user is the same. The productivity will be very different when the functionality can be provided by calling existing webservices rather than building the full mechanism to handle the data in the back-end system.

    With regards to Sue’s first remark: When the application is able to change or create the data in the back-end system, the product-file is by definition an ILF, regardless of the fact that the architects say that product data belongs to the back-end system.

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.