Progetto software 2008/2009. Docente Marianna Nicolosi Asmundo

Transcript

1 Progetto software 2008/2009 Docente Marianna Nicolosi Asmundo

2 Obiettivi del corso Coinvolgervi nello sviluppo di un progetto software in cui mettere a frutto le conoscenze che avete acquisito durante i corsi già frequentati (programmazione, algoritmi, ingegneria del software, database ecc ) applicare un processo per la gestione e lo sviluppo del progetto analogo a quelli usati nel mondo reale

3 Come? Lavorerete in team di 4/6 persone un leader uno o più analisti due o più programmatori Sarete voi a scegliere il ruolo più adatto alle vostre capacità e alla vostra indole. Mi comunicherete la formazione del vostro gruppo ed eventuali modifiche.

4 I Leader Problem solving: determinare i fattori tecnici e organizzativi più importanti strutturare sistematicamente una soluzione motivare gli sviluppatori Identità manageriale: assumersi la responsabilità del progetto coordinazione del resto del team Incentivazione: ricompensare lo spirito di iniziativa saper rischiare Influenza e spirito di gruppo: Mantenere il controllo nelle situazioni critiche relazionarsi bene coi colleghi

5 Il team Staff tecnico auto-organizzato Parola d ordine: cooperazione Se vuoi migliorare in modo incrementale, sii competitivo; se vuoi migliorare in modo esponenziale sii cooperativo. Autore ignoto

6 Criteri di valutazione Qualità del progetto sviluppato Coesione del gruppo Non sono previsti progetti individuali

7 Modalità di esame L esame consiste in sviluppo e consegna del progetto Esame orale Il vostro lavoro verrà monitorato per fasi Una volta consegnato, l intero progetto verrà valutato in maniera complessiva. Ogni membro del team riceverà il medesimo voto a meno che l intera squadra non decida di consegnare anche i diari individuali. Durante l esame orale verrà verificata la competenza di ciascun membro del team rispetto all intero progetto e rispetto al ruolo specifico ricoperto. Verrà anche valutata la conoscenza degli argomenti trattati durante il corso.

8 Contenuti del corso Fasi di sviluppo di un progetto Pianificazione Qualità Analisi del dominio e dei requisiti Progettazione Implementazione Collaudo

9 Cos è un progetto? Un progetto è un impresa temporanea effettuata da persone vincolata da risorse limitate pianificata, eseguita e controllata intrapresa per creare un prodotto o servizio unico Dimensioni di un progetto: Coinvolge una persona sola o molte migliaia Richiede meno di 100 più di 10 milioni di ore per essere completato

10 Esempi Lo sviluppo di un nuovo prodotto o servizio La progettazione di un nuovo veicolo di trasporto

11 Temporaneo & Unico Temporaneo: Ogni progetto ha un inizio e una fine ben precisa (obiettivo raggiunto o irraggiungibile) non significa che dura poco infatti molti progetti durano diversi anni Unico: Ogni progetto riguarda qualcosa che non è mai stata fatta prima ed è pertanto unica un progetto differisce da un altro per il tipo di oggetto sviluppato, per gli strumenti usati, per le persone coinvolte o soltanto per le date

12 Progetti software Il lavoro di ingegnerizzazione del software viene normalmente organizzato in progetti Sistema software di piccole dimensioni: team di sviluppo unico con tre/quattro sviluppatori Sistema software di dimensioni grandi: il lavoro viene suddiviso in molti progetti piccoli Tipi principali di progetto: Modifica di software esistente Sviluppo di un sistema da zero Sistema nuovo costruito con componenti già esistenti

13 Progetti software Sviluppo di: Un compilatore, un editor, un sistema operativo Un applicativo web L implementazione di un algoritmo di ordinamento Un dimostratore automatico

14 Progetti software/ingegneria software In generale non possiamo produrre software nella maniera più immediata 1. I progetti sono in genere di dimensioni consistenti 2. Possono richiedere l applicazione di più strumenti (linguaggi di programmazione, algoritmi) 3. Possono coinvolgere più persone (sviluppatori, committenti e utenti) Ognuno di questi punti basta a giustificare l utilizzo di un processo per lo sviluppo del software

15 Sviluppo del software Avviene tramite comunicazione: Poiché il software, come ogni capitale, incorpora della conoscenza e poiché la conoscenza è inizialmente in larga misura dispersa, tacita, latente e incompleta, lo sviluppo del software è un processo di apprendimento sociale. Questo processo è un dialogo in cui la conoscenza viene raccolta e incorporata nel software. Il processo crea interazione fra gli utenti e i progettisti, fra gli utenti e gli strumenti in evoluzione e fra i progettisti e gli strumenti in evoluzione (la tecnologia). Si tratta di un processo iterativo in cui lo strumento evolutivo stesso fungerà da mezzo di comunicazione e in cui ogni nuova fase del dialogo trae conoscenze sempre più utili dalle persone interessate. H. Baetjer

16 Processo di sviluppo del software? Quando si realizza un prodotto o un sistema è importante svolgere un percorso che aiuti ad ottenere risultati di alta qualità nel tempo prefissato

17 Processo di sviluppo software Chi Gli ingegneri del software adattano il processo alle loro esigenze e poi lo seguono I committenti giocano un ruolo importante nel processo di definizione, costruzione e collaudo Importanza del processo di sviluppo del software Introduce stabilità, controllo e organizzazione Quale processo di sviluppo seguire Il processo che si adotta dipende dal software che si sta realizzando

18 Processo di sviluppo software Cosa si produce I programmi, i documenti e i dati sviluppati come conseguenza delle attività di ingegneria del software definite dal processo Verifica di correttezza del procedimento Qualità, ottimizzazione dei tempi e utilizzabilità a lungo termine del prodotto che si sta realizzando sono i migliori indicatori dell efficacia del processo utilizzato

19 Quindi Un processo di sviluppo software è una struttura di riferimento entro cui si svolgono le attività necessarie alla realizzazione di software di alta qualità

20 Struttura di un processo Attività strutturali Con diverse azioni ed insiemi di attività Attività ombrello applicabili all intero processo di sviluppo

21 Attività strutturali Comunicazioni Pianificazione Modellazione Costruzione Dispiegamento

22 Esempio 1 L attività di modellazione è costituita da due azioni di ingegneria del software: l analisi e il progetto Ciascuna viene rappresentata da un insieme di attività che meglio considera le esigenze del progetto e le caratteristiche del team

23 Esempio 2 Raccolta dei requisiti Progetto di dimensioni limitate 1. Creare elenco figure coinvolte nel progetto 2. Invitarli a una riunione informale 3. Domandare i requisiti e realizzare un elenco finale 4. Stabilire le priorità dei requisiti 5. Prendere nota delle aree in cui esistono incertezze Progetto più esteso 1. Creare elenco figure coinvolte nel progetto 2. Consultare separatamente 3. Costruire elenco preliminare funzioni 4. Programmare riunioni 5. Condurre le riunioni 6. Produrre nelle riunioni una serie di scenari informali 7. Raffinare questi scenari 8. Costruire nuovo elenco dei requisiti delle figure coinvolte 9. Stabilire le priorità dei requisiti 10. Definire i requisiti 11. Prendere nota dei vincoli 12. Discutere i metodi di convalida

24 Attività ombrello Controllo del progetto e sviluppo del software Gestione dei rischi Valutazione della qualità del software Revisioni tecnico formali Misura Gestione del riutilizzo

25 Modelli prescrittivi Definiscono un insieme distinto di attività, azioni, compiti, risultati e prodotti che sono necessari per ingegnerizzare un software di alta qualità. Ogni modello di processo prescrittivo definisce anche un flusso di lavoro, ovvero il modo in cui gli elementi del processo vengono correlati fra loro. Prescrittivo non vuol dire statico : i modelli prescrittivi devono essere adattati alle persone, ai problemi e al progetto.

26 Il modello a cascata 1 Detto anche ciclo di vita classico o modello sequenziale lineare, suggerisce un approccio sistematico sequenziale allo sviluppo del software USO: Quando i requisiti di un problema sono abbastanza noti Il lavoro procede dalla comunicazione al dispiegamento in modo lineare ESEMPI: adattamenti o estensioni bene definite di un sistema esistente

27 Il modello a cascata 2 Communicat ion project init iat ion requirement gat hering Planning estimating scheduling tracking Mode ling analysis design Const ruct ion code t est Deployment delivery support f eedback

28 Il modello a cascata 3 Svantaggi: 1. Il progetto reale si conforma raramente allo schema sequenziale del modello (ogni modifica può essere problematica) 2. Difficilmente il cliente è in grado di enunciare esplicitamente tutti i requisiti (il modello a cascata lo esige) 3. Solo verso la fine del processo il cliente sarà in grado di vedere una versione funzionante dei programmi

29 Modelli a processo incrementale Requisiti iniziali chiari ma progetto molto ampio L utente desidera subito un insieme limitato di funzionalità da raffinare in seguito In questi casi viene scelto un modello di processo progettato per produrre il software ad incrementi

30 Il modello incrementale 1 increment # n C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k increment # 2 deliv ery of nt h increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g increment # 1 analy s i s des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k deliv ery of 2nd increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g anal y s is des i gn C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k deliv ery of 1st increment project calendar t ime

31 Il modello incrementale 2 Esempio: programma di elaborazione testi Stadio 1: funzioni base relative alla gestione dei file, al trattamento del testo e alla produzione di documenti Stadio 2: funzioni più raffinate di trattamento del testo e di produzione dei documenti Stadio 3: controlli ortografici e grammaticali Stadio 4: funzioni avanzate di impaginazione

32 Il modello incrementale 3 Utile quando la disponibilità di personale è insufficiente a garantire l implementazione completa nei termini di tempo stabiliti La realizzazione dei primi stadi può essere affidata ad un piccolo team Se il primo incremento ha successo si può accrescere il team La sequenza di stadi può essere pianificata in modo da evitare rischi di natura tecnica