Lo sviluppo del software: usi e clausole commentate

Lo sviluppo del software:
usi e clausole commentate
Aspetti Tecnici
Prof. Franco Sirovich
Dipartimento di Informatica
Università di Torino
Ipotesi di Fondo
• Software sviluppato “su misura”
• Non “prêt à porter”
• Anche quando il fornitore parte da una base di
semilavorati o da software simile che ha in casa
• Quanto su misura? Specificare nel contratto
• Quando il contratto è scritto bene non si “litiga”!
• Quali specifiche? Quanto specificato?
2
Livelli di Specifica
• Requisiti di utente
– Quali sono le necessità del committente
• Specifiche funzionali
– Come si comporterà il software da realizzare
• Specifiche tecniche
– Scenario di uso, software di ambiente, requisiti
prestazionali
• … essere il più possibile precisi! Usare
linguaggi formali o semiformali
3
Studio di fattibilità
• Tra il dire e il fare ci passa un mare!
• I requisiti sono vaghi e incerti
• Possono essere soddisfatti con funzionalità molto
diverse -> costi e tempi diversi
• Sviluppare i requisiti di utente, le specifiche
funzionali e quelle tecniche richiede abilità, tempo e
denaro -> Studio di Fattibilità
• Se non si può fare uno studio di fattibilità con
contratto separato, strutturare il contratto come
costituito da “due parti”
4
Progettazione
• Sviluppare il documento Requisiti di Utente
• Attività delicata e che richiede
– Collaborazione da parte del committente
– Abilità da parte del fornitore e del committente
– Tempo di tutti e due!
• Dovrebbe essere compreso e accettato dalle
due parti
• Dopo di che si può passare a …
5
Progettazione (2)
• Sviluppare le Specifiche Funzionali e le Specifiche
Tecniche
– Soddisfano le esigenze del committente in un particolare
modo
– Determinano il modo in cui si comporterà il software
prodotto
– Determinano tempi e costi per il fornitore
– Devono essere comprese da committente e fornitore
– Devono essere accettate dal committente e fornitore
• Sviluppare piano dei test di accettazione/collaudo
6
Progettazione (3)
• Sviluppare piano dei test di accettazione/collaudo
–
–
–
–
Modalità di test
Casi di Test
Sequenze di singoli test
Risultati attesi
• Deve essere conforme alle specifiche funzionali!
• C’è un problema di “correttezza” dei casi di test!
• Un piano dei test accettato ha valore prevalente rispetto alle
specifiche funzionali: è una affermazione sulla correttezza del
software: un comportamento atteso
• Prevedere uso di strumenti per automatizzare almeno in parte i
test
7
Realizzazione
•
•
•
•
•
Sviluppare il software
Eseguire i test di progetto
Consegnare ed eseguire i test di collaudo
La fase di accettazione è quella più critica
Si comincia bene se si sviluppano assieme i
test di collaudo
• Ricicli (e penali) a causa di fallimenti del
collaudo
8
Tutto in un solo contratto?
• In genere si fa così
• Documento dei Requisiti, realizzato in
collaborazione
– Obiettivi
– Prestazioni attese
– Software di ambiente
– Ambiente informatico complessivo
– Scadenze temporali
9
Piano di Lavoro
•
•
•
•
•
•
Prodotto dal fornitore; contiene:
Tempi e costi
Specifiche funzionali e tecniche
Procedura di accettazione
Risorse messe a disposizione dal fornitore
A questo punto si dovrebbe definire
l’ammontare del contratto
• È un punto di “recessione”
10
Sono note le “specifiche”?
• Se sono note e condivise (o si deve fare come se)
allora non si hanno due fasi
• Il Piano di Lavoro dovrebbe essere contenuto già nel
contratto che si stipula
• Difficilmente la Procedura di Accettazione può essere
espressa (anche per sommi capi) nel contratto
• La Procedura di Accettazione è forse l’elemento
chiave che determina i rapporti (buoni o cattivi) fra
committente e fornitore
11
Consegna
• La consegna, e configurazione, del software
presso il fornitore è inclusa nel contratto solo
nella misura in cui è necessaria per la
procedura di accettazione
• È conveniente, per i buoni rapporti fra le parte,
che sia effettuata dal fornitore, con la
collaborazione e la supervisione del
committente
• … e quindi sia così pattuito!
12
Versioni intermedie
• Spesso richieste dal committente per avere
visibilità dell’avanzamento
• Consegnare e collaudare costa: occorre che il
committente riconosca questo costo
• Consegnare e non collaudare non serve a
nulla! O meglio, solo ad aumentare i costi …
13
Garanzia
• Risolvere i difetti che si riscontrano dopo
l’accettazione
• Cosa è un difetto? Importanza delle specifiche
funzionali! E del manuale di uso!
• Verificare il difetto, riprodurlo, …
• Produrre una patch
• Verificare l’assenza di regressioni: Test di
accettazione!
• La manutenzione del software dopo la garanzia è tutta
un’altra storia!
14