Torna alla pagina di Ingegneria del software
:: Ingegneria del software - Appunti del 2 Marzo ::
Secondo la definizione della IEEE, "l'ingegneria del software è la disciplina tecnologia e manageriale che riguarda la produzione sistematica e la manutenzione dei prodotti software entro tempi e costi preventivati". Riprendiamo con maggiore attenzione alcuni concetti:
La produzione di un bene o di un servizio informatico rientra in un'attività aziendale ben precisa e definita chiamata processo software. In molti casi questa è legata al concetto di ciclo ideazione - progetto - produzione, di cui l'ideazione è sorprendentemente la parte più difficile e problematica dato che un errore commesso in questa fase richiederà maggiori energie per essere risolto. La sequenza appena descritta non è sempre applicabile, ad esempio in un contesto open-source non si decidono a priori le proprietà che avrà il prodotto, ma solo successivamente basandosi sui feedback e le proposte della comunità.
Vediamo altri termini del glossario IEEE che riguardano l'ingegneria del software:
Si trattano tutte di proprietà di alto livello che cercheremo di ottenere nel corso del ciclo di produzione e che concorrono al concetto di qualità. Abbiamo due tipi di qualità:
Concludiamo questa parte elencando alcune proprietà non funzionali che massimizzano quelle viste prima:
Per processo si intende un insieme di attività eseguite in funzione della produzione di un bene o un servizio. La codifica di un processo produttivo (in generale) permette di ottenere un'alta ripetibilità e riproducibilità dello stesso, così da renderlo indipendente dall'operatore che lo implementa.
Le principali caratteristiche di un processo software sono:
Il processo software legato ad un ciclo di vita è stato il primo ad essere definito ed è tra i tipi più semplici da adottare. E' caratterizzato da una serie di fasi ognuna delle quali prevede un certo numero di attività distinte ed autocontenute che coincidono col ciclo di vita del prodotto.
Se ogni fase consegna il suo prodotto (work product) a quella successiva e non è previsto un ritorno a quella precedente otteniamo un modello sequenziale e ordinato detto a cascata o waterfall. Una volta era molto diffuso, ma attualmente è poco utilizzato perché richiede molto tempo a disposizione e la conoscenza a priori di ogni aspetto da realizzare. E' facilmente intuibile come quest'ultimo requisito sia oggi impensabile a causa dell'elevata variabilità dello scenario tecnologico e di altri fattori endogeni, soprattutto se stiamo lavorando ad un processo su scala molto vasta. Pur essendo ormai obsoleto il waterfall è comunque utile da studiare in quanto i modelli successivi sono suoi derivati e miglioramenti, come ad esempio il modello trasformazionale che al contrario del precedente prevede il riutilizzo e la trasformazione dei componenti già esistenti adattandoli ai nuovi contesti.
Questo argomento lo vedremo meglio nella prossima lezione.
In generale per codificare un processo vanno definite le fasi, quindi il loro ordine (o assenza di ordine), le attività che prevedono e i loro work product. Dal momento che questi ultimi devono essere dati in pasto ad altre fasi per portare avanti il processo globale, per ogni processo software bisogna definire esattamente dove e come salvarli.
Terminiamo il discorso con una considerazione sui possibili scenari di un mercato del software, semplificando al massimo e considerando i ruoli che potrebbero rivestire i vari attori. Abbiamo quattro casi:
Nel capitolo precedente abbiamo visto che il modello waterfall (o a cascata) prevede una serie ordinata e unidirezionale di fasi del ciclo produttivo, ognuna delle quali consegna il suo work product a quella successiva. Potremo passare da modello a processo solo quando riusciremo a definire le attività a livello operativo per implementarlo, sempre rispettando le fasi del ciclo di vita. Bene, vediamole queste fasi:
Alcune critiche mosse contro questo modello le abbiamo già dette, tra queste l'impossibilità di variare i requisiti in fase di sviluppo, la scarsa adattabilità del processo produttivo una volta messo in moto, tempi di produzione molto lunghi. A questi aggiungiamo il fatto l'applicazione rigida di questo modello prevede che ogni software debba essere riscritto da zero ("from scratch"): nulla può essere riciclato.
Si è cercato di superare le rigidità intrinseche del modello waterfall rendendo ripetibili alcune fasi, riutilizzando i risultati di precedenti iterazioni così da assecondare le esigenze di cambiamento. Questa prima modifica al waterfall canonico si chiama mini waterfall e prevede come prima fase, prima ancora dello studio di fattibilità, una pianificazione delle iterazioni. Per quanto riguarda le tecniche iterative ne esistono due principali:
Questi concetti saranno ampliati nella lezione sui modelli iterativi.
Concludiamo segnalando l'esistenza di attività trasversali al progetto, che si effettuano cioè indipendentemente dal modello adottato o dalla fase che si sta affrontando. Queste sono la documentazione, il controllo di qualità e la gestione (di processo, di prodotto e delle configurazioni).