Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

Transcript

1 Business white paper Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

2 Indice 3 Sommario esecutivo 3 Introduzione 3 Best practice a livello aziendale 5 Best practice a livello di progetto 7 Creare un software più efficiente 8 Conclusione

3 Sommario esecutivo Uno dei fattori essenziali nello sviluppo di applicazioni in grado di soddisfare le esigenze aziendali, è l esatta definizione dei requisiti effettivi sin dalla fase iniziale. È necessaria una stesura chiara e concisa dei requisiti, che incorpori tuttavia le informazioni ottenute dalle varie parti interessate. Le best practice, a livello aziendale e a livello di progetto, per la definizione e la gestione dei requisiti forniscono un aiuto nello sviluppo di progetti rispondenti alle metriche aziendali previste. Eliminando i divari esistenti tra i processi eseguiti nei diversi silos IT, i team potranno offrire rapidamente applicazioni in risposta ai cambiamenti dei requisiti dell azienda. Introduzione Uno dei maggiori ostacoli nella creazione di applicazioni in grado di soddisfare i requisiti dell azienda è la difficoltà di ottenere una definizione ben strutturata di tali requisiti. Quando i requisiti vengono definiti da un individuo o da un gruppo di persone al fine di soddisfare le esigenze di gruppi diversi di utenti, è possibile che alcune informazioni vengano perse o non correttamente trattate nel corso del processo. Quando si verifica una simile condizione, è possibile che alcuni difetti vengano introdotti inavvertitamente nell applicazione durante la fase iniziale del ciclo di vita e che non vengano individuati quando la loro eliminazione è ormai troppo onerosa. In realtà, i budget di molti progetti sono stati esauriti a causa di rielaborazioni dovute alla necessità di riallineare le applicazioni ai requisiti aziendali in evoluzione. La distribuzione geograficamente sempre più estesa dei team incaricati dei progetti (dovuta ad outsourcing, fusioni, acquisizioni e ad altri fattori), rende la comunicazione più complessa accentuando questa criticità. Inoltre le applicazioni su cloud, mobili e composite aumentano ulteriormente la complessità del processo di definizione dei requisiti e delle applicazioni stesse. Per effetto della rapida evoluzione dei requisiti aziendali, molte organizzazioni stanno adottando tecniche di sviluppo Agile che implicano la messa a punto dei requisiti sulla base delle informazioni ottenute direttamente dalle parti interessate man mano che il progetto progredisce. I cambiamenti devono essere tracciati e comunicati in tempo reale a tutti i membri del team e possono influire su un requisito approvato precedentemente. Best practice a livello aziendale Le prime tre best practice sono implementate a livello aziendale. Attraverso la standardizzazione di tutta l azienda, un linguaggio e una tracciabilità comuni e la creazione di requisiti ben definiti, che forniscano continuità durante tutto il ciclo di vita dell applicazione, diventano parte della cultura aziendale. Standardizzazione di tutta l azienda: standardizzando la gestione dei requisiti a livello aziendale potrete promuovere la collaborazione ed eliminare i silos tra analisti, team di sviluppo e Quality Assurance (QA). Un sistema unico per la gestione completa dei requisiti garantisce ai team di progetto una versione finale della realtà effettiva al fine di individuare le informazioni più aggiornate. Ciò si rivela particolarmente importante in quanto i requisiti cambiano nel tempo, sia per effetto dei mutamenti nelle condizioni del business sia perché studiati come parte di un processo di sviluppo iterativo come Agile. Un sistema unico di gestione dei requisiti consente inoltre un miglior controllo, fornendo al responsabile delle applicazioni e ad altri dirigenti visibilità sul completamento dei requisiti. Linguaggio comune: fornite linee guida coerenti per il linguaggio utilizzato nella definizione di tutti i requisiti in modo da facilitarne la stesura e l osservanza. Ciò evita un lavoro eccessivo di aggiunta di dettagli non necessari e l impiego di ulteriore tempo per ottenere maggiori informazioni quando le descrizioni sono troppo vaghe. Per l inglese raccomandiamo linee guida che richiedano: : L utilizzo di frasi semplici, all imperativo (ad esempio, include only flights from origin to destination on the departing flights list (nell elenco dei voli in partenza includere solo i voli dalla partenza alla destinazione)). L utilizzo del presente indicativo: in altre parole, considerare di aggiungere una s al verbo. (ad esempio, The system requires a single sign-on (il sistema deve richiedere una singola registrazione). Evitare i caratteri punto e virgola o congiunzioni (e, o). Inserire un requisito per frase facilita la valutazione e l assegnazione del processo di sviluppo e verifica. Evitare l uso di can o may ( può o potrebbe ). I requisiti che contengono questi verbi risulteranno troppo imprecisi. Di fronte a queste difficoltà, in che modo le organizzazioni IT possono offrire applicazioni che siano maggiormente allineate ai requisiti, ai budget e ai programmi di business? In questo white paper verranno esaminate best practice, a livello aziendale e di progetto, che consentano di ottenere requisiti applicativi ben definiti. Queste procedure forniscono un aiuto ai team che utilizzano Agile e altri processi iterativi nonché ai team che impiegano metodi a cascata tradizionali. Il miglioramento della definizione dei requisiti e dei processi di gestione consente di ridurre i tempi necessari per fornire progetti software e aumenta la probabilità di successo. 3

4 Un altra best practice che incoraggia l uso di un linguaggio comune per i requisiti, è fornire un modello o un insieme di modelli per la definizione dei requisiti. Seguire queste linee guida non solo renderà i requisiti più efficaci e facili da seguire, ma ne consentirà inoltre la misurazione della qualità. Le metriche qualitative includono: Righe di testo: il numero di righe di testo nel documento contenente i requisiti. Se esiste uniformità nella descrizione dei requisiti, questo criterio di valutazione consente all utente di stimare la funzionalità e il livello di test richiesti per il software. Imperativi: il numero di imperativi nelle diverse categorie quali shall, must e will. Il numero di imperativi offre una stima approssimativa del livello di funzionalità del progetto richiesto nel software. Offre inoltre una stima del livello di test richiesto per soddisfare queste necessità. Frasi deboli: il numero di frasi poco efficaci contenenti espressioni quali large, fast, enough ( grande, rapido, sufficiente ),ecc. Uno stile poco efficace indica requisiti di progetto non delineati con chiarezza che quindi non sono verificabili. Completezza: la percentuale di requisiti che non contengono espressioni quali TBD (to be determined) e TBS (to be specified) ( da determinare e da specificare ). I requisiti che contengono queste espressioni sono considerati incompleti. Espressioni di possibilità: numero di espressioni quali can, may, I/we think ( può, potrebbe, penso/pensiamo ) ecc. Queste espressioni indicano requisiti che potrebbero essere difficili da soddisfare nella fase di sviluppo. Tracciabilità: agevolate la tracciabilità durante tutto il ciclo di vita dell applicazione, per determinare se il progetto corrente soddisfa i requisiti. La possibilità di tracciare bidirezionalmente i collegamenti tra requisiti e test, nonché tra requisiti e codice, consente agli analisti business e ad altre parti interessate di verificare che l ambiente IT offra quanto previsto dal business. Pone i requisiti alla base dei test per l applicazione, permettendo al team incaricato dell assicurazione di qualità (QA) di effettuare una verifica rispetto ai criteri definiti dal business. La tracciabilità da requisito a codice, consente agli sviluppatori il riutilizzo nel caso sia necessaria una funzionalità simile in applicazioni diverse. Per il team QA, la tracciabilità garantisce la registrazione della copertura del test case associato ai requisiti di business, essenziale per la segnalazione del difetto. La tracciabilità fornisce inoltre al responsabile incaricato delle applicazioni e ad altri dirigenti, la visibilità delle metriche di progresso più importanti, ovvero il livello di efficacia dell applicazione nel soddisfare le esigenze dell azienda. Tra le metriche di tracciabilità sono inclusi: Requisiti tracciati: il numero di requisiti tracciati verso o da ogni specifica. Requisiti non tracciati: numero di requisiti che non sono tracciati. Requisiti tracciati in modo non costante: numero di requisiti che vengono tracciati in modo non costante. Collegamenti: numero di collegamenti verso l alto e verso il basso per ogni requisito. Ciò consente di determinare il riutilizzo e l impatto dei cambiamenti sull applicazione nel complesso. Copertura: percentuale di requisiti tracciati per test superati, test non superati o test non eseguiti. 4

5 Best practice a livello di progetto Le successive quattro best practice si applicano a livello di progetto. L adozione di queste best practice apporta chiarezza al processo di definizione dei requisiti e aiuta ad eliminare le rielaborazioni nella fase di sviluppo e di test delle applicazioni. Inoltre, aiutano ad eliminare l eccesso di lavoro e le rielaborazioni nel processo stesso di definizione dei requisiti. Essere essenziali: non create asset di requisiti se non forniscono un valore effettivo al team incaricato dell applicazione. Gli asset con maggior valore saranno quelli riutilizzabili. Un approccio essenziale include l automatizzazione dei processi e l eliminazione degli sprechi. Un organizzazione sistematica dei requisiti, facilita l individuazione dei requisiti necessari e di quelli eliminabili. La standardizzazione del contenuto dei requisiti, mediante l uso di modelli e di un linguaggio comune, contribuisce a facilitarne la comprensione e ad eliminare le rielaborazioni. Iterazione: create iterativamente requisiti per generare feedback, promuovere la collaborazione e permettere ai team di identificare i difetti nelle fasi iniziali del ciclo di vita di sviluppo del software. Una best practice consiste nell avviare il processo con un requisito aziendale di livello elevato descrivendo chi necessita della funzionalità, per quale scopo e perché. Quindi, anziché lavorare in modo isolato, l analista business che scrive il requisito deve rivolgersi di nuovo ai soggetti interessati per ottenere informazioni in merito all efficacia descrittiva delle esigenze aziendali da parte del requisito di livello elevato. Gli sviluppatori devono inoltre fornire feedback sulla presenza di sufficienti informazioni per avviare la codifica. Se le informazioni risultano insufficienti, l analista deve eseguire analisi più approfondite per aggiungere ulteriori dettagli. Ma se le informazioni sono sufficienti, gli sviluppatori inizieranno il processo di sviluppo. Figura 1 HP ALM Coverage Analysis fornisce una tracciabilità in tempo reale di tutti gli elementi del ciclo di vita, tra cui attività, test e difetti. Requisiti diversi richiederanno livelli diversi di dettaglio. Risparmiate tempo e riducete la complessità fornendo il livello adeguato di elaborazione. Non è necessario descrivere eccessivamente requisiti facilmente comprensibili. 5

6 Quando in un progetto vengono effettuate iterazioni della definizione dei requisiti, è importante misurare il punto e la modalità di cambiamento di tali requisiti nel tempo. Tra i criteri di valutazione dei cambiamenti sono inclusi: Instabilità: il numero di requisiti aggiunti, eliminati e modificati classificati per motivo di cambiamento. Requisiti iniziali assegnati: il numero di requisiti tecnici e non tecnici originariamente forniti dal cliente. Questo criterio, insieme ai requisiti finali assegnati e alle modifiche per requisito, descrive in termini quantitativi il cambiamento dei requisiti. Requisiti finali assegnati: numero di requisiti tecnici e non tecnici utilizzati per creare il prodotto software finale. Modifiche per requisito: numero di modifiche apportate a ciascun requisito. Modifiche nel tempo: ad esempio numero di modifiche alla settimana. Questo criterio descrive il livello di instabilità dei requisiti. Verso la fine del ciclo di vita del software il numero deve ridursi a indicare la convergenza dei requisiti. Causa della modifica: la classificazione delle cause delle modifiche consente di identificare i motivi comuni che hanno portato alla modifica e può essere utilizzata per migliorare il processo. Origine della modifica: l identificazione dell origine della modifica (ovvero, chi ha richiesto la modifica), aiuta a prevedere in anticipo le origini di possibili modifiche future. Visualizzare: talvolta un immagine è realmente più efficace di mille parole. Utilizzate la visualizzazione per migliorare la comprensione dei requisiti nonché delle dipendenze tra requisiti. La visualizzazione facilita l identificazione dei potenziali problemi quali la mancanza di use case. Inoltre le immagini possono essere più facili da leggere ed esplorare dei requisiti basati su testo. I team che non desiderano seguire la procedura Agile di scrittura del codice in una fase precoce del processo, possono utilizzare la visualizzazione e le simulazioni per ricavare feedback anticipati al fine di raggiungere molti degli obiettivi previsti. Collaborare: per ottenere requisiti corretti, collaborate ed eliminate i silos tra gruppi fin dall inizio del processo. Ad esempio, sebbene un analista business possa avere ben chiaro il punto di vista dell utente riguardo a cosa dovrebbe rappresentare uno specifico requisito, la collaborazione con il team di sviluppo fornirà la visione necessaria a capire se l implementazione del requisito è realizzabile. Figura 2 Gli asset di requisiti che possono essere riutilizzati, ad esempio modelli di processi aziendali (Business Process Model, BPM) utilizzabili per generare requisiti, forniscono il maggior valore. 6

7 Creare un software più efficiente HP Application Lifecycle Management (ALM) è una piattaforma unificata scalabile che consente all IT di gestire l intero ciclo di vita dell applicazione, collegando i rilasci delle applicazioni dalla proposta di progetto alle operazioni di implementazione. Fornisce una funzionalità di gestione completa dei requisiti in un sistema unico al fine di allineare i team incaricati del progetto. HP ALM consente ai team di: Utilizzare modelli per requisiti e importare materiale da fonti originali in formati conosciuti dai business analyst, tra cui documenti Microsoft Word e Microsoft Excel. HP ALM fornisce un editor con funzionalità complete di elaboratore di testi (simile a Microsoft Word) per la modifica di use case e requisiti strutturati. Tracciare i requisiti per progettare i piani e creare gli indicatori prestazionali chiave (Key Performance Indicator, KPI) per l elaborazione dei requisiti. L analisi della copertura fornisce una tracciabilità in tempo reale di tutti gli elementi del ciclo di vita, tra cui attività, test e difetti. Generare automaticamente un framework del piano di test dai requisiti con tracciabilità completa, per consentire al team QA di verificare che cosa conta maggiormente per l azienda. HP ALM genera automaticamente una documentazione dei requisiti aziendali in formati personalizzati, distribuibile ai dirigenti e ad altri membri appropriati dell azienda. Riutilizzare gli asset di requisiti tramite l integrazione di HP ALM con molti strumenti di altri fornitori. Gli analisti business possono importare layout e mockup dell interfaccia utente nonché business process model (BPM). HP ALM identifica tutti i percorsi di progetto di un BPM e genera automaticamente requisiti per ogni percorso e fase del modello, risparmiando il tempo legato alla traduzione manuale. Gestire i requisiti per i dati allegando tabelle dati di Microsoft Excel. HP ALM supporta l organizzazione chiara dei requisiti con la possibilità di elencare i requisiti funzionali, non funzionali e per i dati. Adottare un approccio iterativo alla definizione dei requisiti utilizzando la gestione delle versioni a livello di requisito e lungo l intero processo. Creare e confrontare linee di base per identificare i cambiamenti tra generazioni, cicli e impegno. HP ALM offre la possibilità di far progredire i requisiti dai concetti iniziali al requisito reale, con convalida appropriata. Utilizzare numerose forme di visualizzazione dei requisiti tra cui modelli del processo, mockup di schermate, diagrammi di flusso dei dati e mappe delle funzionalità. Collaborate con altri team utilizzando un sistema unico per la gestione completa dei requisiti con accesso globale basato su Web. HP ALM fornisce la gestione delle versioni di tutte le definizioni di requisiti in un ampio archivio per un accesso e una collaborazione congiunti tra i team. Figura 3 Immagini e mockup di interfaccia utente possono essere più facili da leggere e comprendere rispetto alle descrizioni basate su testo. 7

8 HP Requirements Management è integrato in HP ALM per offrire una piattaforma unica e accessibile da browser per analisti aziendali, project manager, progettisti, sviluppatori, incaricati dei test e vicepresidente delle applicazioni. I requisiti gestiti in HP ALM sono visibili agli interessati principali durante l intero ciclo di vita dell applicazione nonché disponibili all istante per gli sviluppatori negli ambienti IDE più diffusi, quali Microsoft Visual Studio e Eclipse. È possibile rappresentare viste dashboard per tutti gli interessati in termini di relazioni con i requisiti (ad esempio la capacità di determinare quali moduli di codice sorgente per sviluppatore o test case soddisfano specifici requisiti). Ciò fornisce il contesto di business a tutte le aree di distribuzione dell applicazione. Dato che le modifiche di un requisito possono influire in modo significativo sugli altri requisiti e a sua volta su codice e test, tali modifiche possono essere gestite in tempo reale in HP ALM. Inoltre ognuna di queste modifiche può essere annullata poiché l intero sistema dispone del controllo delle versioni a livello operativo, fattore critico per una collaborazione globale. Conclusione Dopo l adozione di queste best practice, è molto probabile che i progetti soddisfino le metriche di business previste, inclusi budget, programmi e soddisfazione del cliente. Eliminando i divari esistenti tra i processi operativi eseguiti nei silos IT, HP ALM consente ai team di offrire rapidamente applicazioni in risposta ai cambiamenti dei requisiti dell azienda. Un azienda del settore sanitario a livello globale ha recentemente migliorato la gestione dei requisiti nell ambiente ERP. Grazie a HP Requirements Management, sono stati in grado di: Specificare e collegare i requisiti, facilitando la determinazione e l identificazione delle relazioni esistenti tra i diversi requisiti. Associare i requisiti a test case e codice, determinando un collegamento tracciabile alla definizione dei requisiti corrispondenti. Associare i difetti alle esecuzioni di test, al fine di vedere quali requisiti ne sono influenzati analizzando nel dettaglio esecuzione dei test, test case e requisiti collegati. Fornire un rapporto visivo che descriva nel dettaglio lo stato di tutti i test per identificare i livelli di qualità e i rischi associati. Passare a un ambiente di documentazione dei requisiti privo di documenti cartacei. Tutto ciò ha consentito ai team applicativi di garantire una tracciabilità più completa, agevolando la verifica della conformità ai requisiti e del collaudo positivo di tutto il materiale sviluppato. Grazie a una migliore comunicazione e collaborazione, gli analisti, i team di sviluppo, di QA e di progetto, hanno ottenuto una visione più chiara di ciò che doveva essere realizzato, riuscendo in tal modo a sviluppare un software perfettamente allineato alle aspettative del business e dell utente. Una poco lungimirante definizione dei requisiti aziendali aumenta la percentuale d errore e nuoce al business. Monitorate la qualità, evitate il rework e raggiungete i vostri obiettivi visitando hp.com/go/rm Restate connessi hp.com/go/getconnected Le tendenze tecnologiche, le novità e le soluzioni HP per il successo del tuo business Condividete questo documento con i vostri colleghi. Copyright 2011 Hewlett-Packard Development Company, L.P. Le informazioni contenute nel presente documento sono soggette a modifiche senza preavviso. Le sole garanzie per i prodotti e i servizi HP sono previste espressamente nella garanzia che accompagna tali prodotti e servizi. Nessuna affermazione contenuta nel presente documento può essere ritenuta un estensione di tale garanzia. HP non è responsabile per errori tecnici o editoriali oppure omissioni contenuti nel presente documento. Microsoft è un marchio registrato USA di Microsoft Corporation. 4AA3-6360ITE, Creato Ottobre 2011; Modificato Aprile 2012, Rev. 1