Appunti sui processi software

Definizione dei requisiti

· Progettazione e implementazione del prodotto seguendo

· i requisiti

Convalida del prodotto per verificare che rispetti i

· requisiti

Evoluzione in risposta a cambiamenti nei requisiti

·

Diversi modelli:

· A cascata-Waterfall:

· Le fasi del processo sono affontate

· sequenzialmente, la fase successiva non dovrebbe

partire prima che sia terminata la precedente

Fasi:

· Definizione dei requisiti

· Mediante incontri con utenti si stabiliscono

funzionalità del sistema, vincoli e obiettivi

Progettazione

· Identificazione delle astrazioni fondamentali

Definizione dell’architettura

Modellazione del sistema

Implementazione e test di unità

· Realizzazione del programma e verifica del

funzionamento delle sue parti

Integrazione e test di sistema

· Si uniscono le parti, un test finale determina

se i requisiti sono stati rispettati

Operatività e manutenzione

· Sistema installato e messo in opera

Vantaggi:

· Il risultato di ogni attività e documentato

· Processo simile a quello di altri ambiniti

· ingegneristici, utile in progetti ibridi

Svantaggi:

· Necessità di stabilire tutti i requisiti in

· anticipo

Nessun prodotto tanfibile fino alla ifne del

· progetto

Efficienza limitata dalla serializzazione della

· ttività

Difficolta nella reazione a cambiamenti nei

· requisiti o nella tecnologia

La rigida suddivisione può essere mitigata

· mediante:

Feedback tra fasi successive

· Ripetizione dell’intero processo

·

Sviluppo evolutivo

· Costruzione fin dall’inizio di verisoni parziali del

· sistema finale

Il giudizio degli utenti sulle versioni parziali aiuta a

· definire meglio i requisiti

Due approcci principali:

· Sviluppo esplorativo

· Lavoro a contatto con il cliente

· Si inizia con i requisiti più chiari

· Si integrano poi le nuove funzionalità

·

Prototipo usa e getta

· Prototipi vengono usati per capire i

· requisiti meno chiari e per

sperimentare approcci alla

progettazione

Esso richiede uno sforzo

· implementativo maggiore ma è più

concreto del precedente, di solito l’usa

e getta lo si usa nelle fasi iniziali del

progetto

Vantaggi:

· Soddisfazione immediata del cliente

· Requisiti raffinati mentre il cliente li

· comprende

Flessibilità nel rispondere ai cambiamenti

·

Svantaggi:

· Non si capisce a che punto si è del progetto

· perché il cliente può chiedere continue

modifiche

La documentazione può essere incompleta,

· infatti non tuttele versioni saranno

documentate nel dettaglio, di solito si

aggiorna la documentazione solo alla fine

una volta per tutte

Cambiamenti continui deteriorano la

· struttura del progetto

Specifiche incomplete fino alla fine, portano

· problemi di tipo contrattuale, negli altri casi

ad esempio diciamo che il progetto dura un

anno ed entro quell’anno deve essere

consegnato, in questo caos invece non

abbiamo un documento tecnico che dica

quanto tempo deve durare e il cliente può

continuare a chiedere modifiche, questo

metodo va quindi bene quando una azienda

sta lavorando sul proprio prodotto

Modello a spirale

· Essendo a spirale le 4fasi si ripetono finchè il

· cliente non è soddisfatto

Passando tra la fase 2 e la 3 produciamo un

· prototipo da mostrare al cliente e vedere se è

soddisfatto

Fasi:

· Determinazione degli obiettivi

· definizione degli obiettivi dell’iterazione

corrente, non degli obiettivi generali

Identificazione e risoluzione dei rischi

· sviluppo di un prototipo per analizzare i

rischi e ridurli

Sviluppo e verifica

· Pianificazione dell’iterazione successiva

· revisione del progetto e piani per l’iterazione

successiva

Lo spirale è verso l’esterno: da una descrizione

· sommaria dei requisiti a un sistema finale

completamente sviluppato

Concetto di rischio: qualcosa può andare male, ad

· esempio compilatori inaffidabili, hardware

inefficiente, aggiornamento software di supporto

Sviluppo incrementale

· Soluzione intermesia tra il modello a cascata e

· quello evoluzionistico

Lo sviluppo del sistema viene diviso in incrementi

· detti sprint, ogni spirnt completato viene chiuso e

consegnato al cliente

Ogni futuro sprint può essere ridefinito, glisprint

· chiusi sono ormai chiusi. Si parte con gli sprint più

importanti, gli sprint successivi sono di

funzionalità secondarie

Vantaggi:

· I clienti non devono aspettare il sistema

· completo

I primi incrementi fungono anche da

· prototipi per determiinare i requisiti

successivi

Le funzionalità più importanti vengono

· consegnate per prime e verranno verificate

più a lungo

Svantaggi:

· Difficoltà nell’individuare incrementi

· sufficiente piccoli, infatti gli sprint

dovrebbero essere abbastanza piccoli anche

perchè ogni volta viene consegnato

qualcosa di usabile, quindi devo trovare un

giusto compromesso per le funzionalità che

aggiungo in modo da consegnare qualcosa

di usabile ma in tempi ragionevoli

Alcune funzionalità di base sono comune a

· tutti gli incrementi ma verranno progettate

pensando solo al primo incremento

Esempio: Extreme programming

·

Processi pesanti e leggeri:

· In un processo pesante il lavoro è svolto

· lentamente e sistematicamente con l’obiettivo di

consegnare un prodotto completo che richieda

controlli e modifiche minimi. (Waterfall)

In un processo leggero la pianificazione è adattiva

· e si adottano pratiche che incoraggiano una

risposta rapida e flessibile ai cambiamenti

Prevede uno sviluppo continuo molto snello.

Di solito il software a cui andiamo a puntare è un

software in cui se anche c'è un bug non succede

nulla, abbiamo il problema di soddisfare le

aspettative del cliente ma non succede niente se

magari il software va giù per qualche motivo

Sviluppo Agile

· Per i processi leggeri le metodologie più famose

· vengono riassunte in questo sviluppo agile

si punta più ad avere versioni del software

· funzionanti già dal giorno 1 perchè vogliamo

rilasciarlo il prima possibile piuttosto che a

prodotti completi, testati e con documentazioni

esaustive, invece di pensare al contratto si pensa

alla collaborazione con il cliente e a interagire con

lui, si tenta di rispondere sempre al cambiamento

identificato.

La metodologia agile vuole rompere i vincoli

· contrattuali, non vuole quindi realizzare un

prodotto software guardando alla tempistica il

requisito che avevamo all'inizio e i costi, vuole

però guardare al fatto di avere un sofware perfetto

in tutto quello che deve fare, non interessa se la

documentazione non è pronta perchè tanto la si

può fare dopo e si punta a creare una sinergia con

il cliente piuttosto che a soddisfare i contratti,

questo funziona bene ad esempio in un'azienda di

servizi, se quindi devo vendere un servizio e non

un prodotto.

Esistono anche modelli ibridi che consentono di

· adattarsi alle caratteristiche del progetto e del team di

sviluppo

Riassunto quale scegliere:

· progetti di software critico, in cui la qualità è più

· importante di tempi e costi → modello a cascata

modificata (pesante)

grandi progetti aziendali che vengono usati per

· decenni → modello a spirale (leggero o pesante a

seconda della criticità)

progetti di dimensioni medio/piccole con necessità

· di contenere costi e tempi → extreme

programming (leggero)

Unified Process

· Esso è un esempio di modello ibrido

· Si adatta ad approcci evolutivi o incrementali

· Si adatta ad approcci leggeri o pesanti

· Si fanno molti test

· Profondamente basato su UML e su OOD, OOA

· Esso abbraccia il paradigma ad oggetti, per questo è il

· migliore che possa essere usato

Spesso adottato nella variante Rational Unified Process

· (RUP) che era la versione commerciale, ha la possibilità

di fare prospetti, gestire costi e rischi, il tutto

automatizzato da oftware professionali

RUP e UP sono comunque molto simili, RUP estende UP

Software development Process (SDP) o Software

· Engineer Process (SEP) definisce il chi, il quando, il cosa

e il come dello sviluppo software

Unified Software development Process (USDP) è il SEP

· ideato dagli autori di UMP, esso viene comunemente

chiamato UP (Unified Process)

In origine il progetto UML doveva fornire sia un

· linguaggio visuale sia un processo di ingegneria del

software; UP è la parte relativa al processo

UML è stato standardizzato dall’ OMG, UP no

· UP modella il cosa come attività e manufatti

· Attività: compiti che verranno eseguiti dagli

· individui o dai gruppi che partecipano al progetto

Manufatti sono materiale richiesto o prodotto dal

· progetto

UP ci permette ad esempio di documentare chi, nel

· progetto, si occupa di cosa scandendo bene i tempi di

scadenza

UP è un processo generico di sviluppo del software e

· deve essere istanziato per ciascuna organizzazione e

anche per ciascun progetto specifico

Anche se RUP è più completo di UP, bisogna comunque

istanziarlo

Il processo di istanziazione consiste nella definizione e

integrazione di:

Standard per il gruppo di lavoro

· Modelli di documento standard

· Strumenti, quali compilatori, gestori della

· configurazione, etc.

Archiviazione, per quanto riguarda la gestione dei

· difetti, la gestione del progetto, etc.

Modifiche del ciclo di vita, per esempio strumenti

· più sofisticati per il

controllo del livello di qualità per sistemi “safety-

· critical”

UP è basato su 3 assiomi fondamentali:

· È pilotato dai casi d’uso e dai fattori di rischio

· E&rsquo