Ciclo di vita del SW e diagrammi UML

Ciclo di vita del SW e diagrammi UML

By Emanuela Giaconi

Ciclo di vita del SW

• fasi attraversate da un progetto software durante la sua evoluzione

• dall’idea iniziale alla manutenzione

• il risultato finale è il prodotto software stesso,

• documentazione ad esso associata.

Ciclo di vita del SW

Ciclo di vita del SW

​Collegarsi a www.menti.com e rispondere alla seguente domanda:​

Quali sono le fasi di vita di un prodotto SW?

Ciclo di vita del SW

Fasi

• ​Studio di fattibilità

• Raccolta dei requisiti

• Analisi

• Progettazione

• Implementazione

• Test

• Installazione in produzione

• Manutenzione (ordinaria ed evolutiva)

Ciclo di vita del SW

Open Ended

Che cos'è lo studio di fattibilità e a cosa serve?

Studio di fattibilità

• ​Con lo studio di fattibilità viene effettuata una valutazione preliminare di costi e benefici

• Opzioni alternative già esistenti

• Analisi risorse umane e finanziarie​

• Questa fase generalmente si conclude con la presentazione di una offerta al cliente (preventivo o documento di fattibilità

Ciclo di vita del SW

Open Ended

Cosa deve fare la fase di analisi? Qual è il suo output?

Raccolta dei requisiti e analisi

• Nella successiva fase, quella di specifica dei requisiti, possiamo riconoscere le seguenti attività:

  • analisi del problema

  • definizione delle funzionalità, dell’operatività, dei vincoli interni ed esterni alla azienda, delle prestazioni e di ogni caratteristica richiesta al sistema per soddisfare la necessità del cliente

Ciclo di vita del SW

Raccolta dei requisiti e analisi

• redazione di un documento di Specifica dei Requisiti Software (SRS – Software Require-ment Specification) 

• convalida delle specifiche: prima di procedere alla realizzazione il SRS viene analizzato e rivisto con il committente per validare ogni singola specifica individuata.

• La specifica dei requisiti risponde alla domanda

“che cosa deve fare il sistema?” ​

Ciclo di vita del SW

Open Ended

Esempio: quali potrebbero essere i requisiti per la realizzazione di un sistema per la gestione di una biblioteca comunale?

Requisiti

Raccolta dei requisiti

• La raccolta dei requisiti stabilisce le funzionalità del sistema senza interessarsi di “come” queste funzioni verranno realizzate

• L’insieme delle attività che si ”occupano” di requisiti prende anche il nome di ingegneria dei requisiti (requirements engineering).

• Requisito: Ogni informazione (ottenuta in qualche modo) circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare.​

Raccolta dei requisiti

• La definizione dei requisiti rappresenta l’analisi completa dei bisogni dell’utente e del dominio del problema allo scopo di definire quello che il sistema deve fare.

• La raccolta dei requisiti è spesso considerata l’attività più difficile, perché richiede la collaborazione tra più gruppi di partecipanti con differenti background​

Stakeholder

• Le diverse persone coinvolte in tale processo sono chiamate gli stakeholder.

• Sono da considerarsi stakeholder tutte le persone in qualche modo interessate alla messa in opera del sistema, a ogni livello della organizzazione

“Gli stakeholder– o portatori di interesse – sono tutte quelle persone o gruppi che influenzano e/o sono influenzati dalle attività di un’organizzazione, dai suoi prodotti o servizi e dai relativi risultati di performance.” 

                                                     (Edward Freeman  , 1984)​

Stakeholder

• Inoltre sia le funzioni svolte che i fabbisogni individuali sono diversi a ogni livello della azienda e spesso gli stakeholder effettuano richieste diverse che possono anche sfociare in requisiti in conflitto tra loro.

• Ogni stakeholder può fornire una descrizione astratta e imprecisa del sistema che l’analista deve essere in grado di elaborare per ottenere una descrizione dettagliata e matematica dello stesso.​

Analisi

• La fase di analisi dei requisiti è particolarmente delicata e l’introduzione di errori in questa fase può portare anche al fallimento dell’intero progetto:

•  in ogni caso questi errori sono difficili da individuare e spesso vengono scoperti “troppo tardi”, nelle ultime fasi del processo di sviluppo del software, quando l’intervento per risolverli risulta essere molto oneroso.​

Open Ended

Elenca i requisiti che ritieni necessari per la definizione di un sistema di e-commerce

Analisi

Analisi - Rischi

• I principali rischi sono quelli di “dimenticare” o ignorare una funzionalità, di implementare in modo errato o incompleto una richiesta, di realizzare interfacce utenti poco intuitive e difficili da usare.

• Un suggerimento per identificare i requisiti rilevanti in un processo di progettazione di sistemi informatici viene dato dalla normativa ISO 13407, anche conosciuta come human-centered design process (UCD).​

Open Ended

Identifica quali possono essere i rischi e i problemi che possono insorgere nella fase di analisi

Analisi - ISO 13407

Analisi

• ​analisi può essere svolta in toto all’inizio oppure iterativamente durante il processo.

• A seconda del modello di sviluppo che viene adottato, l’analisi può essere ripetuta o meno durante il ciclo di vita del software. ​

Open Ended

Quali tipi di requisiti devono essere analizzati?

Requisiti

I requisiti software possono essere classificati

• a livello di dettaglio: 

  • requisiti utente(user requirements)

  • requisiti di sistema(system requirements)

Ciclo di vita del SW

Requisiti

I requisiti software possono essere classificati

• per tipo di requisito che rappresentano:

  • requisiti funzionali

  • requisiti non funzionali

  • requisiti di dominio

Ciclo di vita del SW

Requisiti utente e di sistema

• i requisiti utente sono quelli che “osserva il cliente”, cioè le esigenze sentite dall’utente finale e descritte con il linguaggio del cliente: chiamati requisiti aperti

• i requisiti di sistema sono quelli imposti da vincoli esistenti, come per esempio l’utilizzo di apparecchiature esistenti all’interno della azienda o di interfacciamento con sistemi aziendali già in funzione o anche di natura fiscale e/o legislativa (rispetto della normativa sulla sicurezza e sulla privacy, contabilità e bilancio secondo la normativa CEE ecc.) : chiamati requisiti chiusi

Ciclo di vita del SW

Requisiti utente e di sistema

Ciclo di vita del SW

Requisiti funzionali

• I requisiti funzionali (Functional Requirement) descrivono le funzionalità che il sistema deve avere e tutti i servizi che dovrà offrire agli utenti.

• I requisiti funzionali devono essere:

  • completi: devono indicare tutti i servizi richiesti dagli utenti;

  • coerenti: i requisiti non devono avere definizioni contraddittorie.

Ciclo di vita del SW

Requisiti non funzionali

• I requisiti non funzionali (Non-Functional Requirement) sono quelli imposti dalle modalità operative, dal ciclo di vita del prodotto”, nel caso di un sistema di produzione, oppure dalla “catena del freddo” nel caso di un prodotto alimentare surgelato, o dalle precedenze nel triage in un pronto soccorso ecc., o del rispetto della normativa vigente

• di prodotto

• organizzativi

• esterni​

Requisiti di dominio

• I requisiti di dominio dipendenti dal dominio in cui il sistema deve operare come la riservatezza nel caso di dati sensibili, le leggi della fisica e/o tecnologia nel caso di impianti industriali, la sicurezza sul lavoro, ...

• Esempio tipico: login e password per accedere ad un'area protetta​

Raccolta dei requisiti e analisi

Raccolta dei requisiti. Requisiti

Diverse tecniche:

• Interviste

• Osservazioni sul campo

• Gruppi di Lavoro, ecc.

​

Ciclo di vita del SW

I requisiti: l’anello debole dello sviluppo SW

lUn celebre studio effettuato dallo Standish Group su un campione di 8000 progetti riporta risultati sconfortanti:

l16% di successi, 53% di fallimenti parziali

Ciclo di vita del SW

I requisiti: l’anello debole dello sviluppo SW

La maggior parte delle volte il fallimento del sistema viene “scoperto” in ritardo

Le principali cause che determinano del ritardo  sono:

• insufficiente azione di interazione e discussione tra gli attori coinvolti;

• insufficiente individuazione dei conflitti tra requisiti, sempre presenti in ogni progetto;

• mancato coinvolgimento degli utenti nella verifica dei requisiti individuati dagli analisti;

• mancato coinvolgimento degli utenti nell’esprimere feedback sulle ipotesi prospettate dai progettisti;

Ciclo di vita del SW

I requisiti: l’anello debole dello sviluppo SW

• insufficiente controllo sull’evoluzione dei requisiti durante l’intero ciclo di vita del sistema;

• rinvio della presa in carico del nuovo requisito sopraggiunto in corso d’opera a una release successiva;

• mancato accordo sui contenuti e/o i costi e/o i tempi durante la rinegoziazione per l’aggiunta di un requisito sopraggiunto in corso d’opera.

Ciclo di vita del SW

I requisiti: l’anello debole dello sviluppo SW

Ciclo di vita del SW

Verifica e validazione dei requisiti

Ciclo di vita del SW

​La validazione dei requisiti deve essere fatta durante tutto il ciclo di sviluppo ed esige di controllare:

• correttezza: una specifica è corretta se rappresenta perfettamente il sistema che il cliente richiede;

• completezza: una specifica è completa quando contempla tutti i possibili scenari possibili per il sistema;

• coerenza: i requisiti non si devono contraddire tra di loro;

• chiarezza: la descrizione di una specifica non deve dare adito a possibili interpretazioni diverse;

Verifica e validazione dei requisiti

Ciclo di vita del SW

• ​realismo: la richiesta deve essere “fisicamente” realizzabile e implementabile nonostante tutti i vincoli;

• verificabilità: quando il sistema è stato costruito deve essere possibile eseguire tutti i test per certificare che il sistema soddisfi i requisiti;

• tracciabilità: tutte le funzioni del sistema devono essere individuabili e messe in relazione con un requisito funzionale: questa operazione è molto importante per lo sviluppo di test e per valutare i cambiamenti.

Verifica e validazione dei requisiti

Ciclo di vita del SW

• I requisiti non funzionali (legati alle modalità operative), invece, spesso indicati in modo generico dall’utente, possono risultare non quantificabili e difficili da verificare

• a differenza dei precedenti, per i quali è possibile dire in “modo binario” se sono rispettati o meno, per questi generalmente è possibile dare un valore quantitativo del grado di soddisfacimento del requisito.

Verifica e validazione dei requisiti

Ciclo di vita del SW

Open Ended

Individua le attività di progettazione? qual è l'output di questa fase?

Progettazione

• Individuare la soluzione implementativa migliore rispetto agli obiettivi funzionali, a quelli non funzionali ed ai vincoli. ​

• definizione dell’architettura del sistema, organizzazione strutturale del sistema con componenti software, l’interfaccia dei componenti e le relazioni tra di essi. ​

Output

• istruzioni operative per la realizzazione del progetto (dettagli implementativi).

• documenti opportunamente strutturati.

Ciclo di vita del SW

Progettazione

• rappresentazione astratta e indipendente dalla tecnologia.

• implementazione non ambigua

• diagramma di flusso o UML activity diagram.

Entrambi gli strumenti servono a realizzare la scomposizione delle attività da compiere in elementi sempre più piccoli che possano essere facilmente implementati con opportuni insiemi di istruzioni del linguaggio di programmazione scelto.

Ciclo di vita del SW

Open Ended

In cosa consiste la fase di implementazione?

Implementazione

• tempi stretti: Integrated Development Environment (IDE)

• IDE: editor di codice sorgente, compilatore e/o un interprete, tool di building automatico, e debugger

• sistemi di controllo di versione (SVN o GitHub, ad esempio)

• sistemi di gestione delle dipendenze da librerie esterne (Maven, ad esempio)

• tool per semplificare la costruzione di una GUI

• navigatore di classi, analizzatore di oggetti e un diagramma della gerarchia delle classi

Ciclo di vita del SW

Implementazione

• IDE multi-linguaggio, come Eclipse, NetBeans e Visual Studio

• metodologie di programmazione più moderne tendono a fare diventare la fase di scrittura del codice quella principale in tutto il progetto informatico

• primo debugging: ossia la rimozione degli errori di sintassi e degli errori più evidenti, come la mancata inizializzazione di variabili, che possono compromettere la compilazione o il funzionamento del programma

• live debug: Tendono ad evidenziare in tempo reale, oltre al codice che inevitabilmente porterà ad errori di compilazione, anche frammenti di codice inutili, blocchi ripetuti, inizializzazioni di variabili non necessarie, ecc.

Ciclo di vita del SW

Open Ended

Identifica la fase successiva alla fase di implementazione e descrivi i contenuti che dovrebbe avere a tuo parere

Test

• verifica funzionamento conforme alle specifiche della fase di analisi.

• errori logici e concettuali,

• verifica del comportamento effettivo del programma rispetto a quello previsto

• suite di test eseguite automaticamente durante la build ed il packaging del progetto, allo scopo di ridurre il più possibile il rischio di regressione.

Ciclo di vita del SW

Open Ended

In cosa consiste secondo te la fase di avvio e passaggio in produzione?

Avvio e passaggio in produzione

• Dopo il test, raggiunto un livello sufficiente di qualità, il programma può entrare in produzione.

• B2C: rilascio sul mercato, fisico (negozio), virtuale (ecommerce, download) o mobile (PlayStore, AppStore)

• B2B, applicazioni web (siti di e-commerce, portali, gaming-on-line, ecc): installazione ed il collaudo presso la sede del cliente che li ha richiesti.

Ciclo di vita del SW

Open Ended

Quale dovrebbe essere secondo te lo scopo della fase di manutenzione?

Manutenzione

• Manutenzione ordinaria: interventi correttivi necessari per via di errori sfuggiti ai test o dovuti al funzionamento del programma in condizioni non previste durante la sua progettazione;

• Manutenzione evolutiva: interventi di variazione od arricchimento delle funzioni del programma per via di nuove necessità operative del programma stesso;

• esempio: aggiornamento continuo dei programmi gestionali per stare aggiornati rispetto alle normative fiscali.

Ciclo di vita del SW

Modelli

• Modello a cascata

• Modello a spirale

Ciclo di vita del SW

Modello a cascata

• modello di processo di sviluppo software con un flusso sequenziale lineare, suddiviso in fasi.

• una fase inizia dopo il completamento della fase precedente.

Ciclo di vita del SW

Modello a cascata

• ​il risultato di una fase diventa l'input per la fase successiva.

• una sola fase alla volta.

• non adatto per sviluppare progetti complessi.

• non adatto per un progetto con requisiti mutevoli.

Ciclo di vita del SW

Modello a spirale

• alternativa al modello a cascata

• obiettivo principale: analizzare il rischio

• Le fasi del modello a spirale includono pianificazione, analisi dei rischi, ingegneria e valutazione

Ciclo di vita del SW

Modello a spirale

• Il progetto software passa continuamente attraverso queste fasi in iterazioni chiamate spirali.

• Al termine di ogni fase viene prodotto un prototipo.

• l'output viene mostrato al cliente per ottenere un feedback.

Ciclo di vita del SW

Modello a spirale

• adatto a progetti grandi e complessi.

• analisi dei rischi continua.

• maggiore controllo verso tutte le fasi di sviluppo.

• analisi del rischio potrebbe richiedere dipendenti esperti e le spirali potrebbero richiedere molto tempo.

• non adatto per piccoli progetti.

Ciclo di vita del SW

UML

UML, Unified Modeling Language, è un linguaggio semiformale e grafico (basato su diagrammi) per:

• specificare

• visualizzare

• realizzare

• modificare

• documentare

gli artefatti di un sistema software: sorgenti, eseguibili, documentazione, file di configurazione, tabelle di database, benchmark, ...

Ciclo di vita del SW

UML

Linguaggio di modellazione per:

• capire e descrivere le caratteristiche di un nuovo sistema o di uno esistente.

• indipendente dall’ambito del progetto.

• indipendente dal processo di sviluppo.

• indipendente dal linguaggio di programmazione (progettato per essere abbinato alla maggior parte dei linguaggi object-oriented).

• fa parte di un metodo di sviluppo, non è esso stesso il metodo.

Ciclo di vita del SW

UML

• vero e proprio linguaggio, non una semplice notazione grafica

• insieme di elementi che hanno anche una rappresentazione grafica

• linguaggio semiformale perché descritto in linguaggio naturale e con l’uso di diagrammi, cercando di ridurre al minimo le ambiguità.

• ha regole sintattiche (come produrre modelli legali)

• regole semantiche (come produrre modelli con un significato).

Ciclo di vita del SW

Diagramma casi d'uso

Diagramma delle classi

Diagramma degli stati

descrive il comportamento di entità o di classi in termini di stato (macchina a stati).

Diagramma delle attività

descrive un processo attraverso dei grafi in cui i nodi rappresentano le attività e gli archi l'ordine con cui vengono eseguite.

Diagramma di sequenza

• descrive uno scenario: sequenza di azioni in cui tutte le scelte sono state già effettuate;

• in pratica nel diagramma non compaiono scelte, né flussi alternativi.

Deployment Diagram

• descrive un sistema in termini di risorse hardware, dette nodi, e di relazioni fra di esse

• distribuzione delle componenti software rispetto alle risorse hardware disponibili sul sistema