Rational Unified Process in Software Testing

La metodologia Rational Unified Process (RUP) usa l’approccio orientato agli oggetti nella sua progettazione e l’uso della notazione UML (Unified Modeling Language) è progettato e documentato per illustrare i processi in azione. Utilizza tecniche e pratiche provate commercialmente.

È un processo considerato pesante e preferibilmente applicabile a grandi team di sviluppo e grandi progetti, ma il fatto che sia ampiamente personalizzabile permette di adattarlo a progetti di qualsiasi scala.

Specifici

Per la gestione dei progetti, il modello RUP (Rational Unified Process) fornisce una soluzione disciplinata come i compiti e le responsabilità delineate in un’organizzazione di sviluppo software.

RUP (Rational Unified Process) è, in sé, un prodotto software. È modulare e automatizzato, e la sua intera metodologia è supportata da diversi strumenti di sviluppo integrati e venduti da IBM attraverso le sue “Rational Suites”.

I metodi di competizione nel campo dell’ingegneria del software includono “camere bianche” (considerate pesanti) e agili (leggere) come la Programmazione Estrema (XP-Extreme Programming), Scrum, FDD, e altri.

Ci sono alcune linee guida e modelli che sono definiti, per i membri dello staff di un ciclo di produzione, da RUP: parte del cliente e una valutazione del progresso del progetto da parte del suo management. Aiuta gli sviluppatori a rimanere concentrati sul progetto.

Requisiti di gestione

La documentazione corretta è essenziale per qualsiasi progetto su larga scala; si noti che RUP descrive come documentare la funzionalità, i limiti del sistema, le restrizioni di progettazione e i requisiti aziendali.

I casi d’uso e gli scenari sono esempi di artefatti di processo dipendenti, che sono stati considerati molto più efficaci nel catturare i requisiti funzionali.

L’uso di un’architettura basata sui componenti

L’architettura basata sui componenti crea un sistema che può essere facilmente estensibile, promuovendo il riutilizzo e il software una comprensione intuitiva. Un componente di solito si riferisce ad un oggetto nella programmazione orientata agli oggetti.

RUP fornisce un modo sistematico per costruire questo tipo di sistema, concentrandosi sulla produzione di un’architettura eseguibile nelle prime fasi del progetto, cioè prima di impegnare risorse su larga scala.

I componenti a cui si fa riferimento qui sono generalmente inclusi nelle infrastrutture già esistenti nel luogo. Queste infrastrutture includono CORBA così come Component Object Model (COM).

L’uso di modelli visivi di software nel modello Rup

Astraendo la programmazione del codice e rappresentandola usando blocchi grafici, RUP può essere un modo efficace per avere una visione d’insieme di una soluzione.

L’uso di modelli visivi può anche permettere agli individui con un profilo meno tecnico (come i clienti) di avere una migliore comprensione di un dato problema, e quindi essere più coinvolti nel progetto nel suo insieme.

Il linguaggio di modellazione UML è diventato uno standard industriale per rappresentare i progetti, ed è ampiamente usato da RUP! Leggi i dettagli esclusivi di Agile Testing

Controlla la qualità del software

Non assicura la qualità del software è il fallimento più comune in tutti i progetti di sistemi informatici. Di solito, si pensa alla qualità del software dopo il completamento dei progetti o la qualità è la responsabilità di un diverso team di sviluppo.

Gestione e controllo del cambiamento del software

In tutti i progetti software, l’esistenza del cambiamento è inevitabile. RUP definisce metodi per controllare e monitorare i cambiamenti. Poiché un piccolo cambiamento può influenzare le applicazioni in modi totalmente imprevedibili, il controllo dei cambiamenti è essenziale per il successo di un progetto.

RUP (Rational Unified Process) definisce anche le aree di lavoro e di sicurezza, che garantiscono ad un programmatore che i cambiamenti in un altro sistema non influenzeranno il tuo sistema.

Fasi della metodologia RUP

Fin qui queste linee guida sono generali, da rispettare per attraversare la vita di un ciclo di progetto. Le fasi (vedi figura seguente) indicano l’enfasi data al progetto in un dato momento. Per catturare la dimensione temporale di un progetto, RUP divide il progetto in quattro fasi diverse:

Inizio o Design: enfasi sulla portata del sistema;

Preparazione: enfasi sull’architettura;

Costruzione: enfasi sullo sviluppo;

Transizione: enfasi sull’applicazione.

RUP si basa anche sulle 4 P:

• People
• Design
• Product
• Process

I livelli sono composti da iterazioni. Le iterazioni sono finestre di tempo; le iterazioni hanno definito il termine come le fasi sono oggettive.

Tutte le fasi generano artefatti. Questi saranno usati nella fase successiva e documentano il progetto e permettono un migliore follow-up.

Fase di design

La fase di design o di iniziazione contiene i flussi di lavoro necessari per l’accordo delle parti interessate – stakeholders – con gli obiettivi, architettura e pianificazione del progetto. Se questi attori hanno una buona conoscenza, non sarà necessario analizzare. Altrimenti, è necessaria un’analisi più elaborata.

In questa fase, i requisiti essenziali del sistema sono trasformati in casi d’uso. L’obiettivo non è di chiuderli del tutto, ma solo quelli che sono necessari per dare forma al parere.

La fase è di solito breve e serve per definire se è fattibile continuare con il progetto e definire i rischi e il costo dell’ultimo. Si può realizzare un prototipo da far approvare al cliente. Come cita il RUP, l’ideale è eseguire iterazioni, che devono essere ben definite in termini di quantità e obiettivi.

Fase di Elaborazione

La preparazione sarà per il disegno del sistema, come complemento all’indagine e/o documentazione dei casi d’uso, di fronte all’architettura del sistema, per rivedere il modello di business del progetto e per iniziare la versione del manuale utente. Si deve accettare: La descrizione del prodotto (aumento + integrazione) è stabile; il piano del progetto è affidabile? I costi sono ammissibili?

Fase di costruzione

Nella fase di costruzione, inizia lo sviluppo fisico del software, codici di produzione, test alfa. I test beta sono stati eseguiti all’inizio della fase di transizione.

È necessario accettare i test, i processi stabili e di prova, e il codice del sistema è “baseline”.

Fase di transizione

In questa fase è la consegna (“deployment”) del software, che esegue il piano di distribuzione e consegna, il monitoraggio e la qualità del software. I prodotti (rilasci, versioni) stanno per essere consegnati, e la soddisfazione del cliente luogo. In questa fase si svolge anche la formazione degli utenti.

Discipline della metodologia RUP (Rational Unified Process)

La disciplina del Business Modeling

Le organizzazioni sono sempre più dipendenti dai sistemi IT, quindi è imperativo che i tecnici dei sistemi informativi sappiano come le applicazioni sono integrate nello sviluppo dell’organizzazione. Le aziende investono nell’IT, che comprende il vantaggio competitivo del valore aggiunto dalla tecnologia.

L’obiettivo della modellazione del business è di stabilire prima una migliore comprensione e comunicazione tra l’ingegneria del business e l’ingegneria del software.

Comprendere il business significa che gli ingegneri del software devono capire la struttura e le dinamiche dell’azienda di destinazione (il cliente), i problemi attuali che l’organizzazione sta affrontando e potenziali metodi e strategie per fare ammenda.

Un altro aspetto importante da non sottovalutare è che le parti interessate come gli sviluppatori così come i clienti e anche gli utenti finali devono avere una chiara comprensione dell’organizzazione, e una caratteristica importante di questa comprensione è che deve essere comune tra tutte le parti coinvolte.

Il business modeling spiega come descrivere la visione di un’organizzazione in cui il sistema sarà implementato e come usare questa visione come base per descrivere i processi, le funzioni e le responsabilità.

Requisiti del sistema

Questo corso spiega come ottenere richieste dalle parti interessate (“parti interessate”) e convertirle in un insieme di requisiti che i prodotti funzionino all’interno del sistema da costruire e fornire i requisiti dettagliati di ciò che è necessario per il sistema.

Analisi e progettazione della disciplina (“Design”)

Lo scopo dell’analisi e della progettazione è di mostrare come il sistema sarà realizzato. L’obiettivo è costruire un sistema che:

Esegua in un ambiente di esecuzione specifico, i compiti e le funzioni specificate nelle descrizioni dei casi d’uso

Soddisfa tutte le esigenze

È facile da mantenere quando non ci sono cambiamenti nei requisiti funzionali, i risultati del progetto in un modello di analisi e design ha opzionalmente un modello di analisi.

Il modello di design è utilizzato come una versione concettuale del codice sorgente, mostrando solo il minimo indispensabile. Questo permette all’utente di qualsiasi ispezione di accertare lo stile in cui il codice sorgente è stato reso.

Il modello di disegno è reso in modo tale da contenere diverse divisioni di disegni. Queste divisioni sono memorizzate all’interno di determinati sottosistemi.

Ogni sottosistema ha un’interfaccia distinta che è progettata con precisione. Contiene anche descrizioni di come gli oggetti di queste classi collaborano per realizzare il disegno dei casi d’uso.

L’implementazione della disciplina

Gli effetti dell’applicazione sono:

• Con riferimento ai sottosistemi stratificati organizzati per un’applicazione, si configura il codice di organizzazione.
• Si realizzano diverse classi o divisioni di componenti. Questi componenti includono

1. File sorgente
2. Eseguibili e
3. Binari

• I componenti sviluppati come unità vengono testati

Incorpora i risultati prodotti dai singoli esecutori (o team), in un sistema eseguibile. I sistemi sono realizzati attraverso i componenti dell’applicazione.

Il processo mira a svolgere un’importante funzione, che è quella di definire la procedura esatta da utilizzare, al fine di riutilizzare i componenti che sono o già esistenti o sono stati appena introdotti.

Questo permette una possibilità di manutenzione del sistema fastidiosa e un miglioramento sostanziale delle possibilità di utilizzo dei componenti.

Test di disciplina

Gli scopi del test di disciplina sono:

• Controllare l’interazione tra gli oggetti
• Controllare la corretta integrazione di tutti i componenti del software
• Controllare che tutti i requisiti siano stati eseguiti correttamente
• Identificare e assicurarsi che i difetti vengano affrontati prima dell’implementazione del software
• Assicurarsi che tutti i difetti vengano rivisti e chiusi

Conclusione

Nel caso in cui ci siano difetti nel progetto, la loro correzione può richiedere costi inutili dovuti al fatto che i difetti non vengono portati alla luce in tempo utile.

Se il progetto, invece, viene testato nella sua interezza, questo sarebbe vantaggioso in quanto i difetti che potrebbero insinuarsi nei progetti possono essere identificati e accertati al più presto.

Questo, a sua volta, avrà una massiccia riduzione dei costi legati alla correzione dei difetti.