Lo sviluppo del software: usi e clausole commentate Aspetti Tecnici. Prof. Franco Sirovich Dipartimento di Informatica Università di Torino

Transcript

1 Lo sviluppo del software: usi e clausole commentate Aspetti Tecnici Prof. Franco Sirovich Dipartimento di Informatica Università di Torino

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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