Linea guida: Decisioni importanti per analisi e progettazione
Queste linee guida descrivono importanti elementi da considerare nella personalizzazione degli aspetti di analisi e progettazione del processo.
Relazioni
Descrizione principale

Decidere come utilizzare i prodotti di lavoro

Determinare quali prodotti del lavoro  utilizzare e le relative modalità d'impiego.  Oltre ad identificare i prodotti del lavoro da utilizzare, è importante anche personalizzarli in modo da farli aderire alle necessità del progetto. 

La tabella riportata di seguito specifica i prodotti del lavoro di analisi & progettazione raccomandati e quelli facoltativi (da utilizzare ad esempio solo  in certi casi). Per ulteriori considerazioni sulla personalizzazione, consultare la sezione relativa nella pagina descrittiva del prodotto del lavoro.

Prodotto di lavoro Scopo

Personalizzazione (facoltativo, consigliata)

Modello di analisi (Classe di analisi) Un modello di analisi consente di comprendere meglio i requisiti prima di decidere sul progetto. In sistemi complessi può essere utilizzato per offrire una panoramica concettuale sul sistema stesso.

Facoltativo

Numerosi progetti si servono inizialmente di un Modello di progettazione invece di un Modello di analisi.

I modelli di analisi che vengono creati in un progetto sono di solito artefatti temporanei, che evolvono in modelli di progettazione.

Mappa di esplorazione, Prototipo dell'interfaccia utente

Progetti con interfacce utente grandi e complesse devono attuare la progettazione dell'interfaccia utente.

Facoltativo

Progettazioni dell'interfaccia utente più informali possono bastare nel caso di uno sviluppo meno impegnativo.

Modello di progettazione

La maggior parte dei sistemi, anche i più piccoli, devono essere progettati prima di essere implementati per evitare rilavorazioni costose imputabili ad errori nel progetto. I modelli visivi facilitano le comunicazioni sul progetto. I tool per il forward engineering e reverse engineering possono garantire uniformità con il modello di implementazione e risparmiare impegno.

Consigliato per la maggior parte dei progetti.

In progetti di dimensioni ridotte, l'uso di tool automatizzati non è critico, anche se può offrire vantaggi nella produttività a lungo termine.

Classe di progettazione; Pacchetto di progettazione

Le classi e i pacchetti sono componenti base per qualsiasi progetto orientato agli oggetti. La progettazione orientata agli oggetti rappresenta l'approccio di progettazione standard, utilizzato nella maggior parte dei progetti.

Consigliato per la maggior parte dei progetti.

Le problematiche principali per la personalizzazione vertono essenzialmente sulla decisione degli stereotipi da utilizzare, che possono essere catturati nelle linee guida della progettazione.

Realizzazione di caso d'uso

Offrire un ponte per collegare casi d'uso e progetto.

Consigliato per la maggior parte dei progetti.

Interfaccia

Le interfacce sono utilizzate di solito per definire il comportamento indipendentemente dai componenti a grana grossa che realizzano il comportamento stesso.

Consigliato per la maggior parte dei progetti.

La progettazione basata su componenti sta assumendo anch'essa il ruolo di progettazione standard.

Sottosistema di progettazione

I sottosistemi di progettazione consentono di incapsulare il comportamento in un componente che fornisce le interfacce, a sua volta utilizzato per incapsulare le interazioni tra classi e/o altri sottosistemi.

Consigliato per la maggior parte dei progetti.

I sottosistemi sono spesso utili per aumentare il livello di astrazione del progetto. Rendono i sistemi più comprensibili.

Evento

Utile nei casi in cui i sistemi devono rispondere a molti eventi esterni. Consigliata per i sistemi real-time.

Protocollo

Richiesto per i sistemi real-time. Consigliata per i sistemi real-time.

Segnale

Utile nei casi in cui i sistemi richiedono simultaneità e sono basati su eventi.

Richiesto per i sistemi real-time.

Utile nei casi in cui i sistemi richiedono simultaneità e sono basati su eventi.

Consigliata per i sistemi real-time.

Capsula

Consigliata per i sistemi real-time, anche se può risultare utile nella modellazione e progettazione di un qualsiasi sistema ad elevato grado di simultaneità.

Consigliata per i sistemi real-time.

Modello di dati Utilizzato per descrivere la struttura logica e possibilmente fisica delle informazioni permanenti.

Consigliata per i progetti che utilizzano un database.

Modello di distribuzione Mostra la configurazione dei nodi di elaborazione al run-time, i collegamenti tra gli stessi e le istanze e gli oggetti del componente che in essi risiede.

Facoltativo.

Numerosi sistemi sono dotati di più nodi di elaborazione e pertanto devono utilizzare il Modello di distribuzione, che può essere catturato, tuttavia, come una sezione del Documento dell'architettura software e non esiste come artefatto identificato indipendentemente.

Proof of concept strutturale Utilizzato per determinare se esiste una soluzione che soddisfa i requisiti significativi in termini strutturali. Consigliato per la maggior parte dei progetti.

Molti progetti usano Proof of concept strutturale per determinare la praticabilità dei requisiti. Può assumere vari formati, ad esempio:

  • un elenco di tecnologie note che sembrano appropriate per la soluzione
  • uno sketch di un modello concettuale di una soluzione
  • una simulazione di una soluzione
  • un prototipo eseguibile.
Architettura di riferimento L'architettura di riferimento accelera lo sviluppo e riduce i rischi riutilizzando soluzioni comprovate.

Consigliato per la maggior parte dei progetti.

Se esiste materiale che si adatta all'architettura di riferimento, è possibile ridurre drasticamente i tempi di sviluppo e i rischi.

Documento dell'architettura software (SAD) Il Documento dell'architettura software ha l'intento di offrire una panoramica completa dell'architettura del sistema. Questa panoramica è utile per comprendere il sistema e catturare le decisioni chiave dell'architettura.

Consigliato per la maggior parte dei progetti.

Una panoramica ad alto livello dell'architettura software è utile per tutti i sistemi, tranne nei casi di sistemi più piccoli. I sistemi complessi richiedono in genere un livello di dettaglio più ampio e più viste rispetto ai progetti più piccoli.

Prototipo dell'interfaccia utente Utilizzato per illustrare e verificare la funzionalità e utilizzabilità prima di avviare lo sviluppo vero e proprio. È uno strumento efficace per convalidare il progetto prima di incorrere in lungaggini.

Consigliato per la maggior parte dei progetti.



Decidere quali report utilizzare

La decisione relativa ai report da utilizzare dipenderà dai tool dei report disponibili nel progetto. Se i tool sono sono disponibili, si consiglia di generare report per prodotti di lavoro basati su modelli, quali classi di progettazione e realizzazioni di casi d'uso. Report esistenti nella configurazione del RUP sono disponibili nelle pagine descrittive del prodotto di lavoro oppure raggruppati nel browser della struttura del prodotto di lavoro in questione.

Decidere come eseguire la revisione

Decidere il livello di revisione da utilizzare per ogni prodotto del lavoro.  In modo specifico, decidere le modalità di revisione ed approvazione dei risultati di analisi & progettazione e per quali estensioni vanno esaminati tali risultati.  

I vantaggi nella conduzione di verifiche durante analisi & progettazione includono:

  • Individuazione di problemi che sono impossibili o molto difficili da rilevare in fase di verifica. Ad esempio, problematiche di stile e layout. 
  • Un metodo per applicare uno stile di modellazione comune e un'opportunità per gli individui di mettersi a confronto. 
  • Individuazione dei difetti che sono rilevabili solo in un momento successivo quando il progetto è già in fase di verifica.

Gli svantaggi delle revisioni durante analisi & progettazione includono:

  • La richiesta di tempo e risorse.  
  • Un probabile utilizzo non corretto nel caso di cattiva gestione.

I fattori che possono essere alterati per le revisioni di analisi & progettazione sono le tecniche di revisione, le risorse e l'ambito. Di seguito sono riportati alcuni esempi di ciò che è possibile attuare nel progetto:

  • Decidere che le modifiche locali a un sottosistema vengano valutati da un collega di pari livello, che condurrà un'ispezione e trasferirà i risultati su carta.
  • Decidere quali parti del progetto non sono da revisionare; ad esempio, revisionare solo alcune classi per ciascun membro del progetto e sperare che questo garantisca uniformità nella qualità dello stile con il resto dei risultati.
  • Decidere se il documento dell'architettura software debba essere revisionato dal cliente in una riunione a parte.
  • Decidere di utilizzare riunioni per una revisione formale per modifiche importanti delle interfacce che implicano sul lavoro di molti membri del progetto.

Per ulteriori informazioni sui livelli di revisione, consultare Linea guida: Livelli di revisione.  

Decidere se generare il codice

Il modo di progettare è diverso a seconda se si genera il codice da un modello di progettazione o no. Se si genera il codice, il progetto deve essere dettagliato. Se non si genera un codice da un modello, non è necessario essere molto dettagliati nel progetto. Al contrario, i dettagli nel progetto dovranno essere sincronizzati con il codice manualmente.