- Questo argomento ha 5 risposte, 6 voci, ed è stato aggiornato l'ultima volta 6 anni, 10 mesi fa di
.
-
Messaggi
-
Ti scrivo in merito al metodo che dovremmo utilizzare per il conteggio degli FPA nei progetti che utilizzano servizi web. Forse puoi aiutarmi con qualche intuizione.
Descriverò due scenari ipotetici per spiegare la situazione.1. Scenario standard: nessun servizio web
Requisiti:
L'utente deve essere in grado di creare, visualizzare e modificare le informazioni sul prodotto. In questa situazione conteremo:Transazione genere Complessità Punti funzionali Prodotto ILF Basso 7 Crea prodotto NO Media 4 Visualizza il prodotto EQ Media 4 Modifica prodotto NO Media 4 Totale 19 2. Il nostro scenario: i servizi web devono essere utilizzati
Requisiti:
L'utente deve essere in grado di creare, visualizzare e modificare le informazioni sul prodotto.
I dati sul prodotto vengono memorizzati in un'altra applicazione. L'applicazione da sviluppare deve inviare e recuperare dati tramite servizi web.In questa situazione, possiamo considerare che la seconda applicazione che memorizza le informazioni sul prodotto è un secondo utente.
Contiamo una transazione per ogni set di dati che attraversa il confine dell'applicazione.Transazione genere Complessità Punti funzionali Crea prodotto NO Media 4 Richiesta: Crea prodotto EQ Media 4 rispondere: Crea prodotto NO Media 4 Visualizza i dettagli del prodotto EQ Media 4 Richiesta: Dettagli del prodotto EQ Media 4 rispondere: Dettagli del prodotto NO Media 4 Aggiorna i dettagli del prodotto NO Media 4 Richiesta: Aggiorna i dettagli del prodotto EQ Media 4 rispondere: Aggiorna i dettagli del prodotto NO Media 4 Totale 36 Questo approccio è corretto? Che tipo di esperienza hai con questo tipo di situazioni?
Ciao Ilie,
Tratto una situazione come questa come indicato di seguito.
• Punto di partenza: Nesma FPA.
Scenario standard
Qui abbiamo un sistema e un confine di sistema da considerare. Conta questo come dichiarato.servizi web
Qui abbiamo due sistemi e due confini di sistema da considerare (non consideriamo possibile ESB come sistema indipendente in mezzo per questo esempio).Sistemi:
• Fine frontale (FE) per l'utente finale
• Backend (ESSERE) per l'archiviazione dei datiLa FE invia messaggi a BE e riceve messaggi da BE. I servizi web gestiscono i messaggi e fanno parte della FE. La FE può essere considerata come un utente della BE (la FE ha il comando).
Il sistema da contare è il FE, presupposto è che l'ES esista e non cambi.Sulla base di questo possiamo affermarlo:
• La FE non ha ILF, sono in BE.
• I servizi web non hanno un proprio confine.
• BE: niente da contare.
• Contare: solo la FE compresi i servizi web.Quindi nella FE stiamo cercando funzioni transazionali. Una funzione transazionale è unica, funzione elementare dal punto di vista dell'utente. Tieni presente che i messaggi da e verso la BE non sono elementari. Fanno parte delle transazioni dell'utente.
Quindi contiamo:
• Crea media EI prodotto 4
• Visualizza media EQ prodotto 4
• Modifica media EI prodotto 4
Totale 12
Nella tua 2. Il nostro scenario, inoltre non conti per la seconda applicazione, come lo consideri un utente. Quindi consideri i messaggi di quell'utente come unici, funzioni elementari. Secondo le definizioni di Nesma (per esempio. 7.1) tuttavia non sono elementari, quindi non dovrebbero essere contati.Se la BE cambia, quindi i messaggi e / o ILF dovrebbero essere contati, per questo BE, ancora non per la FE.
Spero che questo ti aiuti!
Saluti,
Martin Jacobs
QSM EuropaCiao Ilie,
Questa non è una domanda facile a cui rispondere.
Prima di tutto: Con FPA si misura la dimensione della funzionalità che un'applicazione fornisce a un utente (Linee guida Nesma; v2.1; sezione 3.1.2).
Adesso, aggiungiamo un terzo scenario.
Requisiti:
L'utente deve essere in grado di creare, visualizzare e modificare le informazioni sul prodotto.
I dati sul prodotto vengono memorizzati in un'altra applicazione, direttamente dall'applicazione che deve essere misurata.In scenario 1, hai un'applicazione con le dimensioni di 19 FP.
In scenario 3, l'applicazione fa esattamente lo stesso dal punto di vista degli utenti finali (l'utente che deve essere in grado di creare, visualizzare e modificare le informazioni sul prodotto). Così, in entrambi gli scenari a questo utente viene offerta la stessa identica funzionalità. Ciò significa che la dimensione della funzionalità (dal punto di vista degli utenti finali) in entrambi gli scenari dovrebbe essere lo stesso (in questo caso: 19 FP).Ora la mia domanda è: cosa è, logicamente, la differenza tra il tuo scenario 2 e il mio scenario 3?
I webservice citati fanno parte della prima applicazione e sono in grado di memorizzare e modificare i dati direttamente nel file logico, quindi non c'è alcuna differenza. Ciò significa che la dimensione funzionale della prima applicazione è ancora 19 FP, se utilizza o meno servizi web (I dispositivi web sono un'implementazione tecnica della funzionalità richiesta).
O, per dirla diversamente, i requisiti che l'utente finale ha non cambiano quando si decide di utilizzare i servizi web per soddisfare questi requisiti.Quindi Martin ed Edwin,Cosa contare per lo sviluppo dei servizi web nel backend BE?
Supponiamo che BE abbia già le tabelle dei prodotti in atto, ma non hai i servizi web per fornire la funzionalità per supportare il front-end?
Per questo la BE otterrà 3 servizi web:
* CreateProduct
* GetProduct
* UpdateProductCosa contare per quella funzionalità?
Ciao, per favore dimmelo in Scenario 3, è l'applicazione da ridimensionare possiede il file del prodotto? Quindi in quel caso vedo che il dimensionamento è lo stesso. tuttavia, se il file del prodotto è di proprietà di un'applicazione esterna al sistema da conteggiare, verrebbe considerato un EIF e quindi cambierà la dimensione.
Vedo chiaramente però come scenario 1 e 2 nella prima conversazione risulterebbe lo stesso 19 FP presuppone che il file del prodotto sia di proprietà dell'applicazione da ridimensionare.
Adesso, facciamo questa domanda, cosa succede se il servizio web fa riferimento a un file al di fuori del confine come nel caso di google maps, allora manterremmo tutto uguale tranne che invece di un ILF sarebbe un FEI?
In scenario 3, come proposto da Edwin, i servizi web fanno parte dell'applicazione da contare. Non ho problemi con il conteggio.
La risposta di Alexander si riferisce a qualcosa che vedo abbastanza spesso, ovvero che il sistema di back-end offre servizi web per gestire le richieste sui dati. Quando questi servizi devono essere costruiti nel sistema back-end, verranno conteggiati in modo simile allo scenario 3.
La dimensione funzionale di un sistema front-end non cambierà, se i servizi web sono disponibili o meno. La funzionalità che deve essere fornita all'utente è la stessa. La produttività sarà molto diversa quando la funzionalità può essere fornita chiamando i servizi web esistenti piuttosto che costruire il meccanismo completo per gestire i dati nel sistema di back-end.
Per quanto riguarda la prima osservazione di Sue: Quando l'applicazione è in grado di modificare o creare i dati nel sistema di back-end, il file-prodotto è per definizione un ILF, indipendentemente dal fatto che gli architetti affermino che i dati di prodotto appartengono al sistema di back-end.
- Devi essere loggato per rispondere a questa discussione.