Superare l'Open Source

Storia del Free Software

La storia del software Open Source, come oggi lo viviamo e conosciamo, è, in termini informatici, una storia antica e affonda le radici in quella parte della cultura visionaria americana che promuove la libertà di azione e di espressione in tutti i campi del sapere umano ([1]) e che ha prodotto nel tempo una pletora di sottoculture e movimenti diffusisi in tutto il mondo. Sin dai primordi dell'informatica moderna, cioè dalla diffusione dei personal computer, i pionieri di questa materia, attraverso le loro visioni, hanno tracciato quello che oggi rappresenta la vita di miliardi di persone sulla Terra. Si pensi che gente come Turing, sin dai primordi pensava all'Intelligenza Artificiale e alle sue future applicazioni. 

Richard Stallman è un visionario. 

Egli è il fautore di software storici e diffusissimi quali per esempio Emacs ([2]). Nel 1983 dà vita al progetto GNU: inizia a sviluppare una serie di tool per il suo sistema operativo GNU (qualcuno dice che GNU significa <<GNU is Not Unix>>). Questi tool verranno poi inclusi nel kernel di un piccolo sistema operativo di uno sconosciuto studente norvegese di nome Torvarld che darà al mondo nel 1991 invece il famosissimo sistema operativo Linux,  oggi uno dei sistemi operativi open/source più usati al mondo (ce ne sono altri: il BSD per esempio o il Minix).

Nel 1985 fonda la Free Software Foundation, un movimento che sostanzialmente promuove l'uso di software libero: libero di essere utilizzato per qualsivoglia scopo, di essere studiato e modificato, copiato, ridistribuito sia nella forma originale che in quella modificata.  Il movimento del Software Libero prende così forza e in dieci anni inizia con la sua forza concettuale dirompente a diffondersi anche negli ambienti non specialistici rompendo gli argini e uscendo dalla nicchia in cui si era rintanato, passando dal mondo dei Nerd (oggi riconvertiti in Geek) al vasto pubblico. Oggi il software libero è utilizzato nelle case di milioni di persone attraverso sistemi operativi Gnu/Linux quali Ubuntu o Fedora oppure nei browser come Firefox. Anche involontariamente quando navighiamo in Internet il sistema che distribuisce le pagine Web è molto probabile sia basato su software Open Source. Tutto questo ha successivamente favorito la pervasione della rete e della cultura di Internet. 

Free Software / Open Source / FLOSS

Quali forme di software libero esistono? Nel corso della storia del software libero non sono mancate polemiche e non è mancata la differenziazione delle idee che ha portato differenti gruppi a creare differenti definizioni di software libero.

In prima istanza c'è il software completamente libero come predicato dalla FSF e da Stallman e che ha portato alla definizione delle licenze GNU/GPL. In questa licenza (oggi alla versione 3) essenzialmente il software prodotto è concesso con la possibilità di copiarlo, modificarlo e ridistribuirlo liberamente a patto che il codice sorgente venga consegnato. In tal modo la proprietà del software è dell'umanità e nessuna azienda privata può copiare il codice e brevettarlo. 

Nel tempo sono state create diverse licenze meno restrittive della GPL come la MIT o addirittura, licenze open source limitanti come le licenze IBM Public License e Microsoft Public License ([3]).

C'è un'altra strada intrapresa che è quella del Freeware (oppure dello Shareware) cioè software con sorgente chiuso ma liberamente copiabile e distribuibile. Tale licenza in tutte le sue derivazioni permette di diffondere il proprio lavoro senza la necessità di distribuire il codice sorgente.

Modelli di business basati su Open Source

Oggi l'Open Source è arrivato ad un modello di maturità tale che molte aziende stanno utilizzando per fare del business. Anzi moltissime startup sono nate e continuamente nascono a seguito di progetti open source. Il modello che ho visto vincente su tali software è quello di avere due prodotti: uno community e l'altro enterprise. la versione community ha meno feature ed è più instabile. L'azienda utilizza il lavoro della community per apportare le necessarie correttive ed evolutive alla versione enterprise che è seguita da un gruppo di sviluppatori stabili. In tal modo la versione community diffonde il nome e attira sviluppatori "gratis". Essa beneficia di idee e feature che poi sono stabilizzate nella versione enterprise.

Alcune altre aziende distribuiscono il codice sorgente e aggiungono servizi di alta qualità anche molto costosi offrendo prestazioni paragonabili a software close source.

Alcune aziende vincenti, secondo la mia opinione, sono:

- Digium che ha generato parecchio business tramite il centralino VOIP Asterisk

- RedHat con la derivazione del sistema operativo Linux

- Alfresco con il suo CMS

- Liferay con il suo famoso portale utilizzato anche da grandi imprese

Esistono poi aziende come Google che utilizzano l'Open Source e ne scrivono parecchio. In [4] si cita che Google ha prodotto circa 14 milioni di linee di codice fra Android e Chrome ed altri prodotti tutti completamente free.

>> La mia Opinione <<

Come è possibile per un'azienda dell' IT conciliare il diritto d'autore sul proprio software e l'uso dello stesso come open source? Come favorire la diffusione di formati aperti, di software libero e nel contempo preservare il lavoro di tanti operatori del settore informatico? Dovremmo porci il problema della futura concorrenza dovuta a modelli di business che potrebbero superare l'attuale logica del software a sorgente chiuso e addirittura la logica in generale del software open source, autoprodotto o su commissione. E' infatti da un po' di tempo che si sente parla di Cloud Computing di Software as a Service (SaaS) e di Platform As a Service (PaaS). Lungi dall'essere ancora paradigmi consolidati, abbiamo però esempi vivissimi di aziende che stanno basando il proprio business sul concetto di nuvola e ormai anche pachidermi come.

Il concetto di Cloud Computing può essere sfruttato da regioni come la Puglia come aggregatore di aziende per creare una  filiera per l'erogazione di servizi nella nuvola creando finalmente quella famosa sinergia produttiva che tanto manca alla nostra Regione.

Per essere concreti quindi:

1) Le aziende devono favorire la diffusione e l'uso dell'open source nelle forme più aperte in quanto permette la costruzione di servizi a valore aggiunto su tali software come è già successo su piattaforme chiuse quali Tibco, SAP, Microsoft.

2) La legge nel breve può  "proteggere" il capitale di conoscenza mediante l'acquisizione di Software Libero e Open Hardware in ambiti nei quali il software è visto come una commodity: sistemi operativi, produttività personale, telefonia, videosorveglianza, ecc. Il Software Libero è ancora una chimera invece in tutte quelle applicazioni che prevedono lo sviluppo di software con forti componenti di know-how acquisito nel tempo. In questo caso non è possibile affidarsi completamente ad aziende con una storia per esempio recente che rischiano di lasciare il mercato (per es. chiudono). In questo caso la Regione deve tutelarsi mediante la garanzia di un software proprietario vendor riconosciuti con roadmap definite.

3) tuttavia la logica del software libero o di alternative simili potrebbero prendere piede nei prossimi anni per cui è necessario definire una strategia di superamento delle logiche della proprietà intellettuale stabilendo una visione a lungo termine che potrà favorire la migrazione verso il cloud computing e la formazione di filiere di servizi ad alto valore aggiunto che aggreghino più realtà del territorio.

  

Alcuni dubbi

Per un ente pubblico qual è il vantaggio di possedere il codice sorgente o avere un freeware? Per esempio possedere il codice sorgente del sistema operativo permette di avere significativi vantaggi sull'uso free dello stesso?

I modelli di business delle aziende basate sulla protezione del capitale intellettuale sono datati? Scompariranno? 

E' possibile proteggere del tutto tali aziende o sperabilmente le piccole? Non si corre il rischio solo di mascherare una realtà purtroppo mutevole facendo in modo che le stesse aziende poi fra qualche anno non siano capaci di competere con i nuovi modelli? Non sarebbe meglio invece investire e incentivare il passaggio del know-how dal prodotto ai Servizi? Cosa propone il modello Cloud? Potrebbe essere quest'ultimo un' evoluzione del Software Libero?

BIBLIOGRAFIA

[1]. Storia della libertà americana. Eric Foner. Donzelli Editore, 2009

[2]. Buona parte della vita di Stallman la si trova su Wikipedia sia in italiano che in inglese o sul suo sito ufficiale

[3]. La Open Source Initiative ha lo scopo di censire tutte le licenze open source esistenti: http://www.opensource.org/

[4]. World's biggest open-source company? Google. http://news.cnet.com/8301-13505_3-10354530-16.html

Social Project Management

Secondo la definizione contenuta nel PMBOK (Project Management Body of Knowledge) rilasciata dal Project Management Institute, PMI, il Project Management è <<...the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements>> [1]. Questa definizione indica il Project Management come quella disciplina che, adottando specifiche conoscenze, capacità, tecniche e strumenti permette di raggiungere gli obiettivi prefissati dal progetto. Possiamo quindi affermare che il Social Project Management è un modo nuovo di intendere il Project Management in quanto mediante l'uso della conoscenza, delle attitudini, delle tecniche e degli strumenti caratteristiche delle reti reti sociali, permette di conseguire i risultati di progetto prefissati. Per rete sociale (social network) si intende un insieme di individui collegati fra loro da specifiche relazioni (amicizia, lavoro, interessi comuni) come definito in [2]. All'interno di un progetto il team è un insieme di persone con una forte relazione, quella del raggiungimento degli obiettivi del progetto, per cui essa rappresenta una rete sociale di tipo temporaneo inserita all'interno della rete sociale più ampia di un'organizzazione o della vita extra-lavorativa.

In base a queste considerazioni è intuitivo pensare che la modalità "sociale" di gestione dei progetti può rappresentare un modo naturale di conduzione del progetto e più legato alla esperienza personale della propria vita reale che ad una imposizione "dall'alto" di attività. E' quindi possibile per il Project Management appropriarsi delle specificità delle reti sociali per ottenere risultati che probabilmente con il classico Project Management non sarebbero raggiungibili. Per esempio in una rete sociale basata su relazioni di amicizia o di stima, la conoscenza non viene nascosta ma esposta e discussa per cui per un membro della rete è più facile accedere alla conoscenza rispetto a quello che potrebbe succedere in un ambiente lavorativo chiuso. Un'altra caratteristica positiva delle reti sociali è il forte riconoscimento e condivisione degli obiettivi, per cui gli appartenenti alla rete posseggono un commitment maggiore e portano avanti le attività in maniera più determinata. In sintesi: 

il Social Project Management, mediante le specifiche potenzialità delle reti sociali si propone di individuare metodi, strumenti e pratiche che possono condurre ad una migliore conduzione dei progetti.

Ma quali sono i concetti specifici delle reti sociali che il Social Project Management sfrutta per raggiungere i propri obiettivi? Facciamo un passo indietro: in un recente libro [3], come anche nel suo blog dedicato a questo tema [4], Stephen Denning scrive come sia necessario reinventare il management mediante la trasposizione di cinque principali caratteristiche che riguardano:

1.       gli obiettivi aziendali

2.       il ruolo dei manager

3.       le modalità di coordinamento

4.       i valori di riferimento

5.       la comunicazione

Il primo "shift" riguarda gli obiettivi aziendali e prevede la transizione dalla semplice vendita del prodotto così com'è alla predisposizione dell'azienda nel deliziare i propri clienti creando il giusto prodotto in base alle loro preferenze, come esempio di questo principio, Denning porta la Apple (delight the customer). La seconda transizione riguarda il passaggio da uno stile di management direttivo, ad uno stile collaborativo in cui il manager non è più un controllore ma un facilitatore (enabler) capace di liberare le energie del team. La terza caratteristica da migrare è la modalità di coordinamento intesa non più come rigida gerarchia dei ruoli ma come autonomia nella produzione allineata di requisiti di prodotto. Il quarto shift è il cambio di focus dal valore che guida le organizzazione e cioè il ritorno economico e la massimizzazione dell'efficienza verso valori dedicati alla innovazione e alla crescita dell'organizzazione sul lungo termine. Infine il quinto passaggio è la modalità di comunicazione che deve passare dalla modalità top-down, che prevede la diffusione di comunicazioni di tipo direttivo, ad una comunicazione "bottom-up" che prevede un colloquio fra entità "alla pari" capaci di perseguire obiettivi comuni, risolvere problemi e generare nuove idee.

Nella diserzione di Denning è evidente il fatto che la comunità dei manager, o almeno una parte ben nutrita, visti anche i tanti libri scritti sull'argomento (si veda [4] per una lista), si sta chiedendo se nuovi paradigmi sono possibili e fra questi le idee di Denning si avvicinano molto al concetto di Social Project Management infatti i punti 2, 3 e 5 parlano proprio della necessità di far emergere dal basso  l'organizzazione del progetto per generare quel valore aggiunto necessario al raggiungimento degli obiettivi di progetto.

Una recente ricerca di Forrester ([5]) conferma quanto scritto da Denning: in essa si afferma che il focus si sta spostando dalle istituzioni alle comunità e che le aziende devono imparare a cogliere questi segni e invece che osteggiare o rallentare il social computing, devono imparare a sfruttarlo a proprio vantaggio. Una delle modalità che io propongo per iniziare questo cambio di paradigma è quello di sfruttare la potenza dei Social Network partendo proprio dai progetti e quindi dal project management. Attraverso il Social Project Management infatti le aziende potranno incominciare a costruire reti sociali e collaborative su piccoli team di progetto che per forza di cose si propagheranno fino a pervadere tutta l'organizzazione, come è successo e sta succedendo per la vita reale con piattaforme quali Facebook e Google+.

Lo scopo di questo post è quello di identificare le caratteristiche salienti del Social Project Management mediante l'analisi delle caratteristiche distintive dei social network del social computing che, almeno secondo alcune definizioni, sono le reti sociali basate su piattaforme informatiche. E' importante analizzare le caratteristiche del social computing in quanto rappresenta il tipo di rete sociale sulla quale si basa il social project management e dalla quale prende tutte le potenzialità. Infine passerò a descrivere le caratteristiche principali che deve possedere una metodologia di Social Project Management. Il post non ha la pretesa di esaurire l’argomento ma anzi, mediante la discussione e l’approfondimento, vuole porre le basi per la costruzione di una metodologia del Social Project Management.

Le Social Network

Il concetto di social network viene introdotto già nel 1954 da Barnes ([6]). Lo studio delle reti sociali attraverso la Social Network Analysis, ha destato e desta particolare interesse in molte aree della scienza per le modalità con cui gli attori delle reti sociali possono interconnettersi e per come tali interazioni possano far emergere strutture ordinate e comportamenti collettivi determinati. L'analisi delle reti sociali (social network analysis) si concentra soprattutto sulle relazioni e per tale motivo ha sviluppato e teorie, modelli e applicazioni basati sulle relazioni che collegano gli attori. Una social network è una rete di attori interdipendenti (detti anche nodi) collegati da una relazione che permette la transizione di un flusso di risorse (materiali o immateriali) fra gli attori stessi. Questa definizione può essere ricavata dagli studi di Wasserman e Faust in [7].

La social network analysis ha lo scopo di studiare le reti sociali primariamente analizzando le relazioni e cercando di individuare pattern di regolarità o proprietà emergenti all'interno delle reti. In tal modo per esempio, tramite l'analisi delle relazioni è possibile effettuare previsioni sull'evoluzione delle reti sociali studiandone le caratteristiche di base. Una delle teorie nate dalla social network analysis è lo Small World Experiment ([14])  ipotizzato da diversi autori ma realizzato da Stanley Milgram negli anni '60, in cui si predice che nella rete sociale "umanità" formata da tutti gli individui della terra e da tutte le possibili relazioni fra essi, il grado massimo di separazione fra due attori qualsiasi è di grado 6 per cui fra me e Barak Obama ci saranno cinque individui sulla terra che, attraverso relazioni di amicizia, affari, ecc., collegheranno me e Obama. Di recente l'esperimento è in fase di realizzazione su un grande network come Facebook.

Social Computing

In questo post per social computing intendo indicare lo studio delle reti sociali basate su sistemi informatici e specificatamente su piattaforme software quali per esempio blog, e-mail, piattaforme di social networking, social bookmarking e così via. L'introduzione di tali software ha amplificato le modalità di relazione presenti nelle reti sociali classiche e ha connesso le persone in modi totalmente nuovi. La diffusioni di piattaforme quali Facebook e Twitter ha inoltre permesso di ampliare il raggio di azione degli attori proprio perché sono sorte nuove modalità di relazionarsi fra individui grazie a tali software. Per tale motivo probabilmente la Social Network Analysis dovrà ampliare le proprie teorie e le proprie tecniche grazie anche al fatto che gli esperimenti possono essere condotti in tempi brevi e con un numero di attori elevato rispetto alle classiche reti sociali.

E' su questo campo  che il Social Project Management può muoversi e svilupparsi per cui è fondamentale pensare a individuare le potenzialità che il social computing può offrire per individuare quali di queste potenzialità possono essere sfruttare dal Social Project Management e in che modo.

Caratteristiche del social computing:

·         Social Awareness. E' la caratteristica principale delle reti sociali che prevede il riconoscimento da parte di un individuo dell'appartenenza ad una rete sociale. Senza tale coscienza la rete non si sviluppa. In particolare l'uso di gruppi e di cause favorisce l'espansione della rete sociale.

·         Ambient awareness. E' l'applicazione della social awareness nel social computing e rappresenta la consapevolezza da parte di un individuo della presenza di un altro individuo attraverso i media digitali. Rappresenta quindi una estensione della physical awareness che si manifesta mediante il linguaggio del corpo, la visione diretta, ecc. Questa nuova consapevolezza la si sperimenta col costante uso dei social media e quindi rappresenta una nuova e moderna forma di consapevolezza.

·   Relazioni. E' l'elemento fondamentale delle reti sociali. Il Social Computing ha moltiplicato la possibilità di allacciare e creare nuovi tipi di relazioni espandendo in maniera enorme l'suo di tali relazioni (es. viral marketing)

·         User Generated Content. Prima dell'avvento delle piattaforme Facebook o MySpace, i contenuti erano aggiornati sul Web da un singolo utente mediante classici processi redazionali. Il flusso informativo era quindi rivolto in una singola direzione e il corso futuro di tale flusso è determinato dalla volontà di uno o pochi utenti. Nel Social Computing, i contenuti sono dinamici e generati da chiunque aderisca alla rete. Non esiste una pre-disposizione dei contenuti ma questi verranno generati di volta in volta tramite conversazioni e post e quindi è difficile prevedere quali saranno i contenuti futuri

·   Emozionale. Sulle reti di amicizia è importante verificare come il fattore emozionale ne guidi l'espansione e la creazione di contenuti. Per esempio la vicinanza degli amici su Facebook o sul proprio spazio permette di condividere con essi problemi familiari  o gestire situazioni critiche ad punto di vista personale. Abbiamo visto nel recente attacco di Oslo come l'attentatore (Breivik) abbia coltivato e alimentato l'odio solo attraverso primariamente attraverso l'uso dei social network e  poi attraverso contatti sociali diretti.

·    Interattiva. Il Social Computing portare un'alta interattività nelle reti sociali. Le applicazioni che girano su Facebook non sono solo chat e post ma soprattutto giochi interattivi o applicazioni di diverso tipo che generano nuovi contenuti anche multimediali e che parecchi giovani preferiscono rispetto per esempio alla televisione, rappresentando quindi uno strumento di intrattenimento in forte crescita.

·   Fiduca. Trust. Le reti sociali e i contenuti sono guidati dalla fiducia riposta nei propri contatti. Maggiore è la fiducia e il grado di relazione dei contatti e maggiore è l’affidabilità che un individuo percepisce sulle informazioni provenienti dai propri contatti piuttosto che da altre sorgenti.

·         Team Distribuiti. Un'altra caratteristica importante del social computing è il fatto che l'elaborazione dell'informazione non è centralizzata ma distribuita sui nodi della rete. Quindi, per esempio, tutti i contenuti su un determinato argomento possono essere distribuiti e aggiornati sui differenti nodi della rete e non centralizzati su uno in particolare.  L'uso delle tecnologie si è quindi trasferito dalla centralizzazione di applicazioni specializzate ad applicazioni distribuite e che forniscono più soluzioni ([11]).

A queste caratteristiche si affiancano una serie di funzionalità che le piattaforme per il social computing possiedono e che contribuiscono alla crescita delle reti stesse facilitando il rinforzo delle relazioni o la formazione di nuove relazioni (si veda [10]) :

·     Meet-up. Capacità della piattaforma di social computing di fornire funzionalità di condivisione e scambio di informazioni mediante videocomunicazione, chat, condivisione del desktop.

·       Mash-up. Capacità della piattaforma di social computing di fornire funzionalità di aggregazione di contenuti e ridistribuzione degli stessi.

·         Tagging. Capacità di marcatura di qualsiasi contenuto o documento.

·         Social Search. Capacità di ricerca attraverso i contenuti dei nodi della rete.

·  Peer ratings. Capacità della piattaforma di marcare con indici di gradimento i contenuti permettendone una valorizzazione.

·       Comments and trackbacks. Possibilità di commentare i contenuti da parte di qualsiasi partecipante alla cerchia di amici o della rete.

·         Voten-driven content. Possibilità di assegnare un voto e un feedback ad un qualsiasi contenuto;

·     Document Sharing. Possibilità di memorizzare, condividere e realizzare documenti e quindi contenuti anche in maniera interativa.

Come possiamo sfruttare queste caratteristiche nel Social Project Management? Quale valore aggiunto possono apportare alla pratica del Project Management? E’ davvero necessario cambiare paradigma? Partiamo da quest’ultima domanda e chiediamoci se in effetti ha senso pensare ad un nuovo paradigma. In un articolo del 2002 Kosela & Howell ([12]) partono da questa domanda e tentano di dimostrare che le attuali teorie e metodologie del Project Management vadano riviste alla luce del numero dell'alto numero di progetti che falliscono o che si discostano significativamente dagli obiettivi (scope, tempi, costi) iniziali. Gli autori criticano l'attuale teoria del Project Management auspicando il diffondersi di nuovi paradigmi e teorie. Essi partono dal presupposto che il Project Management ha attualmente una teoria sottostante individuabile ma per nulla consolidata e lo dimostrano mediante la comparazione con aree di conoscenza simili a quella del Project Management individuando una teoria dei progetti ed una del management. Dopo questa scoperta di una teoria (anzi due) latente ma poco approfondita l'articolo si spinge nel dimostrare, mediante l'analisi empirica dei fallimenti, che pur essendoci una teoria sottostante, il Project Management fallisce costantemente i suoi obiettivi e pertanto va riformato. L'articolo, a mio avviso, non effettua una dimostrazione puramente scientifica e andrebbe basata su un campione maggiormente significativo, è pur vero però che ciò che le pratiche del PMBOK predicano e ciò che invece in fase di esecuzione avviene nei progetti è molto difforme. A cosa è dovuta questa differenza fra la parte di management e la parte di esecuzione di un progetto? Primo: ogni progetto realizza un prodotto/servizio unico, e quindi in fin dei conti ricorda un esperimento scientifico in cui c'è una fase di formulazione delle ipotesi (requirements), una fase di esecuzione dell'esperimento (realizzazione) e una fase di verifica delle ipotesi (test). E' quindi chiaro che ogni progetto non può prevedere con esattezza se gli obiettivi prefissati verranno raggiunti e in che modo, per cui il piano risultante deve necessariamente cambiare e adattarsi alle situazioni. Secondo, il classico project management parte dall'ipotesi che il team di progetto sia organizzato come una catena di montaggio e che ogni task assegnato abbia particolari input derivanti dai task precedenti. L'assegnazione di un task ha delle date di inizio e di completamento. Tale assunzione andrebbe bene se gli agenti che fanno parte del team fossero degli automi con comportamenti deterministici ma ciò non è vero e per tale motivo molti piani devono tener conto della aleatorietà dei comportamenti umani che spesse volte sono guidati da una forte componente emozionale (gelosia e invidia dei colleghi, depressione e situazioni familiari proprie, aspirazioni e passioni, ecc.).

I project manager quindi non solo non possono essere certi in anticipo del quando e come verranno realizzati gli obiettivi ma non posso prevedere neanche con quale modalità esecutiva realizzeranno tali obiettivi per cui citando l'articolo precedente: << All too often, however, only the original plan and scheduling data are ever produced. They continue ro conver the office wall long after they are obsolete and bear little resemblance to ther current progress of the job.>>

Il Social Project management non è un paradigma che vuole sostituire la teoria del Project Management, qualsiasi essa sia, né penso può essere pensato come una metodologia che si adatta a tutti i progetti, ma in essa può essere pensata per occupare, almeno per ora, una nicchia legata a piccoli progetti in cui è preponderante la componente creativa e collaborativa (per esempio l’organizzazione di iniziative o progetti di marketing). Tuttavia è possibile pensare che, utilizzando le teorie dei Social Networks e dell'intelligenza collettiva, in futuro il Social Project Management possa rappresentare una valida alternativa in molte situazioni.

Il Social Project Management considera il progetto è un'impresa collettiva e temporanea che ha lo scopo di realizzare un prodotto o un servizio o un determinato risultato.

Come noterete rispetto alla definizione classica del PMI c'è un passaggio in più (impresa collettiva) e cioè la consapevolezza del progetto come impresa di una rete sociale di persone collegate dal progetto ma che, relazionandosi con l'esterno, si collega e si espande ben oltre i confini del progetto stesso.

Il Social Project Management va oltre il Project  Management riconoscendo il team di progetto come appartenente ad una rete sociale che può essere quella formale del progetto e quella informale e ben più ampia esterna al progetto. Il Social Project Management deve focalizzare l'attenzione sulla costruzione e il rafforzamento delle relazioni fra individui in modo da creare fiducia fra i membri della rete per condividere maggiormente conoscenza ed esperienza e poter realizzare l'oggetto del progetto.

In base a quanto detto fin ora quali sono le caratteristiche del Social Project Management? Questo articolo non può trattare tutte le aree di conoscenza coperte dal PMBOK né è possibile pretendere che il Social Project  sia visto come il paradigma che sostituirà il classico Project Management. Per tale motivo mi limiterò ad elencare le caratteristiche salienti del Social Project Management alla luce delle definizioni del Social Computing. Quella del Social Project Management è un'area parecchio nuova e ancora non esistono delle definizioni universalmente accettate né dei metodi riconosciuti e per tale motivo ben venga qualsiasi discussione su queste tematiche.

• Approccio Bottom up contro approccio top down: processi e metodologie rigide per il controllo e la pianificazione contro costruzione fluida dei processi del team;
• Piano di Comunicazione contro comunicazione in streaming aperta e continua verso tutti; Nel Social Project Management tutta la comunità interna ed esterna al progetto ha visibilità degli eventi del progetto nel momento in cui questi avvengono.
• Project Manager come pianificatore e controllore contro Facilitatore di processi, persone, comunicazione ecc.
• Strumenti e pratiche fornite da software specifico contro uso di piattaforme di Social Computing
• Formal Knowledge contro Tacit Knowledge: la comunità, condividendo gli stessi interessi e costruendo la propria identità sociale di progetto, favorisce la circolazione della conoscenza anche se molta di essa è tacita. In un progetto prevale invece la conoscenza formale e formalizzata e spesse volte questa risulta gelosamente nascosta agli altri membri del team.

Nel Social Project Management il ruolo del Project Manager è quello del coordinatore e del coacher; la sua figura deve favorire l'autonomia degli attori impegnati nelle attività di progetto. Tale ruolo è molto vicino a quello del manager di Blanchard e che emerge  nel libro "The One Minute Manager Meets the Monkey" ([13]) in cui si afferma che il manager deve auspicarsi il passaggio dall'assegnazione dei compiti alla delega dei compiti in cui le attività non sono discusse e gestite rigidamente dal manager ma sono prese in carico dai collaboratori che, attraverso il self-management le portano a termine e conseguono la crescita professionale.

Attenzione a  non considerare il Social Project Management come una mancanza di metodologie e completamente destrutturato, è invece da rimarcare il fatto che il ruolo del Project Manager deve essere quello di facilitare l'emergere di quei processi che portano al raggiungimento degli obiettivi. Il Social Project Management fa uso per esempio di piani e di schedulazioni e anzi queste assumono un ruolo preponderante in quanto rappresentano la guida costante della rete sociale legata al progetto. Possiamo quindi affermare che tutti gli elementi fondanti del Project Management si possono ritrovare nel Social Project Management ma non sono confinati all'interno di documenti o processi ma sono costantemente resi pubblici alla rete sociale che li usa per orientarsi e per organizzarsi attorno ad essi.

Conclusioni

Parecchio lavoro deve essere fatto per rendere il Social Project Management una disciplina consolidata e soprattutto molta sperimentazione da parte dei team di progetto. Il Social Project Management però riconosce da un lato la sempre maggiore complessità dei progetti e delle tecnologie in gioco che portano a riconoscere un limite del classico Project Management in diverse situazioni e dall’altra la necessità di vedere il progetto come un’impresa di una rete sociale che può gestire tale complessità mediante la forza e la potenza delle relazioni e della comunicazione aperta. Il Social Project Management non può prescindere dal Social Computing, cioè dalle tecnologie a supporto delle Social Network.

Le direzioni di questo mio studio saranno due: da un lato cercherò di mettere in relazione le aree di conoscenza del Project Management mostrate nel PMBOK con il Social Project Management, dall’altro cercherò di individuare le caratteristiche di una piattaforma di Social Computing a supporto delle reti social per il Social Project Management.

La speranza è che questo articolo attiri una sana discussione attorno a questo tema e possa aiutare la comunità dei Project Manager nel loro arduo ma stimolante lavoro.

Bibliografia

[1]. PMBOK. Project Management Institute, 2008, ISBN: 978-1-933890-51-7

[2]. Wikipedia, http://en.wikipedia.org/wiki/Social_network

[3]. The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st Century, October 2010, Stephen Denning, ISBN:   0470548681

[4] Stephen Denning Blog, The Leader's Guide to Radical Management

[5]. Forbes. Social Computing:  How Networks Erode Institutional Power - And What To Do About It.

[6]. Barnes, J. (1954). Class and Committees in a Norwegian Island Parish. Human Relations, 7, 39-58

[7]. Social network analysis: methods and applications. Stanley Wasserman, Katherine Faust. Cambridge University Press; 1 edition (November 25, 1994). ISBN: 0521387078

[8]. Una scheda di sintesi della teoria delle social network la si può trovare nel IS Theory database.

[9]. Information System Characteristics and Social Network Software Adoption. Amy Y. Chou, David C. Chou.

[10]. “Social Computing: How Networks Erode Institutional Power – And What To Do About It”. Forrester Research: Technology research and advice. http://www.forrester.com/ResearchThemes/SocialComputing

[11]. Dotsika & Patrick, 2006

[12]. The underlying theory of project management is obsolete. Lauri Koskela & Gregory Howell. Procedings of the PMI Research Conference, 2002, Pg. 293-302.

[13]. The One Minute Manager Meets The Monkey. K. Blanchard, W. Oncken, Hal Burrows.  ISBN: 0-688-10380-4

[14]. Wikipedia. http://en.wikipedia.org/wiki/Small_world_experiment

Un articolo interessante scritto da Stephen Denning è anche il seguente:

[15]. Learning To Herd Cats.  Forbes. http://www.forbes.com/sites/stevedenning/2011/06/07/learning-to-herd-cats/

 In cui viene spiegato in maniera molto sintetica, ma chiara, il paradigma dei 5 shift.

Sulle Difficoltà che un Progetto ICT incontra nelle prima fasi di sviluppo

Oggi mi è capitato di discutere con un collaboratore che sta seguendo un piccolo progetto ma complesso sia dal punto di vista del prodotto da realizzare sia dal numero e tipo di utenti con cui si interfaccia  per la raccolta dei requisiti.

E' emerso che rispetto alla stima iniziale, che prevedeva una serie di funzionalità concordate a priori con il cliente, il progetto ha cambiato direzione aggiungendo nuove funzionalità sempre più complesse al prodotto da realizzare per cui in questo momento ci si trova nella spiacevole situazione di dover mantenere la schedulazione iniziale con un cambiamento di contenuti abbastanza importante.

Abbiamo provato ad analizzare la questione ed è emerso che la stima iniziale ha sottostimato la fase di raccolta dei requisiti e analisi funzionale ovvero rispetto a quanto pianificato in fase di stima queste due attività si sono allungate di molto per due motivi:

1. indisponibilità del cliente ad incontri continuativi e suoi ritardi nell'approvazione dei verbali per cui la fase di raccolta dei requisiti e analisi funzionale è slittata rispetto al piano;
2. durante gli incontri la fantasia dell'utente e del cliente stesso ha spaziato parecchio chiedendo nuove funzionalità anche complesse.

A posteriori quello che mi viene da pensare è che è mancato:

la capacità di negoziare i requisiti

una modalità diversa di gestire i requisiti

Nel primo caso è una capacità personale. Nel secondo caso invece possiamo pensare ad una modalità di lavoro che da un lato catturi le necessità degli utenti ma dall'altro conduca la raccolta eliminando le divagazioni.

Continua...

Un Tool per la Stima del Software: download

In un precedente post ho introdotto le tecniche di stima del software come in Funciont Point o gli Use Case Point (UCP).

Ho sviluppato un foglio excel composto da tre sezioni che andrebbero valutate indipendentemente:

1) una sezione che guida alla stima degli UCP;
2) una sezione che aiuta nella stima del software a livello architetturale
3) una sezione per valutare il team mix di progetto


E' possibile scaricarlo al seguente link: software estimation tool download.

La gestione di progetti con Facebook e pochi altri strumenti

Sarà capitato di dover coordinarsi in fretta e furia per far partire una piccola iniziativa, magari in poco tempo e con la necessità di includere un po' di persone. Quello che succede è un gran perdita di tempo solo per mettersi d'accordo sul daffarsi e magari senza pianificare le attività con il rischio di dimenticare dettagli importanti. Se poi il gruppo di lavoro è distante fisicamente allora le cose si complicano ulteriormente fra telefonate e comunicazioni incrociate. Risultato? L'iniziativa ha successo comunque ma arriviamo stanchi, abbiamo perso parecchio tempo e abbiamo sicuramente dimenticato qualcosa d'importante! Non sto parlando solo di progetti di lavoro ma anche della vita reale: per esempio organizzare una festa, scrivere un libro o un articolo o organizzare un viaggio con degli amici e avere poco tempo e tante cose da fare! Con l'aiuto di Facebook; e di strumenti online è possibile organizzare piccoli progetti utilizzando strumenti online accessibili dai propri dispositivi mobili e completamente gratuiti.

Nella scelta degli strumenti ho considerato le seguenti caratteristiche:

• Uso di strumenti on-line 
• Utilizzabilità degli strumenti su dispositivi mobili 
• Possibilità di condividere l'uso degli strumenti con gli amici  
• Nessun costo 
• Nessuna iscrizione agli strumenti ma utilizzo di un'unica email e password per lavorare

Aggiungere un Gruppo

Ecco i passi: 

1. Creare un gruppo in Facebook 
E' possibile nella pagina principale di Facebook, creare un gruppo Aperto, Chiuso o Segreto. Nel primo caso tutti possono vedere il gruppo, vedere chi c'è nel gruppo e leggere i post; nel secondo caso dall'esterno è possibile solo vedere il gruppo e chi c'è dentro ma non leggere i post; nel terzo caso il gruppo non è visibile se non ai soli membri. C'è poi la possibilità di creare una fan page nel caso si voglia rendere il progetto completamente aperto e ricevere il contributo di tutti gli amici.
Che tipo di gruppo creare dipende dal tipo di progetto: se si deve organizzare una vacanza forse sarebbe bello mostrare a tutti il progetto su Facebook e magari ricevere il contributo di altri che hanno avuto le stesse esperienze oppure mediante il gruppo chiuso nascondere i post e quindi non mostrare le attività del progetto. 

Aggiungere amici al gruppo su Facebook

2. Aggiungere gli amici al gruppo
E' possibile farlo in fase di creazione del gruppo o successivamente come mostra l'immagine che segue.

3. discutere e pianificare la soluzione
Prima di partire è necessario discutere la soluzione e pianificare le attività raccogliendosi attorno ad un tavolo virtuale. Per guidare la discussione è importante concentrarsi sulle seguenti domande: 

• Cosa? Che cosa si vuole dal progetto cioè quali sono gli obiettivi: relax completo? esplorazione? vacanza culinaria?
• Come? Come si intende raggiungere gli obiettivi? Organizzare tour in macchina? Prenotare un villaggio vacanze all inclusive? Fare il tour a piedi o con soli mezzi pubblici?
• Chi? Dopo aver stabilito le cose da fare si decide chi fa cosa e quindi si distribuiscono i compiti
• Quando? Infine si decide entro quanto completare le attività

In attesa dell'attivazione delle video-chiamate all'interno di Facebook è possibile con la versione 5.5 di Skype condividere la lista degli amici e accedere a Facebook da Skype per cui il team di progetto potrà essere sempre connesso e comunicare con pochi click.

Videochiamate con Skype integrate in Facebook. Siamo tutti in attesa dell'uscita!

Per portare avanti il brainstorming invece vi consiglio di utilizzare lo strumento di mind mapping on-line Mindmeister (http://www.mindmeister.com/) che permette di collaborare online costruire il diagramma insieme agli amici. E' possibile schedulare e assegnare i task per cui è lo strumento ideale per partire. Purtroppo non è integrato in Facebook ma è possibile autenticarsi utilizzando la propria google mail senza iscriversi al servizio. 

Brainstorming and planning

Come si nota dall'immagine in alto, MindMeister permette di utilizzare varie icone e colori ma ha anche la possibilità di assegnare dei task. Lo strumento utilizza iCal per pubblicare la lista di attività per cui è possibile importare fra i propri calendari anche quello di Mindmeister  (solo nella versione premium però), in aggiunta invia le e-mail di notifica prima del completamento dell'attività. 

4. Condividere dei documenti
In tre semplici passi abbiamo messo in piedi un progetto. Rimane solo da capire come condividere i documenti in un posto comune. Se non abbiamo dei documenti in locale ma vogliamo crearne di nuovi in maniera collaborativa possiamo utilizzare il servizio Docs.Com che ci permette di creare on-line i documenti Office che ci servono: Doc, Excel e Power Point e vonsividerli con un link su Facebook. E' possibile indicare che tipo di autorizzazioni dare e quindi scegliere fra la visualizzazione totale alla visualizzazione ai gruppi, alla visualizzazione personale.

Creare documenti Office online

Se i nostri documenti non rientrano nella categoria Doc, Excel, Power Point allora è possibile utilizzare il servizio di cloud sharing DivShare che gratuitamente mette a disposizione 5Gb di spazio. Anche con DivShare non è necessario registrarsi ma basta usare il proprio login Fabcebook.

Abbiamo finito! Con quattro semplici passi abbiamo messo in piedi un progetto, condiviso idee e piani e documenti. Non resta che lavorare!

La Stima del Software

Introduzione

Quotidianamente, migliaia di project manager e sviluppatori di tutto il mondo sono alle prese con un rompicapo ben più difficile del Sudoku. Essi sono chiamati da clienti impazienti a fornire una valutazione in termini economici dello sviluppo di una nuova applicazione o della evoluzione di una parte di essa. Generalmente i tempi sono stretti e alla fine il numero partorito viene preso come legge e utilizzato nella catena di autorizzazioni (il capo del capo ecc) come sempre più un numero definitivo.

La realtà dietro a queste azioni è purtroppo fatta di parecchie incertezze e spesse volte quel numero magico non si avvicina nemmeno lontanamente alla realtà. Per esempio dopo aver effettuato la stima il Project Manager si ritrova già con i primi cambiamenti e durante i primi incontri con gli utenti finali si capisce che il sistema da realizzare è csicuramente diverso da quello che si immaginava prima delle stime. 

Nel corso del tempo la "scienza dei calcolatori" ha sviluppato una serie di metodologie di stima dei progetti, che presenterò brevemente in questo post, a dimostrazione dello sforzo di tanti nel dare una struttura a questa arte. Personalmente posso dire che fra tutti i metodi utilizzati preferisco utilizzare quello degli Use Case Points (UCP) a cui ho apportato una modifica che tende a renderlo meno aleatorio e permette di calcolare non solo i giorni/uomo ma anche il costo stimato del progetto. 

Modelli di Stima

E' meglio prima di tutto sottolineare una cosa: la stima è la valutazione più probabile dello sforzo profuso nello sviluppo di un determinato sistema software (tralasciamo i costi per ora). La stima rappresenta quindi un modello e quindi una rappresentazione della realtà che non sarà mai la realtà stessa. La mia conclusione personale è stata quindi quella di prendere in considerazione un modello di stima, quello che più si avvicina alle realtà che gestisco cercando di adattarlo in base ai feedback ricevuti alla fine dei progetti. Lo scopo di questo post non è quello di dare dei consigli in quanto la strada va trovata in base alla propria organizzazione, ma di fornire una carrellata sui metodi più conosciuti cercando di fornire la bibliografia necessaira per poter scegliere da soli. Spero di potervi aiutare.

 

Lines Of Code - LOC ovvero linee di codice

E' stato il primo sforzo per rendere scientifico l'approccio alla misurazione del software e si basa sul computo del numero di linee di codice che compongono il software. Chiaramente è una misura che si può raccogliere solo a prodotto finito oppure utilizzata prima dello sviluppo ma in seguito alla stimo di qualche altro tipo di effort (per es. Function Point).

Cosa dobbiamo includere nel calcolo delle linee di codice? Esistono una serie di indicazioni che il Software Engineering Institute (SEI) ha rilasciato attraverso una cecklist e in cui vengono indicate le parti da conteggiare e quelle da escludere [1]. Il calcolo produce le DLOC (Delivered LOC) che sono le linee di codice utili al dimensionamento del software e quindi al calcolo dell'effort. Computando invece tutte le linee di codice (compresi per es. dichiarazioni e commenti) si ottiene invece il SLOC (Source LOC).

E' possibile convertire le LOC in effort mediante l'applicazione di indici di produttività che però sono legati all'organizzazione che rilascia i progetti per cui, in base alla propria esperienza pregressa potremmo avere, per esempio, un indice di produttività (IP) di 160 DLOC al giorno uomo e quindi calcolare l'effort: Effort (in gg/uu) = DLOC/IP. 
Se non si dispone di indici di produttività si può utilizzare una stima parametrica derivata anch'essa da progetti pregressi di altre organizzazioni e introdotta  da Boehm nel 1981 ([2]). Essa è la Basic COCOMO e si basa sul tipo di organizzazione di progetto:

• Organic Project: progetti con piccoli team, requisiti stabili e tecnologie conosciute, pressione temporale bassa.
• Semi-detached: progetti con team medi, requisiti variabili e pressione temporale anche se non rappresenta un vincolo
• Embedded: grandi team, requisiti sconosciuti o con grande variabilità, forte pressione temporale e la data di rilascio rappresenta un vincolo, ambienti complessi con hardware complesso e tecnologie sconosciute.

Nel Basic COCOMO il calcolo dell'effort è il seguente:

Effort Applied (E) = a * (SLOC)^b [mesi uomo]

Development Time (D) = c * E ^  [mesi]

People required (P) = E / D [persone]

dove:

     c = 2.5 e 

	a	b	d
Organic	2.4	1.05	0.38
Semi-detached	3.0	1.12	0.35
Embedded	3.6	1.20	0.32

Boehm ha successivamente introdotto il modello Intermediate COCOMO che utilizza 15 parametri di stima e il COCOMO II che rappresenta un modello completo di stima sganciato dall'uso delle LOC ma utilizza gli elementi di progettazione del software.

COCOMO II

Il COnstructive COst MOdel II è un modello di stima incrementale che può essere utilizzato nelle diverse fasi del ciclo di vita del software fornendo di volta in volta stime più precise. Le fasi in cui è possibile effettuare la stima sono:

• Applications Composition. E' la stima che interviene durante la fase di prototipizzazione e quindi a monte del progetto.
• Early Design. E' la stima che interviene durante la fase di startup del progetto e prende in considerazione fattori di complessità (o cost drivers) quali il linguaggio da utilizzare, gli skills del tersonale impiegato, la complessità del prodotto ecc.
• Post-architecture. Si utilizza durantye lo sviluppo del progetto o addirittura in fase di manutenzione dello stesso. 

Le ultime due stime impiegano il concetto di Function Point per calcolare gli effort. Per una descrizione dettagliata del modello COCOMOII si rimanda a [3].

Function Points (FP)

Una misura della complessità del software alternativa all'effort è sicuramente quella legata ai Function Points che ha largo seguito in grandi istituzioni a tal punto che esiste un'organizzazione IFPUG - International Function Point User Group - che regola ufficialmente le attività legate ai FP e che pubblica regolarmente il Function Point Counting Practices Manual che rappresenta la metodologia di calcolo ufficiale [4].

Il concetto alla base della Function Point Analysis (FPA) è quello di scomporre il sistema da sviluppare in componenti elementari che possono essere facilmente censite e classificate in diverse tipologie. Il computo di tutti questi mattoncini elementari e la relativa classificazione determina la complessità del singolo componente e quindi del sistema nel suo complesso.  La FPA può essere impiegata nelle prime fasi del progetto per la stima complessiva dello stesso ma ha più efficacia quando si basa sui requisiti e quindi sulla relativa documentazione.

Vediamo quali sono i componenti da individuare nel sistema ma prima di tutto è necessario determinare i confini del sistema da analizzare, per cui è necessario stabilire quali funzioni rientrano nel sistema e quali invece sono erogate da sistemi esterni. Una volta determinato il confine (boundary) si possono identificare i seguenti componenti:

• Data Function
• • ILF. Internal Logical File: raggruppamento logico di dati mantenuto all'interno del confine applicativo che ha lo scopo di memorizzare informazioni a supporto di processi elementari    (es. cliente, utente, fattura, ecc.)
  • EIF. External Interface File: sono strutture logiche di dati provenienti da sistemi esterni.
• Transazionali 
• • EI. External Input. Transazioni elementari necessarie al mantenimento delle strutture logiche legate agli ILF 
  • EO. External Output. Transazioni elementari che fanno fluire informazioni dall'interno del sistema verso l'esterno. 
  • EQ. External Inquiries. Transazioni elementari necessarie a selezionare dati e visualizzarli all'utente finale. I dati possono provenire ed essere aggregati da più ILF e EI

 Ci sono poi dei calcoli accessori da effettuare per ognuna delle caratteristiche precedenti:

• RET. Record Element Type. Sono sottogruppi legati ad un ILF o EIF. Per esempio il dato logico fornitore può avere collegati dei RET indirizzo, telefono, ecc.  
• DET. Data Element Type: sono i tipi di dati elementari utilizzati all'interno di un ILF e EIF  
• FTR. File Type Reference: numero di ILF o EIF legate ad una particolare transazione

Vediamo ora come calcolare il valore in FP della nostra applicazione. Tale valore viene chiamato Unadjusted Function Point (UFP) in quanto non prende in considerazione le caratteristiche generali dell'applicazione. Tali caratteristiche, dette GSC, verranno introdotte successivamente. 

Veniamo al calcolo del UFP: per ognuna delle caratteristiche elencate va calcolata la complessità in termini di bassa, media, alta (Low, Afvg, High) in base al numero di RET e DET e FTR calcolati per ogni caratteristica:

Per ILF e EIF: DETs RETs 1-19 20-50 >50 1 Low Low Avg 2-5 Low Avg High >5 Avg High High

Per EI: DETs FTRs 1-4 5-15 >15 <2 Low Low Avg 2 Low Avg High >2 Avg High High

per EO ed EQ: DETs FTRs 1-5 6-19 >19 <2 Low Low Avg 2-3 Low Avg High >3 Avg High High

Quindi si calcola quante caratteristiche rientrano nelle classi Low, Avg, High e per ognuna di esse vengono calcolati i function point secondo la tabella che segue:

	Complessità			Totale
Source	Low	Avg	High
ILF - Internal Logic File	_ * 7 = _	_ * 10 = _	_ * 15 = _
EIF - External Interface Files	_ * 5 = _	_ * 7 = _	_ * 10 = _
EI - External Inputs	_ * 3 = _	_ * 4 = _	_ * 6 = _
EO - External Output	_ * 4 = _	_ * 5 = _	_ * 7 = _
EQ - External Queries	_ * 3 = _	_ * 4 = _	_ * 6 = _

Quindi per esempio gli ILF di tipo Low valgono ognuno 7 function point, gli ILF di tipo Avg valgono ognuno 19 function point e tutti gli ILF di tipo high valgono ognuno 15 function point. 

La somma totale di tutti i function point per ognuna delle caratteristiche ILF, EIF, EI, EO ed EQ rappresentano, come detto, gli UFP Unadjusted Function Points.

In aggiunta ai precedenti componenti elementari di calcolo la Function Point Analysis considera una serie di fattori di complessità legati in generale al sistema da sviluppare. Sono 14 e precisamente:

• Data communications. Complessità generale, valutata da 0 a 5, del trasferimento delle informazioni: 0 batch processing, 5 applicazione con front-end e diversi protocolli di trasferimento utilizzati
• Distributed Data Processing. Complessità legata alla distribuzione della elaborazione dei dati: 0 nessuna distribuzione, 5 i dati soino raccolti e processati in differenti moduli e/o sistemi esterni
• Performance. Livelli di performance e responsività richiesti al sistema: 0 nessun requisito di performance, 5 i tempi di risposta sono critici e sono richieste attività di performance analysis e impiego di tool di monitoraggio
• Heavily Used Configuration. Grado di dipendenza dal tipo di hardware ad utilizzare: 0 nessuna specificità, 5 allocazione di parti di hardware per specifici moduli dell'applicazione.
• Transaction Rate. Frequenza di esecuzione delle transazioni: 0 bassa, 5 molto alta
• On-line data entry. Quale percentuale di transazioni richiede interazione con l'utente finale: 0 tutto in bacth mode, 5 più del 30% delle transazioni sono interattive
• End-user efficiency. Grado di interattività del sistema. Esiste una tabella con 16 macro-caratteristiche dell'interfaccia utente e viene richiesto di valutare quali e quante di queste 16 caratteristiche sono necessarie al sistema finale. Il valore va da 0 - nessuna - a 5 - sei o più delle caratteristiche. Le sedici caratteristiche sono ad es.: uso di menu, scrolling, help online, pop-up, supporto multilingue, ecc.
• On-line update. Quanti ILF sono gestiti e aggiornati da transazioni interative (on-line): 0 nessuno, 5 la maggioranza degli ILF e in aggiounta si richiedono politiche di recovery automatico dei dati.
• Complex processing. Gradi di complessità dei calcoli matematici richiesti all'applicazione. Anche qui viene fornita una tabella con cinque modalità di calcolo e si computa quante di queste modalità sono utilizzate: 0 nessuna, 5 tutte.
• Riusabilità. Grado di riusabilità del codice: 0 nessuna riusabilità, 5 l'applicazione è esplicitamente sviluppata per essere riutilizzata in altri contesti.
• Installation ease. Grado di complessità della installazione: 0 nessuna richiesta particolare, 5 l'installazione è richiesta; ci sono particolari requisiti da verificare e testare.
• Operational ease. Grado di complessità richiesto per la manutenzione applicativa (back-up, start-up applicativo e riavvio dei sistemi, procedure di recovery ecc.): 0 nessuna specifica attività, 5 tutto automatizzato
• Multiple sites. Grado di distribuzione dell'applicazione: 0 stand-alone, 5 applicazione distribuita e utilizzata da più utenti di più organizzazioni, richiesta installazione su più ambienti e hardware.
• Facilitate change. L'applicazione deve essere sviluppata per facilitare il cambiamento? Si utilizza una tabella di cinque caratteristiche richieste per la gestione del cambiamento. 0 indica nessuna delle caratteristiche, 5 tutte

Al termine della valutazione delle caratteristiche precedenti può essere calcolato il valore aggiunto (VAF - Value) richiesto dall'applicazione nel seguente modo:

VAF = 0.65 + somma(caratteristiche)/100

Infine il valore finale in function point del nostro sistema si calcola come

 FP = UAF * VAF

Sintetizziamo i passi per calcolare i FP:

1. Determinare tutti gli ILF, EIF, EO, EI, EQ
2. Determinare tutti RET, DET e FTR
3. Associare RET, DET e FTR alle caratteristiche del punto 1
4. Calcolare, in base alle tabelle precedenti, il livello di complessità di ogni ILF, EIF, EO, EI ed EQ nei termini Low, Avg, High
5. Calcolare gli UFP sommando tutti i valori ottenuti secondo la tabella di conversione complessità/function point
6. Calcolare il VAF
7. Calcolare i function point FP = UFP * VAF

Ottenuto il valore dei FP, si deve procedere con il calcolo dell'effort mediante l'applicazione di un indice di produttività. Ad oggi esistono una serie di  tabelle computate in base a dati storici che mostrano i valori delle ore/uomo necessarie a sviluppare un Function Point. Esiste un database generale di progetti ed effort mantenuto dal ISBSG (www.isbsg.org) ma in genere possiamo considerare per i progetti Java un indice di produttività pari a 0.9 FP al giorno/uomo per progetti medio/piccoli (max 350 FP) fino a 0.5 F/P per progetti grandi (>2000 FP).

Use Case Points

Un metodo di stima alternativa ai Function Point è basato sulla analisi dei casi d'uso del sistema che sono utilizzati principalmente dalla metodologia RUP (Rational Unified Process). Il metodo deriva da un lavoro del 1997 da parte di Gustav Karner ([5])  e prevede essenzialmente il computo e la classificazione degli attori del sistema e dei relativi casi d'uso mediati attraverso una serie di fattori che rappresentano gli elementi "ambientali" che influenzano il progetto di sviluppo. 

Il primo passo è quello di calcolare gli Unadjusted Use Case Point, UUCP: si parte con il censire e valutare la complessità gli attori del sistema e degli use case secondo le tabelle che seguono:

Complessità Definizione Peso SIMPLE Un attore ha complessità SIMPLE se rappresenta un altro sistema esterno e la comunicazione avviene attraverso l'uso di librerie o API (Application Programming Interface) 1 AVERAGE Un attore è AVERAGE se interagisce con mediante: 1. un protocollo di comunicazione  2. terminale di linea. 2 COMPLEX Un attore è COMPLEX se interagisce con il sistema mediante interfaccia grafica. 3  Attori Complessità Definizione SIMPLE Uno use case è SIMPLE se attiva al massimo 3 transazioni e può essere realizzato con meno di 5 oggetti di analisi. AVERAGE Uno use case è AVERAGE se attiva dalle 3 alle     7 transazioni ed è possibile realizzarlo usando dai 5 ai 10 oggetti di analisi. COMPLEX Uno use case è COMPLEX se utilizza più di 10 transazioni e deve essere realizzato von più di 10 oggetti di analisi. Use Case

UUCP si ottiene sommando per ogni attore e ogni use case il peso ottenuto:

UUCP = somma(Ni*Wi)

Dopo il calcolo degli UUCP si devono valutare i fattori che influenzano il progetto di sviluppo e precisamente i TCF, Technical Complexity Factor, e gli EF, Environmental Factor. I TCF rappresentano i fattori tecnici che possono influenzare lo sviluppo del sistema, essi sono 13 e hanno pesi definiti e precisamente:

Fi	Fattori Tecnici di Complessità	Wi
F 1	Distributed systems.	2
F 2	Application performance objec­tives, in either response or throughput.	1
F 3	End user efficiency (on-line).	1
F 4	Complex internal processing.	1
F 5	Reusability, the code must be able to reuse in other applications.	1
F 6	Installation ease.	0.5
F 7	Operational ease, usability.	0.5
F 8	Portability.	2
F 9	Changeability.	1
F 10	Concurrency.	1
F 11	Special security features.	1
F 12	Provide direct access for third par­ties	1
F 13	Special user training facilities	1

Ad essi si assegna un valore da 0 a 5: 0 nessuna influenza o importanza, 5 massima influenza (o importanza) sul progetto.

il TCF si calcola nel seguente modo:  

TCF = 0.6 + somma(Fi*Wi)/100

Gli Environmental Factor (EF)  aiutano a calcolare l'efficienza del progetto e considera le seguenti caratteristiche: 

F j	Fattori che contribuiscono alla  efficienza del progetto	Pesi
F  1	Familiar with Objectory (*)	1.5
F  2	Part time workers	-1
F  3	Analyst capability	0.5
F  4	Application experience	0.5
F  5	Object oriented experience	1
F  6	Motivation	1
F  7	Difficult programming language	-1
F  8	Stable requirements	2

(*) Siccome il contesto in cui è possibile applicare gli use case è più ampio rispetto all'uso della metodologia Objectory, è possibile sostituire il fattore F1 con "Familiarità con la metodologia adottata".

EF = 1,4-0,03 * somma (Wi * Fj) 
 
Dove per gli Fj possiamo assegnare valori da 0 a 5: 0 irrilevante, essenziale 5
Infine possiamo calcolare il valore di UCP come segue:
 

UCP = UUCP * TCF * EF.

 

Nel suo articolo originale Kerner effettua una valutazione dell'effort necessario a sviluppare uno UCP, mediante l'analisi di tre progetti differenti ottenendo un range che va da 20 ore uomo a 28 ore uomo per lo sviluppo di uno UCP. In un lavoro successivo Ribu ([6]) riporta che il range dell'effort può variare da 15 a 30 ore per UCP mentre Shneider e Winters propongono di adottare l'applicazione parametrica dell'effort contandpo il numero di caratteristiche superiori al valore 3 e applicare il valore 20 o 28 (v. [7]). Il consiglio, come anche per i Function Point è di dotarsi di dati storici per la propria azienda in quanto ogni team di sviluppo e ogni azienda avrà i suoi indici di produttività per cui solo nel tempo, mediante l'analisi a posteriori dell'effort impiegato si potranno ottenere i valori corretti di quel team o azienda. Per iniziare è possibile applicare la regola di Shnider per cui si può utilizzare il valore 20 per progetti semplici e il valore 28 per progetti molto complessi.


Aggiornamento: ho creato un tool per la gestione delle stime che è possibile scaricare a questo link: download tool per la stima software

 

BIBLIOGRAFIA

Molte di queste informazioni sono state tratte dal buon libro di Shivprasad  sulla stima del software: "How to Prepare Software Quotation" , Draft 1.0. http://k.1asphost.com/UseCasePoints/UseCasePoints.pdf
 
Per i modelli COCOMO vedere:
[1].http://greenbay.usc.edu/csci577/fall2005/projects/team23/LCA/Team23_COCOMOII-SourceLinesOfCodeDefinitionsV1.0.pdf

[2]. Software engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981. Barry Boehm. 

[3]. COCOMO II Model Definition Manual. Jongmoon Baik. http://www.dicyt.gub.uy/pdt/files/6.2.1_-_cocomo_model.pdf

Function Point
[4]. Function Point Counting Practices Manual.  The International Function Point User Group

[5]. Karner Gustav.  Resource Estimation for Objectory Projects. 1993.


UCP

[6]. Ribu, Kirsten. 2001. Estimating Object-Oriented Software Projects with Use Cases.  Master of Science Thesis, University of Oslo, Department of Informatics. 

[7]. Schneider, Geri and Jason P. Winters. 1998. Applying Use Cases: A Practical Guide.  Addison Wesley.

[8]. Una sintesi eccellente della UCP si trovano in "Stima Con i Punti Use Case", Mike Cohn. 

[9]. Un articolo e una discussione sulla produttività delle UCP è l'articolo di Gianfranco Lanza "Function Point: come trasformarli nello sforzo Questo è il problema?"