La portata del software

Transcript

1 La portata del software Portata Contesto. In che modo il software in costruzione si inserirà nel sistema, prodotto o contesto aziendale esistente e quali vincoli impone il contesto? Obiettivi relativi ai dati. Quali dati visibili dall utente deve produrre il software? Quali dati formano il suo input? Funzionalità e prestazioni. Quali funzioni svolge il software per trasformare i dati in input in quelli in output? Si devono considerare aspetti specifici legati alle prestazioni? La portata del progetto software deve essere non ambigua e comprensibile ai livelli gestionale e tecnico.

2 Scomposizione del problema Detto a volte partizionamento o elaborazione del problema Una volta che la portata è stata definita la scomposizione si applica in due aree principali: la funzionalità che si deve offrire La procedura attraverso la quale offrirla La decomposizione continua finché tutte le funzioni e procedure sono state definite

3 Il processo Una volta che uno schema di processo è stato stabilito Si considerino le caratteristiche del progetto Si definisca un insieme di compiti per ogni attività di ingegneria del software Insieme dei compiti = Compiti di ingegneria del software Prodotti Punti di garanzia di qualità Milestone

4 Il Problema e il Processo

5 Il progetto Un progetto è a rischio quando Gli sviluppatori non comprendono le esigenze dei clienti. La portata del prodotto è poco definita (o male). Le modifiche vengono gestite in modo non appropriato. Cambia la tecnologia scelta. Le operazioni devono essere modificate (o sono state definite male). Le date di scadenza sono non realistiche. Gli utenti sono ostili. Perdita delle risorse finanziarie (sponsor). Il team di progetto non contiene persone con le conoscenze appropriate. Manager (e tecnici) non mettono a frutto le lezioni apprese.

6 Approccio di buon senso Partire con il piede giusto. Ciò si ottiene innanzitutto lavorando duramente per comprendere il problema che deve essere risolto e poi definendo gli obiettivi e le attese realistiche per tutti coloro che saranno interessati al progetto Mantenere alta l attenzione. Il manager del progetto deve fornire incentivi per ridurre assolutamente al minimo il ricambio del personale; il team deve concentrarsi sulla qualità in ogni operazione svolta, il management deve fare il possibile per rispondere alle esigenze del team. Tenere traccia dei progressi. Per un progetto software, i progressi devono essere controllati a mano a mano che viene creato il prodotto (per esempio le specifiche, il sorgente, il collaudo) e approvati (usando le revisioni tecnico formali) come parte dell attività di verifica della qualità. Prendere decisioni intelligenti. In pratica le decisioni del project manager e del team di sviluppo devono preferire la semplicità. Condurre un analisi post-mortem. Stabilire un meccanismo generale per trarre lezioni da ogni progetto.

7 W5H2 Why is the system being developed? What will be done? When will it be accomplished? Who is responsible? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehm

8 Pratiche critiche Gestione formale dei rischi Stima empirica dei costi e dei tempi Verifica dell earned value Verifica dei difetti rispetto agli obiettivi di qualità Gestione del personale

9 La misurazione Elemento chiave in un processo ingegneristico Per conoscere a fondo le caratteristiche di ciò che si produce Per valutare il lavoro svolto Le misure e le metriche relative al software non sono assolute e, per questo, sono motivo di dibattito

10 La misurazione Misurazione Processo che assegna numeri o simboli ad attributi di entità del mondo reale, per descriverle secondo regole definite Concetti rilevanti Entità Persona Semaforo Programma Attributo Età Stato Dimensione Valore 18 anni Rosso 35 linee

11 Misura e Metrica Misura Risultato della misurazione Assegnazione empirica ed oggettiva di un valore (numerico o simbolo) ad un entità per caratterizzarne un attributo specifico Metrica, un insieme di regole Per stabilire le entità rilevanti Per definire gli attributi da misurare Per definire l unità di misura Per definire una procedura per assegnare numeri e simboli

12 Procedura di misurazione Formulazione: la derivazione di misure e metriche appropriate alla rappresentazione del software in esame Raccolta: il meccanismo con cui si accumulano i dati dai quali ricavare le metriche formulate Analisi: il calcolo delle metriche e l applicazione di strumenti matematici Interpretazione: la valutazione dei risultati, tesa a gettare luce sulla qualità della rappresentazione Feedback: raccomandazioni per il team di sviluppo ricavate dall interpretazione delle metriche