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

Martedi
10:30-11:30 (probabile cambiamento in futuro)

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

• 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 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).

Modalità d'esame

Sono previsti 2/4 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).

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

---

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.