La chiave per la valutazione leggera è di valutare le cose giuste al momento giusto. Ci sono due modi in cui so di farlo in modo efficace. Con valutazione basata su scenari si utilizzano scenari di attributo di qualità e casi d'uso per guidare la valutazione concentrandosi solo sugli attributi di qualità ad alta priorità. Con la valutazione basata sul rischio identifica i rischi e lascia che i rischi identificati guidino le tue attività di progettazione dell'architettura.
Ci sono due libri che posso consigliare che esplorano questi due approcci (in qualche modo correlati).
Architects Software Intensive Systems di Anthony Lattanze introduce la metodologia di progettazione Architecture Centric e copre scenari basati su pesi leggeri valutazioni. Puoi riconoscere Lattanze dal Workshop sugli attributi di qualità del SEI e ci sono idee simili coinvolte.
Solo abbastanza architettura software: un approccio basato sul rischio di George Fairbanks introduce, beh, un approccio orientato al rischio progettare e valutare l'architettura di un sistema software. Sono disponibili anche alcuni capitoli gratuiti disponibili sul suo sito Web se si desidera un'anteprima. Mentre i principi di questo libro sono immediatamente applicabili, l'approccio non viene fornito con un metodo specifico, quindi dovrai combinare idee provenienti da altre aree. Consiglio vivamente l'approccio SEI per la gestione dei rischi continua per identificare / classificare i rischi in modo prioritario.
L'idea alla base di questi approcci è quella di ridurre il costo della valutazione (e del design) valutando come si va piuttosto che aspettare fino alla fine. Anche se questo è certamente un po 'più pesante di quanto si possa parlare di una lavagna, non è così costoso come un ATAM completamente in fiamme. E se sei a tuo agio, puoi selezionare le pratiche per soddisfare le tue esigenze specifiche.
Indipendentemente dall'approccio che utilizzi per guidare la valutazione, l'idea generale sarà la stessa ...
Prima di iniziare:
- Scenari o rischi degli attributi di qualità, con priorità (può essere informale se è tutto ciò che hai)
- Definizione chiara per decisione go / no-go (come sai che l'architettura è "abbastanza buona")
- Il taglio più recente della descrizione dell'architettura (l'artefatto che stai valutando)
Siediti per una sessione di valutazione:
- Architect presenta una panoramica dell'architettura
- Passa attraverso una vista, mostra come lo scenario o il rischio è soddisfatto
- I problemi sono registrati per essere riparati più tardi
- I ruoli e la procedura generale sono simili a quelli usati per un'ispezione Fagan (architetto o autore, moderatore, registratore).
- La sessione potrebbe richiedere un minimo di un'ora o due a seconda delle dimensioni del sistema.
Una volta terminata la sessione:
- Rivedi i problemi identificati e determina se i criteri di go / no-go sono soddisfatti. In genere ci vogliono circa 3 recensioni per ottenere tutto ha funzionato. Se non vengono soddisfatti, continua a perfezionare e sperimentare (o attenuare i rischi dell'architettura).
- Questa non è una valutazione "tutto o niente": diverse parti della tua architettura potrebbero "passare" mentre altre hanno ancora bisogno di perfezionamento.
Per aiutarti a capire come potrebbe essere l'approccio basato sullo scenario, c'è qualche documentazione pubblica da un progetto di capstone ho lavorato a scuola elementare. La documentazione è un po 'approssimativa, ma potrebbe fornire alcuni esempi dell'approccio basato su scenari nel contesto di ACDM. Eravamo un team di 5 e abbiamo creato una tipica applicazione basata sul web, circa 35 KLOC Java / GWT.