|
Wiki
UniCrema
Materie per semestre
Materie per anno
Materie per laurea
Help
|
|
Uni.IDS-2Marzo History
Show minor edits - Show changes to output
Changed lines 55-56 from:
Questo argomento lo vedremo meglio nelle prossime lezioni. to:
Questo argomento lo vedremo meglio nella [[#i3|prossima lezione]]. Changed lines 67-68 from:
to:
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:
# '''studio di fattibilità'''
# '''specifica dei requisiti'''
# '''progettazione'''
# '''codifica'''
# '''verifica''' e '''validazione'''
# '''manutenzione'''
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:
* la ''throw away'', che prevede la riscrittura completa del prototipo ad ogni iterazione. Ciò che sembra folle e dispensioso in realtà è molto furbo, dato che permette di realizzare un primo prototipo semplice semplice (ad esempio realizzato in PHP e per nulla ottimizzato) in tempi brevi per sottoporlo all'attenzione del cliente; se questo poi lo approva si può passare all'iterazione successiva riscrivendolo in modo ottimizzato e in un linguaggio appropriato mantenendone inalterate le funzionalità
* la ''onion skin'', che prevede prototipi evolutivi a cui aggiungere a ogni passaggio iterativo nuove funzionalità e migliorie, senza cancellare ogni volta tutto il lavoro fatto
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).
Added lines 7-15:
>>left bgcolor=#f5f9fc width=200px border='2px solid #cccccc' padding=5px<<
%center%'''Indice'''
# [[#i1|Il prodotto software]]
# [[#i2|Il processo software]]
# [[#i3|Il modello waterfall]]
>><<
[[#i1]] Added line 43:
Changed line 54 from:
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. \\ to:
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. \\ Added lines 56-68:
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:
* il produttore coincide con il consumatore, il caso più semplice, ovvero un autoconsumo
* produttore e consumatore sono unità distinte di una stessa azienda o istituzione. Già in questo caso è importante conoscere la definizione del processo software
* il produttore è una software house che sviluppa un'applicazione custom per un singolo utente, che quindi compra l'intero ciclo di sviluppo acquisendo la proprietà intellettuale del prodotto in cambio della copertura dei costi più i margini di profitto
* il compratore non acquisisce la proprietà intellettuale, ma paga al produttore solo una licenza d'uso. La software house che sceglie questa modalità si assume un rischio, quello di non riuscire a coprire i costi di sviluppo, quindi deve prevedere nel modo più accorto possibile il numero minimo di copie che venderà
[[#i3]]
!!Il modello waterfall
Changed lines 42-45 from:
to:
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 nelle prossime lezioni.
Added lines 35-41:
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:
* integrazione continua e progressiva
* frequenti rilasci intermedi di codice eseguibile, prima interni poi esterni
* possibilità di effettuare una valutazione indipendente del progresso del progetto, certificabile con opportune metriche che considerano determinati aspetti e caratteristiche. Lo standard ISO 9000 disciplina questi monitoraggi, ma senza dirci se l'operato è di qualità o no, ma solo se le rilevazioni sono state fatte correttamente
Added lines 25-34:
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à:
* '''qualità interna''', che riguarda la concisione e la leggibilità del codice. Maggiore è la qualità interna e minori saranno i costi di adattamento e manutenzione, ed inoltre si rivelerà un mezzo per ottenere quella esterna. E' anche chiamata ''white-box'' proprio perché si deve poter consultare il codice
* '''qualità esterna''', che riguarda le caratteristiche lato utente, come ad esempio le prestazioni, la correttezza, la facilità di utilizzo, eccetera. E' anche chiamata ''black-box'' perché non è necessario guardare il codice
Concludiamo questa parte elencando alcune proprietà non funzionali che massimizzano quelle viste prima:
* '''malleabilità''', ovvero la capacità del prodotto di adattarsi a nuove esigenze sia che sia in corso d'opera sia che sia già finito. Ovviamente questa caratteristica non è propria di ogni tipo di prodotto, ad esempio non lo è per il mercato dei telefonini: per avere una nuova funzionalità (ad esempio, il supporto al VOIP) non puoi fare altro che buttare quello vecchio e comprarne uno nuovo che la supporta
* '''manutenzione correttiva e adattativa''', che è più un servizio che la produzione di un bene
* '''preminenza del design''', che considera la produzione del software come un'attività prevalentemente progettuale
!!Il processo software
Added lines 1-28:
(:title Ingegneria del software - Appunti del 2 Marzo:)
[[Torna alla pagina di Ingegneria del software-> Ingegneria del software]]
----
%titolo%''':: Ingegneria del software - Appunti del 2 Marzo ::'''
!!Il prodotto software
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:
* ''manageriale'', quindi stiamo parlando di un qualcosa che ha aspetti aziendali e/o industriali
* ''produzione sistematica'', cioè di massa. Ciò ci fa capire che non stiamo parlando di "artisti programmatori", ma di veri e propri operai
* ''manutenzione'', quindi l'ingegneria del software non si occupa solo dello sviluppo
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:
* '''affidabilità''', il software si comporta come previsto
* '''correttezza''', il prodotto fa quello che ci si aspetta che faccia. Più formalmente un software è corretto quando soddisfa i requisiti concordati tra gli sviluppatori e i committenti. Questa proprietà può essere messa alla prova ad esempio con una fase di testing
* '''interoperabilità''', quando il software non è monolitico ma è in grado di integrarsi con altri prodotti
* '''manutenibilità''', facilità nel realizzare adattamenti o evoluzioni e semplicità nel correggere gli errori
* '''riusabilità''', riutilizzo di componenti già esistenti
* '''usabilità''', facilità d'uso da parte dell'utente
* '''verificabilità''', possibilità di dimostrare a posteriori la correttezza o altre caratteristiche del software
* '''sicurezza'''
----
[[Torna alla pagina di Ingegneria del software-> Ingegneria del software]]
|
|
