Qual è un buon metodo per fare la valutazione dell'architettura leggera?

Ho familiarità con i metodi di valutazione dell'architettura come il Technical Architecture Tradeoff Analysis Method (ATAM) e il metodo di analisi costi-benefici più orientato al business (CBAM) . Tuttavia, questi metodi sono su larga scala: prescrivono diverse sessioni di brainstorming, presentazioni, sviluppo di una serie di scenari che descrivono compromessi, ecc. Sebbene utili per progetti di una certa dimensione, sono troppo grandi per progetti interni o applicazioni desktop che sono in genere sviluppato da una manciata di sviluppatori (o meno), che sebbene siano piccoli, hanno alcuni vincoli di qualità piuttosto ripidi (prestazioni, scalabilità, adattabilità).

Una pratica tipica che ho usato in passato è avere uno sviluppatore (o l'architetto se un team ne ha uno) per elaborare un'architettura generale per l'applicazione e quindi discuterne su una lavagna con il resto del team, in genere utilizzando qualche notazione pseudo-UML che è facile da disegnare e capire. Questo di solito porta a feedback e alcune iterazioni sull'architettura. Ma tende ad essere un po 'troppo informale e fa sì che vengano fatti tutti i tipi di ipotesi che possono poi rivelarsi decisioni sbagliate.

Metodi come ATAM in genere costringono tutte le parti interessate a riflettere in profondità sull'architettura, il che porta a discussioni fino a quando almeno tutti concordano su cosa sia esattamente l'architettura .

Qualcuno ha esperienza con la valutazione dell'architettura iniziale leggera? In tal caso, quali sono le buone pratiche?

La chiave per una valutazione leggera è valutare le cose giuste al momento giusto. Ci sono due modi che conosco per farlo efficacemente. Con la valutazione basata su scenari, si utilizzano scenari di attributi 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, si identificano i rischi e si lascia che i rischi identificati guidino le attività di progettazione dell'architettura.

Ci sono due libri che posso consigliare che esplorano questi due approcci (in qualche modo correlati).

Architecting Software Intensive Systems di Anthony Lattanze introduce la Metodologia di progettazione incentrata sull'architettura e copre valutazioni leggere basate su scenari. Puoi riconoscere Lattanze dal Workshop sugli attributi di qualità del SEI e ci sono idee simili coinvolte.

Architettura del software sufficiente: un approccio orientato al rischio di George Fairbanks introduce, beh, un approccio orientato al rischio per la progettazione e la valutazione dell'architettura di un sistema software. Ci sono 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 di gestione del rischio continuo del SEI per l'identificazione / definizione delle priorità dei rischi.

L'idea alla base di questi approcci è quella di ridurre i costi di valutazione (e progettazione) valutando man mano che si procede piuttosto che attendere fino alla fine. Mentre questo è certamente un po 'più pesante rispetto a parlare attorno a una lavagna, non è affatto costoso come un ATAM completamente saltato. E se sei a tuo agio, puoi scegliere le pratiche per soddisfare le tue esigenze specifiche.

Indipendentemente dall'approccio che usi per guidare la valutazione, l'idea generale sarà la stessa ...

Prima che inizi:

• Scenari o rischi di attributi di qualità, con priorità (può essere informale se è tutto ciò che hai)
• Definizione chiara per decisione go / no-go (come fai a sapere se l'architettura è "abbastanza buona")
• Taglio più recente della descrizione dell'architettura (l'artefatto che stai valutando)

Siediti per una sessione di valutazione:

• L'architetto presenta una panoramica dell'architettura
• Cammina attraverso una vista, mostra come lo scenario o il rischio sono soddisfatti
• I problemi vengono registrati per essere risolti in un secondo momento
• I ruoli e la procedura generale sono simili a quelli utilizzati per un'ispezione di Fagan (architetto o autore, moderatore, registratore).
• La sessione potrebbe richiedere solo un'ora o due a seconda delle dimensioni del sistema.

Al termine della sessione:

• Rivedere i problemi identificati e determinare se i criteri go / no-go sono soddisfatti. Generalmente sono necessarie circa 3 recensioni per ottenere tutto risolto. Se non soddisfatto, continua a perfezionare e sperimentare (o mitigare i rischi dell'architettura).
• Questa non è una valutazione "tutto o niente" - diverse parti della tua architettura potrebbero "passare" mentre altre necessitano ancora di raffinamento.

Per darti un'idea di come potrebbe essere l'approccio basato sullo scenario, c'è della documentazione pubblica di un progetto capstone a cui ho lavorato a scuola di specializzazione. La documentazione è un po 'approssimativa, ma potrebbe aiutare a fornire alcuni esempi dell'approccio basato sullo scenario nel contesto di ACDM. Eravamo un team di 5 persone e abbiamo creato una tipica applicazione basata sul Web, circa 35 KLOC Java / GWT.

Mi piacciono le discussioni informali sulla lavagna per cominciare. Sono appassionato di scrivere solo la parte dell'applicazione che è necessaria oggi e quindi lasciare gradualmente emergere l'architettura durante l'implementazione. È più come "trovare l'architettura", piuttosto che cercare di inventarla in anticipo. Questo approccio non richiede una valutazione anticipata e aiuta a concentrarsi su ciò che è importante (fornire software funzionante).

Naturalmente, se i requisiti non funzionali lo richiedono (vincoli di memoria, tempi di risposta, numero di utenti simultanei ecc.), È necessario tenerne conto durante l'implementazione del sistema.