Ingegneria del software T1/2006-2007

Ingegneria del software, anno 2006/2007

Ingegneria del software è un corso complementare per la laurea in comunicazione digitale e altri corsi di laurea e fondamentale per il corso di informatica.

Docenti

Carlo Bellettini
e-mail: carlo.bellettini@unimi.it

Orari delle lezioni

Martedi	Venerdi
11:45-13.15 Aula 202	11:45-13.15 Aula V1

Oltre alle lezioni di teoria potrenno esserci delle lezioni in laboratorio per vedere nella pratica i concetti presentati a lezione (con cadenza di 1/2 volte al mese).

Orario di ricevimento del docente

mercoledi'
14:30 Stanza P116

Sito del corso

Se andate qui trovate tutto il materiale necessario,il forum e il wiki ufficiale del corso. Per tener separate le cose spiegate quest'anno dagli altri il wiki non ufficiale verrà redatto qui.

Materiale didattico

• primo libro:
  • Titolo: "Sofware Engineering",II Edizione
  • Autori: Ghezzi,Jazayeri,Mandrioli
  • Casa Editrice: Prentice Hall
  • prezzo: 46 euro

• Secondo libro:
  • Titolo: "A handbook of software and system engineering"
  • Autore: Endres,Rombach
  • Casa editrice: Addison Wesley

Ricordo che vi sono le lezioni videoregistrate di due anni fa,i cui argomenti vengono ripresi abbastanza similmente quest'anno. In più ci sono [URL=http://netdev.usr.dico.unimi.it/~belletc/ISwiki/materiale2005 le slides] sul sito del corso. Per vedere le videolezioni ci si logga con l'account del SILAB (se vi siete dimenticati la password dovete recarvi fisicamente in SILAB per cambiarla). Valgono i lucidi del 2005 a meno che non venga specificato diversamente nel wiki.

Modalità d'esame

Sono previsti 2 compitini e a seconda di come vengono fatti,un tot di minuti all'orale (se la media è sufficiente per tutti e sono ad un livello considerato buono dal prof. l'orale può essere omesso). Verranno messi a disposizione molteplici date di appelli (circa 1 ogni mese).

Iscrizione al forum IS2006

Per iscriversi al forum,bisogna:

• registrarsi se non si ha un account registrato avendo seguito un altro dei corsi (SOD,CISCO,ecc);
• loggarsi con l'account che si ha a disposizione per un altro dei corsi (gli account sono valevoli per tutti i corsi ospitati lì dentro) e poi andare su "Groups" e infine selezionare dal menu a tendina il corso d'interesse. Cliccare poi "Guarda informazioni" e infine "Iscriviti". La conferma della propria iscrizione la si ha tornando all'indice del forum e visualizzando il corso d'interesse.

Editaggio a cura di: Voodoo 17:40, 4 Ott 2006 (CEST)

Contribuisci anche tu!!!
CONTRIBUISCI ANCHE TU AL WIKI RIVERSANDO I TUOI APPUNTI: AIUTERAI CHI NON SEGUE! AIUTERAI TE STESSO A COMPRENDERE MEGLIO CIO' CHE HAI SCRITTO E A RIPASSARE!

---

Diario del corso

Lezione di Martedì 3-10-06

Abbiamo visto le principali definizioni di "ingegneria del software". In generale lo sviluppo di software è un processo che prevede innanzitutto la comprensione ci cosa vogliamo fare e del relativo contesto di utilizzo. Oltre a ciò servono delle metriche oggettive che mi diano la percentuale di raggiungimento dei miei obiettivi. La manutenzione del software occupa spesso il 70% dell'impegno conferito ai progetti.
Oltre a ciò vi sono aspetti manageriali e vincoli (temporali,finanziari,ecc) da rispettare. E' un campo della computer science che ha per oggetto il software. Mentre la scienza tende a confermare la correttezza di teorie attraverso modelli,ipotesi ed esperimenti, l'ingegneria del software attraverso metodologie e relative implementazioni tenta di definire l'utilità di ciò che si sta facendo.

Cenni storici

30/40 anni fa lo sviluppo del software era così caratterizzato:

• processo artigianale;
• richiedeva poche risorse di calcolo;
• solitamente vedeva l'uso di computer da parte di scienziati,fisici per implementazioni di loro teorie;
• problemi ben formalizzati (spesso autoproducevano il software);
• nessuna relzione (e relative problematiche) con i clienti;
• vita breve dei programmi (assolta la loro utilità,il ciclo di vita del software si esauriva);

I computer sono poi diventati economici e da attività di computing stretto si passa alla gestione dell'informazione.

• separazione tra sviluppatore e cliente;
• problemi comunicativi con altre persone (team interni e clienti esterni);
• nascita di team di sviluppo in cui diverse tipologie di esperti lavorano parallelamente ad un problema;

Categorie di qualità del prodotto finale e del processo di sviluppo

Possono essere legate al processo di sviluppo o al prodotto finale,riguardano la visibilità interna (visibile agli sviluppatori) ed esterne (visibili anche ai clienti). Le qualità di entrambi gli aspetti si influenzano a vicenda: è facile che se ho un buon processo di sviluppo,ciò influisca positiviamente sulla qualità finale del prodotto e di conseguenza anche sulla visibilità esterna. Questo può esser dato anche da una visione interna ottimale (buona scrittura del codice,sua organizzazione e documentazione( che automaticamente può riflettersi positivamente sull'esteriorità stessa del prodotto.

Obiettivi

• Affidabilità: un software può esser definito affidabile se produce effetti voluti o comunque degli scostamenti lievi da quello che mi aspetto. Esistono metodi statistici per definirla. Questi "scostamenti" potrebbero anche essere conseguenze spiacevoli per il sistema dell'utente (errori,crash,perdita d'informazione,spyware,ecc),è per questo che spesso nelle licenze software non vi è alcuna responsabilità per gli sviluppatori e l'azienda.
• correttezza: si riferisce a quanto il prodotto segua le specifiche concordate con il cliente. Spesso le specifiche non sono in un linguaggio formalizzato,sono quindi base di interpretazioni differenti e contestazioni.
• robustezza: capacità del software di reagire a imprevisti. Un software potrebbe non essere robusto anche se corretto ed affidabile. Influenza questo parametro anche lo sviluppo e manutenzione del software al cambio del team di sviluppo (quante difficoltà si incontrano nel portare avanti il progetto).
• prestazioni: possono essere effettuate delle misurazioni empiriche per identificare dove val la pena di lavorare per migliorare le prestazioni,oppure l'analisi della complessità degli algoritmi o simulazione con modelli. Un punto a favore è la crescita di potenza dei macchinari e l'abbassamento dei costi relativi. rientrano qui anche la scalabilità (capacità di trattare problematiche complesse più grandi di quelle pronosticate) e i tempi di risposta che influenzano l'usabilità del prodotto.
• usabilità: facilità d'uso di un software. E' molto variabile a seconda della tipologia dell'utete,è per questo che bisogna identificare con precisione i nostri utilizzatori. L'usabilità è quantificabile attraverso esperimenti.
• verificabilità: correttezza del prodotto (visione interna) e mostrare lo stato di avanzamento di sviluppo al cliente.

---

Lezione venerdi 6 ottobre

Manutentibilità

Nel software non c'è un usura "fisica" come per gli oggetti. Può essere principalmente di due/tre tipi:

• correttiva: correzione di una parte del progetto perchè vi sono delle discrepanze con le specifiche.
• adattiva: riadattamento di qualcosa già esistente,spesso perchè cambiano i requisiti e il contesto del prodotto e il software si deve adattare a nuove regole.
• perfettiva: il software va bene così com'è,voglio aggiungerci delle funzionalità (plugins,add-ons,ecc),c'è la voglia di migliorarlo,perfezionarlo.

Riusabilità

Prendo una parte del progetto e la riuso per un altro. Si affianca ad un altro progetto separato,non perdo tempo a risviluppare tutto e sono abbastanza certo sia affidabile,in quanto precedentemente funzionava. Comunque a volte la riusabilità può portare a costi maggiori in termini di tempo/fatica se importo parti di software incomplete che richiedono un'integrazione "studiata" al progetto.

Produttività

Nasce il problema di misurare quantitativamente la produttività degli sviluppatori nel processo di sviluppo. Spesso sono unità di misura adatte per ragionare e quantificare i lavori dal punto di vista manageriale.

• linee di codice/unità di tempo: bisogna tener però presente la qualità del codice e se il confronto fra due sviluppatori,per esempio,avviene su un medesimo lavoro oppure sono lavori di diversa natura (che potrebbero richiedere tempi diversi di sviluppo e modalità diverse);
• punti funzione: si pesa opportunatamente la complessità del progetto partendo dalle specifiche assegnando alle sue varie parti una certa complessità che permette un raffronto con quello realmente impiegato dagli sviluppatori;
• sfrozo mesi/uomo;

Tempismo

Capacità di porre sul mercato il prodotto al tempo giusto o di rispettare i tempi contrattuali in relazione ad un cliente (diventa un metro di giudizio). Se non ho a che fare con dei clienti ma con un prodotto generale (Office per es.) devo capire quando metterlo sul mercato in relazione ai possibili concorrenti. Spesso non essendo pronti tecnologicamente (si è arrivati in ritardo su una certa tecnologia) le grandi aziende promuovono software che ancora non hanno prodotto,costruendo un'immagine atta a far sapere che presto ci sarà il tal software. Oppure vengono promossi progetti che poi non troveranno realtà (vaporware).

Principi influenti sulla qualità del prodotto

• Rigore e formalità: avere un approccio rigoroso che ci guidi nel processo di produzione è uno strumento che ci consente di fare meno errori. Per formalismo intendiamo qualcosa assente da ambiguità,di capibile da una macchina per esempio,cosa che normalmente non avviene nella comunicazione con l'utente. L'uso di formalità nelle specifiche dà benefici,riduce gli errori e li identifica prima (importante perchè identificarli tardi vuol dire fare più fatica ad estirparli - più dipendenze dagli errori commessi,quindi più carico di lavoro - ).
• Separazione degli aspetti: permette di ridurre la complessità dello sviluppo separandone gli aspetti. Si identifica la responsabilità dei gruppi di lavoro per le varie parti,scandendo il ciclo di vita temporale del software (cosa va fatto in un certo momento),ci si concentra su singole qualità e le si implementa,ricordandosi di sviluppare molteplici viste per i vari "esperti" (il modo do vedere le cose dello sviluppatore è doverso da quello del cliente così come è diverso da quello dello sviluppatore). Le specifiche descrittive si concentrano su che cosa va fatto,quelle operazionali su come va fatto. Sicuramente è impensabile l'utilizzo di un'unica vista universale valida per ogni cosa;
• Modularità: posso adottare il top-down o bottom-up,l'importante è riuscire a capire i moduli indipendentemente dagli altri,il che mi consente si concentrarmi solo su una parte anche per debugging e manutenzione. La correttezza della modularità è definita da metriche di:
  • coesione: tutti gli elementi di un modulo sono collegati per far qualcosa in comune,non comprende nulla di non necessario;
  • disaccoppiamento: tutto ciò che serve è lì dentro e ci si appoggia all'esterno per il resto che è necessario. Una struttura è stabile se la coesione è forte e il disaccoppiamento è basso (concentro tutto quel che mi serve con poche dipendenze esterne).
• Information hiding:capacità di nascondere le cose in un modulo,rende il modulo adattabile e più semplicemente modificabile (gli aspetti invisibili al resto possono essere modificati senza ripercuotersi sul resto,per esempio modifiche di metodi/variabili private di una classe). Solo ciò che è nascosto può esser cambiato senza rischio.
• Astrazioni: livelli costruiti su quelli sottostanti in gerarchia.
• Anticipazioni di cambiamento: progettare pensando in avanti,future estensioni al software.

Modello ciclo di vita del SW

Identificare le attività di sviluppo e i tempi giusti di implementazione,quando interromperle per iniziarne una nuova ,ecc. Lo studio di fattibilità si pone delle domande:

• si è in grado di fare il progetto?
• ci torna un guadagno?
• cosa serve per farlo?

Insomma si preoccupa di requisiti e conseguenze tecnologiche ed economiche. Si necessita anche dello studio della concorrenza,nel caso esistano già progetti simili. La stima di costi e tempi di sviluppo insieme alle attività di ricerca precedenti sono spesso intraprese all'inizio del progetto quando ancora non si sa fondamentalmente nulla. Spesso sono esperti esterni all'azienda a compiere tale studio.

---

Lezione di martedi 10 ottobre

Analisi specifiche requisiti

Capire cosa vuole l'utente e specificarlo nella documentazione (interviste al cliente). Possibili problemi di comunicazione fra figure diverse (interne/esterne rispetto al prodotto,per questo si necessita lo sviluppo di viste differenti "del problema"). Coloro che interagiscono con l'applicazione o ne sono in qualche modo influenzati sono definiti Stakeholders.
Alla fine si arriva al documento contrattuale e alla definizione del manuale.

Progettazione

• come realizzare i requisiti (possibile riutilizzo di situazioni precedenti analoghe o simili);
• Creazione di moduli indipendenti o comunque creare un possibile aggancio con le funzionalità esterne (implementazione di moduli stub ancora da definire). In questo modo si arriva a definire dei moduli separati incastrabili potenzialmente l'uno con l'altro.

Integrazione e Test

• approcci bottom-up oppure top-down;
• implementazione degli stub;
• eliminazione delle imprecisioni;
• test di integrazione per assicurarsi che i moduli ricongiunti i "vedano" correttamente;
• test di sistema per provare il sistema implementato completamente;
• il test d'accettazione è il punto di vista dell'utente e dev'esser superatoperchè il prodotto sia valido;

Fasi di alfa e beta test

Sono attività di test che sostituiscono quella di sistema quando non vi è uno specifico cliente (es. grandi prodotti da immettere su un mercato ampio e generico). Come output ci danno il nostro programma consegnabile. Si identificano degli utenti fidati per un feedback significativo:

• alfa test: il prodotto essendo poco affidabile viene fatto testare solitamente dai componenti interni nella compagnia;
• beta test: seleziono dei clienti tipici dandogli la nuova versione,in cambio mi fanno un report degli errori che incontrano.

Modelli

• cascata: famoso negli anni 70,processo sequenziale irreversibile (non si torna indietro su passi già "visti",quindi niente manutenzione,il ciclo di vita del SW termina alla consegna del prodotto stesso). L'innovatività stava nell'introdurre una disciplina nella gestione dei progetti. Esistono delle varianti a questo modello (non definibili "a cascata") in cui è possibile effettuare una singola retroazione ad un passo precedente a quello corrente nel processo di sviluppo;
• modello a V: segue in un certo senso il modello a cascata ma c'è un confronto costante di ogni cosa che produco con l'utente.
• modello a fontana: se qualcosa non va lungo il percorso torno da capo e riconsidero tutto. Riconosce una vita al prodotto SW anche dopo la consegna dello stesso;
• modello prototipale:
  • usa e getta: risolvere problemi a basso livello per poi ricominciare tutto avendo l'esperienza dei problemi risolti,a prescindere da struttura e documentazione;
  • prototipi interni: orientati per esplorare nuove possibilità (linguaggi,piattaforme di sviluppo,ecc);
• modello flipper: non è possibile definire un modello rigoroso,svincolato da pianificazioni;
• modello trasformazionale: si parte dalle specifiche per poi effettuare delle traformazioni che portano ad una release previa prova formale che mi dimostra a priori,se superata,che la release è in linea alle specifiche. Ci sono rigide prove di correttezza;
• modello a spirale: introduce l'analisi dei rischi (portare avanti o meno il progetto a seconda di vari parametri) al ripetersi delle 4 fasi principali. Negli altri modelli solitamente l'analisi di rischio viene fatta all'inizio solo nello studio di fattibilità;
• modello Win Win: si cerca una contrattazione fra sviluppatori/stakeholders tale che entrambe le parti siano soddisfatte.
• modello COTS: pone l'accento sulla riusabilità di componenti esterne per il nostro progetto. Il ciclo di vita del SW può essere molto trasformato se il riuso è dominante nel progetto. Inoltre l'integrazione delle componenti già pronte non deve portare via troppo tempo,altrimenti si poteva implementare tutto da zero.
• modello UP: rappresentazione di tutti i modelli esistenti con qualcosa in più. Si basa su uno dei 9 diagrammi di UML (use cases driven).

---

Lezione di venerdi 13 ottobre

Non c'è stata.

---

eXtreme Programming

XP: eXtreme Programming

Kent Beck "programmazione estrema:Introduzione" XPIntsall ftp.xprogramming.com

Mette a proprio agio il programmatore

Identificato in: portata: quantità di funzionalità che si vogliono implementare tempo: quando devo consegnare? qualità: quanto dev'essere buono il progetto(punta su correttezza e manutentibilità) dev'essere al max per XP costo: quanto vuole spendere?

Il cliente vuole decidere tutti e 4 i parametri.Bisogna far capire che può decidere solo su 3 al max Principi e tecniche: modifica incrementale(in ogni momento dell sviluppo devo pensare per piccoli cambiamenti), accettare il cambiamento(pensare al presente non vuol dire credere che n ci saranno mai cambiamenti), lavoro di qualità(punto di vista psicologico:il programmatore dev'essere soddisfatto per lavorare bene,la ditta abbassa il turn over) Valori: feedback rapido, presumere semplicità(inutile pensare per il domani,il contrario del design for change), coraggio, comunicazione(anche interna al team)

Figure professionali Responsabilità

Management(e/o cliente) ha responsabilità di decidere

 - portata e priorità(specie nel primo rilascio)
 - date rilasci(cmq in funzione dell'ok del tecnico in base alla portata)

Tecnico ha responsabilità di decidere:

 - stime dei tempi
 - pianificazione dettagliata
 - scelte tecnologiche a breve respiro
 - particolarità processo di sviluppo(come attuare certe cose)

Figure professionali Diritti

Management & Customer

 - sapere a che punto è lo sviluppo,no black box come nel Big-Bang, sapere cosa può essere fatto
 - cambiare idea su tutto

Sviluppatori

 - sapere cosa devo fare chiaramente ORA tramite storie di uso (se faccio questo il pc  deve fare questo)
 - dire quanto tempo gli serve,
 - può cambiare idea sul tempo man mano che procede
 - identificare i indicare le funzionalità pericolose per assegnarli una giusta priorità
 - produrre sw in pace,divertendosi.

Ci sono altre 2 figure Coach(project manager)governa il processo, se è bravo XP funziona Xp nn è formale ma è rigoroso

Tracker monitorare il processo con misura(numero linee di codice, numero test passati), decide che cosa esporre al team riguardo al punto della situazione

L'approccio XP

- Planning game (vengono determinate le funzionalità del prossimo rilascio.Fatto da 3 fasi cicliche:Esplorazione(che si può fare?),Impegno(decidere cosa fare nella prossima fase e prendere un impegno),Gestione(direzione dello sviluppo con correzioni da parte del tracker)

- Brevi cicli di rilascio (riduco i rischi, ma i rilasci devono cmq essere significativi,percepibili dall'utente)

- Uso di una metafora (ci vuole un modo intuitivo che inquadri ciò che stiamo facendo in modo più generale, che sostituisca l'architettura del sistema.Anche come vocabolario,i nomi delle variabili per esempio)

- Semplicità di progetto (niente dupplicazioni, manutenzione più semplice, no "implementa oggi e progetta per domani)

- Testing (prima programma i test, poi programma il sw che dovrebbe superare il test)

- Refactoring (Non bisogna avere paura di apportare modifiche che semplifichino il progetto,gradualmente ma quotidianamante rendo più semplice il codice e evito la naturale entropia legata allo sviluppo,come dice Lemann)

- Programmazione a coppie (aiuta ad avere controllo e rispettare le tecniche XP,divide i ruoli,aiuta inserimento e formazione di nuovo personale)

- Proprietà collettiva (il codice nn è senza proprietà.Ci si deve sentire responsabilizzati su tutto il codice anche se nn si conosce tutto alla stessa maniera)

- Integrazione continua (x avere feedback rapidi. Ogni coppia non deve avere solo risolvere il suo problema,ma anche come integrare.è sua responsabilità)

- Settimana di 40 ore (fidelizzazione, soddisfazione di lavorare nel team.)

- Cliente sul posto (una parte del cliente dev'essere insieme nel team di sviluppo sul posto di lavoro.Spesso è un problema,gli viene tolta una risorsa.Come pro è che le specifiche sono leggere)

- Standard di codifica (facilitare la comunicazione attraverso il codice ad aiuta il refactoring)

Raggruppamento per fasi

 - Requirements (gli utenti fanno parte del team di sviluppo,consegne incrementali)
 - Design (Metafora per unificare il progetto, refactoring,presumere la semplicità)
 - Code (coppie, proprietà collettiva,integrazioni continue,standard di codifica)
 - Test (testing unità continuo scritto prima del codice unità, test funzionale scritto dagli utenti)

E la documentazione? è nel codice, la codifica standardizzata permette leggibilità al programmatore L'utente sa già tutto, ha persino scritto i test!!

Quando non si può usare XP Negli ambienti che proibiscono anche solo uno degli approcci usati (barriere tecnologiche che impediscono un feedback rapido, necessità burocratica di avere documentazione, spazi di lavoro che non permettono schieramenti a coppie) Ipotesi di Beck - Fowel : i metodi di progettazione agile abbattono l'impatto di richieste di cambiamento

Lezione di venerdì 20 ottobre

Lezione sospesa. Leggi l'avviso dul forum ufficiale.

---