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).
|