Adozione del framework COBIT 5

I precedenti articoli sono nati dall’esigenza di capire in modo approfondito il significato di IT Governance e di conoscere alcuni strumenti per la relativa gestione. Si è trattato, dunque, di una fase propedeutica e formativa in cui sono state descritte le necessità gestionali del settore IT di un’azienda e i framework, quali COBIT 5 e Scrum, che ne consentono la buona organizzazione e ottimizzazione.

Il passo successivo riguarda l’applicazione di tali modelli a situazioni reali. A tal proposito, qualche settimana fa, Insoftware è stata contattata da un’altra azienda per modificare e migliorare un sistema informativo in parte già esistente. Per convenzione chiameremo l’azienda committente “C-Scordia” e il responsabile del settore IT di tale azienda Ing. A.

Al fine di poter gestire opportunamente il lavoro commissionato ad Insoftware, è stato redatto un documento che contenesse il quadro generale del lavoro da portare a termine. Tale documento è composto da quattro sezioni:

  1. Descrizione del documento: viene indicato a cosa serve e a chi è rivolto. In questo caso, è diretto all’Ing.A. e al Resp. di Insoftware e serve a stabilire come si comporta il sistema informativo allo stato attuale, elencando quali modifiche devono essere apportate.
  2. Stato del prodotto: sono individuati gli stakeholder, è definito l’obiettivo del software e le sue caratteristiche, in quale contesto viene usato e quali sono le criticità che potrebbero comportare dei rischi.
  3. Pianificazione dei rilasci: che non è altro che una tabella in cui inserire orientativamente una data di rilascio per ognuno dei requisiti fondamentali da soddisfare.
  4. Specifica dei requisiti: in cui vengono descritti i casi d’uso e i requisiti da soddisfare. Per avere un quadro completo e dettagliato dei requisiti sono state usate due tabelle. La prima tabella elenca le macro funzionalità che devono essere implementate (sono da intendersi come dei corposi task). La seconda invece specifica i dettagli di ogni macro requisito, andando ad indentificare tutti i sotto-task da portare a termine per completare una funzionalità.

I campi della prima tabella sono:

  • Numero: identificatore univoco del requisito nel contesto del progetto
  • Tipo: classificazione del requisito (F-funzionalità, O-operatività, C-conformità, U-usabilità, S-sicurezza, T-tempi di progetto, B-budget di progetto, D-documentazione, manutenzione e supporto)
  • Descrizione: descrizione del requisito
  • Richiedente: chi ha richiesto il requisito
  • Data: data in cui il requisito è stato espresso
  • Importanza: importanza del requisito nell’ambito dello specifico progetto, dal punto di vista del richiedente (1. essenziale – 2. molto importante – 3. importante – 4. abbastanza importante – 5. secondario)
  • Priorità: priorità temporale attribuita dal richiedente per l’implementazione del requisito, utilizzabile dai progettisti in un’ottica di rilasci incrementali. (1. alta – 2. media – 3. bassa)
  • Criterio di verifica: descrizione del criterio di verifica utilizzabile da parte del richiedente per verificare l’aderenza del prodotto finale al requisito
  • Legame con altri requisiti: indica se il requisito ha relazioni con altri requisiti
  • Status: il grado di stabilità del requisito, articolato sulla base del ciclo di vita dei requisiti (P – proposto dal richiedente A – in attesa di dettagli indispensabili I – implementato V – verificato E – eliminato)

I campi della seconda tabella sono:

  • Numero: identificatore univoco del sotto-task nel contesto del progetto
  • Descrizione: descrizione del sotto-task
  • Importanza: importanza del sotto-task nell’ambito dello specifico progetto, dal punto di vista del richiedente (1. essenziale – 2. molto importante – 3. importante – 4. abbastanza importante – 5. secondario)
  • Priorità: priorità temporale attribuita dal richiedente per l’implementazione del sotto-task, utilizzabile dai progettisti in un’ottica di rilasci incrementali. (1. alta – 2. media – 3. bassa)
  • Specifiche del committente: dettagli aggiuntivi che l’Ing A. ritiene fondamentali per la buona implementazione del sotto-task
  • Status: il grado di stabilità del requisito, articolato sulla base del ciclo di vita dei requisiti (P – proposto dal richiedente A – in attesa di dettagli indispensabili I – implementato V – verificato E – eliminato)

Il documento è stato redatto in prima stesura dopo il primo incontro avvenuto tra l’Ing. A. e il responsabile di Insoftware, e successivamente modificato e dettagliato a seguito del secondo incontro.

Riferimenti

Modello di requisiti di un progetto – UniRoma

Elenco dei requisiti – adcorsi.com

 

Scrum e le Medotologie Agili

Nel modello  COBIT 5 si percepisce come l’interazione con gli stakeholder e la loro soddisfazione sia un punto focale per la buona riuscita di un progetto e per lo sviluppo di un’organizzazione. Lo stesso concetto viene sfruttato per la progettazione e lo sviluppo di software usando la Metodologia Agile. Questa è una branca dell’Ingegneria del software che individua un metodo basato sull’interazione continua con il commintente del prodotto.

Nel 2001 venne publicato il Manifesto Agile, il quale indicò i principi che dovevano essere rispettati da una metodologia per potersi definire Agile:

“Gli individui e le interazioni più che i processi e gli strumenti”
“Il software funzionante più che la documentazione esaustiva”
“La collaborazione col cliente più che la negoziazione dei contratti”
“Rispondere al cambiamento più che seguire un piano”

Nell’approccio classico alla gestione di attività di progetto, si segue un iter fatto da analisi dei requisiti, progettazione, sviluppo, test e manutenzione del prodotto software. Tale sistema è risultato spesso inadeguato alle esigenze del cliente. Infatti il committente del software, a progetto finito, poteva ritrovarsi con un prodotto che non era esattamente come avrebbe voluto. Il nodo della questione è la “traduzione” delle necessità del cliente da soddisfare in requisiti funzionali del software.

L’idea del Medoto Agile si basa sulla possibilità di realizzare un progetto per passi successivi, detti sprint. Ad ogni sprint si aggiungono funzionalità e si verifica la soddisfazione del cliente, mostrandogli il lavoro svolto fino a quel punto. Questo sistema iterativo consente di apportare agilmente modifiche al progetto, di evitare un fallimento a conclusione dello stesso e di abbattere i costi di produzione del software.

Il framework Scrum

Scrum è, con molta probabilità, il metodo agile più diffuso. Questo framework di project management usa gli sprint precedentemente citati per aggiustare il processo di sviluppo del software in modo coerente rispetto alle esigenze del committente. Generalmente queste iterazioni durano da 2 a 4 settimane. I componenti principali sono: roles, work products, activities.

I 4 work products (detti “artefatti”) di cui Scrum prevede la compilazione sono:

  • Product Backlog: è il documento che contiene tutti i requisiti funzionali dell’intero pregetto. È costituito da gruppi di item, a ciascuno dei quali è assegnata una priorità di svolgimento. È possibile inoltre indicare coloro che devono occuparsi degli item e approssimativamente in quanto tempo concluderli.
  • Sprint Backlog: definisce i task da completare all’interno di un singolo sprint. Diventa importante scegliere i task in base alla priorità assegnata nel Product Backlog e in base al tempo che si pensa di impiegare per portarli a termine.
  • Product Burndown: è un grafico che stima il lavoro svolto nelle iterazioni previste per la conclusione del progetto. Viene aggiornato alla fine di ogni sprint per monitorare l’andamento complessivo del lavoro.
  • Sprint Burndown: è un grafico in cui viene monitorato il progresso del lavoro svolto e quello ancora da svolgere (quantificato ad esempio in ore) all’interno di un singolo sprint.

Scrum prevede l’esistenza di 3 ruoli primari, quali:

  • Product Owner: è colui che porta avanti gli interessi di tutti gli stakeholder, realizzando la stesura del Product Backlog. Si occupa di stimare il valore del progetto, i tempi di consegna e se il prodotto finito sia accettabile o meno. Ha il compito di aggiustare i requisiti e le priorità ad ogni sprint ed è colui che si occupa dello Sprint Plannig (di cui si parlerà dopo). Tutti i partecipanti al progetto possono fare riferimento a questa figura per domande o precisazioni utili al completamento dei task.
  • Scrum Master: è colui che deve accertarsi che il team lavori in modo coeso ed efficiente. Deve preoccuparsi di eliminare ostacoli e interferenze che possano rallentare il lavoro e deve garantire che la medotologia Scrum venga seguita. È un componente del team stesso che ha il compito di garantire il successo dello sprint e deve gestire i Daily Meeting, ma non può modificare gli item e la loro priorità. In pratica, deve monitorare l’andamento del lavoro, verificando quotidianamente i task che vengono portati a termine.
  • Scrum Team: è un gruppo di sviluppatori e programmatori che portano a termine i task. Vanno da un minimo di 5 ad un massino di 9, e devono essere autonomi nella gestione del loro larovo. È compito di questo team produrre lo Sprint Backlog, identificando gli item di priorità maggiore e mutandoli in task da raggiungere in quel preciso sprint. Devono, inoltre, realizzare la stesura del Product Burndown e dello Sprint Burndown.

Le attività di project management invece sono:

  • Sprint Planning: è la riunione che viene fatta quando il Product Owner ha già stilato il Product Backlog, e, in presenza di tutti i componenti del team e dello Scrum Master, descrive gli item di maggior priorità. Sarà compito del team porre i giusti quesiti per affrontare al meglio i task. All’interno di questa attività viene fatta una descrizione dell’obiettivo che si cercherà di raggiungere nello sprint che sta per iniziare. Lo Scrum Team, dopo tale riunione, stilerà lo Sprint Backlog.
  • Daily Meeting: è un breve incontro mattutino di 15 minuti che avviene ogni giono allo stesso posto e alla stessa ora. Vi partecipano i componenti del team e lo Scrum Master, il quale annota il lavoro svolto il giorno precedente dagli sviluppatori e quello che porteranno avanti il giorno stesso. Non è usato per la risoluzione dei problemi, quanto per organizzare il lavoro quotidianamente e stilare lo Sprint Burndown.
  • Sprint Review: avviene alla fine di ogni sprint per valutare se l’obiettivo è stato portato a termine e con quali risultati. I partecipanti sono il Product Owner, lo Scrum Master, il Team e anche il committente, al quale verrà mostrata una demo del software con le funzionalità aggiunte durante lo sprint.
  • Sprint Retrospective: segue lo Sprint Review ed è necessario per apportare migliorie alla pianificazione del lavoro indicando cosa continuare a fare, cosa non fare più e cosa iniziare a fare per ottenere sprint sempre più efficienti.
  • Release Planning: lo Scrum Team, usando il Product Backlog, stila un documento non troppo dettagliato in cui pianifica le risorse necessarie per portare a termine il progetto come il numero di sprint, la durata di ognuni di essi, il numero di componenti del team.
Attività Scrum Sorgente: http://vijoy4.files.wordpress.com/2013/04/scrum3.jpg
Attività Scrum
Sorgente: http://vijoy4.files.wordpress.com/2013/04/scrum3.jpg

 

Si può facilmente dedurre come la difficoltà maggiore nell’impostare una medotologia agile come Scrum all’interno di un’azienda sia la realizzazione di questi documenti, che in genere possono essere implementati in fogli di calcolo. In realtà il problema può essere risolto usando opportuni tool, open source o a pagamento, disponibili su web come iceScrum, AGILEFANT, OpenProject o Jira.

Riferimenti
“Panoramica sulla IT Governance” – Stefano ROSSINI

“Scrum” – Wikipedia

“Metodologia Agile” – Wikipedia

“I principi sottostanti al Manifesto Agile”

“Processi e metodologie di sviluppo” – Stefano ROSSINI

“Agile methodology”

“Scrum” – Eclipse

“Scrum” – OpenWare.org

Il nucleo di COBIT

Nel precedente articolo è stato introdotto il mondo dell’IT Governance e le difficoltà che le imprese si trovano ad affrontare per la gestione dei sistemi informatici. In questo articolo verrà esaminato in dettaglio il framework COBIT, nella versione 5.

COBIT 5 nasce nel 2012 con lo scopo di fornire alle aziende, grandi o piccole, pubbliche o private, schemi e modelli che consentano di trasformare i costi dovuti all’infrastruttura tecnologica in benefici, economici e non. Esso è il frutto di più di un decennio di studi, aggiornamenti e utilizzi sul campo da parte dell’ISACA (Information Systems Audit and Control Association). Questo framework usa come punto di partenza per la definizione degli obiettivi di IT le esigenze degli stakeholder, che sono letteralmente i portatori di interesse economico per un’azienda.

IT is complicated. IT  Governance doesn’t have to be.

Questo motto, estrapolato da un documento introduttivo di COBIT, rende l’idea di come un’organizzazione  e un governo ottimale dell’IT semplifichino le attività di business. COBIT 5 supporta le aziende affinché raggiungano i loro obiettivi, sfruttando i benefici dei sistemi informatici e riducendone al minimo rischi e costi.

Questo framework si basa su cinque principi fondamentali, i quali sono elencati nell’immagine sottostante (estratta dalla documentazione ufficiale).

I cinque principi su cui si basa COBIT

I cinque principi su cui si basa COBIT

 

  1. Soddisfare le esigenze degli stakeholder

    COBIT 5 definisce una sequenza di obiettivi “a cascata” partendo proprio dalle esigenze e dalle aspettative degli stakeholder. Consente, quindi, di mappare tali requisiti con i processi aziendali, personalizzandoli e adattandoli a quel particolare stakeholder (o insieme di stakeholder). Permette così all’organizzazione di raggiungere i propri obiettivi gestendo rischi e ottimizzando le risorse a disposizione. Si tratta di una procedimento di tipo top-down attraverso cui generici requisiti vengono specializzati e assegnati alle opportune aree dell’azienda.

    Obiettivi COBIT a cascata
    Obiettivi COBIT a cascata

     

  2. Considerare l’Organizzazione nel suo complesso

    COBIT 5 descrive modelli di governance e management dell’IT in modo tale da poterli integrare completamente nella governance globale dell’organizzazione. In questa visione olistica di Governance sono citati i cosiddetti “attivatori” e i “ruoli“. I primi sono costituiti da tutte quelle risorse dell’organizzazione che consento il raggiungimento degli obiettivi aziendali. Si tratta quindi di processi, risorse umane, infrastrutture tecnologiche, informazioni e strutture senza cui sarebbe impossibile il funzionamento dell’azienda. I ruoli invece sono costituiti dalle persone, da come esse si rapportano tra loro e dalle responsabilità che hanno. Nella figura successiva vengono ben chiarite le relazioni tra i vari settori e viene anche anticipato il principio 5, in cui Management e Governace sono separati.

    Ruoli, attività e relazioni
    Ruoli, attività e relazioni

     

  3. Applicare un’infrastruttura integrata ed univoca

    COBIT 5 fornisce sia dettagliate descrizioni per attività ad alto livello che per piccoli sottoinsiemi. COBIT 5 può definirsi come  un’unica infrastruttura integrata perché ingloba la maggior parte di principi degli standard più usati oggi, riuscendo a coprire tutti gli aspetti di governance e di management. In sostanza, opportunamente adattato, può essere applicato in un qualsiasi aspetto dell’azienda.

  4. Adottare un approccio globale (olistico)

    Solo considerando nel complesso tutte le parte interagenti nell’organizzazione è possibile ottenere una governance e un management dell’IT ottimali. Gli attivatori, che influenzano l’andamento globale dell’azienda, sono guidati dagli obiettivi IT. In particolare COBIT individua sette attivatori:

    • Principi, policy e strutture: strumenti che consentono di definire le linee guida dell’organizzazione;
    • Processi: insieme di attività che hanno il compito di portare a termine dei task prefissati, in funzione degli obiettivi globali;
    • Strutture organizzative: gruppo di individui che decidono modi e tempi degli obiettivi da raggiungere;
    • Cultura, etica e comportamento: caratterizzano l’organizzazione e gli individui che la compongono;
    • Informazione: è l’insieme di dati che vengono prodotti ed elaborati in tutti i settori dell’azienda;
    • Servizi, infrastruttura e applicazioni: sono gli strumenti e le strutture informatiche che consentono la memorizzazione ed elaborazione delle informazioni;
    • Persone, abilità e competenze: sono le risorse fondamentali sia per prendere le decisioni sia per portare avanti le attività di un’organizzazione.

     

    Attivatori individuati da COBIT 5 e loro relazioni
    Attivatori individuati da COBIT 5 e loro relazioni

     

  5. Separare la governance dal management

    La Governance definisce gli obiettivi da raggiungere in accordo con lo stakeholder e monitora i processi valutandone le performance e verificando il rispetto della policy aziendale. Solitamente è attuata dal consiglio di amministrazione. All’interno di questo settore vengono individuati cinque processi, per ciascuno dei quali sono definite le pratiche di valutazione, direzione e monitoraggio (EDM). Il Management, invece, disciplina la parte più esecutiva, pianificando e monitorando le attività vere e proprie. Comprende le quattro aree di pianificazione, costruzione, esecuzione e monitoraggio (PBRM):

    • Allineamento, pianificazione e organizzazione (APO)
    • Costruzione, acquisto e implementazione (BAI)
    • Erogazione, servizio e supporto (DSS)
    • Monitoraggio, valutazione e rilevazione (MEA)

    COBIT 5 fa delle precise raccomandazioni riguardo tale distinzione tra management e governance, ma ciò che viene sottolineato maggiormente è che la struttura dell’azienda deve essere tale da gestire pienamente tutte le aree fondamentali di governance e management.

Divisione Governance Management
Divisione Governance Management

 

Per poter avere una panoramica generale di tutti i requisiti da soddisfare affinchè l’IT Governance risulti ottimale, viene pubblicata di seguito la scheda riassuntiva tratta dalla documentazione ufficiale.

Panoramica completa dei documenti da realizzare secondo COBIT 5 per ottenere un'efficace ed efficiente Governance IT
Panoramica completa dei documenti da realizzare secondo COBIT 5 per ottenere un’efficace ed efficiente Governance IT

Riferimenti

COBIT 5 Framework

COBIT 5 – Ing. Claudio CILLI

Stakeholder – Wikipedia

Cos’è l’IT Governance?

Le medie e grandi aziende che vivono in quest’epoca di “rivoluzione informatica” si trovano a fare i conti con la crescita troppo celere dell’Information and Communication Technology (il cui acronimo è ICT), di cui non possono assolutamente fare a meno. Con ICT si intende, infatti, l’insieme di programmi software e apparecchiature digitali che consentono la gestione, memorizzazione ed elaborazione di dati, insieme alle varie forme digitali di comunicazione.
Tale processo di sviluppo ha avuto grandi ripercussioni sulle richieste di mercato. Quindi la struttura tradizionale di un’azienda non può restare immutata, ma deve adeguarsi e diventare più dinamica e flessibile per evitare di rimanere indietro. Occorre passare da una struttura fondamentalmente verticale ad una più orizzontale, orientata ai processi. Poiché i cambiamenti che si dovranno affrontare non risulteranno facili, occorre usare metodi e strategie per non incorrere in fallimenti nella riorganizzazione dell’architettura aziendale.

A tale scopo nasce l’IT Governance, un insieme di regole e schemi che consentono la gestione ottimale di sistemi di Information Technology. È la capacità organizzativa di manager amministrativi ed esecutivi che consente di ottenere il compromesso migliore tra gli obiettivi aziendali e gli investimenti nei sistemi informativi.

L’IT Governance, in particolare, si occupa di:

  • Strategic Alignment/Allineamento Strategico: per garantire che gli obiettivi aziendali vengano supportati correttamente dall’IT;
  • Value Delivery/Erogazione del Valore: per assicurare che l’IT produca un ritorno economico;
  • Risk Management/Gestione del Rischio: per gestire i rischi degli investimenti IT;
  • Resource Management/Gestione delle Risorse: garantire che vengano rispettati i requisiti preposti con il minor utilizzo di risorse (umane ed economiche);
  • Performance Measurement/Misurazione delle Performance: valutare le prestazioni del sistema di IT.
Le cinque aree dell'IT Governance
Le cinque aree dell’IT Governance

L’IT Governance non è da intendersi né come un mero sistema di osservazione e valutazione, né come un regolamento che stabilisce esclusivamente ruoli e responsabilità. È piuttosto un processo che sfrutta direttive, standard e strategie affinché il settore dell’IT di un’azienda risulti efficace ed efficiente.
Talvolta accade che un’azienda adotti un IT Governance informale, non standardizzata, rischiando di fare investimenti sbagliati. Da quando si è capito che un buon governo dei sistemi informativi apporta notevoli migliorie nella gestione di un’azienda, sono stati pensati schemi di supporto che formalizzano l’IT Governance.

In particolare è stato identificato lo Standard ISO/IEC 20000, del 2005, che fu il primo standard per la gestione dei servizi informatici. In quanto tale, fissa i requisiti di qualità per i servizi erogati.

Il Control Objectives for Information and related Technology (il cui acronimo è COBIT) è invece un framework che si pone l’obiettivo di valutare se l’IT Governance di un processo produttivo è efficace. Diversamente può fornire uno schema per renderlo tale. Consente inoltre di organizzare le attività della funzione di IT di un’azienda secondo un modello di processi generalmente accettato.
COBIT è stato creato dall’ISACA (Information Systems Audit and Control Association) e dall’ITGI (IT Governance Institute ) ed è stato pubblicato nella prima edizione nel 1996, nella seconda edizione nel 1998. In realtà nasce come framework di verifica e controllo dell’IT. Nel 2000 viene rilasciato COBIT 3, che segna il passaggio a framework per la gestione IT. Altre due edizioni furono COBIT 4.0 nel 2005 e COBIT 4.1 nel 2007. L’ultima versione è stata rilasciata nel 2012 ed è COBIT 5.0.

Un’altra proposta di Governance è data da AGIT, che è l’acronimo di AGIle software developmenT. Si basa sulla metodologia Scrum ed è un modello per lo sviluppo software che limita il più possibile i fallimenti di tale processo di sviluppo. La continua interazione con il committente del software e la suddivisione del processo di sviluppo in molteplici step sono il fulcro di tale framework.

Riferimenti
“Panoramica sulla IT Governance” – Stefano ROSSINI
Corporate Governance – Wikipedia
IT Governance – Wikipedia
COBIT – Wikipedia
ITIL – Wikipedia
COSO & COBIT center – SOX
“Software per la gestione di infrastrutture IT secondo lo standard ITIL: un modello e una guida di valutazione” – Riccardo VOLANTE
Master “Audit e Governance nell’ICT” – Dario RUSSO
“IT Governance Model” – The Higher Ed CIO
Tecnologie dell’informazione e della comunicazione – Wikipedia
ISO/IEC 20000 – Wikipedia
FAQ COBIT – AEIA