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.