Dimensionierung von Webanwendungen

[SueHannan]

Ich bestimme eine Webanwendung und als Teil der Webanwendung, es gibt noch eine andere App (innerhalb der Grenze) das ist die Verwaltung von Inhalten auf der Website. Meine Frage bezieht sich auf die Anwendung, die den Inhalt verwaltet. Diese Anwendung füllt verschiedene Webseiten (unterschiedlicher logischer Anordnung) mit Überschrift, Fusszeile, und Kassetten-/Karussellinhalt. Wir dimensionieren mit der geschätzten NESMA-Methode, sodass keine DETs oder RETs verwendet werden. In diesem Sinne, Ich habe für jede Webseite ein ILF in Betracht gezogen, das ein anderes logisches Layout hat. Und dazu, wenn die Informationen auf der Seite beibehalten werden, die ich aufgenommen habe 3 NEIN. Außerdem, ein EO, da die Seite selbst nicht bestimmt ist (mit anderen Worten, es könnten 1-viele Patronen vorhanden sein). Können Sie bestätigen, dass wir die Größe genau angeben?? In Betracht ziehen 3 Webseiten unterschiedlichen logischen Layouts, wir würden am Ende mit 3 ILFs, 9 NEIN, und 3 EOs. Notiz, der Benutzer ist in diesem Fall das Unternehmen, das die Anwendung für die Website betreibt, auf die der Kunde letztendlich zugreift.

Und dazu, die Homepage (eine Webseite) hat eine Kopf- und Fußzeile, die beibehalten wird. Da es sich bei der Homepage um ein ILF handelt, wurde bereits mitgezählt 2 EIs und EO…dann würden die Kopf- und Fußzeile keine zusätzlichen EIs hinzufügen.

Während wir weiterhin verstehen, was hier bemessen wird, Wir haben auch die Website-App, auf die der Kunde zugreift. In diesem Fall, sie empfangen (ES IST DAS) die Homepage, so dass ein weiteres EO für die Daten von innerhalb der Grenze nach außen hinzugefügt würde (der Kunde).

Stimmt dies mit den NESMA-Regeln und Zählpraktiken überein??

[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), Fusszeile (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 NEIN. 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.

Grüße, 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 (1NEIN), populates footer (1NEIN), populates the carousel on home page (1NEIN), populates one cartridge A with a layout different from a second cartridge B (2NEIN), so all in all, 1 ILF and 5 NEIN…now what about the Add, Change, Löschen…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 NEIN?

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 diesem Fall, the end user (customer), queries the website and views the home page (with the header, Fusszeile, 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.

Vielen Dank!

[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, Veränderung, 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.

Vielen Dank

[Frank Vogelezang]

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

Website
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 (d.h.. 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…

Ja, we have one ILF for the web pages. Then for the HFC (one RET), we have 3 EI’s for the Add, Aktualisieren, Löschen. jedoch, 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, und 9 NEIN (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. jedoch, 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 beim 18:43?

[Frank Vogelezang]

No further comments. It made perfect sense to me.

[Autor]

Beiträge