Metodologie di Sviluppo Software: Ciclo di Vita, Prototipazione e Modelli Evolutivi (SDLC, RAD, Spirale, UML)

I Classici del Ciclo di Vita dello Sviluppo dei Sistemi (SDLC)

Il modello del ciclo di vita per lo sviluppo dei sistemi è l'insieme delle attività che analisti, progettisti e utenti svolgono per sviluppare e implementare un sistema informativo. L'approccio del ciclo di vita di sviluppo dei sistemi è costituito da 6 fasi:

1. Ricerca preliminare: La richiesta di assistenza per un sistema informativo può verificarsi per vari motivi. Indipendentemente da essi, il processo inizia sempre con la richiesta di una persona.
2. Determinazione dei requisiti di sistema: L'aspetto chiave dell'analisi dei sistemi è comprendere tutti gli aspetti importanti dell'azienda che è oggetto di studio.
3. Progettazione del sistema (System Design): La progettazione di un sistema informativo produce dettagli su come il sistema soddisferà i requisiti identificati durante la fase di analisi. Gli specialisti di sistemi si riferiscono spesso alla fase di progettazione logica rispetto allo sviluppo del software, che viene definita progettazione fisica.
4. Sviluppo del software: Il responsabile dello sviluppo del software può installare software di terze parti o scrivere programmi personalizzati per il richiedente. La scelta dipende dal costo di ciascuna alternativa, dal tempo disponibile per scrivere il software e dalla disponibilità di programmatori. In generale, gli sviluppatori che lavorano in grandi organizzazioni appartengono a un gruppo professionale stabile.
5. Test di sistema: Nel test di sistema, il sistema viene utilizzato in via sperimentale per garantire che il software non abbia difetti, che operi secondo le specifiche e nel modo in cui gli utenti si aspettano. Vengono immessi dati di test nel suo complesso per la trasformazione e i risultati vengono poi esaminati.
6. Implementazione e valutazione: L'implementazione è il processo di verifica e installazione di nuove apparecchiature, formazione degli utenti, installazione dell'applicazione e creazione di tutti i file necessari per l'utilizzo dei dati. Una volta installate, le applicazioni vengono utilizzate per molti anni. Tuttavia, le organizzazioni e gli utenti cambiano nel tempo, e anche l'ambiente è dinamico. Pertanto, è chiaro che le applicazioni devono essere mantenute.

Dimensioni della Valutazione del Sistema

La valutazione di un sistema viene effettuata per identificare punti di forza e di debolezza, e si verifica lungo le seguenti dimensioni:

• Valutazione operativa: Valutazione di come funziona il sistema, inclusa la sua facilità d'uso, tempo di risposta, adeguatezza dei formati di dati, affidabilità e livello di utilizzo.
• Impatto organizzativo: Individuazione e misurazione delle prestazioni per l'organizzazione in settori come la finanza, l'efficienza operativa e l'impatto competitivo. È incluso anche l'impatto sul flusso di informazioni interno ed esterno.
• Revisione degli amministratori: Valutazione delle attività di manager e amministratori all'interno dell'organizzazione e degli utenti finali.
• Performance di sviluppo: Valutazione del processo di sviluppo basata su criteri quali tempo e sforzi di sviluppo, conformità con i budget e le norme, e altri criteri per la gestione dei progetti. È inclusa anche la valutazione di metodi e strumenti utilizzati nello sviluppo.

Prototipazione (Prototyping)

I prototipi sono una visione preliminare del futuro sistema da implementare. La prototipazione di un sistema informativo è una tecnica utile per la rapida raccolta di informazioni specifiche sui requisiti degli utenti.

I prototipi reali dovrebbero essere introdotti presto nel ciclo di vita dello sviluppo dei sistemi, durante la determinazione dei requisiti. In questo modo, l'analista cerca le prime reazioni degli utenti e dell'amministrazione al prototipo, raccoglie i suggerimenti degli utenti per modifiche o miglioramenti del sistema per la costruzione di un prototipo, identifica potenziali innovazioni e dettaglia i piani per rivedere quella parte del sistema che deve essere realizzata per prima.

Tipi di Prototipo

• Prototype Patching (Prototipo di Rammendo): Un sistema che ha tutte le caratteristiche proposte, ma è in realtà un modello di base che sarà eventualmente migliorato. Questo tipo di prototipo funziona, ma non è efficiente né elegante.
• Prototype non operativo (Non-Operational Prototype): Il secondo tipo di prototipo è un modello in scala o non funzionale per testare alcuni aspetti del design. Questo può essere fatto quando la codifica necessaria per le applicazioni è troppo ampia per essere prototipata completamente, ma si può ottenere un'idea utile del sistema sviluppando solo prototipi di input e output. È possibile cercare il feedback degli utenti sulle interfacce (input e output). A causa di costi e tempi eccessivi, non si potrebbe fare altrimenti, ma si può cogliere parte dell'utilità del sistema basandosi solo su input e output nel prototipo.
• Primo prototipo di serie (First-of-a-Series Prototype): Un terzo concetto di prototipazione comporta la creazione di un modello in scala reale o un primo sistema, chiamato anche pilota. Questo tipo di prototipo è utile quando sono state programmate numerose installazioni dello stesso sistema. Il modello su scala reale o funzionale consente l'interazione realistica con il nuovo sistema, minimizzando al contempo il costo di superare eventuali problemi che si presentano.
• Selected Features Prototype (Prototipo a Caratteristiche Selezionate): Un prototipo a oggetti selezionati consente che il sistema sia messo in atto, mentre altre funzioni possono essere aggiunte in un secondo momento. Questo si riferisce alla costruzione di un modello operativo che include alcune, ma non tutte, le caratteristiche che avrà il sistema finale. Quando si costruisce questo tipo di prototipo, il sistema è costruito in moduli, quindi se le caratteristiche ricevono una valutazione positiva, possono essere inserite nel sistema finale, molto più grande, senza dover fare un lavoro enorme sulle interfacce. I prototipi realizzati in questo modo sono parte del sistema attuale, non sono solo un modello.

Sviluppo di un Prototipo

Al momento di decidere se includere lo sviluppo di prototipi nel quadro del ciclo di vita dello sviluppo dei sistemi, l'analista deve considerare che tipo di problema sta risolvendo e come il sistema fornisce la soluzione.

Linee guida per lo sviluppo di un prototipo

1. Lavorare con Moduli Gestibili: È utile che l'analista, quando esegue il prototipo, modelli solo alcune delle caratteristiche di un sistema per ottenere un modello funzionale. Un modello gestibile è quello che consente l'interazione con le sue caratteristiche principali, ma può ancora essere costruito separatamente dagli altri moduli di sistema. Le caratteristiche del modulo considerate meno importanti sono volutamente lasciate fuori dal prototipo iniziale.
2. Costruzione Veloce del Prototipo: La velocità è essenziale per il successo dello sviluppo di un prototipo. Il prototipo consente di accorciare i tempi di interazione degli utenti con il sistema in modo che possano iniziare a sperimentare con esso. Le tecniche di raccolta delle informazioni tradizionali, quali interviste, osservazioni e ricerche di file, vengono utilizzate. Lo sviluppo di un prototipo dovrebbe essere completato in una settimana. Per costruire un prototipo così rapidamente è necessario utilizzare strumenti particolari, come sistemi di gestione e software per database, che consentono già l'input e l'output diffuso. In questa fase del ciclo di vita, l'analista continua a raccogliere informazioni su ciò di cui gli utenti hanno bisogno e desiderano dal sistema. Mettere insieme un prototipo operativo rapidamente nelle fasi iniziali del ciclo di vita di sviluppo del sistema fornisce preziosi commenti su come dovrebbe procedere il resto del progetto. Così si mostra all'utente come agiscono le parti del sistema.
3. Modifiche al Prototipo: Un terzo orientamento per lo sviluppo del prototipo è quello di essere flessibile ai futuri cambiamenti. Ciò significa evitare la creazione di moduli altamente interdipendenti. In generale, il prototipo viene modificato più volte, passando attraverso diverse iterazioni. Le modifiche al prototipo dovrebbero avvicinare il sistema a ciò che gli utenti ritengono importante. Ogni modifica richiede un'ulteriore valutazione da parte degli utenti; queste modifiche devono essere apportate rapidamente, in uno o due giorni, a seconda anche della velocità di valutazione degli utenti.
4. Sottolineare l'Interfaccia Utente: L'interfaccia utente del prototipo (ed eventualmente del sistema) è molto importante perché ciò che si cerca di ottenere con il prototipo è consentire agli utenti di mostrare le loro crescenti esigenze. Le informazioni devono essere a più livelli per interagire facilmente con il prototipo del sistema. L'obiettivo dell'analista è progettare un'interfaccia che consenta all'utente di interagire con il sistema con una formazione minima e che permetta il massimo controllo delle funzioni rappresentate da parte degli utenti.

Vantaggi e Svantaggi della Prototipazione

• Svantaggi: È difficile gestire lo sviluppo dei prototipi in progetti di sistemi più grandi. Gli utenti e gli analisti possono scambiare un prototipo per un sistema finito, quando non è appropriato.
• Vantaggi: C'è la possibilità di apportare modifiche al sistema nelle prime fasi di sviluppo. C'è la possibilità di interrompere lo sviluppo di un sistema che non è funzionale. È possibile soddisfare più da vicino le esigenze e le aspettative degli utenti.

Il Modello RAD (Rapid Application Development)

Il Rapid Application Development (RAD) è un modello di processo lineare sequenziale per lo sviluppo del software che pone enfasi su un ciclo di sviluppo molto breve. Questo è un approccio basato sulla costruzione di componenti.

Fasi del Modello RAD

Il RAD comprende le seguenti fasi:

1. Modellazione della Gestione (Business Modeling)

Il flusso di informazioni tra le funzioni aziendali viene modellato in modo da rispondere alle seguenti domande:

• Quali informazioni guidano il processo di business?
• Quali informazioni vengono generate?
• Chi le produce?
• Dove si trovano le informazioni?
• Chi le trasforma?

2. Modellazione dei Dati (Data Modeling)

Il flusso di informazioni definito nella fase di modellazione della gestione viene raffinato come un insieme di oggetti di dati necessari per supportare l'azienda. Definisce le caratteristiche (attributi) di ciascuno degli oggetti e le relazioni tra questi oggetti.

3. Modellazione del Processo (Process Modeling)

Gli oggetti dati definiti nella fase di modellazione dei dati vengono trasformati per rendere il flusso di informazioni necessario per implementare una funzione di gestione. Vengono create descrizioni dei processi per:

• Aggiungere
• Modificare
• Eliminare
• Recuperare un oggetto dati.

4. Generazione dell'Applicazione (Application Generation)

Il RAD presuppone l'utilizzo di tecniche di quarta generazione. Invece di creare software con linguaggi di programmazione di terza generazione, il processo RAD lavora riutilizzando i componenti del programma esistenti (ove possibile) o creando componenti riutilizzabili (quando necessario). In tutti i casi, si utilizzano strumenti automatizzati per facilitare la costruzione del software.

5. Collaudo e Consegna (Testing and Turnover)

Poiché il processo RAD enfatizza il riutilizzo, molti dei componenti dei programmi sono già stati testati. Ciò riduce il tempo di collaudo. Tuttavia, è necessario testare tutti i nuovi componenti e le interfacce devono essere esercitate accuratamente. Il RAD scompone il sistema in componenti, ciascuno dei quali può essere sviluppato da un team diverso, per poi essere integrati nell'applicazione finale.

Modelli Evolutivi del Processo Software

Il software, come tutti i sistemi complessi, si evolve nel tempo. I modelli evolutivi sono iterativi e sono caratterizzati dal modo in cui consentono agli ingegneri di sviluppare versioni del software sempre più complete.

Modello Incrementale

Il modello incrementale combina elementi del modello lineare sequenziale (applicato ripetutamente) con la filosofia interattiva della prototipazione. Ogni sequenza lineare produce un "incremento" del software.

Quando si utilizza un modello incrementale, il primo incremento è spesso un elemento essenziale (core). Questo affronta i requisiti di base, ma molte funzioni aggiuntive (alcune note, altre no) non vengono rimosse. Questo processo viene ripetuto in seguito alla consegna di ogni incremento, fino a sviluppare un prodotto completo. A differenza dei prototipi, il modello incrementale si concentra sulla fornitura di un prodotto operativo con ogni incremento. Gli incrementi della prima versione non sono "scartati" dal prodotto finale, ma offrono la possibilità di servire l'utente e forniscono anche una piattaforma per la valutazione da parte dell'utente.

Dettagli Aggiuntivi sul Modello Incrementale

In un approccio generico, il processo è diviso in 4 parti: analisi, progettazione, codice e test. Tuttavia, per la produzione di software, si utilizza il principio del lavoro di linea, impiegato in molte altre forme di programmazione. Il cliente è tenuto in costante contatto con i risultati di ogni incremento. È lo stesso cliente che include o scarta gli elementi alla fine di ogni incremento, in modo che il software sia più adatto alle loro reali esigenze. Il processo viene ripetuto fino a quando il prodotto completo è sviluppato. Così il tempo di consegna è notevolmente ridotto.

Come i metodi di modellazione, il modello incrementale è di natura interattiva, ma si differenzia da essi in quanto alla fine di ogni incremento offre un prodotto completamente operativo. Il modello incrementale è particolarmente utile quando non c'è un organico sufficiente. I primi passi possono essere eseguiti da un piccolo gruppo di persone e si può aggiungere personale a ogni incremento, se necessario. Inoltre, ogni incremento può essere progettato per gestire i rischi tecnici.

Caratteristiche del Modello Incrementale

• Evita progetti di grandi dimensioni e offre "qualcosa di valore" agli utenti con una certa frequenza.
• L'utente è più coinvolto.
• Difficile valutare il costo totale.
• Difficile da applicare a sistemi transazionali che tendono ad essere integrati e operare nel loro complesso.
• Richiede manager esperti.
• Gli errori nei requisiti vengono rilevati in ritardo.
• Il risultato può essere molto positivo.

Vantaggi del Modello Incrementale

• Riduce i tempi di sviluppo iniziale, poiché la funzionalità è implementata in parte.
• Fornisce un impatto positivo per il cliente, grazie alla consegna anticipata di parti operative del software.
• Il modello fornisce tutti i vantaggi del modello a cascata (waterfall) riducendo i suoi svantaggi solo all'interno di ogni incremento.
• Consente al cliente di ricevere un prodotto più velocemente rispetto al modello a cascata.
• È più facile adattarsi ai cambiamenti, limitando la dimensione degli incrementi.
• La versatilità richiede un'attenta pianificazione sia a livello amministrativo che tecnico.

Svantaggi del Modello Incrementale

• Non è raccomandato per Sistemi in tempo reale, con elevato livello di sicurezza, elaborazione distribuita e/o indice di rischio elevato.
• Richiede molta pianificazione, sia amministrativa che tecnica.
• Richiede obiettivi chiari per lo stato del progetto.

Modello a Spirale (Spiral Model)

Il modello a spirale per l'ingegneria del software è stato sviluppato per combinare le migliori caratteristiche sia del ciclo di vita classico che della prototipazione, aggiungendo un nuovo elemento di analisi del rischio.

Processi del Modello a Spirale

1. Comunicazione con il cliente: Lavori per snellire l'interazione Sviluppatore - Cliente.
2. Pianificazione: Definizione di risorse, tempo e altre informazioni relative al progetto.
3. Analisi del Rischio: Valutazione e gestione tecnica dei rischi.
4. Ingegneria (Engineering): Costruzione di una o più rappresentazioni dell'applicazione.
5. Costruzione e Adeguamento: Attività di costruzione, collaudo e installazione dell'applicazione.
6. Valutazione del Cliente: La reazione dei clienti nei confronti dell'applicazione ottenuta dalla fase di progettazione e costruzione.

Cicli e Iterazioni

I cicli tipici includono:

• Sviluppo di concetti
• Sviluppo di nuovi prodotti
• Miglioramento del nuovo prodotto
• Manutenzione del prodotto

Durante la prima fase, si definiscono gli obiettivi, le alternative e i vincoli, e si analizzano e identificano i rischi. Il cliente valuta il lavoro di ingegneria (quadrante di valutazione del cliente) e suggerisce modifiche. In base al feedback del cliente, si verifica la successiva fase di pianificazione e analisi dei rischi. In ogni anello attorno alla spirale, il completamento dell'analisi dei rischi si traduce in una decisione "proseguire o non proseguire". Ad ogni iterazione attorno alla spirale (a partire dal centro e muovendosi verso l'esterno), si costruiscono versioni successive del software sempre più complete e, in definitiva, il sistema operativo stesso.

Caratteristiche del Modello a Spirale

• È un modello evolutivo che coniuga il modello classico con la prototipazione.
• Include la fase di analisi del rischio.
• È ideale per la creazione di prodotti migliori con diverse versioni, come nel caso del software per microcomputer moderno.
• L'ingegneria può essere sviluppata attraverso il ciclo di vita classico o la prototipazione.
• Questo è l'approccio più realistico oggi.

Vantaggi e Svantaggi del Modello a Spirale

• Vantaggi: Riduce il rischio del progetto. Integra gli obiettivi di qualità. Integra sviluppo, manutenzione, ecc.
• Svantaggi: Genera un tempo lungo per sviluppare il sistema. Modello costoso. Richiede esperienza nell'individuazione dei rischi.

Modello di Sviluppo Concorrente (Concurrent Development Model)

Il Modello di Sviluppo Concorrente, noto anche come Concurrent Engineering (dato da Davis Sitaram), può essere rappresentato sotto forma di struttura come una serie di importanti attività tecniche, compiti e condizioni ad essi associati.

Questo modello è spesso utilizzato come paradigma di sviluppo client/server. Fornisce una meta-descrizione del processo software. Il modello concorrente è in grado di descrivere le molte attività del software che avvengono contemporaneamente.

La maggior parte dei modelli di processi di sviluppo software sono guidati dal tempo (più si va avanti, più si è in fase di sviluppo). Un modello di processo concorrente è guidato dalle esigenze dell'utente, dalle decisioni di gestione e dagli esiti degli esami.

Il modello di processo concorrente definisce una serie di eventi che attivano le transizioni da uno stato all'altro per ciascuna delle attività di ingegneria del software. Durante le prime fasi di progettazione, se viene rilevata un'inconsistenza nel modello di analisi, questo genera l'evento "analisi corretta", che fa scattare l'attività di analisi delle modifiche apportate allo stato di standby. Si tratta di un tipo di modello di rete in cui tutte le persone agiscono simultaneamente.

Un sistema client/server è costituito da un insieme di componenti funzionali. Quando applicato a client/server, il modello di processo concorrente definisce le attività in due dimensioni:

• Dimensione dei sistemi.
• Dimensione dei componenti.

Gli aspetti a livello di sistema sono affrontati in tre fasi: progettazione, montaggio e utilizzo. Il modello di processo concorrente è applicabile a tutti i tipi di sviluppo del software e fornisce un quadro accurato dello stato di un progetto.

Realizzazione della Concorrenza

1. Le attività di sistemi e componenti avvengono contemporaneamente e possono essere modellate con un approccio object-oriented.
2. Un'applicazione client/server viene tipicamente implementata con molti componenti, ciascuno dei quali può essere progettato e realizzato contemporaneamente.

Vantaggi e Svantaggi del Modello Concorrente

• Vantaggi: Ideale per i progetti che costituiscono distinti gruppi di lavoro. Fornisce un quadro preciso dello stato di un progetto.
• Svantaggi: Non è efficace se le condizioni di cui sopra non si applicano. Se non ci sono gruppi di lavoro distinti, non si può lavorare con questo metodo.

Modello Unificato (UML)

Introduzione a UML

UML (Unified Modeling Language) è emerso negli anni '90 dopo la necessità di trovare un linguaggio di modellazione per unificare un settore in crescita che aveva seguito la "guerra dei metodi" degli anni '70 e '80. Sebbene sviluppato principalmente per diverse metodologie object-oriented di seconda generazione (a livello di notazione), UML non è solo un linguaggio object-oriented per la modellazione di terza generazione. La sua portata si estende oltre i suoi predecessori. È l'esperienza, la sperimentazione e l'adozione graduale del principio che rivela il suo vero potenziale e consente alle organizzazioni di realizzarne i benefici.

Definizione di UML

UML è un linguaggio di modellazione per specificare, visualizzare, costruire e documentare gli artefatti di un processo di sistema intensivo.

• Nel processo di sistema intensivo, un metodo viene applicato per arrivare o evolvere verso un sistema.
• Come linguaggio, è utilizzato per la comunicazione. È un modo per catturare la conoscenza (semantica) di un argomento e la conoscenza esplicita (sintassi) per salvaguardare il problema della comunicazione. Il problema è il sistema oggetto di studio.
• Come linguaggio per la modellazione, si concentra sulla comprensione di un soggetto attraverso la formulazione di un modello del soggetto (e dei loro rispettivi contesti). Il modello include la conoscenza dell'argomento, e la corretta applicazione di questa conoscenza è l'intelligenza.
• Si occupa di unificazione, integrando le migliori pratiche della tecnologia dell'industria meccanica e dei sistemi informativi attraverso tutti i tipi di sistemi (software e non-software), domini (business vs. software) e processi del ciclo di vita.
• Applicato per specificare, può essere utilizzato per comunicare "cosa" è richiesto da un sistema e "come" un sistema può essere eseguito.
• Riguardo a come si applica per visualizzare i sistemi, può essere utilizzato per descrivere visivamente un sistema prima che venga eseguito.
• Quanto a come si applica per costruire i sistemi, può essere utilizzato per guidare l'implementazione di un sistema, simile a un "progetto".
• Quanto a come si applica per documentare i sistemi, può essere utilizzato per acquisire la conoscenza di un sistema durante tutto il ciclo di vita del processo.

UML non è:

• Un linguaggio di programmazione visuale, ma un linguaggio di modellazione visuale.
• Uno strumento o una specifica di archiviazione, ma un linguaggio di specifica per la modellazione.
• Un processo, ma attiva i processi.

Fondamentalmente, UML è legato alla cattura della comunicazione e alla stratificazione (disintegrazione in livelli) della conoscenza.

Utility di UML

UML è un linguaggio di modellazione a scopo generale, ampiamente applicabile, supportabile da strumenti e standardizzato a livello industriale. Si applica a una moltitudine di diversi tipi di sistemi, domini e metodi o processi.

• Come linguaggio di uso generale, si concentra sul nucleo di un insieme di concetti per l'acquisizione, la condivisione e l'utilizzo della conoscenza, accoppiato con meccanismi di estensione.
• Come linguaggio di modellazione per il complesso del caso, può essere applicato a diversi tipi di sistemi (software e non-software), domini (business vs. software) e metodi o processi.
• Come linguaggio per il modello supportato da strumenti, gli strumenti sono disponibili per sostenere l'implementazione del linguaggio per specificare, visualizzare, costruire e documentare i sistemi.
• Come standard industriale per la modellazione, il linguaggio non è chiuso, non è proprietà di nessuno, ma piuttosto un linguaggio estensibile e pienamente aperto riconosciuto dall'industria.

UML consente la cattura della comunicazione e la stratificazione della conoscenza a livelli strategici, tattici e operativi per facilitare l'aumento di valore, migliorare la qualità, ridurre i costi e i tempi di immissione sul mercato, gestire i rischi ed essere proattivi rispetto al potenziale aumento della complessità e del cambiamento.

Modello di Sviluppo Basato su Componenti (Component-Based Development)

Il modello di sviluppo basato su componenti (o assemblaggio di componenti) incorpora molte delle caratteristiche del modello a spirale. È di natura evolutiva e richiede un approccio interattivo alla creazione di software. Tuttavia, questo modello applica componenti software già preparati (chiamati classi).

Ciò è possibile grazie al fatto che, se adeguatamente progettate e implementate, le classi orientate agli oggetti sono riutilizzabili per diverse applicazioni e architetture di sistemi basati su computer.

In primo luogo, si identificano le classi candidate esaminando i dati che verranno trattati dall'applicazione e l'algoritmo che verrà creato per ottenere il trattamento. Se queste classi sono state create da programmi precedenti, vengono memorizzate in una libreria di classi o repository. Inoltre, si determina quali di esse sono già esistenti, al fine di riutilizzarle.

Il modello di sviluppo basato su componenti è dominante nel riutilizzo del software, e il riutilizzo offre vantaggi agli ingegneri del software. Studi sul riutilizzo (QSM Associates, Inc.) riportano che l'assemblaggio dei componenti porta a una riduzione del 70% del ciclo di sviluppo, dell'84% dei costi del progetto e un indice di produttività del 26,2%. Non c'è dubbio che l'assemblaggio di componenti offra vantaggi significativi per gli ingegneri del software.

Vantaggi del Modello Basato su Componenti

1. Riutilizzo del software.
2. Semplifica i test.
3. Semplifica la manutenzione del sistema.
4. Qualità superiore.

Elementi Correlati

• Notazione dei componenti
• Diagramma dei componenti
• Interfacce
• Componenti e nodi (diagramma di distribuzione)
• Restrizioni
• Analisi dei rischi
  • Vantaggi e svantaggi

Conclusione sul Modello Basato su Componenti

Questo modello si basa sulla costruzione continua di una libreria di componenti (classi/oggetti) per ogni sistema. Quando si va a costruire un nuovo sistema, si definiscono gli oggetti del sistema, si cercano gli oggetti nella libreria, si costruiscono quelli che non esistono, li si inserisce nella libreria e si assemblano gli oggetti. La metodologia cerca di essere in continua evoluzione attraverso una fase di pianificazione, analisi del rischio, progettazione, costruzione e adattamento, valutazione del cliente, e ripete la procedura in modo che le prime iterazioni sviluppino concetti, sviluppino ulteriormente i nuovi componenti, cerchino poi di migliorare e infine forniscano la manutenzione.