Sizing Web Applications

[SueHannan]

I am sizing a web application and as part of the web app, there is another app (within the boundary) that is managing content on the website. My question is pertaining to the application managing the content. This application is populating various web pages (of different logical layout) with header, footer, and cartridge/carousel content. We size using the Estimated NESMA method so no DET’s or RET’s are used. With that in mind, I have considered an ILF for each web page that is a different logical layout. In addition, if the information on the page is maintained I have included 3 EI’s. Furthermore, an EO since the page itself is not determined (in other words there could be 1-many cartridges). Can you confirm we are sizing this accurately? Consider 3 web pages of different logical layout, we would end up with 3 ILF’s, 9 EI’s, and 3 EO’s. Note, the user in this case is the business maintain the application for the website which ultimately is accessed by the customer.

In addition, the home page (one web page) has a header and footer that is maintained. Since the home page is an ILF that has already bee counted along with 2 EI’s and an EO…then the header and footer would not add any additional EI’s.

As we continue to understand what is being sized here, we also have the website app that the customer accesses. In this case, they are receiving (EO) the home page so it would add another EO for the data from inside the boundary to outside (the customer).

Is this in agreement with the NESMA rules and counting practices?

[Frank Vogelezang]

Hi Sue,

I don’t think that you should count 1 ILF per webpage, but an ILF for webpages with perhaps additional recordtypes for webpages with a different logical lay-out. That detail might not be relevant since you are doing a high-level analysis. Any particular webpage is a record in that ILF. The function you describe populates the header (1), footer (1) and carrousel (1-n) of webpages, where you can add, modify and delete some of these elements for any given webpage. For this functionality I would count 1 ILF and 3 EI. The fact that the rest of the logical layout of different pages might be different, is not relevant for this functionality.

I am in doubt about the EO you count. It seems to be for the display of the whole page. From your description this seems out of scope for the app described.

Regards, Frank

[SueHannan]

Hi Frank, thank you for your answer. So let me run through it again…

I have an app that populates content on a website. It populates header (1EI), populates footer (1EI), populates the carousel on home page (1EI), populates one cartridge A with a layout different from a second cartridge B (2EI), so all in all, 1 ILF and 5 EI’s…now what about the Add, Change, Delete…in some cases you can add a new cartridge (same layout as A) and even delete cartridge (same layout A), do I toss in another EI for the add and another for the delete making it 7 EI’s?

Now separate from the app that adds content to the web pages, I have an app (the website) that the customer uses, so that has been counted as part of my total application sizing. In this case, the end user (customer), queries the website and views the home page (with the header, footer, carousel, and say a cartridge)…this is my EO for this app.

Make sense?

[SueHannan]

The populating of the webpage is done by the business and the website is a customer facing application. I am considering both these apps as in-scope for my application sizing.

Thanks!

[SueHannan]

I re-read and I see now, one ILF…3 EI’s for the Add, Modify and Delete. So for all the other interactions, like add, change, delete a cartridge that contains text and urls and setting up the footer and the navigation and other content is not separate elementary process?

I believe based on the 1-n above, that would take into account all the other interactions in setting up content for the website.

Thank you

[Frank Vogelezang]

The way I see the data structure in most CMS systems:

webpage
Header
Footer
Caroussel (1-n)
Content (1-x)

The functionality you describe only maintains the Header/Footer/Caroussel occurrences, so I see
– Add HFC
– Update HFC
– Delete HFC

The display of the total page (i.e. HFC + Content) is different CMS-functionality that is out-of-scope for the functionality to maintain HFC occurrences. It makes perfect sense to include the EO to display the page to the user into the application functional size. There should be other functionality to populate the content of the website.

A different layout for a Caroussel A and B means different values for the functions with which the HFC occurrences are maintained rather than different functions in my view.

[SueHannan]

Hi Frank, I believe I am following…

Yes, we have one ILF for the web pages. Then for the HFC (one RET), we have 3 EI’s for the Add, Update, Delete. However, since there are two other RET’s and we are not sizing using RET’s, we determined we have 2 x’s 3 EI’s to account for the 2 other RET’s and the 3 EI’s to add, update, delete these RET’s. So all in all we ended up with 1 ILF, and 9 EI’s (3 per RET). We concluded this as the DET’s in each RET are different so therefore different logical layout which constituted 3 unique EP’s for each RET. However, the ILF is still 1. We did in fact remove the EQ’s/EO’s for viewing the content of the different web page layouts since this is not the primary purpose.

Thanks for all your help on this and it makes good sense to us.

Feel free to continue to give feedback.

[Frank Vogelezang]

Sue,

Glad to be able to help out. Thank you for this discussion.

[SueHannan]

Hi Frank, did you have any comments or thoughts to our last post on 06/19/2017 at 18:43?

[Frank Vogelezang]

No further comments. It made perfect sense to me.

[Author]

Posts