Come sviluppare un software in azienda

Un riassunto del processo che porta allo sviluppo di un software in ambito aziendale.

Il prodotto di questo progetto di tesi consegue un duplice risultato: la produzione di un software, seppur ad uno stato prototipale, ed un’analisi dell’ambito a cui WrenchDb è destinato.

L’analisi e la conoscenza approfondita dei bisogni e delle alternative presenti sul mercato è un passaggio necessario per costruire una solida base per gli sviluppi del progetto, poiché in questo modo ci si assicura che tutti gli sforzi profusi convergano verso un obiettivo ben definito.

La condivisione di obiettivi di lungo periodo corrisponde spesso a una mancanza di prodotti open source, che nascono dall’intuizione e dall’estro del singolo e finiscono per crescere col tempo, modellati sulla base delle necessità del momento, processo che talvolta porta all’estinzione dello stimolo iniziale.

L’approccio analitico e formale adottato in questo progetto, vuole definire con chiarezza gli obiettivi ed i limiti del progetto stesso per garantire che la “mission” rimanga invariata, ma soprattutto vuole certificare la correttezza di tali propositi confrontandosi con il mercato e i suoi principali concorrenti, diretti e non.

Sulla base di queste premesse, trovando un connubio tra la parte tecnica e quella gestionale del progetto, è nato un prototipo che rappresenta una prima materializzazione di questi obiettivi.

Il progetto in sé necessiterà in futuro di altri sforzi prima di diventare esattamente lo strumento ideale identificato nella fase di analisi, ma quanto svolto finora, sia in termini operativi che di analisi, è già molto, perché offre la possibilità di sviluppare un prodotto a “misura di necessità”, ovvero uno strumento pensato e sviluppato per risolvere un problema, libero da vincoli commerciali e da turbamenti estemporanei. Chiaramente per portare avanti il progetto occorrono risorse e impegno non trascurabili e costanti, ma la storia di altri prodotti open-source insegna che quando l’idea è buona e il risultato inizia ad essere valido le risorse aumentano in un circolo virtuoso che porta verso l’affermazione del prodotto. Ritengo quindi che, per quanto occorra essere consapevoli che quanto realizzato è solo un primo passo verso il traguardo, rappresenti tuttavia un ottimo esempio di applicazione pratica delle nozioni teoriche contenute nei primi capitoli.

Di seguito sono riassunti i principali insegnamenti che sono emersi, e che in qualche modo rappresentano l’essenza di questo progetto di tesi.

  • Come si sviluppa un software in ambito aziendale
  • Come lo sviluppo software può beneficiare di strumenti preesistenti
  • Quali requisiti devono essere soddisfatti affinché uno strumento costituisca una soluzione a 360°
  • Quali categorie di software sono presenti sul mercato e in cosa differiscono
  • Quali metodologie sono applicabili nello sviluppo software
  • Quali metodologie sono adottabili per effettuare stime e gestire i progetti in contesto agile
  • Quali sono pro e contro nell’adottare un approccio agile

Come si sviluppa un software in ambito aziendale

Nel Capitolo 1 è stato analizzato il processo di sviluppo che viene seguito per la realizzazione di software all’interno delle aziende. Questo è modellato molto bene dal concetto di SDLC (System Developement Life Cycle) che nella sua semplicità descrive:

  • Come l’applicazione giunge all’ambiente di produzione a partire dall’ambiente dello sviluppatore
  • Come sia possibile implementare e gestire opportuni processi di test (funzionali, con regressione, integrazione) in modo da garantire il funzionamento e adeguati standard di qualità
  • Come sia necessario coinvolgere l’utente finale all’interno del processo e come questo possa influire nel bene e nel male sul risultato finale

Come lo sviluppo software può beneficiare di strumenti

Sempre nel Capitolo 1, si evidenzia il ruolo degli strumenti che possono essere impiegati all’interno dell’ambito preso in considerazione. Tali strumenti, a seconda della tipologia, possono consistere in soluzioni verticali, ovvero essere pensati per uno specifico problema, o soluzioni orizzontali, impiegate per risolvere un ampio ventaglio di problematiche, ma con un impegno più marcato in fase di personalizzazione.

All’interno del settore preso in esame, sono state descritte le tipologie di piattaforma che principalmente vi sono utilizzate e per ciascuna di esse (crm, cms, ecm, scaffolding) sono stati evidenziati i pregi e i limiti.

Particolare attenzione è stata prestata al ruolo che tali strumenti giocano all’interno del flusso SDLC: essi costituiscono un aiuto quando vengono impiegati come componenti per la risoluzione di un problema e non quando sono utilizzati come panacea di tutti i mali. Qualora costituissero il fine e non il mezzo, oltre a perdere di efficacia, diventano un’arma a doppio taglio, in quanto pur di impiegarli si scende a compromessi, rischiando di costruire un ottimo software che però risolve un problema diverso da quello dell’utente finale.

Una volta assodato questo principio, l’adozione di una piattaforma è soggetta ad una serie di valutazioni volte a:

  • Accertare l’utilità dell’impiego della piattaforma,
  • Accertare che i costi sostenuti non siano superiori ai benefici
  • Individuare eventuali incompatibilità con l’infrastruttura preesistente
  • Verificare la presenza di conoscenze e figure tali da gestire in maniera proficua gli strumenti

 

Quali requisiti devono essere soddisfatti affinché uno strumento costituisca una soluzione a 360°

Sulla base delle considerazioni contenute nel Capitolo 1, sono state individuate le caratteristiche principali che uno strumento di supporto allo sviluppo di applicazioni deve avere per essere produttivo ed integrato all’interno delle modalità operative.

Tali requisiti si sono rivelati indispensabili per delineare le caratteristiche del prodotto e per poter avere un termine di paragone con software alternativi.

Quali software sono presenti sul mercato e in cosa differiscono

Attraverso un’analisi del software presente sul mercato, sono stati selezionati i software e framework più significativi, ovvero quelli che sono maggiormente diffusi e che presentano migliore predisposizione a soddisfare i requisiti indicati nella prima parte del Capitolo 2.

La selezione del software è avvenuta in modo da permettere che ci fosse un campione di riferimento per ciascuna delle tipologie di software menzionate nel Capitolo 1, per garantire un’“universalità” di giudizio. Ciascun prodotto nasce da un’idea propria e presenta caratteristiche ben diverse, nonostante appartengano alla stessa tipologia di software. Sono un esempio Liferay e Sharepoint, entrambi ECM, ma con caratteristiche molto diverse. Considerazioni analoghe possono essere fatte sulle piattaforme CMS Joomla, WordPress, Drupal.

Evidenziare queste sfumature e confrontare tra di loro questi prodotti ha permesso di posizionare WrenchDb rispetto alle altre alternative, capendo che la selezione di funzionalità ipotizzata è sufficiente e competitiva nei confronti delle alternative, usate come piattaforma per lo sviluppo di applicazioni web.

Quali metodologie sono applicabili nello sviluppo software

Prima di procedere con gli sviluppi dell’applicazione è stato utile analizzare le ipotesi per quanto riguarda la gestione del progetto. Per vagliare tutte le ipotesi, oltre al tradizionale approccio Waterfall, sono state prese in considerazione le metodologie agili (Crystal, Scrum, Xp) e soprattutto la filosofia che sottende il concetto di Agile.

Quali metodologie sono adottabili per effettuare stime e gestire i progetti in contesto agile

Tra i vari aspetti di gestione, in particolare è stata ritenuta critica la parte di pianificazione delle attività, sia per le risorse carenti (tempo, persone) che per le incognite tecnologiche legate alla costruzione di un framework senza partire da una base preesistente, fatta eccezione per le componenti standard. Per poter affrontare il progetto senza essere colti impreparati, nella fase di analisi sono state studiate le tecniche di stima in contesto agile.

Quali sono pro e contro nell’adottare un approccio Agile

È indubbio che l’approccio Waterfall abbia dei limiti qualora venga impiegato in ambito informatico, costituiti principalmente da:

  • Difficoltà nell’ effettuare un’analisi esaustiva del problema,
  • Difficoltà ad avere a disposizione tutte le informazioni per provarci,
  • Frequente cambiamento di specifiche dovuto a motivazioni non controllabili,
  • Rapporto Informazione/Costi decrescente, come descritto dal cono di incertezza

Tali limiti sono ovviati, almeno in parte, adottando un approccio iterativo e dinamico, detto approccio Agile. Tale filosofia di pensiero si pone l’intento di rendere la modalità di lavoro disponibile al cambiamento, piuttosto che formalizzare obiettivi precisi.

Sotto la categoria delle metodologie agili sono racchiuse diverse tecniche che differiscono nel modo di standardizzare il team e nella modalità di lavoro.

Questi approcci, descritti a volte come la soluzione a tutti i problemi gestionali, in realtà presentano delle difficoltà applicative, dovute principalmente a:

  • Necessità che tutti gli individui partecipanti al il progetto siano consapevoli del vantaggio introdotto da Agile e ne supportino l’adesione;
  • I membri del team di lavoro, in particolar modo i tecnici, devono essere esperti e motivati al fine di condividere l’obiettivo comune;
  • Le emergenze quotidiane, i contratti da rispettare e vincoli legali o burocratici possono interporsi tra la teoria e la pratica.

Al di là di tali limiti, l’adozione di un approccio Agile, magari con una gestione “ibrida” e non troppo formale, permette di ottenere un buon compromesso in termini di efficienza e fattibilità dell’intento.

Tra le attività di gestione in progetti a lunga scadenza, una delle difficoltà principali consiste nel valutare il lavoro svolto, quello rimanente, e prevedere i tempi di realizzazione al fine di pianificare risorse e attività. La prima difficoltà è quella di individuare un’unità di misura omogenea e comprensibile a tutti.

Tra le varie possibilità, gli approcci più rilevanti sono quelli di utilizzare gli “Story Points” e gli “Ideal days”. La prima tipologia consiste nell’attribuire un valore numerico alle attività da svolgere che sia proporzionale alle complessità, mentre il secondo approccio ragiona in termini di giorni ideali ovvero quelli che ci vorrebbero senza distrazioni o alterazioni della stima dovute alle diverse performance di chi si occupa del task.

L’impiego di queste valutazioni consente di stimare la durata delle attività; i modi più diffusi per effettuare una valutazione, indipendentemente dal tipo di “unità di misura” adottata sono:

  • Consulenza dell’esperto,
  • Analogia,
  • Confronto con esperienze passate,
  • Planning poker

Ovviamente nessuna delle tipologie di stima assicura il raggiungimento degli obiettivi nei tempi prefissati, quindi occorre adottare un “Feature Buffer”, ovvero includere nella pianificazione un set di attività secondarie e quindi opzionali, che servono come margine di sicurezza.

A supporto del project manager, strumenti come i diagrammi di Gantt e la Burnt down chart permettono di tenere traccia del lavoro svolto e di quello da svolgere, ma soprattutto di avere degli elementi per certificare la mole di attività svolte e giustificare le scadenze.

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento