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

Considerazioni sull'analisi dell'architettura

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.