Ingegneria del software: 14 marzo 2005

Processi "in the large" (ovvero scelta dei modelli)
CMM: 1993, modello per autovalutare il processo software.
Cinque livelli di processi:

1. Nessun requisito: il valore dipende tutto dalle persone (niente linee guida, ecc.)
2. Ripetibile: sottoponendo lo stesso problema viene risolto allo stesso modo o meglio. Definisco quali sono le fasi di un processo.
3. Definito (ben definito): documentato, standardizzato a livello di azienda. Customizzabili a livello di progetto (ma customizzazione devono venire approvate).
4. Gestito: Quantificabile ogni obiettivo che ci poniamo. Sono raccolte tutte le metriche necessarie a capire cosa sta succedendo.
5. Ottimizzante: in continua ottimizzazione

Ad ogni livello sono associate delle KPA (Key Public Area)
Ogni KPA é coperta da: scopi, impegni, capacità, attività, metodi di monitoring della realizzazione, metodi di verifica della realizzazione

Per essere di livello 2 (ripetibile):
Gestione dei requirement
Gestione del planning del software
Capacità di fare delle misurazioni
Gestione dei sottocontratti (cose appartate fuori)
Tecniche di garanzia della qualità
Software configurazion management

Per essere di livello 3 (Definito):
Organizzare il processo in maniera completa a livello di azienda
Fare corsi di traning sul processo di sviluppo aziendale
Sforzo di software engineering
Politiche di coordinamento tra gruppi
Tecniche di ispezione del codice

Per essere di livello 4 (Gestito):
Gestione della qualità del software
Gestione delle quantità del software

FOSS:

1. Invenzione: avere l'idea del software
2. Espansione e innovazione: uno o più compagnie si accorgono dell'idea e ci lavorano sopra (o gruppi opensource).
3. Consolidamento: alcuni dei progetti iniziano a superare la selezione (gli altri falliscono o vengono assorbiti)
4. Maturità: Le idee diventano complete, poco spazio per altri
5. I team maturi diventano lenti e poco innovativi, i team FOSS (opensource) iniziano a erodere il mercato dei team commerciali.
6. FOSS Era: alla fine rimangono solo i prodotti dei team FOSS, i prodotti commerciali diventano di nicchia (non si é ancora mai verificata).

http://www.catb.org/~esr/writings/cathedral-bazaar

OpenSource
Come inizia:
1. Parte dalla frenesia personale di uno sviluppatore.
2. Inizia a coinvolgere altra gente
3. Scambi di opinioni tra i programmatori
4. Le persone disposte a spendere (tempo) su quel progetto danno il via al progetto
Come continua:
5. I membri del progetto lavorano al problema fino a produrre dei risultati presentabili.
6. Si rende noto il prodotto
7. Arrivano i primi suggerimenti esterni
8. Interazione fra vecchi e nuovi elementi del gruppo
9. Nuove informazioni vengono acquisite e si ritorna al lavorare sulle nuove idee (punto 5)

E' un problema coordinare un progetto con molti programmatori.
Confronto:

	Proprietario	OpenSource
Modello	Cattedrale	Bazaar
Risorse	Definite	Sconosciute
Planning	Intero progetto	Step by step
Utenti	Utente pagante	Co-developers
Obiettivo	Rispetto del contratto	Risolvere un problema
Motivazione	Stipendio (forte?)	Voglia (debole?)
Stato di progresso	Segreto	Pubblico
Collaborazione	Faccia a faccia	Internet
Assicurazione di qualità	Management	Peer review

Problemi dell'opernsource:

• Poca visibilità (finché un progetto non sfonda...)
• Concorrenza all'interno del progetto: i programmatori hanno idee e/o priorità diverse (il progetto potrebbe spaccarsi)
• Lavori sporchi: ci sono parti che nessuno vuole fare...
• Passaggio delle consegne: Se il capoprogetto se ne vuole andare deve avere il coraggio di cedere il testimone.

Strumenti per l'OpenSource:

• Comunicazione:
  Internet (comunicazione a senso unico: tu publichi, gli altri leggono)
  Forum (mantenere una comunity e rispondere alle domande)
• Sincronizzazione del lavoro e versioning:
  Sul codice (Source Code Management)Sulla documentazione (es. = wiki)
• Automatizzazione delle build (Build Tools):
• Bug tracking

Source Code Management
Programmi: CVS, SubVersion (http://subversion.tigris.com/), Bitkeeper (commerciale, ma usato per Kernel Linux), GNU arch, Monotone
Archivia le varie versioni e gestisce la concorrenza nello sviluppo. "Magazzini di codice"
Check out: estrazione dal repositori di un file
Check in: archiviazione delle modifiche
Caratteristiche comuni:
Versioning dei sorgenti (possibilità di storicizzare versioni del codice)
Gestione della concorrenza
Tagging delle versioni (per lasciare appunti sulle modifiche ad esempio)
Branch: Lo sviluppo può proseguire su più alberi (potrebbe esserci un ramo che non viene più sviluppato e si riprende da una versione precedente)
I salvataggi sono differenziali (solo differenze rispetto alla versione precedente)
Locking esplicito: permetto la modifica solo 1 persona alla volta
Locking implicito: controllo solo al momento del check-in (al massimo ci sarà un sistema manuale (ma guidato) per gestire la sovrapposizione delle modifiche.

Build Tools
make (permette di definire regole di dipendenze per la compilazione e permette di invocare programmi esterni)
ant (apposta per java). Si integra con CVS, JUnit (Framework per unit testing in Java) e permette di stabilire regole di validazione per permettere l'archiviazione (ad esempio no check in che non vengono passati i test JUnit). Molto flessibile ed espandibile

Bug Tracking System
BugZilla, Scarab, GNATS, BugManager
Generalmente via web: permettono di archiviare segnalazioni, bug e gestione degli incarichi di risoluzione dei bug.
1) Segnalazione (anche da anonimi)
2) Definizione bug (se é un bug viene riconosciuto)
3) Presa responsabilità: una persona si prende l'incarico di risolverlo
4) Risoluzione

Open Source su internet:
http://sourceforge.net
CVS, bugtracking, forum

http://www.gotdotnet.org/Workspaces
Per Microsoft.NET

http://www.tigris.org
Specifico per software engineering (ci sono subversion ed altri). Buona qualità, ma tanti requisiti.

Ingegneria del software: 10 marzo 2005

Metodologie Agili
Extreme Programming
Kent Beck: Programmazione estrema: introduzione
Molto materiale, molto di moda.
http://www.extremeprogramming.org
ftp://ftp.xprogramming.com/ftp/xpinstall.pdf
http://www.hxp.it
Le variabili in gioco:
portata: la quantità di funzionalità che si vogliono implementare (delicata: mutevole)
tempo: che si intende dedicare al progetto
qualità: qualità più importanti
costo: quanto sei disposto a spendere
Solitamente si permette al cliente di fissarne al massimo 2:
Qualità dovrebbe essere fisata al massimo
XP vorrebbe mantenere come variabile libera la portata (prezzo fisso le funzionalità variano)
Valori: (sono la linea guida)
Coraggio
Comunicazione
Rapidità
Semplicità
Principi:
Feedback rapido (comunicazione basata sul codice, comunicazione importantissima)
Semplicità: non pianificare per il futuro, per il riuso
Modifica incrementale: sviluppare piccole e semplici funzionalità un po' alla volta
Accettare il cambiamento: essere sempre pronti a stravolgere tutto
Lavoro di qualità: fare trovare bene il programmatore. Se si vuole che il programmatore renda deve essere soddisfatto di ciò che fa. Abbassare il turnover (fare rimanere i programmatori).
Le figure:
Manager o cliente (cliente interno o esterno): ha la responsabilità di decidere la portata, le pirorità tra le funzionalità e le date (ma le tempistiche le decide il tecnico).
Tecnico: Stime dei tempi per le funzionalità, scelte tecnologiche, processo,pianificazione dettagliata (decidere all'interno della pianificazione grossolona quali sono le priorità).
Coach: Guida e coordinamento dei programmatori: é il designer dell'applicazione
Tracker: monitora il progetto e rende publiche le misure relative al progetto.
Diritti del manager:
Vedere i progressi del progetto
Vedere cosa può essere fatto e in che tempi
Cambiare idea (sostituire o modificare funzionalità)
Diritti degli sviluppatori:
Sapere cosa é necessario e che priorità ha. Non dovrà essere formale, ma dovrà essere chiaro.
Fissare il tempo per l'implementazione
Cambiare le stime in base all'esperienza
Fissare le parti critiche (sottolineare quali sono le parti critiche: vitali, difficili da capire, difficili da stimare, ecc. ecc.)
Produrre software in pace.
L'approccio:

• Planning game (discussione con il cliente su quali saranno le prossime funzionalità, ecc.)
  Esplorazione delle funzionalità utili. Vengono scritte su foglietti.
  Impegno: Ognuno dice la sua sui vari foglietti e viene deciso a chi assegnarli
  Gestione: direzione dello sviluppo con correzioni dall'andamento reale. Il tracker qui svuota il suo sacco.
• Brevi cicli di rilascio riduco il rischio di sbagliare le stime. In contrasto con l'"avere rilasci significativi". Indicativamente massimo 1 o 2 mesi
• Uso di metafore é un po' il design informale del progetto. Quadro d'unione del progetto. Difficile trovare la metafora, deve essere condivisa con l'utente.
• Semplicità del progetto NESSUNA DUPLICAZIONE di codice
• Testing testare, testare, testare. Testing del codice: prima scrivere i test, poi scrivere le funzionalità (da fiducia nel codice al programmatore); testing funzionalità: il cliente scrive (in linguaggio comune) i test da effettuare (da fiducia nel programma al cliente).
• Refactoring: Scrivere il codice nella maniera più semplice, più pulito. Posso sistemare anche parti di codice funzionante. Migliora la qualità per i colleghi. Vitale: elimina l'entropia. Continuo e graduale.
• Programmazione a coppie (pair programming) Aiuta a rispettare i principi di XP, a diversi ruoli, aiuta l'integrazione di nuovo personale. Le coppie variano frequentemente. I programmatori devono accettare XP.
• Proprietà collettiva: Tutti devono sapere tutto. Il codice é di tutti, tutti devono tenerci al codice.
• Integrazione continua: ovvero riunire tutte le modifiche, fare delle build (sulla macchina comune)!
• Settimana di 40 ore: Inutile stressarsi: quando si é sotto stress si produce brutto codice. Fare stare bene il programmatore. Piuttosto rifare la pianificazione.
• Cliente sul posto: parlare tanto con il cliente. Un rappresentante del cliente dev essere sempre sul posto. Permette di fare le specifiche leggere all'inizio. Diciamo che deve essere sempre disponibile (non per forza dagli sviluppatori).
• Standard di codifica. La facilita la comunicazione (la comunicazione é sempre attraverso il codice).

Riassumendo:
Requisiti: leggeri, mediante le user stories (l'utente scrive cosa si aspetta dal programma)
Design: basato su una metafora e su CRC (class responsibilities collaborations)
Codice: Programmazione a coppie, proprietà collettiva, integrazione continua, standard di codifica
Test: del codice (del dev), funzionale (del cliente)
Documentazione: la documentazione sta nel codice (talmente chiaro da essere capito e ben testato: i test sono i casi funzionali) e nell'utente che ha seguito il progetto.
Tools per i test: JUnit, NUnit, xUnit
Quando NON usare XP:
Se devo rinunciare anche ad una sola delle pratiche
Impossibilità di avere feedback veloci (ad esempio un'applicazione che impiega 2 giorni a girare)
Team troppo numerosi (idealmente 10)
Necessità di documentazione basata su certificazione
H6: Ipotesi di Beck e Fowler: L'uso di metodologia agili riduce l'impatto della richiesta di modifiche
Quando usare XP:
Cliente indeciso
Lavori non enormi
Disponibilità del cliente

Consultare bene questo (riassunto delle fasi):

Ingegneria del Software: 7 marzo 2005

Step di preparazione di un programma:

Raccolta specifiche

Progettazione Large (architettura) e Small (suddivisione in moduli e sottomoduli)
Definizione dell'architettura del sistema (facilitata dall'applicazione di pattern architetturali)
Produce in output documenti di specifica del progetto (in UML se ad oggetti)

Programmazione e unit testing (verifica singola unità)
Ovvero lo sviluppo di un singolo modulo ed il testing dello stesso mediante:
moduli stub moduli fittizzi: simula dei moduli da cui dipende quello esistente (mock objects). Così isolo solo gli errori presenti nel mio modulo.
moduli guida i test veri e propri: dei moduli che chiamano il modulo da testare e ne testano l'output (e gli eventuali errori previsti).
Tecniche di testing (verranno analizzate nella 4a parte):
Analisi statica
Analisi dinamica
Esecuzione simbolica
Debugging

Integrazione continua e test di sistema
Sostituisco i moduli stub e testo l'intera applicazione
Test di accettazione: test dell'utente. Se il viene superato questo test il prodotto é valido.
Se non avessi un cliente devo trovare dei sottoinsiemi indicativi di clienti.
Alpha test: distribuisco a potenziali clienti fidati (in genere interi)
Beta test: distribuisco a dei clienti fidati

Post release:
Manutenzione
Produce in output un versione migliore a quella precedente.

Fasi trasversali:
Documentazione
Scrivere la documentazione mentre si scrive il codice

Verifica e controllo di qualità
Testing e altre verifiche ad hoc

Gestione del processo (manageriale)
Incentivi, assunzioni, responsabilità, eccezioni

Gestione configurazioni
Gestire team e versioni di moduli.
Non deve succedere che un team cambi un una libreria e le cui modifiche blocchino un altro team.

---

Modelli incrementali

Modello a cascata
Una dopo l'altra le seguenti fasi:
Requisiti -> Progetto -> Codifica -> Testing -> Prodotto
Sono 5 processi separati e consecutivi (non si può tornare indietro). Ognuno produce documenti che sono l'input della fase successiva.
Questo modello non prevede la manutenzione (disastro!)
Problemi: rigidità, congelamento dei prodotti (stima dei costi fatta solo nelle prime fasi), monoliticità (tengo all'unico rilascio), manutenzione fatta solo sul codice.

Modello a V

Le frecce grigie rapperesentano validazioni da parte dell'utente, mente quelle bianche dei controlli da parte del programmatore

Modello a Fontana

Come il modello a cascata, ma ad ogni modifica riparto dall'analisi dei requisiti e procedo via via oltre.

Modello prototipale

Lavorare molto sulla creazione di un prototipo. Affrontando una prima volta i problemi saprò come affrontarli dopo.
Throw away: una volta fatto andrebbe buttato e il progetto riparte da zero.
L2: La prototipizzazione ridurece sensibilmente le richieste e gli errori di progettazione (specialmente per l'interfaccia utente)

Problemi dei modelli incrementali:
Planning complicato: necessario pianificare tutte le iterazioni
Rischio di caricare troppo la prima iterazione
Rischio di avere troppe iterazioni
Rischio di avere troppe sovrapposizioni tra un'iterazione e l'altra
http://www.rational.com/products/whitepapers/102016.jsp

Modello flipper
E' poco più che una provocazione: completamente indefinito, equivale a nessun modello!

---

Modelli trasformazionali
Dalle specifiche formali si arriva al prodotto finale tramite dei passi nei quali ogni volta le specifiche vengono specializzate, ottimizzate, rese più concrete, riviste.
Purtroppo sono modelli molto "costosi" in termini di tempo!
Per questo sono applicabili solo a parti di progetti molto critiche.
Usati pochissimo.

Meta-modello a spirale
Basato sui rischi: concentrato sulla valutazione del rischio (di fallimento del progetto, ecc.)
Ogni iterazione é scomposta in 4 fasi:

1. Determinazione obiettivi, alternative, vincoli (? progettazione)
2. Valutazione alternative, identificazione rischi (? revisione della progettazione)
3. Sviluppo e verifica (?sviluppo e test)
4. Pianificazione fase successiva

Ogni giro di spirale corrisponde ad un ciclo completo delle 4 fasi (che sono rappresentate nei piani).
Il raggio della spirale (numero di passaggi nelle 4 fasi) corrisponde al costo.

Modello Win Win
Derivato dal modello a spirale, aggiunge 3 fasi per la definizione delle specifiche.
Ci si rende conto che la definizione delle specifiche é come una lotta fra il committente e chi produce. Scopo di questo modello fare sì che alla fine sia il committente, sia chi produce abbiano la sensazione di averla avuta vinta sulle specifiche.

Modello COTS (Componente Off The Shelf)
Conosciuta anche come RAD (Rapid Application Development) o Progettazione per componenti.
Da importanza al riuso di codice tra un progetto ed un altro. Classificare e ricercare i moduli

1. Analisi delle richieste
2. Analisi dei possibili componenti
3. Modifica delle richieste (per cercare di usare componenti trovati)
4. Design del sistema concentrandosi sulla riutilizzabilità
5. Sviluppo ed integrazione dei componenti
6. Validazione del risultato

Le fasi sottolineate sono quelle caratteristiche del modello COTS

Ingegneria del software: 3 marzo 2005

Separazione dei principi
Separazione delle responsabilità (non tutte le responsabilità alla stessa persona)
Separazione nel tempo (Prima si progetta poi si codifica)
Separazione nel considerare le qualità (non tutte le qualità vanno cercate immediatamente: es. prima mi preoccupo che sia robusto, solo un secondo momento che si portabile)
Separazione nelle viste da usare (es: flusso dei dati, flusso di controllo, della sicurezza, ecc. ecc.: fare diagrammi separati)
Aspetti legati al problema e legati all'implementazione (specifiche (il cosa) contro implentazione (il come))
Separazione in parti (modularizzazione: separare le parti. Non affrontare un programma in maniera monolitica, ma suddividerlo in parti)
L4: Il valore dei modelli dipende dalle viste che vengono scelte

UML ha 9 viste

1. Modularità:
   Utile per affrontare un problema (divido problemi complessi in problemi meno complessi: scomposizione top-down)
2. Riutilizzabilità: comporre un problema complesso da moduli esistenti (bottom-up)
3. Capire meglio parti complesse come somma di parti più semplici
4. Più manutenibile: a fronte di una modifica basta che controllo l'unità che lo contiene, non tutto il codice.

Quando la modularità é fatta bene: quando un modulo contiene solo le parti che gli competono.
Coesione (interna): tutto il contenuto del modulo ha un compito comune.
Disaccoppiamento (esterno): un modulo deve avere pochi riferiment esterni.
L 27: Una struttura é stabile se ha una forte coesione un alto disaccoppiamento.

Information hiding (incapsulamento?): L8: Solo ciò che é nascosto può essere cambiato senza rischi.
Astrazione Fornire dei layer che offrono funzionalità senza per forza sapere come vengono implementate

Principi

Rigore
Difficile da definire rigorosamente (affidabilità di un prodotto artistico?)

Formalità
Formalità é il rendere poco possibile interpretazioni sbagliate
La fase di coding é sempre formale, ma bisogna portare la formalità anche nelle altre fasi per avere i seguenti benefici:
correttezza (una cosa formale é più facilmente verificabile)
manutenibilità (ad esempio una documentazione chiara aiuta un nuovo programmatore a capire dovemettere le mani)
riusabilità

Information hiding (incapsulamento?):
L8: Solo ciò che é nascosto può essere cambiato senza rischi.
Astrazione
Fornire dei layer che offrono funzionalità senza per forza sapere come vengono implementate
Anticipazione del cambiamento
I requisiti i un programma sono estremamente mutevoli nel tempo (rieschieste altre funzionalità, ec.)
Bisogna immaginarsi diversi scenari di possibili evoluzioni per premunirsi da possibili
sviluppi.
Generalità
Ovvero non risolvere un problema specifico, ma cercare di risolvere un caso generale che può contenre quello specifico
Incrementalità
Non consegno subito un prodotto completo, ma continuo a proporre nuove release che portano nuove funzionalità.

L2 (di Boehm): Il costo di una modifica dipende da quanto é avanzato il progetto. La maggior parte degli errori avviene nelle prime fasi di un progetto.

Secondo eXtreme Programming invece la difficoltà delle modifiche converge (grazie a delle tecniche che Boehm non aveva)

Primo approccio:
Code & Fix (utente e programmatore coincidono)
Codifica e ripara -> Tutto nella testa del programmatore
Big bang
Nessun feedback durante la fase di programmazione e alla fine consegna: big bang!

Identificare le attività di sviluppo: workflow (cosa fare)
Dividere bene in workflow
Studio di fattibilità: feasibility study
Valuto se é fattibile, che risorse impiegare, ecc. ecc.
Analisi estramente difficile (il committente é sempre impreciso)
(spesso commissionata all'esterno)
Analisi e specifica dei requisiti
Capire cosa vuole il cliente
Identificare i problemi bloccanti (stakeholder)
Quali saranno le funzionalità richieste?
Quali le qualità richieste (robustezza, ecc.)
Possibili output:
Documento contrattuale approvato dal cliente
Manuale utente (o maschere di iterazione)

Ingegneria del software: 28 febbraio 2005

Cos'é l'ingegneria del software:
Disciplina tecnologica e manageriale che riguarda la produzione sistematica e la manutenzione dei prodotti software che vengono sviluppati e modificati entro i tempi e i costi preventivati...

Inizialmente la produzione di software era di tipo artigianale, crescendo lo sviluppo é diventato più complesso ed ha iniziato a necessitare team di sviluppatori e coordinamento tra di essi.
La manutenzione di un software occupa circa il 70% del budget.
Obiettivi:
Rispetto di certe qualità del prodotto finale
Terminologia comune (tra gli informatici)
Lista di riferimento
Dare una definizione (difficile dare una definizione formale e difficile misurarla)

QUALITA'
4 categorie:
Qualità del processo (di solito implica la qualità del prodotto)
Qualità del prodotto
Qualità interne (di solito portano a anche a qualità esterne)
Qualità esterne (apparenza del prodotto)

Affidabilità (processo)
Vengono prodotti gli effetti voluti o con scostamenti "tollerabli"
Esistono definizioni statistiche sulla probabilità di affidabilità.
L'affidabilità NON E' SCONTATA (vedi disclaimer dei contratti software)

Correttezza (processo)
Rispetta le specifiche concordate (fa quello che deve fare).
Le specifiche rispettano i desideri del cliente?
R. Glass Law (L1): Deficienze nella raccolta dei requisiti é la prima ragione di fallimento dei progetti.

Robustezza (prodotto)
Capacità di funzionare anche in casi leggermente diversi da quelli previsti dalle specifiche.
Tolleranza degli errori (fault tollerance).
Innoquità (safety): non faccia danni in qualsiasi caso.

Prestazioni (prodotto)
Calcolo delle prestazioni: tempo di esecuzione e uso di memoria.
Non ci si può affidare esclusivamente alla crescita dell'hardware.
Si possono misurare:
empiricamente: monitor, profiler, analisi della complessità
simulazioni: modelli della teoria delle code
Tempi di risposta accettabili

Usabilità (prodotto)
(essere user friendly)
Capacità di essere usata facilmente dall'utente
Interfaccia intuitiva
Standardizzazione dei metodi di interazione
Importantissimo nel caso di applicazioni web
Nielsen-Norman (L6): L'usabilità é quantificabile
Quantità e tipo di errori che gli utenti compiono, movimenti degli occhi, del mouse, ecc.

Verificabilità (interna del prodotto)
E facile verificare la correttezza del mio prodotto?
Lunghezza media dei moduli, dei nomi, ecc.
Stili nei commenti, ecc.

Verificabilità (interna ed esterna del processo)
O Visibilità
Quanto dell'avanzamento del processo é visibile esternamente?

Manutenibilità (prodotto)
60, 70% dei costi é dopo il rilascio
Sottocategoria: correttiva
(riparabilità): é semplice riparare ad eventuali errori?
Sottocategoria: adattativa e perfettiva (evolvibilità): semplicità di aggiungere nuove parti o di adattarne altre già esistenti.
Nella maggior parte dei casi si modifica solo il codice dimenticandosi di aggiornare anche la documentazione, ecc. ecc.
Lehman's law (L27 e L28): Se un software é usato verranno chiesti dei cambiamenti. Un sistema che evolve aumenta la sua complessità interna (entropia) a meno che non si cerchi di contenerla.

Riusabilità (prodotto)
Riesco a riutilizzare parti del codice scritto?
Incapsulare parte del codice in componenti, classi, librerie riutilizzabili.
Mellroy's law (L15): La riutilizzabili del software aumenta la produttività.

Produttività (processo)
Unità prodotte / sforzo compiuto (potrebbe essere: linee di codice/ore di lavoro o punti funzione/ore di lavoro)
La cosa peggiore per un progetto in ritardo é dargli nuove risorse.

Tempismo (processo)
Rispettare i tempi contrattuali
Ritardi possono compromettere il successo di un prodotto
Difficile per i continui cambi di richieste da parte del cliente durante lo sviluppo
Soluzioni: consegnare e continuare a incrementare le funzionalità

Ingegneria del Software: Presentazione

Il prossimo esame che intendo preparare é ingegneria del software.
Per chi di voi ancora non lo sapesse é possibile vedere le lezioni dell'anno accademico 2004/2005 ONLINE.
L'indirizzo é: http://vc.dsi.unimi.it/?courseid=6
Per il login é necessario un account Silab.

Alcune informazioni del corso (tratte dalla prima lezione: 28-02-2005):

Presentazione del corso
Sito: http://bellettini.usr.dico.unimi.it/~belletc/home/IS2005
email:carlo.bellettini ovviamente at unimi.it
Libri di testo (consigliato solo seguire):
Ghezzi, Jazayeri, Mandrioli - Ingegneria del software
AlbertEndres, Dieter Rombach - A Handbook of Software and Systems Engineering (da cui sono tratte le "leggi" citate)
Forum (iscriversi usando email università): http://sod.usr.dico.unimi.it/forum/

Argomenti:
Modelli di ciclo di vita del software (i processi)
Linguaggi di specifica (automi a stati finiti, reti di Petri)
Progettazione (Object Orientation e UML)
Tecniche di verifica e convalida (tecniche di testing e analisi)
Management (breve)
Esame: orale (ma di circa 1 ora: 1 o 2 domande per argomento)
Compitini: 4 (uno per argomento), domande a risposta multipla

Presentazione

In questo blog
...vorrei raccogliere gli
appunti della mia esperienza alla facoltà triennale di informatica
all'Università Statale di Milano. Consigli, appunti, indici delle lezioni e
quant'altro...

Chi sono io
Mi chiamo Michele Bernardi, sono nato a
Sondrio il 24 marzo 1978. La mia carriera universitaria é iniziata con 3
DISASTROSI anni al politecnico di Milano, facoltà di ingegneria biomedica. Dopo
questi 3 anni mi sono "redento", ho deciso di abbandonare l'università ed ho
iniziato a lavorare come programmatore. 4 anni dopo in preda ad un raptus di
follia mi sono iscritto alla laurea triennale in Informatica all'Università
Statale di Milano... Finalmente illuminato dalla giusta scelta universitaria ho
iniziato a spendere serate e weekend studiando.

Commenti
Ogni commento (purché civile) é ben accetto anzi
fortemente consigliato.

Per contattarmi personalmente (anche se generalmente preferirei tramite blog) il mio indirizzo é questo:

powered by IMHO 1.3