Fasi di vita dello sviluppo software

Le fasi di vita del software all'interno del processo SDLC

Il SDLC definisce le fasi che sono necessarie per la produzione del software:

  • Pianificazione
  • Analisi
  • Progettazione
  • Implementazione

Pianificazione

Comprende la valutazione del problema, la raccolta di informazioni, lo studio di fattibilità e l’approvazione. Questa fase include anche una stima dei tempi delle attività; tali stime possono basarsi su particolari metodologie (es. Waterfall) o derivare da metodi puramente empirici. Indipendentemente dal metodo adottato è necessario procedere ad effettuare l’analisi del problema, che può essere più o meno approfondita a seconda della complessità del problema e dell’approccio utilizzato. In questa fase l’obiettivo principale è quello di condurre un’analisi preliminare, proporre soluzioni alternative, descrivere i costi e benefici e presentare una soluzione valida. Prima di tutto è necessario definire gli obiettivi del software a partire dalla comprensione delle necessità; di particolare importanza è capire la natura e la portata del problema in esame. Anche se un problema si riferisce solo a un piccolo segmento dell’azienda, è importante capirne la rilevanza nel contesto complessivo, le ripercussioni dell’introduzione di nuove logiche di business e individuare con quali interlocutori relazionarsi. Generalmente il committente ha già analizzato la situazione prima di arrivare a chiedere lo sviluppo di un software presentando un problema; tale formulazione è spesso viziata da una visone parziale delle infrastrutture, da conoscenze tecniche carenti e da una visione problema-centrica della situazione. Di conseguenza, in questa fase, è doveroso proporre soluzioni alternative:

 

  • Verificando che quanto chiesto segua la direzione aziendale,
  • Verificando che non esistano già in azienda strumenti adatti alla risoluzione del problema, o simili,
  • Verificando che non esistano già strumenti commerciali che si occupano di determinate problematiche,
  • Tenendo presente tutti gli aspetti di lungo periodo che sono spesso ignorati a favore di un compromesso immediato,
  • Contattando dipendenti del reparto committente o consulenti esterni per validare le motivazioni della richiesta,
  • Studiando le soluzioni adottate dagli altri (concorrenti, altre aziende in generale).

 

Ciascuna ipotesi viene valutata in termini di costi e benefici, dove ovviamente si convertono in termini monetari anche fattori non strettamente tali, come affidabilità, manutenibilità, tempi di apprendimento, possibilità di impiego delle risorse interne etc.. L’output di questo processo decisionale sarà una delle seguenti opzioni:

 

  • Lasciare il sistema come è,
  • Modificare un software esistente (nuove funzionalità, correzioni all’esistente),
  • Sviluppare un nuovo sistema.

 

La fase di analisi preliminare affronta le problematiche relative alle necessità o opportunità che possono essere poste dai vai interlocutori. La comprensione del problema e l’individuazione delle componenti della soluzione, porta alla determinazione dei costi, dei benefici, dei requisiti delle risorse e dei bisogni dell’utente specifico richiesti per il completamento. Il processo di sviluppo è soggetto all’approvazione della direzione che ne giudicherà lo studio di fattibilità.

 

Di seguito sono riportati diversi ambiti dello studio di fattibilità:

 

  • Fattibilità operativa
  • Fattibilità economica
  • Fattibilità tecnica
  • Fattibilità di fattori umani
  • Fattibilità giuridico/politica

 

Progettazione

Durante questa fase si formalizzano le specifiche di progetto, il cui dettaglio varia fortemente a seconda della tipologia di applicazione e della complessità del progetto stesso. Ad esempio, se l’applicazione ha un contesto B2C (Business To Consumer, ovvero l’ambito di relazioni che un’impresa commerciale detiene direttamente con i suoi clienti per le attività di vendita e/o di assistenza) si darà importanza ad aspetti quali layout, grafica e usabilità, mentre in contesti B2B (Business To Business, ovvero l’ambito di relazioni che un’impresa commerciale detiene  con altre imprese) o Intranet saranno trascurati. Inoltre si approfondiscono gli aspetti tecnici per dare al progetto un’architettura di riferimento. A seconda del livello di complessità del progetto e dell’organizzazione aziendale, lo studio può includere hierarchy diagram, layout diagram, business process diagram, pseudo-codice e un diagramma entità-relazione. Questi elementi di design sono necessari per descrivere il sistema in maniera sufficientemente dettagliata, in modo che gli ingegneri e gli sviluppatori possano lavorare al progetto con un tempo di startup minimo. In molti casi in questa fase ci si limita a determinare i punti essenziali per lo startup del progetto, con l’intento di definire meglio in seguito, per approssimazioni successive, i dettagli più specifici.

Implementazione

L’implementazione è la fase operativa in cui si produce il software. Le modalità di lavoro possono essere molteplici, comunque nella maggioranza dei casi si tende ad adottare un approccio iterativo al fine di poter validare via via il lavoro svolto e verificare che le aspettative del committente siano soddisfatte. Capire quando è opportuno coinvolgere interlocutori esterni al team di sviluppo per la validazione del lavoro è una tematica delicata e dipende fortemente dall’interlocutore e dallo stato del progetto. Infatti, tendenzialmente, le persone esterne al gruppo di lavoro informatico sono abituate ad avere a che fare con prodotti finiti e non con semilavorati, quindi è necessaria una sorta di “flessibilità mentale” per comprendere che quanto viene mostrato è uno stato intermedio e che occorre immaginarsi il lavoro complessivo. Il committente tenderà sempre ad associare il risultato finale a quanto presente nello stato intermedio; di conseguenza è buona norma quella di non presentare mai software non funzionante, perché altrimenti immaginerà simili comportamenti a regime. Invece è molto probabile che non ritenga critica la mancanza di funzionalità, almeno finché i tempi di progetto rispettano la tabella di marcia ipotizzata ad inizio lavori.

Integrazione e test

Questa fase serve principalmente per verificare la presenza di errori, bug e interoperabilità tra sistemi ed è propedeutica al rilascio in produzione vero e proprio. I test si differenziano in diverse tipologie, di cui si discuterà nel paragrafo successivo, e giocano un ruolo fondamentale per certificare il corretto funzionamento del sistema

 

Rilascio

Conseguentemente all’accettazione del software da parte del committente e del superamento dei test funzionali imposti dal reparto IT, il software viene messo in produzione e viene eseguita l’attività effettiva di utilizzo da parte del committente.

Manutenzione

Durante questa fase il software viene manutenuto affinché il sistema non diventi obsoleto e rimanga funzionante ed efficiente. Ad esempio, se il sistema si appoggia a sistemi esterni è possibile che alcune modifiche su questi ultimi rendano necessario un aggiornamento del software. Oppure potrebbe essere necessario effettuare delle correzioni a seguito dell’individuazione di errori non precedentemente emersi.

Nel corso della vita dell’applicativo è possibile che si renda necessaria l’introduzione di nuove funzionalità o la modifica a funzionalità preesistenti. In questi casi la cosa più corretta da fare dal punto di vista teorico è ripartire dall’analisi preliminare e dalla pianificazione.

Abbandono

Nella maggior parte dei casi le problematiche che hanno richiesto la produzione del software persistono indefinitamente, ma a volte succede che queste decadano e che non si renda più necessaria la manutenzione del software.

Nel caso sia implementata una soluzione stand-alone, sarà possibile dismettere le infrastrutture software e hardware necessarie all’applicazione.  Nel caso in cui solo alcune funzionalità devono essere dismesse è possibile valutare se migrare le funzionalità presenti su un’altra piattaforma. In questo caso si può decidere anche di oscurare le funzionalità non necessarie e mantenere in piedi il software, poiché le operazioni di migrazione sono spesso onerose. Il problema si pone quando si tratta di una piattaforma commerciale, dove l’eliminazione della stessa abbatte i costi di licenza.

Ovviamente le operazioni di dismissione devono essere coerenti con le normative vigenti in termine di privacy e conservazione. Ad esempio dismettendo un software documentale, dobbiamo comunque mantenere le copie archiviate delle fatture per evitare sanzioni amministrative.

 

Nell’esempio descritto in Figura 1.2 sono riportate le fasi di vita dell’applicazione con granularità massima.

Come per le metodologie di sviluppo, in campi applicativi pratici, queste fasi non sempre sono esplicite, ne seguono la sequenza esatta riportata in letteratura. Ad esempio è possibile che le fasi di analisi e progetto siano portate avanti contestualmente durante la formalizzazione da passare agli sviluppatori, o che tutte queste funzionalità siano interamente delegate agli sviluppatori.

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