Queste sono le i principi E regole si trova nel Metodo di Misurazione COSMIC v4.0.2

Aggregazione dei risultati delle misurazioni

Regole

a) Per qualsiasi processo funzionale, le dimensioni funzionali dei singoli movimenti di dati devono essere aggregate in un unico valore di dimensione funzionale in unità di CFP sommandoli insieme.

Dimensione (processi funzionali) = Σ dimensione(Entrate) + Σ dimensione(Uscite) +Σ dimensione(Letture) + Σ dimensione(Scritture)

b) Per qualsiasi processo funzionale, la dimensione funzionale delle modifiche ai requisiti utente funzionali deve essere aggregata dalle dimensioni dei movimenti di dati che sono stati aggiunti, modificati o eliminati nel processo funzionale per fornire una dimensione della modifica in unità di CFP , secondo la seguente formula.

Dimensione (Cambia(processi funzionali)) =
Σ dimensione (movimenti dati aggiunti) +
Σ dimensione (movimenti dati modificati) +Σ dimensione (movimenti dati cancellati)

Per ulteriori informazioni sull'aggregazione delle dimensioni funzionali, vedere la sezione 4.3.2. Per misurare la dimensione del software modificato, vedere la sezione 4.4.2.

c) La dimensione di una parte di software all'interno di un ambito definito deve essere ottenuta aggregando le dimensioni dei processi funzionali per la parte, soggetti alle regole e) ed f) di seguito

d) La dimensione di qualsiasi modifica a una parte di software all'interno di un ambito definito deve essere ottenuta aggregando le dimensioni di tutte le modifiche a tutti i processi funzionali per la parte, soggetti alle regole e) ed f) di seguito.

e) Le dimensioni di parti di software o di modifiche a parti di software possono essere sommate solo se misurate allo stesso livello di granularità del processo funzionale dei loro FUR.

f) Le dimensioni delle parti di software e/o i cambiamenti nelle dimensioni delle parti di software all'interno di uno stesso livello o da livelli diversi devono essere sommati solo se ha senso farlo, ai fini della misurazione.

g) La dimensione di una parte di software può essere ottenuta sommando le dimensioni dei suoi componenti (indipendentemente da come la parte è scomposta) ed eliminando i contributi dimensionali dei movimenti di dati tra le componenti.

h) Deve essere identificata una sola uscita per tutti i messaggi di errore/conferma emessi da qualsiasi processo funzionale a un utente funzionale umano.

i) Se il metodo COSMIC viene esteso localmente (ad esempio per misurare alcuni aspetti della dimensione non coperti dal metodo standard), allora la dimensione misurata tramite l'estensione locale deve essere riportata separatamente come descritto nella sezione 5.1 e NON deve essere aggiunta al metodo COSMIC dimensione ottenuta con il metodo standard, misurata in CFP (vedere più avanti nella sezione 4.5).

Comandi di controllo in applicazioni con interfaccia umana

Regola

In un'applicazione con un'interfaccia umana i "comandi di controllo" devono essere ignorati poiché non comportano alcun movimento di dati su un oggetto di interesse.

Il principio di misurazione COSMIC

I principi

a) La dimensione di un processo funzionale è pari al numero dei suoi movimenti di dati.

b) La dimensione funzionale di una porzione di software con ambito definito è pari alla somma delle dimensioni dei suoi processi funzionali.

Reporting delle misurazioni COSMIC

Regola

Oltre alle misurazioni effettive, registrate come in 5.1, dovrebbero essere registrati alcuni o tutti i seguenti attributi di ciascuna misurazione, a seconda dello scopo della misurazione e del livello desiderato di comparabilità con altre misurazioni, ad esempio a fini di benchmarking.

a) Identificazione del componente software misurato (nome, ID versione o ID configurazione).

b) Le fonti di informazione utilizzate per identificare i FUR utilizzati per la misurazione

c) Il dominio del software

d) Una descrizione dell'architettura degli strati in cui viene effettuata la misurazione, se applicabile.

e) Una dichiarazione dello scopo della misurazione.

f) Una descrizione dell'ambito della misurazione e la sua relazione con l'ambito complessivo di un insieme di misurazioni correlate, se presente. (Utilizzare le categorie di ambito generiche nella sezione 2.2)

g) Il modello della strategia di misurazione utilizzata (COSMIC o locale), con la modalità di elaborazione (on-line o batch)

h) Gli utenti funzionali del software

i) Il livello di granularità degli artefatti software disponibili e il livello di scomposizione del software.

j) Il punto nel ciclo di vita del progetto in cui è stata effettuata la misurazione (in particolare se la misurazione è una stima basata su requisiti incompleti o è stata effettuata sulla base delle funzionalità effettivamente fornite).

k) L'obiettivo o il margine di errore ritenuto della misurazione.

l) Indicare se è stato utilizzato il metodo di misurazione COSMIC standard e/o un'approssimazione locale del metodo standard e/o se sono state utilizzate estensioni locali (vedere sezione 4.5). Utilizzare le convenzioni di etichettatura delle sezioni 5.1 o 5.2.

m) Un'indicazione se la misurazione riguarda la funzionalità sviluppata o fornita (la funzionalità "sviluppata" si ottiene creando nuovo software; la funzionalità "consegnata" include la funzionalità "sviluppata" e include anche la funzionalità ottenuta con mezzi diversi dalla creazione di nuovo software, vale a dire comprese tutte le forme di riutilizzo di software esistente, implementazione di pacchetti software, utilizzo di parametri esistenti per aggiungere o modificare funzionalità, ecc.).

n) Un'indicazione se la misurazione riguarda funzionalità appena fornite o è il risultato di un'attività di 'miglioramento' (vale a dire la somma è di funzionalità aggiunte, modificate ed eliminate – vedere 4.4).

o) Il numero dei componenti principali, se applicabile, le cui dimensioni sono state sommate per ottenere la dimensione totale registrata.

p) La percentuale di funzionalità implementate dal software riutilizzato

q) Per ciascun ambito compreso nell'ambito di misurazione complessivo, una matrice di misurazione, come specificato nell'Appendice A.

r) nome dello stazzatore ed eventuali titoli di certificazione COSMIC; la data della misurazione

Etichettatura della misurazione COSMIC

Regole

Il risultato di una misurazione COSMIC deve essere annotato come "x CFP (v)", dove:

  • 'x' rappresenta il valore numerico della dimensione funzionale,
  •  'v' rappresenta l'identificazione della versione standard del metodo COSMIC utilizzata per ottenere il valore numerico della dimensione funzionale 'x'.NOTA: Se per ottenere la misurazione è stato utilizzato un metodo di approssimazione locale, ma per il resto la misurazione è stata effettuata utilizzando le convenzioni di una versione COSMIC standard, deve essere utilizzata la convenzione di etichettatura di cui sopra, ma l'uso del metodo di approssimazione deve essere annotato altrove – vedere la sezione 5.2.Etichettatura delle estensioni locali COSMIC
    Regola
    Un risultato di misurazione COSMIC che utilizza estensioni locali deve essere annotato come:' x CFP (v) + z FP locale', dove:
  •  'x' rappresenta il valore numerico ottenuto aggregando tutti i risultati delle singole misurazioni secondo il metodo COSMIC standard, versione v,
  •  'v' rappresenta l'identificazione della versione standard del metodo COSMIC utilizzata per ottenere il valore numerico della dimensione funzionale 'x'.
  •  'z' rappresenta il valore numerico ottenuto aggregando tutti i risultati delle misurazioni individuali ottenuti dalle estensioni locali del metodo COSMIC.

Gruppo dati

Principio

Ciascun gruppo di dati identificato deve essere unico e distinguibile attraverso la sua raccolta unica di attributi di dati.

L'identificazione di diversi gruppi di dati (e quindi di diversi oggetti di interesse) si è spostata nello stesso processo funzionale

Regola

Per tutti gli attributi dei dati che appaiono nell'input di un processo funzionale:

  1. a) insiemi di attributi di dati che hanno frequenze di occorrenza diverse descrivono diversi oggetti di interesse;
  2. b) insiemi di attributi di dati che hanno la stessa frequenza di occorrenza ma diversi attributi chiave identificativi descrivono diversi oggetti di interesse;
  3. c) tutti gli attributi dei dati in un insieme risultante dall'applicazione delle parti a) e b) di questa regola appartengono allo stesso tipo di gruppo di dati, a meno che i FUR specifichino che può esserci più di un tipo di gruppo di dati che descrive lo stesso oggetto di interesse in input al processo funzionale (vedi Nota 3)

Questa stessa regola si applica a tutti gli attributi dei dati che appaiono nell'output di un processo funzionale, o a tutti quelli che vengono spostati da un processo funzionale alla memoria persistente, o a tutti quelli che vengono spostati dalla memoria persistente a un processo funzionale.

NOTA 1. Può essere utile quando si analizzano output complessi, ad esempio report con dati che descrivono diversi oggetti di interesse, considerare ciascun gruppo di dati candidato separato come se fosse l'output di un processo funzionale separato. Ciascuno dei tipi di gruppi di dati identificati in questo modo deve essere inoltre distinto e conteggiato durante la misurazione del report complesso. Per esempi, vedere le "Linee guida per il dimensionamento del software applicativo aziendale" [7], in particolare l'esempio nella sezione 2.6.1 e la sua analisi in 2.6.2. Si veda anche l'analisi degli esempi 4 e 5 nella sezione 4.2.4.

NOTA 2. Esaminare il modo in cui gli attributi dei dati sono fisicamente raggruppati o separati in input o in output può aiutare a distinguere diversi tipi di gruppi di dati, ma non è possibile fare affidamento su di essi per distinguerli. Ad esempio, due o più insiemi di attributi di dati presenti sullo stesso input o output che sono fisicamente separati per ragioni estetiche o per facilità di comprensione, apparterranno allo stesso tipo di gruppo di dati se soddisfano la regola di cui sopra.

NOTA 3. Vedere la sezione 3.5 del Manuale di Misurazione per le definizioni, i principi e le regole per i movimenti di dati che spostano gruppi di dati, e la sezione 3.5.7 (esempi 2, 3, 4 e 5) e 3.5.11 per le eccezioni a queste regole per i movimenti di dati, come da regola c sopra.

Processo funzionale

Regole

a) Un processo funzionale deve appartenere interamente all'ambito di misurazione di un pezzo di software in uno e solo uno strato.

b) Un processo funzionale deve comprendere un minimo di due movimenti di dati, vale a dire l'Entry che attiva più un Exit o un Write, dando una dimensione minima di 2 CFP. Non esiste un limite superiore al numero di movimenti di dati in un processo funzionale e quindi nessun limite superiore alla sua dimensione.

c) Un processo funzionale in esecuzione si considera terminato quando ha soddisfatto i suoi FUR per tutte le possibili risposte alla sua Entrata scatenante. Una pausa nel trattamento per motivi tecnici non sarà considerata come cessazione del processo funzionale.

Granularità del processo funzionale

Livello di granularità del processo funzionale

Regole

  1. a) La misurazione precisa della dimensione funzionale di una parte di software richiede che i suoi FUR siano conosciuti a un livello di granularità al quale i suoi processi funzionali e i sottoprocessi di movimento dei dati possano essere identificati.
  2. b) Se alcuni requisiti devono essere misurati prima che siano stati definiti in modo sufficientemente dettagliato per una misurazione precisa, i requisiti possono essere misurati utilizzando un

Sez.

DESCRIZIONE PRINCIPI E REGOLE

approccio approssimativo. Questi approcci definiscono il modo in cui i requisiti possono essere misurati a livelli più elevati di granularità. I fattori di scala vengono quindi applicati alle misurazioni ai livelli di granularità più elevati per produrre una dimensione approssimativa al livello di granularità dei processi funzionali e dei relativi sottoprocessi di spostamento dei dati. Vedere le "Linee guida per la misurazione approssimativa della dimensione funzionale COSMIC" [6].

Guarda anche processo funzionale

Un processo funzionale che richiede dati da un utente funzionale

Regole

a) Un processo funzionale deve ottenere un gruppo di dati tramite un movimento di dati di immissione da un utente funzionale, quando il processo funzionale non ha bisogno di dire all'utente funzionale quali dati inviare, come in uno dei seguenti quattro casi:

  •  quando un utente funzionale invia un gruppo di dati tramite una voce di attivazione che avvia il processo funzionale;
  • quando un processo funzionale, dopo aver ricevuto un gruppo di dati tramite un Entry di attivazione, attende, aspettandosi l'arrivo di un ulteriore gruppo di dati dall'utente funzionale tramite un Entry (può verificarsi quando un utente funzionale umano inserisce dati nel software applicativo aziendale);
  • quando un processo funzionale, avviato, richiede all'utente funzionale "inviami i tuoi dati adesso, se ne hai" e l'utente funzionale invia i suoi dati;

  • quando un processo funzionale, una volta avviato, ispeziona lo stato di un utente funzionale e recupera i dati richiesti.

    Negli ultimi due casi (che tipicamente si verificano nei software di 'polling' in tempo reale), per convenzione non deve essere identificata alcuna uscita dal processo funzionale per ottenere i dati richiesti. Il processo funzionale deve semplicemente inviare un messaggio di richiesta a un utente funzionale e la funzionalità di quel messaggio di richiesta è considerata parte della voce. Il processo funzionale sa quali dati aspettarsi. Per questo caso dovrà essere identificata una sola voce.

    b) Quando un processo funzionale deve ottenere i servizi di un utente funzionale (ad esempio per ottenere dati) e all'utente funzionale è necessario dire cosa inviare (tipicamente quando l'utente funzionale è un altro pezzo di software esterno all'ambito del software) in corso di misurazione), dovrà essere individuato un movimento di dati di Uscita seguito da uno di Entrata. L'Uscita invia la richiesta dei dati specifici; la voce riceve i dati restituiti.

Utenti funzionali

Regole

a) Gli utenti funzionali di una porzione di software da misurare dipendono dallo scopo della misurazione.

b) Quando lo scopo di una misurazione di una parte di software è legato allo sforzo di sviluppare o modificare la parte di software, allora gli utenti funzionali dovrebbero essere tutti i diversi tipi di mittenti e/o destinatari previsti di dati da/verso il funzionalità nuova o modificata, come richiesto dai suoi FUR.

NOTA: I FUR possono specificare che un insieme di utenti funzionali deve essere identificato individualmente. Tuttavia saranno dello stesso tipo se ciascun evento è soggetto agli stessi FUR

Il modello del software generico

I principi

a) Una parte di software interagisce con i suoi utenti funzionali attraverso un confine e con l'archiviazione persistente all'interno di questo confine.

b) I requisiti utente funzionali di una parte di software da misurare possono essere mappati in processi funzionali unici.

c) Ciascun processo funzionale è costituito da sottoprocessi.

d) Un sottoprocesso può essere uno spostamento di dati o una manipolazione di dati.

e) Uno spostamento di dati sposta un singolo gruppo di dati.

f) Esistono quattro tipi di movimento dei dati, Entry, Exit, Write e Read.

  •  Una voce sposta un gruppo di dati in un processo funzionale da un utente funzionale.
  • Un'Uscita sposta un gruppo di dati da un processo funzionale a un utente funzionale.
  • Una scrittura sposta un gruppo di dati da un processo funzionale all'archiviazione persistente.
  • Una lettura sposta un gruppo di dati dall'archiviazione persistente a un processo funzionale.

g) Un gruppo di dati è costituito da un insieme unico di attributi di dati che descrivono un singolo oggetto di interesse.

h) Ogni processo funzionale viene avviato attivando il movimento dei dati di ingresso. Il gruppo di dati spostato dalla voce di attivazione viene generato da un utente funzionale in risposta a un evento di attivazione.

i) La dimensione di un processo funzionale è pari al conteggio totale dei suoi movimenti di dati

j) Un processo funzionale deve includere almeno il movimento dei dati di ingresso che attiva e un movimento dei dati di scrittura o di uscita, ovvero deve includere un minimo di due movimenti di dati. Non esiste un limite massimo al numero di movimenti di dati in un processo funzionale

k) A titolo approssimativo ai fini della misurazione, i sottoprocessi di manipolazione dei dati non sono misurati separatamente; si presuppone che la funzionalità di qualsiasi manipolazione dei dati sia tenuta in considerazione dal movimento dei dati a cui è associata

NOTA: Il modello software generico COSMIC, come suggerisce il nome, è un "modello" logico che espone unità in cui il software elabora i dati adatti alla misurazione delle dimensioni funzionali. Il modello non intende descrivere la sequenza fisica dei passaggi attraverso i quali viene eseguito il software né alcuna implementazione tecnica del software.

Strato

I principi

a) Il software in uno strato fornisce un insieme di servizi che è coeso secondo alcuni criteri definiti e che il software in altri strati può utilizzare senza sapere come vengono implementati tali servizi.

b) La relazione tra il software in due strati qualsiasi è definita da una "regola di corrispondenza" che può essere l'una o l'altra

  •   "gerarchico", ovvero al software del livello A è consentito utilizzare i servizi forniti dal software del livello B ma non viceversa (dove la relazione gerarchica può essere verso l'alto o verso il basso), oppure
  •   'bidirezionale', vale a dire che il software del livello A può utilizzare il software del livello B e viceversa.

c) Il software in uno strato scambia gruppi di dati con il software in un altro strato attraverso i rispettivi processi funzionali.

d) Il software in uno strato non utilizza necessariamente tutti i servizi funzionali forniti dal software in un altro strato.

e) Il software in uno strato di un'architettura software definita può essere suddiviso in altri strati secondo un'architettura software definita diversa.

Ambito di una misurazione

Regole

a) L'ambito di qualsiasi parte di software da misurare deve essere derivato dallo scopo della misurazione.

b) L'ambito di qualsiasi misurazione non deve estendersi su più di uno strato del software da misurare

Il modello di contesto del software COSMIC

I principi

  1. a) Il software è limitato dall'hardware.
  2. b) Il software è tipicamente strutturato in livelli.
  3. c) Uno strato può contenere uno o più pezzi di software 'pari' separati.
  4. d) Qualsiasi parte di software da misurare sarà definita dal suo ambito di misurazione, che sarà confinato interamente in un singolo strato.
  5. e) L'ambito di una parte di software da misurare dipende dallo scopo della misurazione.
  6. f) Gli utenti funzionali di una parte di software da misurare devono essere identificati dai suoi Requisiti Utente Funzionali (FUR) rispettivamente come mittenti e/o destinatari previsti di dati da/verso il software.
  7. g) I requisiti funzionali del software possono essere espressi a diversi livelli di granularità.
  8. h) Una misurazione precisa della dimensione COSMIC di una parte di software richiede che i suoi FUR siano conosciuti ai livelli di granularità ai quali i suoi processi funzionali e sottoprocessi possono essere identificati.
  9. i) Una misurazione approssimativa della dimensione COSMIC di una parte di software è possibile se i suoi requisiti funzionali sono misurati ad un elevato livello di granularità mediante un approccio approssimativo e scalati ai livelli di granularità dei processi funzionali e dei sottoprocessi.

Livelli di granularità per la misurazione di un processo funzionale

Regole

  1. a) Una misurazione della dimensione funzionale di una parte di software richiede che i suoi FUR siano conosciuti ai livelli di granularità ai quali i suoi processi funzionali e i sottoprocessi di movimento dei dati possono essere identificati.
  2. b) Se alcuni requisiti devono essere misurati prima che siano stati definiti in modo sufficientemente dettagliato per una misurazione precisa, i requisiti possono essere misurati utilizzando un approccio approssimativo. Questi approcci definiscono il modo in cui i requisiti possono essere misurati a livelli più elevati di granularità. I fattori di scala vengono quindi applicati alle misurazioni ai livelli di granularità più elevati per produrre una dimensione approssimativa ai livelli di granularità dei processi funzionali e dei relativi sottoprocessi di movimento dei dati. Vedere le linee guida per la misurazione precoce o rapida della dimensione funzionale COSMIC mediante approcci di approssimazione. [6].

Entrata (E)

I principi

a) Una voce deve spostare un singolo gruppo di dati che descrive un singolo oggetto di interesse da un utente funzionale oltre il confine e nel processo funzionale di cui la voce fa parte. Se l'input per un processo funzionale comprende più di un gruppo di dati, ciascuno dei quali descrive un diverso oggetto di interesse, identificare una voce per ciascun gruppo di dati univoco nell'input. (Vedere anche la sezione 3.5.7 su "Unicità del movimento dei dati".)

b) Una voce non deve far uscire dati oltre il confine, né leggere o scrivere dati da/su memoria persistente.

Regole

a) Il gruppo di dati di un Entry attivante può consistere di un solo attributo di dati che informa semplicemente il software che "si è verificato un evento Y". Molto spesso, soprattutto nel software applicativo aziendale, il gruppo di dati dell'elemento di attivazione ha diversi attributi di dati che informano il software che "si è verificato un evento Y e qui ci sono i dati su quel particolare evento".

b) I battiti dell'orologio che attivano gli eventi devono essere sempre esterni al software da misurare. Pertanto, ad esempio, un evento di ticchettio dell'orologio che si verifica ogni 3 secondi deve essere associato a una voce che sposta un gruppo di dati di un attributo di dati. Si noti che non fa differenza se l'evento di attivazione viene generato periodicamente dall'hardware o da un'altra parte di software al di fuori dei confini del software da misurare.

c) A meno che non sia necessario uno specifico processo funzionale, l'acquisizione della data e/o dell'ora dall'orologio del sistema non sarà considerata come causa di un'Iscrizione o di qualsiasi altro spostamento di dati.

d) Se il verificarsi di un evento specifico provoca l'immissione di un gruppo di dati comprendente fino a 'n' attributi di dati di un particolare oggetto di interesse e i FUR consentono che altri occorrenze dello stesso evento possano causare l'immissione di un gruppo di dati che ha valori per gli attributi di solo un sottoinsieme degli 'n' attributi dell'oggetto di interesse, allora deve essere identificata una voce, spostando un gruppo di dati comprendente tutti gli 'n' attributi dei dati.

e) Quando si identificano le voci in una schermata che consente agli utenti funzionali umani di inserire dati nei processi funzionali, analizzare solo le schermate piene di dati. Ignora qualsiasi schermata formattata ma altrimenti 'vuota', ad eccezione di possibili valori predefiniti, e ignora tutti i campi e le altre intestazioni che consentono agli utenti umani di comprendere i dati di input richiesti.

NOTA. Potrebbe essere necessario considerare campi e altre intestazioni quando si misurano i FUR per modifiche alle voci – vedere sezione 4.4.1.

Esci (X)

I principi

a) Un'Uscita sposta un singolo gruppo di dati che descrive un singolo oggetto di interesse dal processo funzionale di cui l'Uscita fa parte attraverso il confine verso un utente funzionale. Se l'output di un processo funzionale comprende più di un gruppo di dati, identificare un'uscita per ciascun gruppo di dati univoco nell'output. (Vedere anche la sezione 3.5.7 su "Unicità del movimento dei dati".)

b) Un'Uscita non deve immettere dati oltre il confine, né leggere o scrivere dati da/su memoria persistente.

Regole

a) Una richiesta che restituisce testo fisso (dove "fisso" significa che il messaggio non contiene valori di dati variabili, ad esempio il risultato della pressione di un pulsante per "Termini e condizioni" su un sito web di acquisti), deve essere modellata come avente un'uscita per l'output di testo fisso.

NOTA: per l'output della funzionalità "Guida", consultare le "Linee guida per il dimensionamento del software applicativo aziendale". Per l'emissione dei messaggi relativi alle condizioni di errore o alla conferma del successo, vedere la sezione 3.5.11 del presente Manuale di misurazione.

b) Se un'Uscita di un processo funzionale sposta un gruppo di dati comprendente fino a 'n' attributi di dati di un particolare oggetto di interesse e i FUR consentono che il processo funzionale possa avere un'occorrenza di un'Uscita che sposta un gruppo di dati che ha valori per gli attributi di solo un sottoinsieme degli 'n' attributi dell'oggetto di interesse, sarà identificata un'uscita, spostando un gruppo di dati comprendente tutti gli 'n' attributi di dati.

c) Quando si identificano le uscite, ignorare tutti i campi e le altre intestazioni che consentono agli utenti umani di comprendere i dati di output.

NOTA: potrebbe essere necessario considerare il campo e altre intestazioni quando si misurano i FUR per le modifiche alle uscite – vedere sezione 4.4.1

Leggi (R)

I principi

a) Un Read sposta un singolo gruppo di dati che descrive un singolo oggetto di interesse dall'archiviazione persistente a un processo funzionale di cui il Read fa parte. Se il processo funzionale deve recuperare più di un gruppo di dati dall'archiviazione persistente, identificare una lettura per ciascun gruppo di dati univoco recuperato. (Vedere anche la sezione 3.5.7 su "Unicità del movimento dei dati".)

b) Una lettura non deve ricevere o uscire dati oltre il confine né scrivere dati nell'archivio persistente.

c) Durante un processo funzionale, movimento o manipolazione di costanti o variabili che sono interne al processo funzionale e che possono essere modificate solo da un programmatore, o calcolo di risultati intermedi in un calcolo, o di dati memorizzati da un processo funzionale risultante solo dall'implementazione, piuttosto che dai FUR, non saranno considerati movimenti di dati letti.

d) Un movimento di dati di lettura include sempre qualsiasi funzionalità di "richiesta di lettura" (quindi un movimento di dati separato non verrà mai conteggiato per alcuna funzionalità di "richiesta di lettura"). Vedi anche la sezione 3.5.9.

Regole

a) Identificare una lettura quando, secondo i FUR, il software da misurare deve recuperare un gruppo di dati dalla memoria persistente.

b) Non identificare una lettura quando i FUR del software da misurare specificano qualsiasi utente funzionale software o hardware come origine di un gruppo di dati o come mezzo per recuperare un gruppo di dati archiviato in modo persistente. (In questo caso vedere i principi e le regole per le Entrate e le Uscite.)

Scrivi (W)

I principi

a) Una scrittura sposta un singolo gruppo di dati che descrive un singolo oggetto di interesse dal processo funzionale di cui la scrittura fa parte all'archiviazione persistente. Se il processo funzionale deve spostare più di un gruppo di dati nell'archiviazione persistente, identificare una scrittura per ciascun gruppo di dati univoco spostato nell'archiviazione persistente. (Vedere anche la sezione 3.5.7 su "Unicità del movimento dei dati".)

b) Una scrittura non riceverà o emetterà dati oltre il confine, né leggerà dati dall'archiviazione persistente.

c) Il requisito di eliminare un gruppo di dati dall'archiviazione persistente deve essere misurato come un singolo movimento di dati di scrittura.

D)

Non sono considerati movimenti di dati di scrittura:

  • Lo spostamento o la manipolazione di qualsiasi dato che non esisteva all'inizio di un processo funzionale e che non è stato reso persistente una volta completato il processo funzionale;
  • Creazione o aggiornamento di variabili o risultati intermedi interni al processo funzionale;
  • Memorizzazione dei dati mediante un processo funzionale risultante solo dall'implementazione, piuttosto che dai FUR. (Un esempio potrebbe essere l'uso dell'archiviazione per archiviare temporaneamente i dati durante un processo di ordinamento di grandi dimensioni in un lavoro elaborato in batch.)

Regole

a) Identificare una Scrittura quando, secondo i FUR, il software da misurare deve spostare un gruppo di dati nella memoria persistente.

b) Non identificare una Scrittura quando i FUR del software da misurare specificano qualsiasi utente funzionale software o hardware come destinazione del gruppo di dati o come mezzo per memorizzare il gruppo di dati. (In questo caso vedere i principi e le regole per le Entrate e le Uscite.)

Manipolazione dei dati associata ai movimenti di dati

Principio

Tutta la manipolazione dei dati in un processo funzionale deve essere associata ai quattro tipi di movimento dei dati (E, X, R e W). Per convenzione, si presuppone che i movimenti di dati di un processo funzionale tengano conto anche della manipolazione dei dati del processo funzionale.

Regole

a) Un movimento di dati di immissione tiene conto di tutta la manipolazione dei dati per consentire a un gruppo di dati di essere inserito da un utente funzionale (ad esempio manipolazioni di formattazione e presentazione) e di essere convalidato.

b) Un movimento di dati di uscita tiene conto di tutta la manipolazione dei dati per creare gli attributi di dati di un gruppo di dati da produrre in output e/o per consentire al gruppo di dati di essere prodotto in output (ad esempio manipolazioni di formattazione e presentazione) e da instradare all'utente funzionale previsto .

c) Un movimento di dati di lettura tiene conto di tutti i calcoli e/o l'elaborazione logica necessari per recuperare un gruppo di dati dall'archiviazione persistente.

d) Un movimento di dati di scrittura tiene conto di tutti i calcoli e/o elaborazioni logiche per creare o aggiornare un gruppo di dati da scrivere o per eliminare un gruppo di dati.

e) La manipolazione dei dati associata a uno qualsiasi di questi movimenti di dati non include alcuna manipolazione dei dati necessaria dopo che il movimento dei dati è stato completato con successo, né include alcuna manipolazione dei dati associata a qualsiasi altro movimento di dati.

Unicità del movimento dei dati e possibili eccezioni

Regole

NB Tutte le regole COSMIC riguardano tipologie di utenti funzionali, gruppi di dati, movimenti di dati, processi funzionali e oggetti di interesse. Per facilità di lettura, normalmente omettiamo "tipo" da questi termini. Questa convenzione è seguita nelle regole a), b) ec) di seguito, ma nella regola d) includiamo il 'tipo' dove è utile distinguere un 'tipo' da una 'occorrenza'.

a) A meno che i Requisiti Utente Funzionali non siano quelli indicati nelle regole b) o c), tutti i dati che descrivono qualsiasi oggetto di interesse che deve essere inserito in un processo funzionale devono essere identificati come un gruppo di dati spostato da una Voce.

NOTA: un processo funzionale può, ovviamente, avere più voci, ciascuna delle quali sposta dati che descrivono un diverso oggetto di interesse.

La stessa regola equivalente si applica a qualsiasi movimento di dati di lettura, scrittura o uscita in qualsiasi processo funzionale.

b) Se i Requisiti Utente Funzionale specificano che diversi gruppi di dati devono essere inseriti in un processo funzionale ciascuno da un diverso utente funzionale, dove ciascun gruppo di dati descrive lo stesso oggetto di interesse, allora dovrà essere identificata una Voce per ciascuno di questi diversi gruppi di dati.

La stessa regola equivalente si applica alle uscite di dati verso diversi utenti funzionali da qualsiasi processo funzionale.

NOTA: qualsiasi processo funzionale deve avere una sola voce di attivazione.

c) Se i Requisiti Utente Funzionali specificano che diversi gruppi di dati devono essere spostati dall'archiviazione persistente in un processo funzionale, ciascuno dei quali descrive lo stesso oggetto di interesse, allora deve essere identificata una Lettura per ciascuno di questi diversi gruppi di dati.

La stessa regola equivalente si applica alle scritture in qualsiasi processo funzionale.

NOTA: questa regola è analoga alla regola b). Nel caso in cui i FUR leggano diversi gruppi di dati che descrivono lo stesso oggetto di interesse, probabilmente avranno avuto origine da diversi utenti funzionali. Nel caso in cui i FUR scrivano gruppi di dati diversi, essi saranno probabilmente resi disponibili per essere letti da utenti funzionali diversi.

d) Gli eventi ripetuti di qualsiasi tipo di movimento di dati durante l'esecuzione non verranno conteggiati.

Ciò si applica anche se più occorrenze del tipo di movimento dei dati differiscono nella loro esecuzione poiché valori diversi degli attributi dei dati del gruppo di dati spostato comportano percorsi di elaborazione diversi seguiti attraverso il tipo di processo funzionale.

Messaggi di errore/conferma e altre indicazioni di condizioni di errore

Regole

a) Deve essere identificata un'Uscita per tenere conto di tutti i tipi di messaggi di errore/conferma emessi da qualsiasi processo funzionale del software misurato da tutte le possibili cause in base ai suoi FUR, ad esempio successi o fallimenti di: convalida dei dati immessi o per un chiamata per recuperare dati o renderli persistenti o per la risposta da un servizio richiesto da un altro software.

NOTA: Se i FUR del processo funzionale non richiedono l'emissione di alcun tipo di messaggio di errore/conferma, non identificare alcuna Uscita corrispondente.

b) Se un messaggio a un utente funzionale umano fornisce dati oltre a confermare che i dati immessi sono stati accettati o che i dati immessi sono errati, allora questi dati aggiuntivi dovrebbero essere identificati come un gruppo di dati spostato da un'Uscita in modo normale , oltre all'errore/conferma Exit.

c) Tutti gli altri dati, emessi o ricevuti dal software sottoposto a misurazione, da/verso i suoi utenti funzionali hardware o software dovrebbero essere analizzati secondo i FUR rispettivamente come Uscite o Entrate, secondo le normali regole COSMIC, indipendentemente dal fatto che il i valori dei dati indicano una condizione di errore.

d) Le letture e le scritture sono considerate per tenere conto di qualsiasi segnalazione associata di condizioni di errore. Pertanto non verrà identificata alcuna voce nel processo funzionale oggetto di misurazione per qualsiasi indicazione di errore ricevuta a seguito di una lettura o scrittura di dati persistenti.

e) Non dovrà essere identificata alcuna Entrata o Uscita per qualsiasi messaggio che indichi una condizione di errore che potrebbe essere emessa durante l'utilizzo del software da misurare ma che non è richiesto che sia elaborato in alcun modo dai FUR di quel software, ad esempio un messaggio di errore emesso da il sistema operativo.

Modificare uno spostamento di dati

Regole

a) Se un movimento di dati deve essere modificato a causa di un cambiamento nella manipolazione dei dati associata al movimento di dati e/o a causa di un cambiamento nel numero o nel tipo di attributi nel gruppo di dati spostato, verrà misurata una CFP modificata, indipendentemente dal numero effettivo di modifiche in un unico movimento di dati.

b) Se un gruppo di dati deve essere modificato, i movimenti di dati che spostano il gruppo di dati modificato la cui funzionalità non è influenzata dalla modifica al gruppo di dati non saranno identificati come movimenti di dati modificati.

NOTA: una modifica ai dati visualizzati sulle schermate di input o output che non sono correlate a un oggetto di interesse per un utente funzionale non sarà identificata come CFP modificata. (Vedere la sezione 3.3.3 per esempi di tali dati.)

Dimensioni del software funzionalmente modificato
Regola
Dopo aver modificato funzionalmente una parte del software:
Nuova dimensione totale (parte di software modificata) = Vecchia dimensione totale (parte di software)

+ Dimensione Σ (movimenti dati aggiunti) – Dimensione Σ (movimenti dati eliminati)

Dimensioni e impegno della CFP del software

Manuale di misurazione, v4.0.2 Copyright © 2017

COSMIC Sizing è conforme allo standard internazionale: ISO 19761:2011

COSMICO

Articoli recenti

Commenti recenti

    Archivi

    Categorie