Elenco di controllo: Documento dell'architettura software |
|
 |
Questo elenco di controllo assiste nel verificare che il Documento dell'architettura software sia stabile, corretto e completo. |
|
Relazioni
Descrizione principale
Voci elenchi di operazioni
Generale
Il sistema, nel suo complesso, si basa su un'architettura solida perché:
-
L'architettura sembra stabile.
L'esigenza di stabilità è dettata dalla natura stessa della fase di Costruzione: un progetto in costruzione in
genere espande, aggiungendo sviluppatori che lavorano in parallelo, che comunicano in maniera non costante tra
loro durante la lavorazione del prodotto. Il grado di indipendenza e parallelismo necessario durante la
Costruzione non può essere raggiunto se l'architettura non è stabile.
L'importanza di un'architettura stabile non può essere sottovalutata. Non essere lasciarsi ingannare nel
pensare che 'abbastanza stabile' sia accettabile - instabile è instabile, ed è meglio che l'architettura sia
esatta e rinviare l'inizio della Costruzione anziché procedere. I problemi di coordinamento che derivano dal
tentare di riparare l'architettura mentre gli sviluppatori tentano di costruire sulle sue fondamenta, annullano
qualsiasi vantaggio che sembra sia possibile ottenere dall'accelerare la pianificazione. Cambiare
l'architettura durante la Costruzione ha un vasto impatto: è dispendioso, disgregativo e demoralizzante.
La vera difficoltà nel valutare la stabilità architettonica è l'imprevisto; la stabilità si misura in relazione
a cambiamenti previsti. Ne consegue, che la stabilità è essenzialmente una misura soggettiva. Possiamo,
tuttavia, basare la soggettività su più di una congettura. L'architettura in se viene sviluppata partendo dalla
considerazione di scenari significativi dal punto di vista architettonico - sottoinsiemi di casi d'uso che
rappresentano la funzionalità più difficile in termini tecnologici che il sistema deve supportare. La
valutazione della stabilità di un'architettura prevede la verifica che la stessa offre ampia copertura, per
garantire che non si presentino 'sorprese' che impediscano il progresso dell'architettura.
Esperienze precedenti con l'architettura possono anche fornire buoni indicatori: se il tasso di modifiche
subite dall'architettura è basso e si mantiene basso nel coprire nuovi scenari, ci sono buone ragioni per
credere che l'architettura si stia stabilizzando. In caso contrario, se ad ogni nuovo scenario l'architettura
deve subire modifiche, la stessa è ancora in fase di evoluzione e il raggiungimento del punto di riferimento
iniziale non è garantito.
-
La complessità del sistema corrisponde alla funzionalità che offre.
-
La complessità concettuale è appropriata dati gli skill e l'esperienza dei propri:
-
utenti
-
operatori
-
sviluppatori
-
Il sistema è dotato di una singola architettura uniforme e coerente
-
Il numero e i tipi di componenti sono ragionevoli
-
Il sistema è dotato di una struttura di sicurezza integrale. Tutti i componenti di sicurezza collaborano per
proteggere il sistema.
-
Il sistema sarà in grado di soddisfare gli obiettivi di disponibilità.
-
L'architettura consentirà il ripristino del sistema in caso di guasto nel periodo di tempo richiesto.
-
I prodotti e le tecniche su cui si basa il sistema corrispondono al ciclo vitale previsto?
-
Un sistema ad interim (tattico) con breve ciclo vitale può essere costruito utilizzando tecnologia vecchia
perché verrà abbandonato dopo poco.
-
Un sistema il cui ciclo vitale è previsto di lunga durata (la maggior parte dei sistemi) deve essere
costruito basandosi su tecnologia avanzata e metodi che possano essere mantenuti ed espansi per supportare
esigenze future.
-
L'architettura definisce chiaramente le interfacce per consentire il partizionamento per lo sviluppo di team
paralleli.
-
L'architettura è sufficientemente comprensibile per il progettista di un elemento del modello che sarà così in
grado di progettare e sviluppare l'elemento con successo.
-
L'approccio di creazione pacchetti riduce la complessità e migliora la comprensione.
-
I pacchetti sono stati definiti per essere molto coesivi all'interno, mentre i pacchetti sono accoppiati
liberamente tra loro.
-
Sono state considerate soluzioni simili all'interno del dominio comune dell'applicazione.
-
La soluzione proposta è di facile comprensione anche per chi ha una conoscenza approssimativa del dominio del
problema.
-
Tutti gli elementi del team condividono la visione dell'architettura presentata dall'architetto di software.
-
Il documento dell'architettura software è corrente.
-
Le linee guida non state seguite.
-
Tutti i rischi tecnici sono stati mitigati o risolti in un piano di contingenza. I nuovi rischi individuati sono
stati documentati e analizzati per determinarne l'impatto potenziale.
-
I requisiti chiave per il rendimento (budget stabiliti) sono stati soddisfatti.
-
Scenari di test, test harness e configurazioni di prova sono stati identificati.
-
L'architettura non è "sovradimensionata".
-
I meccanismi implementati sembrano sufficientemente semplici per l'uso.
-
Il numero di meccanismi è modesto e coerente con l'ambito del sistema e le esigenze del dominio del
problema.
-
Tutte le realizzazioni definite per l'iterazione corrente possono essere eseguite dall'architettura, come
dimostrato dal diagramma che riporta:
-
-
Interazioni tra oggetti,
-
Interazioni tra compiti e processi,
-
Interazioni tra nodi fisici.
|
Modelli
Complessiva
-
Il partizionamento e la suddivisione in livelli del sottosistema e del pacchetto è coerente da un punto di
visto logico.
-
Tutti i meccanismi di analisi sono stati identificati e descritti.
Sottosistemi
-
I servizi (interfacce) dei sottosistemi nei livelli superiori sono stati definiti.
-
Le dipendenze tra sottosistemi e pacchetti corrispondono alle relazioni tra dipendenze tra le classi contenute.
-
Le classi in un sottosistema supportano i servizi identificati per il sottosistema stesso.
Classi
-
Le classi entità chiave e le loro relazioni sono state identificate.
-
Le relazioni tra classi entità chiave sono state identificate.
-
Il nome e la descrizione di ciascuna classe riflette chiaramente il ruolo assunto.
-
La descrizione di ogni classe cattura con precisione le responsabilità della classe.
-
Dove opportuno, le classi entità sono state mappate ai meccanismi di analisi.
-
I nomi dei ruoli delle aggregazioni e delle associazioni descrivono con precisione la relazione tra le classi
correlate.
-
Le molteplicità di relazioni sono corrette.
-
Le classi entità chiave e le loro relazioni sono coerenti con il modello di business (ove presente), il modello
dominio (ove presente), i requisiti e le voci di glossario.
Considerazioni generali sul modello
-
Il livello di dettaglio del modello è a un livello opportuno dati gli obiettivi del modello.
-
In relazione al modello di business, ai requisiti del modello o il modello di progettazione durante la fase di
elaborazione, le problematiche di implementazione non sono sovraenfatizzate.
-
In relazione al modello di progettazione durante la fase di costruzione, la funzionalità complessiva degli
elementi del modello raggiunta è ben bilanciata, grazie alla composizione di elementi relativamente semplici
per costruire progetti più complessi.
-
Il modello dimostra familiarità e competenza con l'intera gamma di concetti di modellazione applicabili al
dominio del problema; le tecniche di modellazione sono utilizzate in maniera appropriata al problema da
affrontare.
-
I concetti sono modellati nel modo più semplice possibile.
-
L'evoluzione del modello può essere eseguita con semplicità; il modello si adatta facilmente alle modifiche
previste.
-
Nel contempo, il modello è sovrastrutturato per gestire modifiche improbabili, a spese di semplicità e
comprensibilità.
-
Le presupposizioni chiave dietro il modello sono documentate e visibili ai revisori del modello. Se le
presupposizioni sono applicabili a una data iterazione, allora il modello deve essere in grado di evolvere
all'interno di dette presupposizioni, anche se non necessariamente al di fuori delle stesse. La documentazione
delle presupposizioni è un modo per evitare ai progettisti di esaminare "tutti" i possibili requisiti. In un
processo iterativo, è impossibile analizzare tutti i possibili requisiti e definire un modello che sarà in
grado di gestire tutti i requisiti futuri.
|
Diagrammi
-
Lo scopo del diagramma è dichiarato chiaramente ed è facilmente comprensibile.
-
Il layout grafico è preciso ed esprime chiaramente le informazioni prefissate.
-
Il diagramma esprime quanto basta per portare a termine l'obiettivo, ma non di più.
-
L'incapsulamento viene utilizzato con efficacia per nascondere dettagli e migliorare la chiarezza.
-
L'astrazione viene utilizzata con efficacia per nascondere dettagli e migliorare la chiarezza.
-
Il posizionamento degli elementi del modello esprime le relazioni con efficacia: elementi simili o accoppiati
sono raggruppati.
-
Le relazioni tra gli elementi del modello sono facili da comprendere.
-
L'etichettatura degli elementi del modello contribuiscono alla comprensione.
|
Documentazione
-
Ogni elemento del modello ha uno scopo diverso.
-
Nessun elemento del modello è superfluo: ciascuno assume un ruolo importante nel sistema.
|
Recupero da errori
-
Per ogni errore o eccezione, un criterio definisce come il sistema viene ripristinato alla "normalità".
-
Per ogni possibile tipo di errore di input dell'utente o dati errati da sistemi esterni, un criterio definisce
come il sistema viene ripristinato alla "normalità".
-
Un criterio viene applicato uniformemente per la gestione di situazioni eccezionali.
-
Un criterio viene applicato uniformemente per la gestione del danneggiamento dei dati nel database.
-
Un criterio viene applicato uniformemente per la gestione della mancata disponibilità del database, compresa la
possibilità di continuare ad immettere dati e memorizzarli in un momento successivo.
-
Se viene eseguito uno scambio dei dati tra sistemi, un criterio sincronizza le rispettive viste dei dati.
-
Se il sistema utilizza processori ridondanti o nodi per fornire fault tolerance o alta disponibilità, una
strategia garantisce che due processori o nodi non possano mai 'pensare' di essere i principali, o che nessun
processore o nodo possa esserlo.
-
Le modalità di guasto di un sistema distribuito sono state identificate e le strategie per la gestione dei
guasti definite.
|
Transizione e installazione
-
Il processo di aggiornamento di un sistema esistente senza perdita di dati o di capacità di funzionamento è
stato definito e collaudato.
-
Il processo per la conversione dei dati utilizzati da versioni precedenti è stato definito e collaudato.
-
La quantità di tempo e risorse necessari per aggiornare o installare il prodotto è stata compresa e
documentata.
-
La funzionalità del sistema può essere attivata un caso d'utilizzo alla volta.
|
Amministrazione
-
Lo spazio su disco può essere riorganizzato con il sistema in funzione.
-
Le responsabilità e le procedure per la configurazione del sistema sono state identificate e documentate.
-
L'accesso al sistema operativo o alle funzioni amministrative è stato limitato.
-
I requisiti per l'assegnazione della licenza sono stati soddisfatti.
-
Le routine di diagnostica possono essere eseguite con il sistema in funzione.
-
Il sistema esegue il monitoraggio delle prestazioni operative automaticamente (ad es., limite di capacità,
limite delle prestazioni critiche, esaurimento delle risorse).
-
Le azioni intraprese quando si raggiungono i limiti sono state definite.
-
Il criterio di gestione degli avvisi sono stati definiti.
-
Il meccanismo di gestione degli avvisi è stato definiti, se ne è creato un prototipo collaudato.
-
Il meccanismo di gestione degli avvisi può essere 'regolato' per prevenire avvisi falsi o ridondanti.
-
I criteri e le procedure per il monitoraggio e l'amministrazione della rete (LAN, WAN) sono stati definiti.
-
Gli errori di rete possono essere isolati.
-
Una struttura per il tracciamento di eventi aiuta nella risoluzione dei problemi.
-
L'eccesso della struttura è stato compreso.
-
Il personale amministrativo è in grado di utilizzare la struttura con efficacia in base alle proprie
conoscenze.
-
Non è possibile per un utente malintenzionato:
-
accedere al sistema;
-
distruggere dati critici;
-
consumare tutte le risorse.
|
Prestazioni
-
I requisiti di prestazione sono ragionevoli e rispecchiano i vincoli effettivi del problema del dominio: le
specifiche non sono arbitrari.
-
Le stime sulle prestazioni del sistema sono state eseguite - modellate come necessario utilizzando un Modello
di analisi del carico di lavoro - e segnalano che i requisiti di prestazione non rappresentano rischi
significativi.
-
Le stime sulle prestazioni del sistema sono state convalidate utilizzando prototipi strutturali, in particolar
modo per i requisiti critici.
|
Utilizzo della memoria
-
I budget di memoria per l'applicazione sono stati definiti.
-
Le azioni sono state intraprese per rilevare e prevenire perdite di memoria.
-
Un criterio viene applicato uniformemente per la definizione dell'utilizzo, il monitoraggio e la regolazione
del sistema di memoria virtuale.
|
Costi e tempi
-
Il numero effettivo di righe di codice sviluppato fino ad adesso è conforme alle righe di codice stimate al
cardine corrente.
-
Le assunzioni di stima sono state esaminate e restano valide.
-
Le stime di costi e tempi sono stati ricalcolati utilizzando l'esperienza effettiva del progetto e le
prestazioni di produttività più recenti.
|
Portabilità
-
I requisiti di portabilità sono stati soddisfatti.
-
Le Linee guida sulla programmazione offrono indicazioni specifiche sulla creazione del codice portatile.
-
Le Linee guida sulla programmazione offrono indicazioni specifiche sulla progettazione di applicazioni
portatili.
-
È stata creata una 'porta di prova' per verificare le affermazioni di portabilità.
|
Affidabilità
-
I criteri di valutazione della qualità (MTBF, numero di difetti irrisolti, ecc.) sono stati soddisfatti.
-
L'architettura offre capacità di disaster recovery nel caso di guasto del sistema
|
Sicurezza
-
I requisiti di sicurezza sono stati soddisfatti.
|
Problematiche organizzative
-
I team sono ben strutturati? Le responsabilità sono ben suddivise tra i team?
-
Sono presenti problematiche politiche, organizzative o amministrative che limitando l'efficacia dei team?
-
Il team evidenzia conflitti di personalità?
|
Vista caso d'uso
La sezione Vista caso d'uso del documento dell'architettura software:
-
ogni caso d'uso è significativo dal punto di vista strutturale e identificabile come tale perché:
-
è di vitale importanza per il cliente
-
motiva elementi chiave in altre viste
-
è determinante per mitigare uno o più importanti fattori di rischio, compresi eventuali requisiti non
funzionali difficili.
-
non esistono casi d'uso le cui considerazioni strutturali sono state incluse in un altro caso d'uso
-
gli aspetti significativi da un punto di vista strutturale del caso d'uso sono chiari e non perduti nei
dettagli
-
sono chiari gli effetti prodotti dal caso d'uso sull'architettura oppure è stato stabilito un piano per
raggiungere chiarezza e stabilità
-
nessuno dei casi d'uso significativi da un punto di vista strutturale sono stati mancati (può richiedere
l'analisi dei casi d'uso non selezionati per questa vista).
|
Vista logica
La sezione Vista logica del documento dell'architettura software:
-
presenta una panoramica integrale e precisa degli elementi significativi dal punto di vista strutturale della
progettazione;
-
presenta l'insieme completo dei meccanismi strutturali utilizzati nella progettazione progetto con il
fondamento logico utilizzato nella selezione degli stessi;
-
presenta i livelli della progettazione, con il fondamento logico utilizzato per partizionare i livelli;
-
presenta gli eventuali framework o pattern utilizzati nella progettazione, con il fondamento razionale
utilizzato per selezionare gli stessi;
-
Il numero di elementi del modello significativi da un punto di vista strutturale è proporzionale alle
dimensioni e all'ambito del sistema ed ha dimensioni che rendono comprensibili i concetti più importanti in
azione nel sistema;
|
Vista processi
Utilizzazione delle risorse
-
Le potenziali condizioni di competizione (competizione dei processi per risorse critiche) sono state
identificate e le strategie di aggiramento e risoluzione sono state definite.
-
È stata definita una strategia chiara per la gestione delle condizioni di "coda I/O piena" o "buffer pieno".
-
Il sistema esegue l'automonitoraggio (soglia di capacità, soglia prestazioni critiche, esaurimento risorse) ed
è in grado di attuare azioni correttive quando rileva un problema.
Prestazioni
-
I requisiti dei tempi di risposta per ciascun messaggio sono stati identificati.
-
Una modalità diagnostica per il sistema consente di misurare i tempi di risposta dei messaggi.
-
I requisiti di prestazione nominale e massimale per operazioni importanti sono stati specificati.
-
Una serie di test delle prestazioni è in grado di misurare se i requisiti di prestazione sono stati
soddisfatti.
-
I test delle prestazioni includono funzionalità anomale del sistema (arresto e avvio, flusso di eventi
alternati o eccezionali dei casi d'uso, modalità di guasto del sistema).
-
Debolezze strutturali che creano il potenziale per strozzature nelle prestazioni. Particolare enfasi è stata
data a:
-
-
utilizzare alcune risorse finite condivise quali semafori, gestore di file, blocchi, latch, memoria
condivisa, ecc.
-
comunicazione all'interno di processi. Le comunicazioni tra i boundary dei processi sono sempre più
dispendiose di quelle interne ai processi stessi.
-
comunicazione all'interno del processore. Le comunicazioni tra i boundary dei processi sono sempre più
dispendiose di quelle all'interno dei processi stessi.
-
utilizzo di memoria fisica e virtuale; il punto in cui il sistema non ha più memoria fisica disponibile
e incomincia ad utilizzare la memoria virtuale che coincide in genere con una riduzione drastica delle
prestazioni.
Fault tolerance
-
Dove sono in uso processi primario e di backup, il potenziale per più di un processo di ritenere di essere un
processo primario (oppure che nessuno dei processi ritenga di essere il primario) è stato considerato e azioni
specifiche di progettazione sono state intraprese per risolvere il conflitto.
-
Processi esterni sono in grado di ripristinare il sistema in uno stato coerente quando un evento quale un
errore di un processo lascia il sistema in uno stato anomalo.
-
Il sistema è in grado di tollerare errori ed eccezioni, in modo che quando si verifica uno di questi eventi, il
sistema è in grado di ripristinare uno stato coerente.
-
Test diagnostici possono essere eseguiti con il sistema in funzione.
-
Se necessario, il sistema può essere aggiornato (hardware, software) mentre è in funzione.
-
Un criterio è in grado di gestire in maniera uniforme gli avvisi del sistema e i criteri vengono applicati in
maniera uniforme. Il criterio per la gestione avvisi risponde alle esigenze di:
-
-
la "delicatezza" del meccanismo di divulgazione avvisi;
-
la prevenzione di avvisi falsi o ridondanti;
-
i requisiti di formazione e dell'interfaccia utente del personale che userà il meccanismo di
divulgazione avvisi.
-
Le prestazioni del meccanismo di divulgazione allarmi sono state valutate e sono entro soglie di accettabili,
secondo quanto prestabilito nei requisiti di prestazione.
-
I requisiti di carico di lavoro/prestazioni sono stati esaminati e sono conformi. I requisiti di prestazione
non realistici, sono stati rinegoziati.
-
I budget di memoria, nel caso in cui esistano, sono stati identificati ed il software soddisfa detti requisiti.
Sono state adottate contromisure per identificare e prevenire perdite di memoria.
-
È stato impostato un criterio per l'utilizzo della memoria virtuale, compreso come monitorarne e regolarne
l'uso.
Modularità
-
I processi sono sufficientemente indipendenti tra loro in modo da consentire la distribuzione tra processori e
nodi quando necessario.
-
Sono stati identificati i processi che devono essere colocalizzati, per requisiti di prestazioni e produttività
oppure il meccanismo di comunicazione all'interno dei processi (ad esempio, semafori o memoria condivisa) e
l'impatto di non essere in grado di distribuire il carico di lavoro è stato preso in considerazione.
-
Sono stati identificati i messaggi che è possibile rendere asincroni, così possono essere elaborati quando una
o più risorse sono disponibili.
|
Vista distribuzione
-
I requisiti di produttività sono stati soddisfatti dalla distribuzione dell'elaborazione tra nodi e potenziali
strozzature nelle prestazioni sono state risolte.
-
È stata assicurata l'integrità delle informazioni distribuite e potenzialmente replicate tra più nodi.
-
I requisiti di trasporto affidabile dei messaggi, se esistono, sono stati soddisfatti.
-
I requisiti di trasporto sicuro dei messaggi, se esistono, sono stati soddisfatti.
-
L'elaborazione è stata distribuita tra i nodi in modo che il traffico di rete e i tempi di risposta siano
ridotti al minimo, in base ai vincoli di uniformità e di risorse imposti.
-
I requisiti di disponibilità del sistema, se esistono, sono stati soddisfatti.
-
Il tempo di inattività massimo del sistema nel caso di un guasto del server o di rete è stato
determinato e rientra nei limiti accettabili in conformità ai requisiti.
-
Server ridondanti e standby sono stati definiti in modo che sia possibile designare più di uno come
server "primario".
-
Tutte le potenzialità modalità di errore sono stati documentati.
-
Gli errori di rete possono essere isolati, diagnosticati e risolti.
-
La quantità di CPU che è possibile utilizzare è stata identificata e il metodo di misurazione è stato definito.
-
Un criterio dichiarato consente di definire le azioni da intraprendere quando si supera il limite massimo di
utilizzo della CPU.
|
|
© Copyright IBM Corp. 1987, 2006. Tutti i diritti riservati.
|
|