Teoria Locale

Nello sviluppo basato su componenti e su grandi granuli di software, si parte da una versione standard (versione base) di software e si ricavano le altre versioni, dipendentemente dai bisogni dei clienti. Ogni nuova versione riusa le componenti della versione base alcuni dei quali sono modificati per adeguarli alle specifiche del cliente ed aggiunge, se necessario, nuovi moduli. Quando si hanno molte versioni in esercizio, le nuove versioni non necessariamente fanno riferimento alla versione base bensì fanno riferimento a quella che secondo lo sviluppatore è più vicina alle specifiche che deve implementare perché questa diminuisce i tempi di manutenzione.

In questo contesto, ogni versione in esercizio ha una sua vita distinta dalle altre, quindi ognuna diventa un sistema autonomo ed indipendente dalle altre e si perde il concetto di versione base.  Se la documentazione del software non ha una storia analoga a quella del software, tutte le versioni in esercizio sono prive di documentazione. Pertanto, per ogni versione la sola parte formalizzata è il codice. Questo genera i seguenti problemi:

• La mobilità del personale è ridotta se non azzerata e, comunque il turn over di una persona creerebbe un grande danno all’impresa. Perché, la conoscenza delle caratteristiche funzionali e tecniche del software in esercizio è, in gran parte, distribuita tra analisti, e progettisti; ognuno ha un “modello mentale” del sistema che è in esercizio presso i clienti che egli cura. Quindi perché uno di essi sia trasferito deve prima assicurare che il suo “modello mentale” sia trasferito al suo sostituto. Questo trasferimento richiede un tempo imprevedibile ed ha alta probabilità di non essere completo.
• Spesso è il programmatore che deve estrarre dal codice gli aspetti di interesse del funzionamento del software in esercizio presso i clienti. Perché i modelli mentali sono volatili. Pertanto, ogni analista o progettista non ricorda esattamente tutto ciò che riguarda il sistema in esercizio presso un suo cliente. Ciò evidentemente fa sprecare tempo e comunque il risultato non è affidabile. Altresì, quando l’analista o il progettista ritiene di sapere ciò che serve per realizzare le modifiche richieste dal cliente, potrebbe ricordare qualcosa di inesatto o incompleto, sempre perché i modelli mentali sono volatili, ed in questo caso c’è un’alta probabilità di iniettare errori nello sviluppo della modifica.
• Spreco di risorse per la realizzazione di modifiche che erano già state realizzate precedentemente per un altro cliente. Perché non avendo una descrizione rigorosa delle caratteristiche dei sistemi in esercizio l’analista e/o il progettista che deve realizzare la modifica non può sapere cosa sia stato fatto in altre versioni del sistema da altri analisti e/o progettisti.
• Frequentemente le modifiche risultano incomplete. Perché per la stessa carenza di prima spesso non si riesce ad individuare l’esatto impatto di una modifica sul sistema in esercizio. Ciò implica oltre alla rilavorazione onerosa del sistema consegnato anche insoddisfazione del cliente.
• Frequente regressione del software modificato. Perché la stessa carenza rende impossibile né fare un esaustivo piano di test di sistema né, tanto meno, un esaustivo piano di test di regressione. Ciò implica che sono lasciati nel sistema consegnato difetti che sarebbero potuti essere rilevati durante le fasi di test, prima della consegna. Questo causa, oltre all’insoddisfazione del cliente, anche enormi costi per la ricerca e riparazione di questi difetti attraverso i malfunzionamenti rilevati in esercizio.

• BRD (Business Requirement Definition). Documento standard con cui si descrivono I requisiti che sono oggetto di implementazione del progetto.
• BRD Legacy. Si riferisce ad un sistema software ed è Il BRD che descrive i requisiti implementati nella versione in esercizio. Esso esprime tutti i requisiti coperti del dominio applicativo di riferimento dal sistema software che sono stati implementati incrementalmente con tutti i progetti eseguiti per lo stesso dominio e per lo stesso cliente presso cui il sistema è in esercizio.
• Ciclo di vita. È il ciclo della vita di un sistema software si estende nel tempo che va dalla sua nascita al suo ritiro e comprende sia la sua produzione inziale sia tutte le modifiche che nel predetto tempo di operano sullo stesso sistema.
• Complessità del software. È una misura che esprime il numero di condizioni che gestiscono il comportamento del software. Maggiore è il numero di condizioni, maggiori sono i comportamenti del software che devono essere provati come corretti.
• Conoscenza del Dominio Applicativo. Profondità della conoscenza del Dominio Applicativo del sistema software da parte del TAM.
• Dimensione del software. È una misura che dipende dal modello di rappresentazione del software. Può essere: Il numero di funzioni di business che devono essere implementate nel software se il modello di rappresentazione è il BRD, oppure il numero di istruzioni se il modello di rappresentazione è il codice.
• Dominio applicativo. Il contesto in cui operano i sistemi software o applicazioni, con riferimento alla natura e al significato delle informazioni che questi ultimi gestiscono ed il perimetro dei processi di business di cui devono supportarne l’automazione.
• Failure/Malfunzionamento. Incapacità di un sistema software o di un componente di eseguire le sue funzioni come è prescritto nelle specifiche dei requisiti descritti nel BRD. Durante lo sviluppo, i tester osservano solitamente i malfunzionamenti.
• Linea di Prodotto. Un insieme di specifiche che soddisfano un segmento di mercato, piuttosto che un cliente, interessato al dominio applicativo del sistema software. Una linea di prodotto condivide deliberatamente, piuttosto che casualmente o opportunisticamente, un patrimonio di capacità (documentazione, casi di test ecc.) comuni. La specifica del sistema software è costituita da una parte invariante per tutte le installazioni dello stesso sistema software e da un insieme di parti varianti che lo specializzano il sistema in ogni sua applicazione. La produzione di un nuovo BRD è prodotto utilizzando il BRD Legacy con metodi governati e prescritti.
• Livello di competenza del TAM. Livello di conoscenza dello standard BRD ed abilità di applicazione dello stesso nei progetti industriali.
• Processo di sviluppo. Comprende tutte le attività necessarie per la produzione o la manutenzione di un sistema software, che vanno dal concepimento alla consegna ed accettazione del prodotto o della modifica richiesta. Le attività sono raggruppate in fasi. Ogni attività ha delle condizioni di partenza e delle condizioni di chiusura. Tutte le fasi si chiudono tecnicamente con la V&V. A volte le condizioni di chiusura di un’attività richiede la rilavorazione di una o più attività precedentemente già eseguite; e per analogia la V&V a volte richiede di rieseguire attività della fase che ha chiuso o addirittura di attività di fasi precedenti, perciò un processo di sviluppo in esecuzione potrebbe comportare la riesecuzione ciclica di taluni attività anche quando il modello di processo descrive le attività solo in sequenza. Esistono diversi modelli di processo di sviluppo che sono adottati dipendentemente dalle caratteristiche del progetto che si deve eseguire.
• Progettazione sistematica del test. Metodo per la progettazione dei casi di test dipendente solo dalle prescrizioni prescritte nelle specifiche dei requisiti nel BRD.
• Progetto. L’insieme dei processi necessari per implementare i requisiti di un nuovo prodotto o di un cambiamento ad un prodotto in esercizio. I progetti possono essere di dimensioni (numero di persone e di tempo-persona richiesti per eseguirlo) o di complessità (complessità dei requisiti da soddisfare in termini di rischi nella loro specifica e di comportamento del software da implmentare) diverse
• Standard BRD o Analisi. Processo standard di analisi per la produzione del BRD. Esso è costituito da uno o più cicli: produzione/modifica BRD – Verifica e Validazione. il processo termina quando la Verifica e validazione non ha più rilievi.
• TAM (Technical Account Manager). Analista che conduce il processo standard per la produzione del BRD. È considerato senior se ha più di tre anni di anzianità; junior se ha fino a tre anni di anzianità.
• Test di Sistema (TS). Insieme di casi di test che servono per verificare che il sistema software prodotto dal progetto risponda completamente e correttamente ai requisiti specificati nel BRD. Normalmente i casi di test sono eseguiti in un ambiente tecnologico asettico ovvero da laboratorio.
• User Acceptation Test (UAT). Insieme di casi di test che servono per verificare che il sistema software che si sta consegnando all’utente risponda completamente e correttamente ai bisogni del cliente che hanno generato la commessione del progetto. Normalmente i casi di test sono esguiti nell’ambiente tecnologico in cui deve essere messa in esercizio l’applicazione.
• Verifica e Validazione (V&V). processo standard che è eseguito al termine di ogni fase dello sviluppo software per sindacare che la documentazione prodotta sia corretta e completa.

1. L’uso dello standard BRD da parte dei TAM consente di produrre una documentazione rigorosa – BRD– che non risulti avere rilievi di Verifica e Validazione con un impegno persona che si aggira sul 6% e non supera il 10% del costo totale del progetto, tranne che in casi che si possono considerare straordinari e, perciò, rari.  
2. L’uso dello standard BRD richiede un impegno-persona da parte del TAM che percentualmente non ha correlazione con la complessità o la dimensione del progetto. Potrebbe capitare che a progetti di grande dimensione corrisponda una minore percentuale di tempo-persona per l’analisi.
3. La maggiore accuratezza del BRD è condizione necessaria per poter progettare un Test di Sistema (TS) efficace perché fa diminuire le failure scoperte nell’User Acceptation Test (UAT) e che si eseguito con economia di tempo persona.
4. Nell’uso dello standard BRD la profondità di conoscenza del dominio applicativo del TAM aumenta la probabilità di diminuzione dell’impegno persona nell’analisi.
5. Quando il TAM per un progetto produce il BRD usando il BRD legacy del corrispondente sistema software: il BRD avrà una qualità tano più elevata quanto più grande è l’età del BRD Legacy.
6. I BRD prodotti con l’ausilio del BRD Legacy hanno una qualità più neutrale rispetto al livello di competenza ed alla conoscenza del dominio applicativo del TAM.
7. La trasformazione delle versioni di una funzione descritte nei BRD dei sistemi in esercizio in una struttura per Linea di Prodotto produce economie nella produzione di nuovi BRD quando la frequenza di riuso della funzione nel suo futuro ciclo di vita è proporzionale con l’impegno persona necessario per la trasformazione BRD-Legacy in Linea di prodotto.

1. I TAM hanno la necessità di inventariare i bisogni dell’utente che devono soddisfare con lo sviluppo di un nuovo sistema software o con i cambiamenti di un sistema già in esercizio, perché sulla base di questi si deve stilare il contratto con il cliente e si devono fare previsioni sui costi e, quindi, sul compenso da chiedere al cliente. Senza lo standard BRD, il TAM era guidato solo dalla sua esperienza nella produzione del documento dei bisogni del cliente; ovvero sulla base della sua esperienza si faceva un modello mentale del documento da produrre. Quando produceva questo tipo di documento le informazioni che doveva includere, l’organizzazione e la profondità di queste erano un problema che il TAM si poneva ogni volta, anche perché non poteva ricordare tutta l’esperienza che aveva raccolto in precedenza, perché il modello mentale è volatile per natura della mente. La proposizione del problema, la ricerca della soluzione e la soluzione adottata dipendeva dal TAM e per lo stesso TAM dipendeva di volta in volta dalla complessità che avvertiva del problema e da quello che ricordava della sua esperienza. In sintesi l’impostazione del documento da produrre richiedeva del tempo-persona ogni volta che si doveva produrre lo stesso documento ed il tempo-persona speso dipendeva da un numero di aspetti che la mente del TAM si poneva e che dovevano essere specificati nel documento; per quanto si è detto, il numero di aspetti che il TAM si poneva non erano prevedibili; quindi, il tempo-persona dedicato a questa attività non era prevedibile ed occupava, in percentuale rispetto al tempo-persona speso in tutto il progetto, un valore variabile, tra i TAM e per lo stesso TAM tra i progetti, e non prevedibile. Con l’introduzione dello standard BRD sono definiti per tutti i progetti da eseguire: gli aspetti da descrivere, le informazioni da elicitare e descrivere per ogni aspetto, come strutturare il documento prodotto (il BRD); quali devono essere i collegamenti tra i contenuti delle sezioni previste nel BRD. Inoltre, la V&V consente di rilevare eventuali carenze o errori compiuti dall’autore del BRD. Questo fa economia del tempo-persona speso per organizzare il documento e rende il processo di produzione una consuetudine, pertanto il tempo-persona speso per l’analisi, in percentuale rispetto al tempo-persona speso per l’intero progetto, diventa stabile e prevedibile. Per completezza, è opportuno rilevare che l’esperienza di applicazione dello standard fa elicitare esperienza attraverso la quale migliorare lo standard BRD, quindi esso raccoglie tale esperienza che è automaticamente trasferita a tutti i TAM e che non è dimenticabile perché formalizzata nello standard.
2. La correlazione tra dimensione e complessità del progetto con il tempo-persona speso in percentuale per l’analisi non c’è perché la consuetudine nell’applicare lo standard BRD fa sì che il tempo-persona in assoluto si ingrandisca con la dimensione e la complessità del progetto ma in proporzioni paragonabili, per tutti i progetti, al tempo-persona speso per le altre fasi del processo di sviluppo, quindi la percentuale rimane stabile. Inoltre quando le dimensioni del progetto aumentano non tutti gli aspetti da descrivere nel BRD aumentano di dimensioni (per esempio: l’infrastruttura su cui deve funzionare il sistema rimane sempre la stessa per ogni cliente e non cambia per le dimensioni del sistema software da specificare); perciò la percentuale di tempo persona speso per la produzione del BRD per un sistema di grandi dimensioni tende a diminuire in percentuale rispetto a quelli per sistemi di dimensioni più ridotte.
3. L’accuratezza del BRD fa sì che i requisiti nel BRD siano corretti e completi quindi le failure scoperte nel TS dovrebbero contenere tutte quelle che potrebbero essere scoperte nello UAT. Poiché correggere le failure scoperte nello UAT è più costoso di quelle scoperte nel TS, questa situazione rende più economico il processo di sviluppo del software. I rilievi nella V&V dell’analisi aumenta la probabilità di correttezza e completezza del BRD; pertanto maggiori sono i rilievi della V&V maggiore è la probabilità di accuratezza del BRD.
4. La conoscenza del dominio applicativo consente al TAM di dover elicitare meno informazioni per comprendere il reale bisogno del cliente e, quindi, esprimere i corrispondenti requisiti.
5. Il BRD Lecagy ha subito tante più V&V quanto più è vecchio. Pertanto, il suo contenuto ha avuto tante più opportunità di essere affinato e corretto quanto più è vecchio il Legacy. Di conseguenza tutte le parti riusate del BRD Legacy nel nuovo BRD hanno un elevato livello di qualità. Per la necessità di rendere coerenti le relazioni tra le varie parti del BRD (richieste dallo standard BRD) il TAM autore e, successivamente, la V&V sono indotti ad equalizzare la qualità di tutte le parti del BRD. Allora la qualità del BRD è trascinata dalla qualità del BRD Legacy che a sua volta è tanto più alta quanto più vecchio è il legacy.
6. La qualità del BRD Legacy e la conoscenza del dominio applicativo contenuta in esso sono un contributo della competenza e della conoscenza di tutti i TAM che hanno contribuito a produrlo. Il BRD che utilizza il legacy acquisisce una qualità ed una conoscenza del dominio applicativo che sono almeno parzialmente indipendenti dal livello di competenza e conoscenza del dominio applicativo dell’autore. Perciò maggiore è il riuso del BRD Legacy in un BRD di progetto e più le caratteristiche di quest’ultime saranno neutrali rispetto alla competenza e conoscenza del dominio applicativo dell’autore.
7. Per trasformare in linea di prodotto una funzione implementata in più versioni in esercizio in altrettanti clienti è necessario analizzare le sue specifiche nei corrispondenti BRD, individuare le parti invarianti e quelle varianti, produrre la descrizione della funzione nel BRD Legacy. Queste attività richiedono un investimento in impegno-persona. Tale investimento sarà ripagato ogni volta che un TAM avrà bisogno di modificare quella funzione secondo le richieste di un cliente perché avrà in un solo punto la conoscenza di come quella stessa funzione è implementata in tutte le versioni in esercizio; quindi potrà sapere se la modifica è stata già implementata o comunque se può riusare quanto implementato nelle versioni in esercizio. In ogni caso la modifica è implementata riusando quanto più è possibile ciò che è già implementato. Questo produce una economia, a partire dall’analisi, in tutto il processo di sviluppo della modifica della funzione in causa. Perciò per un buon bilancio costi-benefici: maggiore è l’impegno-persona richiesto per la generalizzazione, maggiore deve essere la frequenza di riuso della funzione nel futuro ciclo di vita del software.

1. La conoscenza dello standard BRD e del dominio applicativo possono creare diseconomie nella produzione del BRD. Infatti, i TAM Junior hanno prodotto DRD con il più alto numero di entrambi i tipi di rilievi (“info ambigua” ed “Omissione”). Altresì gli stessi tipi di errori sono stati rilevati con maggiore dispersione nei BRD prodotti dagli junior; quindi i difetti iniettati da questi BRD renderanno meno prevedibili gli impegni-persona che si dovranno spendere nelle fasi del processo di sviluppo a causa delle rilavorazioni che essi comporteranno. Un’altra corroborazione di questo rischio è dato dalla costatazione che l’impegno persona speso dai TAM junior per l’analisi e nettamente maggiore di quello speso dai TAM senior. Infine si verifica che anche per i TAM senior aumenta la probabilità di superare la media di impegno-persona prevista per l’analisi nel caso che il progetto tratti aspetti innovativi del dominio applicativo; ad esempio nel caso di Auriga l’introduzione del regolamento PSD2. Questo rischio può essere mitigato con: il trasferimento accurato di queste competenze ai TAM neofiti; il rafforzamento delle stesse per i TAM junior; l’aggiornamento sistematico per tutti i TAM delle innovazioni di contenuti del dominio applicativo.
2. La carenza di rigorosità dello standard BRD causa carenza di qualità nei BRD prodotti che a loro volta causano diseconomia nel resto del processo di sviluppo dei software consegnati ai clienti. Per mitigare questo rischio è opportuno che dall’analisi dei rilievi prodotti nella V&V e delle failure rilevate nei TS e negli UAT si rilevino i possibili miglioramenti da apportare allo standard BRD in termini sia di processo che di contenuti dello stesso BRD.

• Partendo dalla considerazione che i concetti trattati nell’analisi hanno un’alta profondità semantica, tentare di conferire rigore alla documentazione di questa fase ha senza dubbio un livello di rischio di insuccesso molto alto. Ciò premesso, visto il successo ottenuto con il rigore nella produzione della documentazione dell’analisi, nell’ideologia del “lean thinking” ora si può estendere questa esperienza alle altre fasi del processo di sviluppo che producono documenti con semantica esprimibile più facilmente con rigore o addirittura con formalismo. Pertanto, è opportuno estendere la validazione empirica alla produzione degli altri contenitori della conoscenza del patrimonio comune di conoscenza nello sviluppo software. In particolare lo SDS ( Software Design Specification).