Creazione di software: come valutare il progetto ed essere più produttivi?

La valutazione e il calcolo dei costi della progettazione del software, in particolare le dimensioni, l'impegno, i costi e i tempi necessari, sono spesso fonte di vivaci discussioni tra i valutatori di software. I project manager sono generalmente responsabili di questa attività.

Lo sviluppo del software comporta una serie di attività diverse che richiedono conoscenze specialistiche, in particolare nei seguenti ambitiQueste includono la raccolta, l'analisi e la gestione dei requisiti; la progettazione, la codifica e la verifica e validazione indipendente (IV&V) del software; l'implementazione, la distribuzione, l'installazione e la messa in servizio. Ognuna di queste attività è svolta da una persona qualificata, che utilizza vari strumenti di diverso grado di complessità.

Vedere tutti i software Software Vendor

Che cos'è la produttività? Definizione

La produttività è definita come il tasso di produzione per determinati input. La produttività è espressa come "tante unità di produzione al giorno" o "tante unità di produzione all'ora". La produttività è anche definita come il rapporto tra input e output.

Nel contesto di questo articolo, la produttività si riferisce al tasso di produzione di un'unità di output utilizzando un insieme di input, per un determinato periodo di tempo.

Problemi nella valutazione delle dimensioni del software

Nell'industria informatica odierna, esistono diverse unità di misura delle dimensioni di un software. Queste unità includono, ad esempio, i punti funzione, i punti caso d'uso (UCP), i punti oggetto, i punti funzionalità, i punti Internet, i punti test, l'analisi dei punti funzione (FPA), le linee di codice (LOC) e così via. Non esiste una misura stabilita per convertire le dimensioni del software in una di queste unità.

Stranamente, in queste misure, la dimensione del software viene adattata (aumentata o diminuita), a seconda di fattori come la complessità. Eppure la dimensione è un carattere immutabile. Per esempio, un chilo di formaggio non diventa più pesante o più leggero se la persona che lo pesa è più o meno esperta nel pesare, o se la bilancia è meccanica o elettronica. Facciamo un altro esempio: un chilometro è sempre un chilometro, sia che a percorrerlo sia un giovane o un anziano, sia che la distanza sia misurata in autostrada o in una strada trafficata.

Cambia però la velocità con cui si ottengono i risultati. Se prendiamo gli esempi precedenti, la persona anziana percorrerà sicuramente il chilometro più lentamente di quella giovane. Inoltre, un chilometro viene percorso più rapidamente in autostrada che in città.

Inoltre, non c'è accordo su come contare i LOC. Dobbiamo contare le proposizioni logiche o quelle fisiche? E come va trattata la documentazione online? Va presa in considerazione o meno?

Questi sono alcuni dei principali problemi associati alla valutazione delle dimensioni di un software.

Preoccupazioni per la produttività

L'industria dell'editoria software è ossessionata dalla possibilità di affermare un unico tasso empirico di produttività per tutte le attività.

Si è tentato di definire la produttività come 10 ore-persona per punto funzione, mentre si è tentato di definire la produttività come 10 ore-persona per punto funzione.L'unità di ore-persona per punto funzione può variare da 2 a 135 a seconda delle dimensioni del prodotto, del team e di altri fattori. "Definire la produttività" significa assegnare una cifra che rappresenti lo sforzo necessario, espresso in ore-persona, per sviluppare un'unità di dimensione del software, in modo che la dimensione del software (in punti funzione) possa essere convertita in sforzo di sviluppo (in ore-persona). A volte si scelgono degli intervalli, ad esempio da quindici a trenta ore per PCU. Altre volte vengono create formule empiriche sulla base di un insieme di fattori, come nel caso del "modello di costo costruttivo" (COCOMO).

Il problema di queste misure di produttività è che combinano tutte le attività - analisi dei requisiti, progettazione, revisione, test, ecc. - in un'unica misura. Tuttavia, le competenze richieste per queste attività sono diverse, così come gli strumenti utilizzati e gli input e gli output. Raggrupparli sotto la voce "sviluppo software" e dare un'unica misura della produttività può fornire solo una stima molto approssimativa, e mai accurata.

Progettare software in modo migliore e più veloce: come diventare più produttivi?

Lo sviluppo del software comprende le seguenti attività

• attività di preparazione del progetto, tra cui studi di fattibilità, budgeting finanziario e convalida del progetto (approvazione finanziaria e tecnica e "lancio del progetto")
• attività di lancio del progetto, come l'identificazione del project manager, la creazione di un team di progetto e la creazione dell'ambiente di sviluppo; pianificazione del progetto; definizione di vari protocolli, come gli accordi sul livello di servizio e le procedure di rendicontazione dei progressi; formazione sul progetto
• attività di ingegneria del software, tra cui l'analisi delle esigenze degli utenti, l'analisi dei requisiti del software, la progettazione del software, la codifica e il test unitariodiversi tipi di test di integrazione, funzionali, negativi, di sistema e di accettazione; preparazione della documentazione
• attività di deployment, tra cui installazione di hardware e sistemi; creazione di database; installazione di software applicativo; test pilota; test utente; test di sicurezza.installazione del software applicativo; test pilota; formazione degli utenti; fase parallela e implementazione vera e propria
• attività di chiusura del progetto, compresa la documentazione delle buone e cattive pratiche; analisi del progetto (fine del progetto); archiviazione dei file; pubblicazione delle risorse; esonero del project manager dagli obblighi; inizio della manutenzione del software.

Quando si parla di "regole di base" del settore (procedure accettate e di buon senso) per la produttività, è difficile determinare quali attività siano incluse nel tasso di produttività. Nessuno scommetterebbe sulla misurazione della produttività, anche se si tratta di una regola di base del settore.

Vediamo la natura di queste attività:

1. Analisi dei requisiti: comprendere e documentare le esigenze, i desideri e le aspettative dell'utente, in modo che i progettisti di software comprendano appieno e possano progettare un sistema in stretta conformità con i requisiti dichiarati. La dipendenza da fattori esterni è elevata.
2. Progettazione del software: considerare le diverse opzioni disponibili per l'hardware, il software di sistema e la piattaforma di sviluppo; arrivare alla scelta ottimale per ciascuna di esse; progettare un'architettura che soddisfi i requisiti dichiarati e le aspettative del cliente. L'architettura deve essere compatibile con le tecnologie attuali e il progetto deve essere documentato in modo tale che i programmatori possano comprenderlo e fornire un prodotto conforme alle specifiche originali dell'utente. Esistono diverse alternative e, poiché la progettazione del software è un'attività importante e strategica, gli errori possono avere gravi conseguenze.
3. Codifica: sviluppo di codice software che sia conforme al progetto e contenga il minor numero possibile di errori (è facile lasciare "bug" involontariamente).
4. Revisione del codice: studiare il codice scritto da un altro programmatore, decifrarne la funzionalità e cercare di prevedere gli errori che il cliente potrebbe incontrare nell'utilizzo del software.
5. Test: cercare di scoprire eventuali difetti del software. Tuttavia, è impossibile trovare quasi tutti i difetti. Inoltre, testare il software nella sua interezza è un'attività poco pratica.

Poiché la natura di queste attività è così diversa, è ovvio che la produttività di ciascuna di esse non è uniforme (e quindi non può essere descritta dalla stessa cifra). Il ritmo di lavoro è diverso per ciascuna di queste attività.

Non dipendono dalla quantità di codice prodotto, ma da altri fattori, come :

1. i requisiti, che dipendono dall'efficacia e dalla chiarezza della loro fonte (utenti o documentazione)
2. la progettazione, che dipende dalla complessità del processo, dalle alternative disponibili e dai vincoli con cui la funzionalità deve essere progettata
3. revisione del codice, che dipende dallo stile di codifica
4. il controllo, che dipende da come è scritto il codice (più errori ci sono, più tempo è necessario per i test e i ritest)
5. la codifica stessa, che dipende dalla qualità del progetto.

Di conseguenza, dobbiamo stabilire cifre di produttività diverse per ciascuna di queste attività.

Proviamo a fare un parallelo con l'industria, ad esempio con la punzonatura. Le attività da svolgere sono: 1) impostazione della macchina; 2) impostazione degli utensili; 3) caricamento del lavoro; 4) punzonatura del foro; 5) sbavatura del foro; 6) pulizia; 7) consegna della lamiera per l'operazione successiva.

Se si eseguono più fori, il tempo "per foro" diminuisce, perché le attività di configurazione sono una tantum.

Pertanto, se consideriamo la codifica di un'unità, ad esempio, le attività da svolgere potrebbero essere: 1) ricevere le istruzioni; 2) studiare il documento di progettazione; 3) codificare l'unità; 4) testare e debuggare l'unità per la funzionalità specifica; 5) testare e debuggare l'unità per qualsiasi uso; 6) testare e debuggare l'unità per qualsiasi uso; 7) testare e debuggare l'unità per qualsiasi uso.6) rimuovere il codice non necessario dall'unità; 7) eseguire il test di regressione dell'unità; 8) trasferire l'unità alla fase successiva.

Allo stesso modo, possiamo proporre micro-attività per ogni fase di sviluppo del software.

Dati sulla produttività: empirici o basati su uno studio metodico?

Ciascuna delle attività sopra descritte ha un tasso di successo diverso. È necessario stabilire tempi standard per ciascuna di queste attività. Una volta fatto questo, si dovranno usare tecniche di studio del lavoro, come la sintesi o la stima analitica, per stimare la durata totale dell'incarico.

Sia che le tecniche di studio del tempo vengano utilizzate per effettuare studi sulla produttività individuale o per raccogliere dati empirici, lo sviluppo del software non è né totalmente meccanico né totalmente creativo. È anche poco realistico pianificare attività con una forte componente creativa; i metodi di studio del lavoro tengono conto di questo aspetto dello sviluppo del software. Si sta facendo molta ricerca sulla "produttività esecutiva" e forse in futuro saranno disponibili metodi per "cronometrare" la produttività nello sviluppo del software. Al momento, i dati empirici sembrano essere la soluzione preferita.

Dove trovare i dati empirici? La prima opzione è rappresentata dagli studi sul lead time che utilizzano tecniche di ingegneria industriale. L'altro modo, più semplice e affidabile, è quello di affidarsi ai dati storici forniti dai fogli di presenza.

La maggior parte dei software di gestione del tempo utilizzati dall'industria è orientata alle buste paga e alla fatturazione. Non raccolgono dati al livello più basso per stabilire le tendenze della produttività. La maggior parte di questi software registra due o tre livelli di dati, oltre alla data e all'ora. Un progetto viene sempre registrato al primo livello, mentre il secondo e il terzo livello possono essere occupati da un modulo e da un componente, da un componente e da un'attività o da una combinazione simile. Oltre alla data e all'ora in cui il dipendente è presente, i timesheet devono registrare cinque livelli di dati: il progetto, il modulo, il componente, la fase di sviluppo e l'attività svolta. In questo modo, i dati sarebbero disponibili per stabilire misure di produttività in modo empirico e realistico.

Attualmente, le attività di sviluppo del software si concentrano sulla macro-produttività. Questa tendenza deve cambiare e dobbiamo passare dalla macro alla micro produttività. Per farlo, dobbiamo cambiare il nostro software di timesheet e la profondità dei dati che raccogliamo.

Lo studio della produttività a livello micro presenta i seguenti vantaggi:

• Migliore prevedibilità dello sviluppo del software
• Migliori stime di qualità per migliorare i prezzi durante le fasi di sviluppo e finalizzazione del progetto
• Definizione di obiettivi più precisi nell'assegnazione dei compiti, che aumenta la fiducia degli editori di software
• Stime dei costi più accurate

Vedere tutti i software Software Vendor

Conclusioni

È importante capire la differenza tra i termini produttività e capacità. La produttività è il tasso di successo di una microattività; la capacità è il tasso di successo di un impianto (fabbrica, organizzazione, ecc.), e diverse attività sono incluse nel diagramma della capacità. Ai fini della valutazione del software, l'attenzione deve spostarsi dalla macroproduttività (capacità) alla produttività (per la microattività). La raccolta di dati empirici è preferibile per ottenere misure di produttività per le diverse attività di sviluppo del software, poiché le tecniche di studio del tempo e dei compiti non possono fornire un quadro completo della produttività.La raccolta di dati empirici è privilegiata per ottenere misure di produttività per le diverse attività di sviluppo del software, perché le tecniche di studio delle scadenze e dei compiti non possono fornire risultati soddisfacenti quando la missione presenta un alto grado di creatività (come nel caso della pubblicazione di software). Per raccogliere dati empirici, è necessario migliorare il software di registrazione dei tempi. Raccomandiamo questa procedura per calcolare i dati di produttività a tutti i microlivelli.

Gli autori

Murali Chemuturi è esperto di ingegneria industriale presso l'Indian Institution of Industrial Engineering. Ha trascorso oltre trent'anni in organizzazioni professionali, tra cui ECIL, TCS, Metamor e Satyam. Ha lavorato prima nel settore manifatturiero e poi in quello informatico. Attualmente dirige Chemuturi Consultants e ha un interesse particolare per il software per l'industria dello sviluppo software. Ha condotto diversi programmi di formazione in azienda per la gestione di progetti software e la valutazione del software.

Sarada Kaligotla ha conseguito un master in applicazioni informatiche ed è certificata Project Management Professional (PMP) presso il Project Management Institute (PMI) e Certified Software Quality Analyst (CSQA) presso il Quality Assurance Institute (QAI). Attualmente lavora per Blue Cross Blue Shield in Massachusetts. Sarada ha sei anni di esperienza nel settore del software e nella gestione di progetti e sviluppo.