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

 

Una risposta a “Adozione del framework COBIT 5”

  1. Buon pomeriggio Veronica,

    AIEA Associazione Italiana Information Systems Auditors, che rappresento, sta progettando un gruppo di ricerca COBIT5 in ambito Pubblica Amministrazione.

    Le chiederei cortesemente di mettersi in contatto con me tramite email.

    Grazie
    Fabrizio B.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *