- Questo argomento ha 6 risposte, 2 voci, ed è stato aggiornato l'ultima volta 5 anni, 3 mesi fa di
.
-
Messaggi
-
[Questo post è stato originariamente pubblicato come risposta a questa discussione]
Ciao Frank, tutti
È corretto affermare che un EQ è necessariamente correlato a un FEI?
In altre parole, è possibile avere un EQ che non legge / interroga dati permanenti gestiti dall'applicazione esterna?
E questo, indipendentemente da come viene eseguita tecnicamente la query (ws, accesso diretto al database, …)?
Scusa se è una domanda stupida, I am kind of a newbie 🙂
Grazie per il tuo aiuto già
Caro Gram JS,
Non esiste una domanda sciocca quando stai cercando di padroneggiare FPA, quindi grazie per la domanda.La risposta breve alla domanda è NO.
Un EO presenta informazioni a un utente che sono state manipolate e / o la quantità di informazioni è sconosciuta.
- Per esempio, quando chiedo al registro del sito web di Nesma tutti gli utenti che si chiamano “Grammo” il registro non deve elaborare i dati, ma non posso sapere in anticipo quanti utenti verranno presentati. Questo è un esempio di un EO.
- Un altro esempio è un sistema del personale che contiene la tua data di nascita. Posso chiedere al sistema la tua età. Riceverò sempre una risposta, ma la risposta è stata ricavata dai dati di nascita, quindi deve essere prima manipolato.”
- È persino concepibile che non siano coinvolti ILF o ELF. Prendiamo ad esempio un'interfaccia batch o un servizio Web in grado di leggere file Excel o CSV con più record. L'elaborazione del batch è uno o più EI. Un report di quanti record sono stati elaborati è un EO.
Per l'EQ solo il numero di file logici di riferimento (Tipi di file a cui si fa riferimento) è rilevante, se questi sono interni o esterni.
(Avrai notato che ho usato ELF invece di EIF. Questa è la nuova Nesma 2.3 terminologia.)
Spiegazione molto chiara Frank, Grazie mille.
In realtà sto cercando di fare un 'indicativo’ misurazione (che si basa solo sul conteggio dei file logici). E ora sono un po 'perso perché non so quando ho contato un ELF per il (futuro) applicazione che sto cercando di ridimensionare quando interroga (principalmente attraverso ws) dati permanenti da altre applicazioni. Anche, Non ho alcun modello di dati concettuale o altro a mia disposizione. Hai un suggerimento?
Dipende un po 'dalla scala della stima delle dimensioni che stai facendo.
Il metodo indicativo è adatto per un'intera applicazione. Quindi si tenta di costruire un modello concettuale della propria applicazione e dei dati che deve interrogare dalle applicazioni circostanti. In tal caso è possibile utilizzare l'ELF come elemento concettuale per i dati dalle applicazioni circostanti.
Quando si effettua una stima delle dimensioni di un numero limitato di servizi web, poi l'Alto livello (o stimato come lo chiamava Nesma) metodo. Allora non ti preoccupi dell'ELF, poiché comunicherai tramite EI ed EO con le applicazioni circostanti.
Spero che questo ti aiuti.
….perché non contare gli ELF quando si utilizzano i servizi web?
Ho pensato al mezzo che l'applicazione utilizza per consumare i dati (ws, accesso diretto al database, eccetera) dell'applicazione esterna non aveva importanza?Secondo la mia conoscenza, un tipo di entità esterna soddisfa i seguenti criteri:
• Viene utilizzato dall'applicazione per essere conteggiato.
• Non viene mantenuto dall'applicazione per essere conteggiato.
• È gestito da un'altra applicazione.
• È direttamente disponibile per l'applicazione da contare..Utilizzato significa che i dati vengono effettivamente utilizzati anche nel processo di candidatura.
Mantenuto indica che è possibile aggiungere, modificare, o eliminare i dati.
Direttamente disponibile significa che l'applicazione in questione ha sempre i dati aggiornati a sua disposizione, anche se un'applicazione diversa mantiene questo tipo di entità.L'uso di ws cambia qualcosa in questo? Consideriamo ad esempio che i dati non lo sono “direttamente” disponibile quando si accede tramite ws?
Grazie già per il tuo aiuto
Quando si recuperano dati tramite un servizio web, questo non viene considerato disponibile direttamente. Ecco perché la comunicazione con un servizio web in un'analisi di alto livello viene conteggiata come una coppia di EI ed EO, piuttosto che un ELF. In un conteggio indicativo non ti preoccupi di questo tipo di dettagli e conti una fonte di dati al di fuori della tua applicazione come ELF.
Spero che questo ti aiuti.
Ciao Frank,
Tutto il meglio per questo nuovo anno. 🙂
L'identificazione degli ILF e degli ELF è davvero quello che sto cercando di fare qui.
Non c'è sempre un ELF dietro una ws?
Perché non è considerato direttamente disponibile?
….Ho pensato al modo in cui l'applicazione recupera le informazioni (qui tramite un ws) non importava
….Non vedo fondamentalmente la differenza tra l'accesso alle informazioni tramite un JDBC o tramite un ws…Anche, dici che un ws è piuttosto visto come un EI / EO. Anche quando le informazioni recuperate tramite il ws servono solo (è significativo per) una transazione più grande?
Perché leggendo la definizione di un file “Processo elementare (EP)” qui sotto, sembra che nel mio caso la query ws non sia una transazione completa in sé poiché fornisce solo informazioni a una transazione più grande, che è di per sé significativo per l'utente.
Un EP è la più piccola unità di requisito funzionale dell'utente che:
È significativo per l'utente.
Costituisce una transazione completa.
È autonomo e lascia l'attività dell'applicazione che viene conteggiata in uno stato coerente.Grazie ancora per aver condiviso la tua conoscenza ed esperienza e per il tuo tempo.
I migliori saluti
JS
- Devi essere loggato per rispondere a questa discussione.