Ingegneria del software: gestione progetti, stima tempi e riutilizzo

IL PROJECT MANAGMENT

Il manager di un progetto ha la responsabilità globale del suo successo. Tra tutte le sue responsabilità ci sono:

• Analizzare e controllare i rischi
• Relazionarsi con il cliente
• Definire le linee di comunicazione tra le diverse squadre e con il cliente
• Assicurarsi che le persone scelte per lavorare al progetto sia adatte e abbiano il giusto training
• Produrre un piano di lavoro che include la specifica dei tempi, una stima dei costi e la pianificazione del controllo qualità
• Assegnare le attività alle squadre
• Misurare i progressi
• Fare in modo che i progressi avvengano nei tempi stabiliti
• Verificare il rispetto degli obblighi contrattuali
• Verificare che il progetto implementi le migliorie suggerite da esperienze precedenti

Ovviamente il manager spesso delega alcuni di questi compiti, a volte anche tutti, ad altre persone.

STIMA DEI TEMPI DI UN PROGETTO

Gran parte dei progetti di grandi dimensioni richiede più tempo di quello stabilito. Tra le ragioni di questa problematica si hanno:

• Stime troppo ottimistiche
• Scadenze del progetto definite molto tempo prima di aver compreso i requisiti
• Requisiti non statici
• Grande pressione da parte del cliente per ridurre al minimo i tempi

Uno dei compiti più difficili del manager è quello di difendere le proprie stime temporali quando non sono conformi a quelle richieste dal cliente.

RIUTILIZZO DEL SOFTWARE

Parte della responsabilità del manager consiste nel mettere in condizione gli sviluppatori di sfruttare al meglio i componenti disponibili. È quindi davvero necessario che le squadre comunichino in modo efficace per identificare il prima possibile le parti comuni. Il processo di sviluppo deve essere centrato sull'architettura, questo richiede quindi che ci sia un unico architetto, per mantenere la coerenza dell'architettura. Non è necessario che il manager sia l'architetto, ma si deve assumere la responsabilità di delinearne un membro come tale, e il team deve accettare questa decisione.

GESTIONE DELLE PERSONE

Solitamente ogni dipendente ha un manager personale, che può coincidere con il manager del progetto, oppure no. Il manager di progetto cambia di volta in volta mentre con il manager personale si instaura un rapporto di lunga durata. Il lavoro del manager personale consiste nell'assicurare che la carriera del dipendente faccia progressi. Talvolta si usa il termine matrix managment per indicare quando una persona gestisce il progetto e una diversa gestisce i dipendenti. La ragione principale di questa divisione sta nell'evitare il conflitto di interessi. Ovviamente in una realtà in cui coesistono due manager vanno definite le responsabilità per evitare confusioni e conflitti.

LAVORO DI SQUADRA

Per favorire il successo di una squadra è necessario che i membri abbiano le seguenti qualità:

• Un insieme ricco e bilanciato di caratteristiche personali
• Un insieme di capacità appropriato al compito che devono svolgere
• Devono andare d'accordo
• Devono far parte di un'organizzazione più grande che soddisfi le richieste dei dipendenti.

Le squadre sono formate da un numero compreso tra tre ed otto persone. Ogni team deve avere un compito ben definito. Può essere presente un team manager o un membro a capo del team per la completa durata del progetto. Se il progetto è molto grande può formarsi una gerarchia, con il rischio però che la comunicazione diventi molto ardua. Per ovviare a questi problemi si posso attuare due diversi approcci:

• Definire percorsi predeterminati per tutte le comunicazioni tra squadre differenti
• I canali di comunicazione restano sempre aperti a tutti

LEADERSHIP

Le nozioni di leadership e managment sono spesso confuse, seppur le loro funzioni siano profondamente diverse. La differenza sostanziale sta nel fatto che un manager appiana mentre un leader scuote. Un leader conosce la direzione verso cui procedere. I leader possono concentrarsi sugli obbiettivi più importanti a un tale livello da perdere di vista completamente i problemi collaterali, ovviamente questa caratteristica può essere sia positiva che negativa.Un'altra differenza sostanziale tra manager e leader sta nel fatto che le capacità da manager possono essere apprese, almeno fino ad un certo punto, mentre non è chiaro se le capacità da leader possano essere imparate, inoltre non è essenziale che la leadership provenga sempre dalla stessa persona, e questo rende possibile che la leadership si in qualche modo distribuita all'interno della stessa attività. Molte persone sostengono che sarebbe opportuno che la leadership si manifesti spontaneamente Il managment non può essere distribuito.

CONTROLLO QUALITA'

Il controllo qualità è il processo in cui:

• Ci si convince e si convince il cliente che il prodotto consegnato abbia un alto livello di qualità
• Si propongono le basi per un continuo miglioramento.

Per fare questo è necessario osservare e migliorare costantemente il processo di sviluppo del software, solitamente le aziende utilizzano un sistema di gestione della qualità (QMS - Quality Managment System). Il QMS potrebbe richiedere che ogni progetto abbia un piano di qualità con contenuti ben definiti. Il piano di qualità normalmente fa parte della pianificazione globale del progetto e prescrive alcuni aspetti del suo svolgimento. Un QMS include la specifica delle verifiche di qualità eseguite dall'organizzazione per assicurare che il piano di qualità sia rispettato. Un modo alternativo di interpretare il controllo della qualità si ha con il Total Quality Managment (TQM) che si basa sul fatto che la qualità di un prodotto sia influenzata più fortemente dall'impegno delle persone coinvolte, e il suo concetto base è che contribuire al processo, proponendo migliorie, faccia parte del lavoro di tutti i giorni, e quindi prevede anche di migliorare costantemente le qualità delle persone per soddisfare al meglio le necessità dei progetti su cui lavorano. Ecco però alcune argomentazioni contrarie alle registrazioni di qualità formali:

• I costi superano i benefici
• La documentazione lo rende poco flessibile
• Le persone possono essere spinte a non pensare
• Demoralizza i migliori sviluppatori, per i quali scrivere documentazioni e andare alle riunioni è meno interessante che sviluppare software.
• Il controllo eccessivo inibisce l'innovazione, in quanto, prima di fare qualcosa di diverso, va necessariamente inserito nel piano di qualità e va opportunamente approvato.

IL SOFTWARE COME PRODOTTO

Il software presenta una serie di caratteristiche che bisogna sempre tenere in considerazione quando si opera con esso:

• Preminenza del design: la produzione del software è un attività prevalentemente progettuale
• Malleabilità
• Manutenzione correttiva e adattiva
• Qualità interna ed esterna

RAPPORTI TRA COMMITTENTE E SVILUPPATORE

Il rapporto tra committente e sviluppatore può assumere quattro tipologie fondamentali:

• Autoconsumo (lo sviluppatore coincide con il committente)
• Sviluppo interno (sviluppatore e committente sono due entità organizzative distinte della stessa azienda, quindi la proprietà intellettuale non passa di mano)
• Sviluppo su commessa (lo sviluppatore è una software house che sviluppa un'applicazione custom per un singolo cliente che può pagare interamente i costi di sviluppo diventando il titolare di tutti i diritti sul software o pagarne in parte lasciando alcuni diritti allo sviluppatore)
• Software shrink-wrapped (lo sviluppatore è una software house che sviluppa un'applicazione da inserire sul mercato del largo consumo, in questo caso lo sviluppatore mantiene tutti i diritti del suo prodotto software e si limita a concedere all'acquirente una licenza d'uso.

IL MESE UOMO

Il mese uomo costituisce l'unità fondamentale del lavoro in ingegneria del software ed esprime lo sforzo compiuto da una singola persona in un mede si lavoro. Spesso viene sottointesa un ipotesi di linearità, mentre questa è giustificata solo in piccoli intervalli di tempo. Infatti, quando si assegnano troppe risorse ad un singolo compito il tempo necessario per completarlo tende a aumentare invece che a decrescere. Un andamento ideale della curva dei mesi uomo vorrebbe che all'aumentare delle risorse il tempo di realizzazione diminuisca, ma nella curva reale si può notare il contrario.

PIANIFICAZIONE DELLE RISORSE

Il tempo di rilascio di un prodotto è descrivibile con una formula. En = (D/N*S) + N * (P + M*(N-1)) Nella quale:

• En rappresenta il tempo di rilascio in ore con N programmatori con eguale produttività considerata costante nel tempo
• D la dimensione totale del lavoro espressa in righe di codice, D/N la dimensione del compito da affidare in parallelo a ciascun programmatore
• S la produttività oraria del singolo programmatore espressa in istruzioni all'ora
• P l'overhead totale in ore del singolo programmatore dovuto alla pianificazione del suo lavoro
• M*(N-1) l'overhead totale in ore del singolo programmatore dovuto alla sincronizzazione con gli altri programmatori

COSTO DEL SOFTWARE

La determinazione del costo di un software è un problema molto complesso. In generale i modelli di costo del software, come il notissimo CoCoMo, si basano sulla distinzione dei costi diretti e dei fattori di costo indiretti. I principali costi diretti sono:

• Personale tecnico
• Personale di supporto
• Risorse informatiche
• Materiali di consumo
• Costi generali di struttura

I fattori di costo indiretti sono:

• Mancato profitto, dovuto all'indisponibilità delle applicazioni
• Backlog nell'attività dei programmatori

Il costo del software dipende da alcuni elementi di contesto, si distingue tra applicativi scientifici de EDP, programmi di utilità (compilatori e middleware) e applicazioni di sistema (DBMS e sistemi operativi) Poi vengono un certo numero di fattori organizzativi o dimensionali:

• Numero di istruzioni
• Competenze per programmatori
• Complessità del programma
• Stabilità dei requisiti

Uno dei fattori più importanti per la determinazione del costo è la sua dimensione, per la quale si distinguono due tipi di metriche:

• Metriche dimensionali che si basano sul numero di istruzioni del programma
• Metriche funzionali che si basano sulle caratteristiche funzionali del programma

METRICHE DIMENSIONALI

Le metriche dimensionali si basano su una misura diretta del numero di linee di codice del programma in esame. Questa misura si ottiene sottraendo dal numero totale di righe quelle relative ai commenti e a eventuali componenti riutilizzati senza modifiche. Per indicare la dimensione di un programma secondo questa metrica si utilizzano le sigle LOC E SLOC:

• LOC sta per lines of code
• SLOC sta per source lines of code

In base a questa definizione e ad altri parametri come M numero di mesi, E numero totale di errori, C costo totale e PD pagine di documentazione si possono definire diversi indici dimensionali:

• Produttività -> P = LOC/M
• Qualità -> Q = E/LOC
• Costo Unitario -> C = $/LOC
• Livello di documentazione -> D = PD/LOC

METRICHE FUNZIONALI

Le metriche funzionali ricavano un indice della complessità attraverso la misura indiretta delle funzioni che questo deve svolgere. Uno dei metodi più utilizzati è quello dei function point, o punti di funzione. Molti progetti di ricerca negli ultimi 20 anni hanno provato a calcolare la relazione tra metriche dimensionali e metriche funzionali. In particolare il rapporto LOC/FP è pari a 110 nel Cobol, a 65 nel fortran e a 25 nei linguaggi di programmazione di quarta generazione. Quando si usano linguaggi ad oggetti, invece dei function point si utilizzano gli object point, il quale numero in un progetto è valutato sulla base del numero di schermi separati che sono visualizzati, del numero di rapporti prodotti dal sistema e del numero di moduli di programma che devono essere sviluppati. Gli object point sono più facili da valutare partendo dalle specifiche rispetto ai function point, possono quindi essere valutati anche all'inizio del processo di sviluppo, quando è ancora molto difficile valutare il numero di linee di codice necessarie per realizzare un software.