- Questo argomento ha 9 risposte, 2 voci, ed è stato aggiornato l'ultima volta 6 anni, 10 mesi fa di
.
-
Messaggi
-
Sto ridimensionando un'applicazione web e come parte dell'applicazione web, c'è un'altra app (entro il confine) cioè la gestione dei contenuti sul sito web. La mia domanda riguarda l'applicazione che gestisce il contenuto. Questa applicazione sta popolando varie pagine web (di diverso layout logico) con intestazione, piè di pagina, e contenuto della cartuccia/carosello. Dimensioniamo utilizzando il metodo NESMA stimato in modo che non vengano utilizzati DET o RET. Con quello in mente, Ho considerato un ILF per ogni pagina web che ha un layout logico diverso. Inoltre, se le informazioni sulla pagina vengono mantenute ho incluso 3 EI. inoltre, un EO poiché la pagina stessa non è determinata (in altre parole potrebbero esserci 1-molte cartucce). Puoi confermare che stiamo dimensionando con precisione?? Tenere conto 3 pagine web di diverso layout logico, finiremmo con 3 ILF, 9 EI, e 3 Suo. Nota, l'utente in questo caso è l'azienda che mantiene l'applicazione per il sito Web a cui accede in ultima analisi il cliente.
Inoltre, la home page (una pagina web) ha un'intestazione e un piè di pagina che vengono mantenuti. Poiché la home page è un ILF che è già stato contato insieme a 2 EI e un IT…quindi l'intestazione e il piè di pagina non aggiungerebbero ulteriori EI.
Mentre continuiamo a capire cosa viene dimensionato qui, abbiamo anche l'app del sito web a cui accede il cliente. In questo caso, stanno ricevendo (È IL) la home page in modo da aggiungere un altro EO per i dati dall'interno del confine all'esterno (il cliente).
È questo in accordo con le regole NESMA e le pratiche di conteggio??
ciao Sue,
Non penso che dovresti contare 1 ILF per pagina web, ma un ILF per pagine web con forse recordtype aggiuntivi per pagine web con un layout logico diverso. Questo dettaglio potrebbe non essere rilevante poiché stai facendo un'analisi di alto livello. Ogni particolare pagina web è un record in quell'ILF. La funzione che descrivi popola l'intestazione (1), piè di pagina (1) e carosello (1-n) di pagine web, dove puoi aggiungere, modificare ed eliminare alcuni di questi elementi per una determinata pagina web. Per questa funzionalità conterei 1 ILF e 3 NO. Il fatto che il resto del layout logico di pagine diverse potrebbe essere diverso, non è rilevante per questa funzionalità.
Ho dei dubbi sull'EO che conti. Sembra essere per la visualizzazione dell'intera pagina. Dalla tua descrizione questo sembra fuori portata per l'app descritta.
Saluti, Franco
Ciao Frank, La ringrazio per la risposta. Quindi lasciami ripercorrere di nuovo…
Ho un'app che popola i contenuti di un sito web. Popola l'intestazione (1NO), popola il piè di pagina (1NO), popola il carosello in home page (1NO), popola una cartuccia A con un layout diverso da una seconda cartuccia B (2NO), quindi tutto sommato, 1 ILF e 5 EI…ora che dire dell'Add, Modificare, Elimina…in alcuni casi puoi aggiungere una nuova cartuccia (stesso layout di A) e persino eliminare la cartuccia (stesso layout A), aggiungo un altro EI per l'aggiunta e un altro per l'eliminazione facendolo? 7 EI?
Ora separato dall'app che aggiunge contenuti alle pagine web, ho un'app (il sitoweb) che il cliente utilizza, quindi è stato conteggiato come parte del dimensionamento totale della mia applicazione. In questo caso, l'utente finale (cliente), interroga il sito web e visualizza la home page (con l'intestazione, piè di pagina, giostra, e dire una cartuccia)…questo è il mio EO per questa app.
Ha senso?
Il popolamento della pagina Web è svolto dall'azienda e il sito Web è un'applicazione rivolta al cliente. Sto considerando entrambe queste app nell'ambito del dimensionamento della mia applicazione.
Grazie!
Ho riletto e ora vedo, un ILF…3 EI per l'Add, Modifica ed Elimina. Quindi per tutte le altre interazioni, mi piace aggiungi, modificare, eliminare una cartuccia che contiene testo e URL e impostare il piè di pagina, la navigazione e altri contenuti non è un processo elementare separato?
Credo in base all'1-n sopra, che tenga conto di tutte le altre interazioni nell'impostazione dei contenuti per il sito web.
Grazie
Il modo in cui vedo la struttura dei dati nella maggior parte dei sistemi CMS:
pagina web
Intestazione
piè di pagina
carosello (1-n)
Soddisfare (1-X)La funzionalità che descrivi mantiene solo le occorrenze di intestazione/piè di pagina/caroussel, così vedo
– Aggiungi HFC
– Aggiorna HFC
– Elimina HFCLa visualizzazione della pagina totale (cioè. HFC + Soddisfare) è una funzionalità CMS diversa che non rientra nell'ambito della funzionalità per mantenere le occorrenze di HFC. Ha perfettamente senso includere l'EO per visualizzare la pagina all'utente nella dimensione funzionale dell'applicazione. Dovrebbero esserci altre funzionalità per popolare il contenuto del sito web.
Un layout diverso per un Caroussel A e B significa valori diversi per le funzioni con cui vengono mantenute le occorrenze HFC piuttosto che funzioni diverse a mio avviso.
Ciao Frank, Credo di seguire…
sì, abbiamo un ILF per le pagine web. Quindi per l'HFC (un RET), noi abbiamo 3 EI per l'Add, Aggiornare, Elimina. tuttavia, poiché ci sono altri due RET e non stiamo dimensionando usando RET's, abbiamo deciso di avere 2 x 3 EI per tenere conto del 2 altri RET e il 3 EI da aggiungere, aggiornare, cancella questi RET. Quindi, tutto sommato, abbiamo finito con 1 ILF, e 9 EI (3 per RET). Abbiamo concluso questo perché i DET in ogni RET sono diversi, quindi diverso layout logico che costituiva 3 EP unici per ogni RET. tuttavia, l'ILF è ancora 1. Abbiamo infatti rimosso gli EQ/EO per la visualizzazione del contenuto dei diversi layout delle pagine Web poiché questo non è lo scopo principale.
Grazie per tutto il tuo aiuto su questo e ha senso per noi.
Sentiti libero di continuare a dare feedback.
- Devi essere loggato per rispondere a questa discussione.