Sartomiki.net

Ciclo di vita
Per lo sviluppo di un software è possibile definire il ciclo di vita, come un insieme di fasi. Ogni fase prende come input gli output della fase precedente e produce un output, mediante lo svolgimento di alcune attività:
-definizione dei requisiti
-progetto architetturale, che consiste nel dividere il problema in blocchi.
-implementazione di ogni blocco:
--progetto di dettaglio.
--sviluppo.
--testing.
-trasferimento al committente:
--test di accettazione.
--utilizzo (messa in funzione).
-operation:
--manutenzione.
--evoluzione.
Il modello a cascata prevede che le fasi vengano eseguite in modo sequenziale. Il risultato di ogni fase è un insieme di documenti. Il principale inconveniente di questo modello è la durata, in più è difficile definire i requisiti nella fase iniziale.
Il modello incrementale è simile al modello a cascata ma prevede che nel momento in cui si stanno ancora implementando le specifiche, si renda disponibile una versione parzialmente funzionante. In questo modo è possibile continuare a implementare nuove funzioni, anche mentre una prima versione è già stata rilasciata. Con questo metodo i costi aumentano. Ogni ciclo da origine ad un prototipo di passaggio.
Il modello a ciclo evolutivo prevede che vengano sviluppati due modelli a cascata, che portano a versioni differenti. Ogni ciclo da origine ad un prototipo evolutivo.
Il modello unificato è un metodo più sottile in cui non c'è un ordine sequenziale delle fasi, in quanto la definizione dei requisiti può riferirsi anche a dettagli di implementazione, oppure la fase di test avviene in ogni fase o la fase di realizzazione di prototipi si può riferire anche a piccole parti del progetto. Il modello unificato da origine a un processo (modo ordinato di ottenere un determinato scopo).

Attività di supporto
Oltre alle attività elencate nel paragrafo precedente sono necessarie alcune attività di supporto:
-verifica del prodotto ha lo scopo di assicurare che si stia realizzando un prodotto in maniera corretta (review, ispezione, testing, …).
-validazione ha lo scopo di assicurare che il prodotto rispetti le specifiche.
-controllo della qualità ha lo scopo di verificare se un prodotto rispetta alcuni standard di qualità.
-configurazione mgt ha lo scopo di definire, di controllare e modificare gli elementi del sistema di gestione.
-organizzazione del progetto ha lo scopo di pianificare, monitorare, controllare, organizzare il personale.

Definizione dei requisiti
Un requisito software utente è una capacità richiesta dall'utente per risolvere un problema o per raggiungere un obiettivo. L'utente è il fruitore del servizio.
Il requisito di sistema, più in generale, è una capacità software per soddisfare una richiesta, uno standard.
L'ingegneria dei requisiti ricava i requisiti per organizzarli e documentarli. L'analisi dei requisiti si svolge in tre passi:
-ricavare i requisiti.
-analizzare i requisiti (chiari, non ambigui, non contradditori).
-tradurre i requisiti in un linguaggio formale.
I requisiti si possono dividere in:
-funzionali hanno a che fare con ciò che il sistema deve fare. Input -> trasformazione -> output, così come li vede l'utente.
-non funzionali:
--usabilità.
--performance (tempi di risposta e quantità di risorse).
--interoperabilità.
--portabilità.
--aderenza agli standard.
--mantenibilità, facilità di apportare modifiche.
--sicurezza.
I requisiti devono essere non ambigui, consistenti, completi, tracciabili e verificabili (fattori di qualità).
Per definire i requisiti esistono diversi standard. Ad esempio IEEE STD-830 è un documento diviso in capitoli.
Un approccio più recente è quello dei casi d'uso, utilizzato ad esempio da UML.