Qual è un buon metodo per eseguire una valutazione dell'architettura leggera?

9

Ho familiarità con i metodi di valutazione dell'architettura come il metodo di analisi del tradeoff dell'architettura (ATAM) e Metodo di analisi costi benefici (CBAM) . Tuttavia, questi metodi sono abbastanza grandi: prescrivono diverse sessioni di brainstorming, presentazioni, sviluppo di una serie di scenari che descrivono i compromessi, ecc. Sebbene utili per progetti di una certa dimensione, sono troppo grandi per progetti interni o applicazioni desktop tipicamente sviluppato da una manciata di sviluppatori (o meno), che anche se sono piccoli, hanno alcuni vincoli di qualità abbastanza ripidi (prestazioni, scalabilità, adattabilità).

Una pratica tipica che ho usato in passato è quella di avere uno sviluppatore (o l'architetto se un team ne ha uno) per creare un'architettura generale per l'applicazione e poi discuterlo su una lavagna con il resto del team , in genere utilizzando alcune notazioni di pseudo-UML facili da disegnare e comprendere. Questo in genere porta al feedback e ad alcune iterazioni sull'architettura. Ma tende ad essere un po 'troppo informale causando tutti i tipi di ipotesi che possono in seguito rivelarsi decisioni sbagliate.

Metodi come ATAM di solito costringono tutte le parti interessate a riflettere profondamente sull'architettura, il che porta a discussioni finché tutti non sono d'accordo su quale sia esattamente l'architettura .

Qualcuno ha esperienza nel fare una valutazione dell'architettura up-front leggera? Se sì, quali sono le buone pratiche?

    
posta Deckard 03.05.2011 - 22:16
fonte

2 risposte

6

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.

    
risposta data 06.05.2011 - 16:19
fonte
2

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

Ovviamente, se i tuoi requisiti non funzionali lo richiedono (vincoli di memoria, tempi di risposta, numero di utenti simultanei, ecc.), devi tenerne conto al momento dell'implementazione del sistema.

    
risposta data 03.05.2011 - 22:58
fonte

Leggi altre domande sui tag