Operazione: Analisi dell'architettura
Questo compito definisce quando e come condurre un'analisi dell'architettura e considerare i risultati dell'analisi.
Discipline: Analisi e progettazione
Scopo
  • Scoprire la presenza di eventuali rischi non percepiti nei tempi o nel budget.
  • Identificare gli errori di progetto strutturali. Gli errori strutturali sono noti come i più difficili da risolvere, e quelli che creano alla lunga maggior danno.
  • Identificare una potenziale discrepanza tra i requisiti e l'architettura: sovra progettazione, requisiti non realistici o mancanti. In particolare la valutazione potrebbe prendere in esame alcuni aspetti spesso sottovalutati dalle aree operative, di gestione e manutenzione. Come si installa il sistema? È aggiornato? Come si effettua la transizione del database corrente?
  • Valutare una o più qualità strutturali specifiche: prestazioni, affidabilità, modificabilità, protezione, sicurezza.
  • Identificare le opportunità di riutilizzo
Relazioni
RuoliEsecutore primario: Esecutori aggiuntivi:
InputObbligatorio: Facoltativo:
Output
Utilizzo del processo
Passi
Consigli generali
Scopo Consigli generali per ciascuna revisione.

Osservando da lontano non ci sono molte cose che distinguono una valutazione dell'architettura software da qualsiasi altra valutazione o analisi.

Tuttavia, una caratteristica importante dell'architettura software è la mancanza di misurazioni specifiche per molti attributi di qualità strutturali, solo alcuni potranno essere misurati in modo oggettivo. Le prestazioni sono un esempio di dove questa misurazione è possibile. Altre qualità sono più soggettive: l'integrità concettuale ad esempio. Inoltre è spesso difficile decidere il peso da dare ad una metrica in assenza di altri dati di riferimento da confrontare. Se un sistema di riferimento è disponibile e compreso dall'utenza di destinazione, conviene spesso esprimere alcuni dei risultati dell'analisi in modo relativo a questo sistema di riferimento. Ciò potrà verificarsi in un contesto dove il sistema in fase di progettazione potrà essere confrontato con un progetto precedente.

Il punto del ciclo in cui avviene la valutazione ne influenza lo scopo e la completezza.

Diagramma dell'iterazione del ciclo del progetto

  1. Al termine della fase di inizio validità in un ciclo di sviluppo iniziale, solitamente è ancora poca la struttura concreta definita. Ma un'analisi potrebbe scoprire degli obiettivi non realistici, parti mancanti, opportunità mancate di riutilizzo di prodotti esistenti e così via.
  2. La fase migliore per effettuare una valutazione dell'architettura software è al termine della fase di elaborazione. Qui si concentra l'esplorazione dei requisiti nel dettaglio, e la definizione delle linee di base di un'architettura. Un'analisi dell'architettura è richiesta dal RUP in questo punto cardine. Questo è il momento in cui un vasto raggio delle qualità viene esaminato.
  3. Una valutazione più dettagliata potrà essere eseguita durante la fase di costruzione per esaminare le qualità specifiche degli attributi, quali le prestazioni o la sicurezza, ed al termine di questa fase per esaminare qualsiasi problema ancora in sospeso che potrebbe rendere il prodotto non adatto all'utente.
  4. Una valutazione di controllo dei danni potrà essere eseguita più avanti nella fase di costruzione o nella fase di transizione, se le cose sono andate davvero male: non è stata completata la costruzione, oppure si è presentato un numero di problemi non accettabile nella base installata durante la transizione.
  5. In fine la valutazione potrà essere effettuata alla fine della fase di transizione, in particolare per inventariare le risorse riutilizzabili per un eventuale nuovo prodotto o ciclo di evoluzione.

Il revisore ha lo stesso profilo del Ruolo: Architetto di software, con una maggiore propensione alle problematiche tecniche. Leadership, maturità, pragmatismo, e predisposizione al risultato sono importanti a livello inferiore ma comunque importanti, un revisore potrebbe scoprire errori strutturali che possono mettere a rischio i tempi del progetto. È comunque meglio sollevare problemi critici all'inizio, quando possono essere risolti, piuttosto che seguire ciecamente una pianificazione che rischia di portare il team del progetto su un percorso sbagliato. Il revisore strutturale deve bilanciare i rischi con i costi, e restare sensibile agli ampi problemi da superare per il buon esito del progetto. Egli deve inoltre essere un buon comunicatore in grado di sollevare e discutere problematiche delicate.

Riunioni di analisi consigliate
Scopo Definire gli ambiti e gli obiettivi dell'analisi.
Definire gli approcci per ciascuna combinazione ambito/obiettivo. 

Potranno essere utilizzati approcci diversi per eseguire l'analisi:

  • basata su una rappresentazione
  • basata su informazioni
  • basata su scenari
Analisi basata sulla rappresentazione

Procurarsi (o compilare) una rappresentazione dell'architettura, quindi fare domande e ragionare sulla base della rappresentazione.

C'è un ampio raggio di situazioni, dalle organizzazioni che sono molto avanzate dal punto di vista strutturale e che forniranno una descrizione comprensibile con cui partire, ad altre dove sarà necessario identificare l'architetto di software (che può celarsi sotto altro nome) a cui sarà necessario chiedere le informazioni, fino alle aziende dove l'architettura software non è nemmeno conosciuta. Questo processo viene definito "ricerca dell'architettura", ed in pratica assomiglia molto ad una ricerca in una miniera: scavare nel software o nella sua documentazione con un piccone, osservare il codice sorgente, le interfacce, i dati di configurazione e così via.

Un modello che può essere utilizzato per la rappresentazione si trova sotto forma di una vista strutturata nel documento dell'architettura software: la vista logica organizza le classi principali (il modello dell'oggetto), la vista processi descrive i thread di controllo principali e come comunicano, la vista sviluppo mostra i vari sottosistemi e le loro dipendenze, la vista fisica descrive l'associazione degli elementi di altre viste su una o più configurazioni fisiche. Organizzare i problemi di fianco alle varie viste.

Analisi basata sulle informazioni

Definire l'elenco di dati informativi e delle misurazioni necessarie per il ragionamento, prendere le informazioni e confrontarle con i requisiti o con uno standard di riferimento accettato. Tutto ciò si applica bene all'analisi di determinati attributi di qualità, quali le prestazioni, o la solidità.

Analisi basata su uno scenario

Questo è un approccio sistematico del tipo "Cosa se". Trasformare le domande generali in una serie di scenari attraverso i quali dovrà passare il sistema e fare domande basate su di essi. Alcuni esempi di scenari sono:

  • Il sistema viene eseguito sulle piattaforme X e Y. (L'attributo di qualità reale analizzato è la portabilità)
  • Il sistema esegue questa funzione (aggiuntiva) F. (L'attributo di qualità reale è l'espandibilità).
  • Il sistema elabora 200 richieste all'ora. (L'attributo di qualità reale è la scalabilità).
  • Il sistema viene installato sul sito di questo tipo dall'utente. (L'attributo di qualità reale è la completezza e utilizzabilità).

Il vantaggio di un tale approccio è che esso dà al compito una prospettiva molto concreta, comprensibile da tutti gli interlocutori. Consente inoltre di analizzare le omissioni o gli errori nei requisiti, specie se questi sono informali, non scritti o molto generici. Lo svantaggio è che non considera l'architettura stessa come un'oggetto da analizzare, ma considera il sistema come una scatola nera in cui si stanno inviando delle analisi.

In realtà le cose non sono separate così nettamente, e si finisce per utilizzare una parte di ciascun approccio.

Identificazione dei problemi

La scoperta di potenziali problemi viene effettuata per la maggior parte dal giudizio umano basato sulla conoscenza e l'esperienza. Determinati modelli di errore vengono si propagano da un progetto all'altro, da un'organizzazione all'altra. Determinate euristiche potranno essere utilizzate per scoprire delle aree di problemi. Gli elenchi di controllo potranno essere utili (alcuni molto generici verranno proposti in seguito), ed anche i risultati di analisi precedenti se ve ne fossero.

Registrare i problemi potenziali appena si manifestano, descrivendoli con tono neutrale, senza puntare il dito e senza "catastrofismi". Utilizzare piccole schede di cartone per assegnargli una priorità, per organizzarli ed eliminarli.

Successivamente ordinare i problemi candidati in modo decrescente per ambito o impatto, e se ne sono tanti, contrastare prima quelli direttamente in relazione alla questione attualmente gestita, lasciando gli "altri suggerimenti" per dopo, se il tempo lo dovesse consentire. Valutare la realtà del problema: spesso capita che qualcuno percepisca un problema che si rivela poi infondato. Non si è parlato con la persona giusta o guardato all'informazione corretta. Organizzare nuovamente. Definire più fonti di informazione per verificare la realtà del problema. (Un valutatore inesperto tende ad attenersi troppo ai singoli thread.)

Una volta confermato il problema, esaminare rapidamente cosa lo può eliminare, senza dover necessariamente cercare riprogettare in volo il sistema. Appuntare le possibili semplificazioni, riutilizzi ed alternative (ad esempio, comprare o costruire).

Assegnazione delle responsabilità di risoluzione degli errori
Scopo Agire sui difetti identificati. 

Dopo l'analisi, assegnare le responsabilità per ciascun errore identificato. La "Responsabilità" in questo caso non è quella di risolvere il problema, ma di coordinare ricerche aggiuntive o alternative, oppure di coordinare la soluzione dell'errore se ha un grande impatto sull'ambito.



Ulteriori informazioni