Gestione dei progetti software

Il modello di lavoro di un'azienda IT impegnata nello sviluppo di software può essere visto diviso in due parti:

• Creazione di software
• Gestione dei progetti software

Un progetto è un'attività ben definita, che è una raccolta di diverse operazioni eseguite per raggiungere un obiettivo (ad esempio, sviluppo e consegna del software). Un progetto può essere caratterizzato come:

• Ogni progetto può avere un obiettivo unico e distinto.
• Il progetto non è un'attività di routine o operazioni quotidiane.
• Il progetto viene fornito con un'ora di inizio e un'ora di fine.
• Il progetto termina quando il suo obiettivo viene raggiunto, quindi è una fase temporanea nella vita di un'organizzazione.
• Il progetto necessita di risorse adeguate in termini di tempo, manodopera, finanza, materiale e banca della conoscenza.

Progetto software

Un progetto software è la procedura completa di sviluppo del software dalla raccolta dei requisiti al test e alla manutenzione, eseguita secondo le metodologie di esecuzione, in un periodo di tempo specificato per ottenere il prodotto software previsto.

Necessità di gestione del progetto software

Si dice che il software sia un prodotto intangibile. Lo sviluppo del software è una sorta di flusso completamente nuovo nel mondo degli affari e c'è pochissima esperienza nella creazione di prodotti software. La maggior parte dei prodotti software sono realizzati su misura per soddisfare le esigenze del cliente. La cosa più importante è che la tecnologia sottostante cambia e avanza così frequentemente e rapidamente che l'esperienza di un prodotto potrebbe non essere applicata all'altro. Tutti questi vincoli aziendali e ambientali comportano rischi nello sviluppo del software, quindi è essenziale gestire i progetti software in modo efficiente.

L'immagine sopra mostra i tripli vincoli per i progetti software. È una parte essenziale dell'organizzazione del software fornire un prodotto di qualità, mantenendo il costo entro i limiti del budget del cliente e consegnare il progetto come da programma. Ci sono diversi fattori, sia interni che esterni, che possono influire su questo triplo triangolo vincolante. Uno qualsiasi dei tre fattori può avere un impatto grave sugli altri due.

Pertanto, la gestione del progetto software è essenziale per incorporare i requisiti degli utenti insieme ai vincoli di budget e tempo.

Responsabile di progetto software

Un software project manager è una persona che si assume la responsabilità di eseguire il progetto software. Il responsabile del progetto software è perfettamente consapevole di tutte le fasi dell'SDLC che il software dovrebbe attraversare. Il project manager non può mai coinvolgere direttamente nella produzione del prodotto finale, ma controlla e gestisce le attività coinvolte nella produzione.

Un project manager monitora da vicino il processo di sviluppo, prepara ed esegue vari piani, organizza le risorse necessarie e adeguate, mantiene la comunicazione tra tutti i membri del team al fine di affrontare questioni di costi, budget, risorse, tempo, qualità e soddisfazione del cliente.

Vediamo alcune responsabilità che un project manager si assume -

Gestione delle persone

• Agisci come capo del progetto
• Collegamento con le parti interessate
• Gestione delle risorse umane
• Impostazione della gerarchia dei rapporti, ecc.

Gestione del progetto

• Definizione e impostazione dell'ambito del progetto
• Gestione delle attività di project management
• Monitoraggio dei progressi e delle prestazioni
• Analisi dei rischi in ogni fase
• Fai i passi necessari per evitare o risolvere i problemi
• Agire come portavoce del progetto

Attività di gestione del software

La gestione dei progetti software comprende una serie di attività, che includono la pianificazione del progetto, la decisione dell'ambito del prodotto software, la stima dei costi in vari termini, la pianificazione di attività ed eventi e la gestione delle risorse. Le attività di gestione del progetto possono includere:

• Project Planning
• Scope Management
• Project Estimation

Pianificazione del progetto

La pianificazione del progetto software è un compito, che viene eseguito prima che la produzione del software inizi effettivamente. Esiste per la produzione del software ma non comporta alcuna attività concreta che abbia alcun collegamento di direzione con la produzione del software; piuttosto è un insieme di più processi, che facilita la produzione di software. La pianificazione del progetto può includere quanto segue:

Gestione dell'ambito

Definisce lo scopo del progetto; questo include tutte le attività, il processo deve essere eseguito per realizzare un prodotto software consegnabile. La gestione dell'ambito è essenziale perché crea i confini del progetto definendo chiaramente cosa sarebbe stato fatto nel progetto e cosa non sarebbe stato fatto. Ciò fa sì che il progetto contenga attività limitate e quantificabili, che possono essere facilmente documentate e, a sua volta, evita il superamento di costi e tempi.

Durante la gestione dell'ambito del progetto, è necessario:

• Definisci l'ambito
• Decidi la sua verifica e controllo
• Dividi il progetto in varie parti più piccole per facilità di gestione.
• Verifica l'ambito
• Controllare l'ambito incorporando le modifiche all'ambito

Stima del progetto

Per una gestione efficace è necessaria una stima accurata delle varie misure. Con una stima corretta, i manager possono gestire e controllare il progetto in modo più efficiente ed efficace.

La stima del progetto può comportare quanto segue:

• Software size estimation

  La dimensione del software può essere stimata in termini di KLOC (Kilo Line of Code) o calcolando il numero di punti funzione nel software. Le righe di codice dipendono dalle pratiche di codifica e i punti funzione variano a seconda dell'utente o dei requisiti software.

• Effort estimation

  I responsabili stimano gli sforzi in termini di fabbisogno di personale e ore di lavoro necessarie per produrre il software. Per la stima dello sforzo, è necessario conoscere la dimensione del software. Questo può essere derivato dall'esperienza dei manager, i dati storici dell'organizzazione o le dimensioni del software possono essere convertite in sforzi utilizzando alcune formule standard.

• Time estimation

  Una volta valutate le dimensioni e gli sforzi, è possibile stimare il tempo necessario per produrre il software. Gli sforzi richiesti sono suddivisi in sottocategorie secondo le specifiche dei requisiti e l'interdipendenza dei vari componenti del software. Le attività del software sono suddivise in attività, attività o eventi più piccoli in base alla struttura WBS (Work Breakthrough Structure). Le attività vengono pianificate su base giornaliera o in mesi di calendario.

  La somma del tempo richiesto per completare tutte le attività in ore o giorni è il tempo totale investito per completare il progetto.

• Cost estimation

  Questo potrebbe essere considerato come il più difficile di tutti perché dipende da più elementi rispetto ai precedenti. Per stimare il costo del progetto, è necessario considerare:

• Dimensioni del software
• Qualità del software
• Hardware
• Software o strumenti aggiuntivi, licenze ecc.
• Personale qualificato con competenze specifiche per l'attività
• Viaggio coinvolto
• Communication
• Formazione e supporto

Tecniche di stima del progetto

Abbiamo discusso vari parametri che coinvolgono la stima del progetto come dimensioni, impegno, tempo e costo.

Il project manager può stimare i fattori elencati utilizzando due tecniche ampiamente riconosciute:

Tecnica di decomposizione

Questa tecnica assume il software come un prodotto di varie composizioni.

Esistono due modelli principali:

• Line of Code La stima viene eseguita per conto del numero di righe di codici nel prodotto software.
• Function Points La stima viene eseguita per conto del numero di punti funzione nel prodotto software.

Tecnica di stima empirica

Questa tecnica utilizza formule derivate empiricamente per effettuare la stima. Queste formule sono basate su LOC o FP.

• Putnam Model

  Questo modello è realizzato da Lawrence H. Putnam, che si basa sulla distribuzione di frequenza di Norden (curva di Rayleigh). Il modello Putnam mappa il tempo e gli sforzi richiesti con le dimensioni del software.

• COCOMO

  COCOMO sta per COnstructive COst MOdel, sviluppato da Barry W. Boehm. Divide il prodotto software in tre categorie di software: organico, semi-indipendente e incorporato.

Pianificazione del progetto

La pianificazione del progetto in un progetto si riferisce alla roadmap di tutte le attività da svolgere con un ordine specificato ed entro la fascia oraria assegnata a ciascuna attività. I project manager tendono a definire varie attività e le pietre miliari del progetto e organizzarle tenendo a mente vari fattori. Cercano compiti che si trovano in un percorso critico nella pianificazione, che sono necessari per completare in modo specifico (a causa dell'interdipendenza dei compiti) e rigorosamente entro il tempo assegnato. È meno probabile che la disposizione delle attività che si trova fuori dal percorso critico abbia un impatto su tutta la pianificazione del progetto.

Per programmare un progetto è necessario:

• Suddividi le attività del progetto in una forma più piccola e gestibile
• Scopri vari compiti e correlali
• Stima il periodo di tempo richiesto per ogni attività
• Dividi il tempo in unità di lavoro
• Assegna un numero adeguato di unità di lavoro per ciascuna attività
• Calcola il tempo totale richiesto per il progetto dall'inizio alla fine

Gestione delle risorse

Tutti gli elementi utilizzati per sviluppare un prodotto software possono essere considerati risorse per quel progetto. Ciò può includere risorse umane, strumenti produttivi e librerie software.

Le risorse sono disponibili in quantità limitata e rimangono nell'organizzazione come un pool di risorse. La carenza di risorse ostacola lo sviluppo del progetto e può essere in ritardo rispetto alla pianificazione. Allocare risorse extra alla fine aumenta i costi di sviluppo. È quindi necessario stimare e allocare risorse adeguate per il progetto.

La gestione delle risorse include:

• Definizione di un progetto organizzativo appropriato creando un team di progetto e assegnando le responsabilità a ciascun membro del team
• Determinazione delle risorse richieste in una fase particolare e della loro disponibilità
• Gestisci le risorse generando richieste di risorse quando sono necessarie e disallocandole quando non sono più necessarie.

Gestione del rischio di progetto

La gestione del rischio coinvolge tutte le attività relative all'identificazione, analisi e previsione di rischi prevedibili e non prevedibili nel progetto. Il rischio può includere quanto segue:

• Personale esperto che lascia il progetto e nuovo personale in arrivo.
• Cambiamento nella gestione organizzativa.
• Modifica del requisito o interpretazione errata del requisito.
• Sottovalutazione del tempo e delle risorse richieste.
• Cambiamenti tecnologici, cambiamenti ambientali, concorrenza tra le imprese.

Processo di gestione del rischio

Ci sono le seguenti attività coinvolte nel processo di gestione del rischio:

• Identification - Prendere nota di tutti i possibili rischi che possono verificarsi nel progetto.
• Categorize - Classificare i rischi noti in intensità di rischio alta, media e bassa in base al loro possibile impatto sul progetto.
• Manage - Analizza la probabilità di accadimento dei rischi nelle varie fasi. Pianifica per evitare o affrontare i rischi. Tenta di ridurre al minimo i loro effetti collaterali.
• Monitor - Monitorare attentamente i potenziali rischi e i loro primi sintomi. Monitorare anche gli effetti delle misure adottate per mitigarli o evitarli.

Esecuzione e monitoraggio del progetto

In questa fase, le attività descritte nei piani di progetto vengono eseguite secondo i loro programmi.

L'esecuzione deve essere monitorata per verificare se tutto sta andando secondo il piano. Il monitoraggio consiste nell'osservare per verificare la probabilità di rischio e adottare misure per affrontare il rischio o segnalare lo stato di varie attività.

Queste misure includono:

• Activity Monitoring - Tutte le attività pianificate all'interno di alcune attività possono essere monitorate su base giornaliera. Quando tutte le attività in un'attività sono state completate, viene considerata completa.
• Status Reports - I rapporti contengono lo stato delle attività e dei compiti completati entro un determinato periodo di tempo, generalmente una settimana. Lo stato può essere contrassegnato come finito, in sospeso o in lavorazione, ecc.
• Milestones Checklist - Ogni progetto è suddiviso in più fasi in cui vengono eseguite le attività principali (pietre miliari) in base alle fasi di SDLC. Questa lista di controllo delle pietre miliari viene preparata una volta ogni poche settimane e riporta lo stato delle tappe.

Gestione della comunicazione del progetto

Una comunicazione efficace gioca un ruolo fondamentale nel successo di un progetto. Colma le lacune tra il cliente e l'organizzazione, tra i membri del team e altri soggetti interessati nel progetto come i fornitori di hardware.

La comunicazione può essere orale o scritta. Il processo di gestione della comunicazione può avere i seguenti passaggi:

• Planning - Questo passaggio include l'identificazione di tutti gli stakeholder del progetto e le modalità di comunicazione tra di loro. Considera inoltre se sono necessarie ulteriori strutture di comunicazione.
• Sharing - Dopo aver determinato i vari aspetti della pianificazione, il manager si concentra sulla condivisione delle informazioni corrette con la persona corretta al momento giusto. Ciò mantiene tutti i soggetti coinvolti nel progetto aggiornati con l'avanzamento del progetto e il suo stato.
• Feedback - I project manager utilizzano varie misure e meccanismi di feedback e creano rapporti sullo stato e sulle prestazioni. Questo meccanismo garantisce che l'input dei vari stakeholder arrivi al project manager come feedback.
• Closure - Alla fine di ogni evento importante, alla fine di una fase di SDLC o alla fine del progetto stesso, viene formalmente annunciata la chiusura amministrativa per aggiornare ogni stakeholder tramite l'invio di e-mail, la distribuzione di una copia cartacea del documento o altro mezzo di comunicazione efficace.

Dopo la chiusura, il team passa alla fase o al progetto successivo.

Gestione della configurazione

La gestione della configurazione è un processo di tracciamento e controllo delle modifiche nel software in termini di requisiti, design, funzioni e sviluppo del prodotto.

IEEE lo definisce come "il processo di identificazione e definizione degli articoli nel sistema, controllo della modifica di questi articoli durante il loro ciclo di vita, registrazione e segnalazione dello stato degli articoli e delle richieste di modifica e verifica della completezza e correttezza degli articoli".

In genere, una volta finalizzato l'SRS, ci sono meno possibilità di richiedere modifiche da parte dell'utente. Se si verificano, le modifiche vengono affrontate solo previa approvazione della direzione superiore, poiché esiste la possibilità di un superamento dei costi e dei tempi.

Baseline

Si presume una fase di SDLC se è di base, ovvero la linea di base è una misurazione che definisce la completezza di una fase. Una fase è fondamentale quando tutte le attività ad essa relative sono terminate e ben documentate. Se non fosse la fase finale, il suo output verrebbe utilizzato nella successiva fase immediata.

La gestione della configurazione è una disciplina dell'amministrazione dell'organizzazione, che si prende cura del verificarsi di qualsiasi cambiamento (processo, requisito, tecnologico, strategico, ecc.) Dopo che una fase è fondamentale. CM tiene sotto controllo eventuali modifiche apportate al software.

Controllo delle modifiche

Il controllo delle modifiche è una funzione della gestione della configurazione, che garantisce che tutte le modifiche apportate al sistema software siano coerenti e effettuate secondo le regole e le normative dell'organizzazione.

Una modifica nella configurazione del prodotto passa attraverso i seguenti passaggi:

• Identification- Una richiesta di modifica arriva da una fonte interna o esterna. Quando la richiesta di modifica viene identificata formalmente, viene adeguatamente documentata.

• Validation - Viene verificata la validità della richiesta di modifica e viene confermata la sua procedura di trattamento.

• Analysis- L'impatto della richiesta di modifica viene analizzato in termini di pianificazione, costi e sforzi richiesti. Viene analizzato l'impatto complessivo del cambiamento prospettico sul sistema.

• Control- Se il cambiamento prospettico ha un impatto su troppe entità nel sistema o è inevitabile, è obbligatorio ottenere l'approvazione delle alte autorità prima che il cambiamento sia incorporato nel sistema. Si decide se vale la pena incorporare il cambiamento o meno. In caso contrario, la richiesta di modifica viene rifiutata formalmente.

• Execution - Se la fase precedente determina l'esecuzione della richiesta di modifica, questa fase intraprende le azioni appropriate per eseguire la modifica, se necessario esegue una revisione approfondita.

• Close request- La modifica viene verificata per la corretta implementazione e fusione con il resto del sistema. Questa nuova modifica incorporata nel software è documentata adeguatamente e la richiesta viene formalmente chiusa.

Strumenti di gestione del progetto

Il rischio e l'incertezza si moltiplicano rispetto alla dimensione del progetto, anche quando il progetto è sviluppato secondo metodologie prestabilite.

Sono disponibili strumenti che aiutano a una gestione efficace del progetto. Alcuni sono descritti -

Diagramma di Gantt

I diagrammi di Gantt sono stati ideati da Henry Gantt (1917). Rappresenta la pianificazione del progetto rispetto ai periodi di tempo. È un grafico a barre orizzontali con barre che rappresentano le attività e il tempo programmato per le attività del progetto.

Grafico PERT

Il grafico PERT (Program Evaluation & Review Technique) è uno strumento che rappresenta il progetto come diagramma di rete. È in grado di rappresentare graficamente gli eventi principali del progetto sia in modo parallelo che consecutivo. Gli eventi, che si verificano uno dopo l'altro, mostrano la dipendenza dell'evento successivo rispetto a quello precedente.

Gli eventi vengono visualizzati come nodi numerati. Sono collegati da frecce etichettate che raffigurano la sequenza di attività nel progetto.

Istogramma delle risorse

Si tratta di uno strumento grafico che contiene una barra o un grafico che rappresenta il numero di risorse (solitamente personale qualificato) necessarie nel tempo per un evento (o fase) del progetto. L'istogramma delle risorse è uno strumento efficace per la pianificazione e il coordinamento del personale.

Analisi del percorso critico

Questi strumenti sono utili per riconoscere attività interdipendenti nel progetto. Aiuta anche a scoprire il percorso più breve o il percorso critico per completare con successo il progetto. Come il diagramma PERT, a ogni evento viene assegnato un periodo di tempo specifico. Questo strumento mostra la dipendenza dell'evento assumendo che un evento possa procedere al successivo solo se quello precedente è stato completato.

Gli eventi sono organizzati in base alla loro prima ora di inizio possibile. Il percorso tra il nodo iniziale e quello finale è un percorso critico che non può essere ulteriormente ridotto e tutti gli eventi devono essere eseguiti nello stesso ordine.