Dallo studio di fattibilità alla progettazione e implementazione di un progetto software. Il percorso tipico di un team di sviluppo nel cammino che porta alla realizzazione di un applicativo professionale.

Lo scopo di questa serie di articoli è introdurre il lettore nel processo di sviluppo del software prendendo in esame tutti gli aspetti relativi alla creazione del prodotto finito. Partendo dallo studio di fattibilità , si parlerà  di definizione dello scope di progetto, della prima fase di analisi e macrostima delle tempistiche, della scelta degli strumenti e delle tecnologie da utilizzare, dell‘implementazione, del controllo qualità  e del rilascio di un progetto.

Il percorso da intraprendere

In questa serie di articoli (che non sarà  breve) mostreremo un percorso tipico che intraprende un team di sviluppo durante la creazione di un ipotetico applicativo software: durante questo percorso, oltre alle consuete fasi di studio, progettazione e implementazione, immagineremo di dover anche scegliere fra tecnologie concorrenti (meglio implementare il modello ORM con Hibernate, EJB 3.0 o Spring?) quella che più si adatta alle esigenze del progetto stesso, del team di lavoro e che meglio permette di raggiungere gli obiettivi prefissati.
L‘obiettivo, certamente molto ambizioso, dovrà  sicuramente essere limitato in molti passaggi a una semplice panoramica lasciando molti aspetti in sospeso per dare la possibilità  al lettore di seguire il filo logico intrapreso senza il rischio di intraprendere un cammino senza fine e senza una meta da raggiungere.
Durante questo lungo cammino i vari temi saranno presentati e affrontati anche grazie all‘aiuto di altri autori che daranno il loro contributo in vari settori in cui sono particolarmente esperti.

Il programmatore e le sue api

L‘idea di dar vita a questa serie di articoli è nata giocando con le parole che compongono il titolo della serie e che si prestano a duplice interpretazione: la API (Application Programming Interface) intesa come libreria, componente o genericamente uno strato di software, ma anche le “api”, nel senso di insetto capace di produrre miele così come di causare dolorose punture se posto in situazione di pericolo.
In veste di programmatore e apicoltore amatoriale, ho deciso di unire due passioni (l‘informatica e l‘apicoltura) e di dar vita a questa serie di articoli: molte delle necessità  che andremo a presentare sebbene inventate in gran parte per esigenze editoriali, sono comunque frutto di una attenta analisi della attività  apistica da un punto di vista informatico (e come potrebbe essere altrimenti?).

Da dove cominciare

In questo primo articolo iniziamo con quella che in genere è la primissima fase di formalizzazione di un progetto. Dando per assodato il fatto che il progetto debba essere fatto (saltiamo quindi la fase di project selection e stima di fattibilità ) iniziamo con la definizione di cosa debba fare o non debba fare il nostro progetto: la prima cosa da fare quindi è definire nel modo più preciso possibile gli obiettivi e il confine del progetto (in una parola lo scope, come definito nella letteratura del Project Management), andando a specificare precisamente cosa invece rimarrà  fuori dal progetto.

NOTA: lo “scope” (portata) di progetto, secondo una sintetica definizione tratta dalla teoria del Project Management (PM) consiste nella individuazione degli obiettivi di progetto e dell‘insieme delle attività  che dovranno essere realizzate per raggiungere tale obiettivo.
Riuscire a stilare in modo sintetico, efficace, comunicativo e semplice lo scope di un progetto è una delle attività  più difficili nell‘ambito di tutto il ciclo di vita del progetto, ma è sicuramente una delle fasi più importanti.
La letteratura imputa a una cattiva definizione dello scope del progetto il fallimento di una percentuale molto alta di progetti. Per chi fosse interessato all‘approfondimento dei temi legati al PM e allo scope di progetto, si rimanda ai riferimenti al terminedi quest‘articolo.

Un valido strumento che ci può venire in aiuto è un artefatto molto usato nella disciplina del project management, il Project Initiation Document (PID), del quale diamo in allegato un template standard (scaricabile dal menù in alto a sinistra).

Presentazione del problema

Una delle prime attività  nello sviluppo di un progetto consiste nello svolgere una serie di interviste con l‘esperto di dominio, il cliente, l‘utente o genericamente con una persona in grado di dare le indicazioni di massima su cosa debba fare questo nuovo prodotto software. Nel nostro caso il primo approccio avviene con un apicoltore professionista il quale, pur non avendo specifiche conoscenze informatiche, è in grado di fornirci alcune precise indicazioni sulla natura del progetto.
Al termine della prima fase di analisi di alto livello, emerge fin da subito che il software non sarà  particolarmente complesso, ma che potranno verificarsi difficoltà  di comprensione del dominio applicativo essendo l‘apicoltura una disciplina ignota alla maggioranza dei programmatori (e probabilmente alla maggioranza delle persone comuni).
Dalle varie conversazioni che si svolgono fra l‘apicoltore e i vari “esperti di computer” emergono alcune interessanti informazioni che elenchiamo qui di seguito in modo piuttosto sintetico.

• Il software che si deve sviluppare ha come obiettivo quello di fornire all‘apicoltore hobbistico, al professionista così come all‘azienda apistica, alcuni strumenti per poter svolgere il proprio lavoro, effettuare statistiche sia sulla produzione che sullo stato degli apiari, ottimizzare gli impegni (economici e materiali), controllare lo stato di salute delle varie famiglie di api: il tutto con il fine di massimizzare i guadagni e di salvaguardare la salute delle singole famiglie di api.
• L‘apicoltore potrebbe non avere spiccate conoscenze informatiche, per cui il sistema dovrà  poter essere utilizzato da chiunque possieda un PC e una connessione a Internet (requisito proposto dal team degli “esperti di computer”).
• Il sistema deve poter essere utilizzato nel modo più semplice possibile senza la necessità  di complesse procedure di installazione client side.
• L‘applicativo dovrebbe poter essere utilizzato in un contesto in cui varie funzionalità  (“servizi”, traduciamo noi) possano essere utilizzate coralmente in modo da consentire all‘utente di controllare lo stato del proprio lavoro o di leggere informazioni (meteo, news, calendario scadenze fiscali, eventi stagionali) senza che l‘utente debba aprire molti programmi diversi, ma simulando la navigazione in un portale web.

Dopo la riunione con l‘apicoltore e sulla base di tutte le informazioni più o meno chiare che l‘analista e il project manager riescono a raccogliere, è possibile procedere alla definizione dello scope di progetto che nel frattempo ha un nome: beeLog (“bee” in inglese significa ape, e quindi il nome rappresenta una estensione del concetto di blog ovvero di diario online). Sebbene l‘oggetto finale del lavoro del team di sviluppo sarà  un portale internet, per beeLog intenderemo l‘applicazione centrale del portale (quella pensata espressamente ad uso e consumo dell‘apicoltore) mentre le altre funzionalità  (gestione utenti, calendario, etc.) non faranno parte del progetto beeLog anche se con esso si integreranno.

L‘applicativo ha come scopo quello di fornire alcuni strumenti all‘utente apicoltore per la pianificazione della propria attività , alla gestione del materiale e della produzione e in generale alla possibilità  di veicolare informazioni all‘interno della comunità  degli apicoltori che useranno il sistema.
L‘applicativo verrà  rilasciato sotto forma di applicazione web e offrirà  funzionalità  ad alta usabilità  tipiche del paradigma Web 2.0. Tale applicazione web sarà  inserita in un portale internet che fornirà  anche altri servizi (vedi elenco) che però non sono parte integrante dello sviluppo dell‘applicazione. L‘organizzazione in forma di portale e la sua installazione fanno parte del progetto. Invece non tutti i servizi che dovranno essere forniti nel portale sono parte del progetto in questa versione.
Un efficace metodo di valutazione e di impostazione di una qualsiasi applicazione prevede di considerare tre fattori di misurazione: qualità  dell‘applicazione (da capire cosa significhi “applicazione ben fatta”…), costi (di sviluppo, di manutenzione e di evoluzione) e performance complessive del sistema. Il buon senso dice che in genere non è possibile ottenere contemporaneamente tutti e tre i requisiti e quindi la scelta sull‘aspetto da privilegiare fornisce importanti indicazioni sul progetto e su come debba essere impostato. Spesso sui libri si dà  una rappresentazione grafica che vede i tre parametri di valutazione come tre vettori ortogonoali fra loro (a sottolineare l‘impossibilità  di imbrigliarli tutti) per cui a volte in modo informale si parla del “cubo costo-qualità -performance”. Ecco un esempio

• Costo: il committente (una associazione volontaristica) vuole porsi come obiettivo quello di realizzare uno strumento che sia utile per l‘attività  professionale dell‘apicoltore, ma è conscia del fatto che durante una prima fase sia impossibile disporre di un consistente budget per finanziare il progetto. L‘applicazione sarà  utilizzabile secondo il modello a consumo per cui si prevede la possibilità  di accedere gratuitamente (ma su registrazione) a un set di funzionalità  di livello base per un utente che ricopra il ruolo di apicoltore amatoriale e un set di funzionalità  avanzate (utilizzabili con una forma di abbonamento annuale) pensate per un apicoltore professionista e per l‘azienda. Per questo motivo il progetto deve essere economico (quindi adotta soluzioni e prodotti open source gratuiti).
• Qualità : la natura particolare del cliente e le indicazioni relative al punto precedente impongono una serie di vincoli importanti; dato che il cliente chiede di limitare il costo, il team di sviluppo accetta, a patto che si possa lavorare al progetto senza imposizioni strette sulle scadenze, sulle licenze e su altri vincoli di progetto. Si decide quindi di sviluppare il progetto utilizzando una licenza open source e il lavoro verrà  eseguito da un team di sviluppo che all‘interno dell‘azienda software svolge attività  di ricerca e test di nuove tecnologie. Il progetto beeLog offrirà  quindi l‘opportunità  di valutare e scegliere fra le migliori soluzioni tecnologiche disponibili sul mercato; saranno utilizzati i pattern architetturali più idonei in modo a realizzare una architettura solida ma facilmente smontabile e ricomponibile per l‘inserimento di nuovi moduli. La qualità  è quindi un requisito fondamentale.
• Performance: sulla base delle considerazioni precedenti (costi bassi, test su nuove tecnologie, utenti che usano il prodotto gratuitamente), le prestazioni non sono un obiettivo da perseguire. È comunque necessario il rispetto di livelli minimi di utilizzabilità  del sistema.

Il cubo dei vincoli Costo-Qualità -Performance aiuta molto nel processo di definizione dello scope di progetto e fornisce praticamente la totalità  delle informazioni necessarie. Un altro strumento importante che spesso viene inserito in un documento PID è la tabella delle priorità  di progetto. Eccone un esempio.

Analisi delle funzionalità  del progetto

Al termine della prima chiacchierata informale con il cliente, il successivo lavoro di sintesi ha permesso di isolare le macro funzionalità  o moduli che comporranno l‘applicazione.

• Modulo Community: il sistema deve prevedere una profilazione utente basata su ruoli (dei quali per il momento si individuano il ruolo amministratore, il ruolo apicoltore amatoriale, e il ruolo apicoltore professionista). Il modulo “Community” deve quindi permettere a un utente di registrarsi ma anche di gestire l‘abbonamento annuale o semestrale con il quale l‘apicoltore professionista potrà  accedere alle funzionalità  avanzate del portale. È prevista una modalità  di accesso come amministratore di sistema il quale può controllare/modificare lo stato dell‘abbonamento, modificare lo stato di un utente e svolgere le consuete operazioni di CRUD utente (Create, Read, Update and Delete).
• Modulo beeLog: è il cuore del portale. Tale applicazione consentirà  all‘utente di inserire i dati relativi ai propri apiari (locazione geografica, indicazioni morfologiche del sito, fioriture prevalenti), di inserire i dati relativi e la storia di ogni singola arnia (età  dell‘ape regina, livello di produzione, malattie, resistenza della famiglia alle malattie). Il modulo dovrà  poi fornire una rappresentazione visuale accattivante (il cliente ha detto che “dovrebbe essere come le mappe di Google”) che fornisca indicazioni sui propri apiari e che una parte di tali informazioni siano condivisibili con gli altri utenti. Per esempio si potrebbe pensare che i dati inseriti dal singolo apicoltore relativamente alla diffusione di parassiti o alle varie fioriture (sono queste informazioni molto utili agli apicoltori per ottimizzare il proprio lavoro e salvaguardare la salute delle famiglie di api) possano essere utilizzati per visualizzare mappe (alla Google Maps appunto) con informazioni facilmente visualizzabili.
• Modulo Calendario: il sistema deve poter consentire al singolo utente di inserire date e scadenze di vario tipo in funzione di eventi per i quali vuole tenere traccia (quindi deve poter ricevere notifica per e-mail o sms). Gli eventi personali sono relativi alla propria attività  (segnare la data del prossimo medicamento o della prossima raccolta di miele) e dovranno potersi sommare agli eventi inseriti dalla redazione (per ricordare la prossima scadenza fiscale, i mercatini, le riunioni in associazione). La visualizzazione deve essere classica, in forma di calendario ma deve esserci anche una visualizzazione a lista (per verificare quando una certa operazione è stata fatta nell‘arco dell‘anno precedente) e deve essere possibile fare ricerche.
• Gestione materiale: un semplice sistema che permetta di sapere quanto materiale è di proprietà , le attrezzature disponibili (arnie che si sono liberate per decesso della famiglia possono essere riutilizzare l‘anno successivo, se il decesso non è causato da malattie contagiose). Altre eventuali molto simili.

Il portale dovrà  poi avere i classici forum, wiki, area download di documenti. Il cliente ha chiesto se ci sia la possibilità  di predisporre gli elementi per inserire la possibilità  di interfacciare il sistema centrale tramite dispositivo mobile (PDA, smart phone etc…) nella successiva release del software (sempre che la prima abbia successo).

Infine il portale deve essere in italiano, ma dovrà  poter essere tradotto in modo semplice e con poco lavoro. Alcune delle informazioni che sono state inserite nel documento di progetto sono state sintetizzate sulla base di numerose chiacchierate effettuate dal team di progetto con i vari responsabili della associazione e direttamente con alcuni apicoltori. Questo ha significato per i membri del team (come sempre avviene) farsi una cultura del dominio applicativo e quindi conoscere come opera un apicoltore, quali sono i suoi obiettivi e quali possano essere le differenze fra un apicoltore amatoriale e un professionista. Tutto questo non è riportato in questo articolo per ovvi motivi di spazio. Ne parleremo in forma sintetica nel prossimo articolo.

Organiziamo le idee: mindmap

Dopo aver raccolto un po‘ di informazioni, il team degli analisti insieme con il project manager stila una lista di macro operazioni che dovranno essere organizzate in modo da poter da un lato fare delle stime (si potrebbe ad esempio pensare di adottare una metodologia metrica come quella di Use Case Points, presentata in questo numero di MokaByte [UCP]), dall‘altro serve per iniziare a stilare l‘elenco delle cose da fare e procedere poi a definire il Gantt di progetto.
Uno strumento particolarmente utile in questa fase è il diagramma mindmap (“mappa mentale”) il quale permette di organizzare e di rappresentare in modo efficace le attività  (con la relativa suddivisoine in sottoattività ) da svolgere; nella figura 2 è riportato il diagramma mindmap di progetto.

Figura 2 – Il diagramma di mindmap relativo al progetto del portale di apicoltura. Il grafico non intende fornire alcuna cardinalità  temporale nà© priorità  dei vari task

Sebbene lo sviluppo del progetto, spece nella fase embrionale, debba essere il più possibile un lavoro corale, in questo momento si inizia a specializzare le attività  in carico ai due ruoli maggiormente attivi in questo momento: il PM e il capo progetto (che in questa nostra ipotetica organizzazione dovrà  anche occuparsi della definizione delle macrostime sull‘effort necessario a sviluppare i vari use case) iniziano a lavorare su due aspetti diversi dello stesso problema.
Da un lato il capo progetto, partendo dal diagramma di mindmap, provvede a creare un elenco più o meno raffinato di use cases per poter iniziare la fase di analisi di dettaglio ma soprattutto per poter raffinare le stime sulle attività . Parallelamente il PM trasforma la struttura grossolana del diagramma in una prima versione di alto livello della WBS (Work Breakdown Structure, Struttura Analitica di Progetto); quando riceverà  le stime di massima dal capo progetto, provvederà  a trasformare la semplice lista delle attività  da svolgere (la WBS appunto) in una diagramma temporale con dipendenze, scadenze e vincoli di vario tipo (diagramma di Gantt). Questa seconda fase verrà  analizzata nel prossimo articolo dove mostreremo quali sono i passi successivi per procedere nello sviluppo del progetto.

Conclusioni

In questa prima parte si è parlato di startup del progetto, dalla analisi alla definizione a grana grossa delle attività  da svolgere. Il messaggio che vorrei cercare di far passare in questi primi articoli è che la parte iniziale di un progetto è molto importante e di fatto condizione tutto quello che segue.
Lo scope di progetto e il PID devono essere i due driver tramite i quali sarà  possibile fare le scelte giuste in ogni fase successiva del progetto. Ogni dettaglio di business, architetturale, tecnologico o di metodologia, dovrebbe sempre essere guidato da quanto scritto nel PID.

Riferimenti

[APM] The art of project management
http://www.scottberkun.com/the-book-the-art-of-project-management/

[PM-1] Claudio Bergamini, “Introduzione al Project Management nelle attività  Software”, MokaByte 85, Maggio 2004
https://www.mokabyte.it/2004/05/pm-1.htm

[PM-2] Claudio Bergamini, “Introduzione al Project Management nelle attività  Software”, MokaByte 86, Giugno 2004
https://www.mokabyte.it/2004/06/pm-2.htm

[UCP] “Use Case Points: Stimare le dimensioni di un progetto software”, MokaByte 123, Novembre 2007

[MDI]”Mieli d‘Italia”, sito completo di informazioni per approfondire il tema dell‘apicoltura
http://www.mieliditalia.it/