scroll-up

25 Maggio 2021
Da DOORS 9 classico a Engineering Requirements Management DOORS Next, un salto di tecnologia e di approccio

Da molti anni IBM Rational DOORS è da anni il leader indiscusso delle soluzioni di Requirements per le aziende Enterprise. Grazie a IBM Rational DOORS concetti come “database centralizzato”, la “tracciabilità”, la “classificazione tramite attributi” sono ormai consolidati nella gestione dei requisiti. IBM Rational DOORS nel tempo ha tracciato una chiara linea di demarcazione con il passato, seguendo in modo attivo non solo all’evoluzione delle metodologie di sviluppo Ingegneristico ma anzi contribuendo in modo attivo alla loro diffusione e standardizzazione.

Lo sviluppo tecnologico che ha portato alla disponibilità di risorse hardware e di connessione un tempo inimmaginabili, offre ora nuove opportunità che l’architettura di IBM Rational DOORS ovvero la versione 9 e successive, può solo cogliere in parte e talvolta volte con un poco di fatica.

La nuova piattaforma IBM per la gestione dei requisiti, ma non solo, IBM Engineering Lifecycle Management (ELM)  fornisce una soluzione integrata completamente web-based, con concetti applicati di Web 2.0. Questo permette di eliminare qualsiasi installazione lato client ed essere produttivi in tempi ancora più rapidi.

La piattaforma ELM garantisce l’accesso al mondo OSLC (IBM, open community Wikipedia) , ovvero di prestare il focus sull’informazione indipendentemente dall’applicazione, possibilità di adottare logiche di  Line Engineering Management, e trarre vantaggio dalla global configuration.

Nel caso non esistano vincoli specifici di progetto, di infrastruttura e di processo, per una prima adozione e per un progetto che nasce ex-novo la nuova soluzione ELM ed in particolare il componente che è corrispettivo a IBM Rational DOORS, ovvero Engineering Requirements Management DOORS Next Generation- IBM Watson IoT (DNG per comodità d’ora in poi) può effettivamente rappresentare la soluzione ampio respiro con uno sguardo al futuro e all’innovazione. Essendo DNG parte della nuova piattaforma gode nativamente dei vantaggi citati e non solo.

Certamente è difficile in poche righe descrivere gli effettivi vantaggi competitivi di DNG rispetto IBM Rational DOORS, ogni singolo aspetto meriterebbe un approfondimento dedicato, oggi invece vi vorrei presentare un particolare aspetto che è principalmente legato all’evoluzione del Data Model.

 

Data Model – da IBM Rational DOORS 9 a DNG: un deciso passo avanti

IBM Rational DOORS 9

In IBM Rational DOORS 9 ogni singolo Modulo formale è un modello di informazione indipendente: gli attributi sono definiti a livello di ogni modulo e l’uniformità del data model è di fatto lasciato alla disciplina degli utenti.

La tentazione di soluzioni estemporanee, modifiche ad hoc (“Cambiamo/aggiungiamo un valore ad un tipo enumerativo solo per questo caso poi normalizziamo…”) portano negli anni alla proliferazione degli attributi e alla deriva del data model inizialmente definito.

L’uso di moduli template, DXL dedicati spesso hanno permesso un maggior controllo però chiunque  ha sofferto prima o poi di incongruenza nelle analisi, reportistica, o nella generazione documentale per non parlare poi nello scambio dati tra progetti e db diversi.

A questa variabilità tra i vari moduli corrisponde l’uniformità all’interno di moduli: gli oggetti sono infatti tutti uguali, del resto gli oggetti in IBM Rational DOORS 9 esistono solo all’interno del loro modulo formale.

Gli attributi di oggetto hanno un valore per tutti gli oggetti di modulo: il modulo formale IBM Rational DOORS 9 è di fatto una tabella sparsa.

Avete mai fatto caso che IBM Rational DOORS 9, chiaramente uno strumento proprio , nativamente non sappia quale dei suoi oggetti siano requisiti?

La specializzazione degli oggetti avviene attribuendo una semantica specifica ad alcuni attributi (con nomi arbitrari: IsRequirement, Object Type, isreq?…).

Engineering Lifecycle Management – DOORS Next Generation (DNG)

L’approccio del data model in DNG è stato completamente rivoluzionato, con l’introduzione del concetto di Artifact Type.

Le informazioni in DNG sono organizzate in artefatti, ognuno con un proprio tipo definito in anticipo.

I tipi di artefatti classificano i requisiti (o i moduli) fornendo un insieme consistente di attributi per ogni tipo.

Avremo artefatti di tipo Information per contenere testo libero, Heading per titoli e dare struttura ai moduli, e tanti artifact type custom quanti ci servono: User Requirement, System Requirement…. Ad esempio:

Artifact type

(User defined)

Default format Artifact attributes Preferred link types
Requirements specification Module •        Approved by

•        Approver position

Information Text
Actor Text •        Status
Use -case diagram Use-case diagram •        Status
Business goal Text •        Priority

•        Status

System  requirement Text •        Accepted

•        Clarity

•        Mitigates

•        Satisfies

•        Satisfied by

Vision Text •        Status

•        Product owner

Use-case specification Text •        Status

•        Product owner

 

Gli artefatti base hanno vita proprio possono vivere in un modulo, in più moduli o senza nessun modulo.

Un modulo in DNG può contenere artefatti di tipo diverso.

Inoltre si possono definire relazioni di link tra i vari tipi di artefatti limitando le possibilità di collegamenti erronei o non voluti.

Ad esempio possiamo evitare che ci siano link da artefatti heading o imporre che tra User Requirement a System Requirement ci siano solo collegamenti di tipo Satisfies (indipendentemente dal modulo in cui gli artefatti siano presenti).

Quindi il Data Model di DNG offre diversi vantaggi:

  • Coerenza delle informazioni;
  • Maggiore controllo amministrativo sul data model (no entropia);
  • Attributi ad hoc a seconda del tipo di informazione;
  • Possibilità di usare artefatti diversi nello stesso modulo;
  • Possibilità di permettere solo le relazioni (links) definiti;
  • Template riproducibile nelle project area (o componenti).

 

IBM Rational DOORS 9, Vittima del proprio successo

Qui potrete trovare una comparazione tra IBM Rational DOORS 9 e DNG:

https://www.ibm.com/docs/en/elm/7.0.2?topic=next-comparison-doors-doors

 

I vantaggi, anche solo considerando il nuovo Data Model, sono evidenti, allora perché tutti gli itenti di IBM Rational DOORS 9 non migrano a DNG?

 

Proprio perché il Data Model di IBM Rational DOORS 9 e DNG sono concettualmente differenti non è possibile uno scambio di dati senza soluzione di continuità tra le due applicazioni.

 

Per dirla nel gergo dei veterani IBM Rational DOORS 9 non si possono scambiare archivi nativi D9 (.dma .dpa) con DNG!

Out of the box esiste un efficiente meccanismo di migrazione (su base ReqIF) che crea in IBM Rational DOORS 9 pacchetti di dati che poi DNG è in grado di ricreare nel proprio formato.

Questo porta i dati grezzi con precisione e permette di migrare un singolo progetto con soddisfazione.

Il vero limite di un approccio “a testa bassa” è che non esistendo il concetto di Artifact Type in IBM Rational DOORS 9 DNG creerà un artifact type (in realtà due, uno per il modulo e uno per l’oggetto) per ognuno dei moduli formali “migrati”, di fatto ricreando la situazione (e quindi il limite) originale di IBM Rational DOORS 9.

Usando questo meccanismo senza adeguata preparazione si perde la possibilità di usare efficacemente il data model definito in DNG. Il prezzo è non trarre vantaggio dai template di progetto, i report, generazione documentale specializzata, lo scambio tra project area, la global configuration…

La migrazione può spaventare realtà aziendali dove IBM Rational DOORS 9 è consolidato, a volte anche con complesse routine DXL.

Va anche aggiunto che per lo più i dipartimenti di ingegneria hanno dimenticato lo sforzo necessario a passare da Word/Excel a IBM Rational DOORS 9 (chi scrive è abbastanza anziano da averlo vissuto).

Il successo di IBM Rational DOORS 9 ha quindi  limitato quello che dovrebbe essere la normale evoluzione tendendo a sopravvalutare i costi di una migrazione rispetto agli evidenti benefici.

 

Un aiuto alla migrazione

Negli ultimi anni in IBM Rational DOORS 9 (da ver 9.6.1.3) è stato inserito uno strumento (Raccogli metriche di migrazione) che crea un report (in un modulo formale) con tante utili informazioni.

Ad esempio può fornirvi tutte le definizioni degli attributi di un progetto, potremmo scoprire ad es che un attributo (stesso nome, stesso tipo) ha esattamente la stessa definizione in quattro moduli ma in altri quattro presenta delle minime differenze in questo caso nei possibili valori:

La situazione è familiare, casi come questo sono potenzialmente problemi già in IBM Rational DOORS 9.

Di sicuro il tool di migrazione creerà in DNG diverse definizioni di Attributi (come potrebbe essere altrimenti?).

Consiglio a tutti di provare questo strumento di metriche, probabilmente ci saranno sorprese, ma questo vi darà la possibilità di intervenire: la manutenzione del data model è un valore di per sé.

Giusto a titolo di esempio in una recente migrazione gli attributi custom sono stati ridotti da oltre 100 a 12!

In DNG lo strumento di migrazione da IBM Rational DOORS 9 permette di usare un attributo (usato come una sorta di Tipo di oggetto) che permetta di mappare i moduli/oggetti di DOORS con gli artifact type precedentemente definiti in DNG.

Questo è essenziale per una migrazione di successo. L’attributo va creato (se non esiste) e se esistente integrato, in modo che copra tutte le definizioni dei dati da migrare. Infine va valorizzato per ogni singola istanza prima di creare il pacchetto di migrazione.

Questa attività di pre-process vi ripagherà con dati pronti a trarre i vantaggi della nuova piattaforma.

Un aiuto da chi ha già esperienza può aumentare l’efficacia di questa transizione. Possiamo collaborare fattivamente con voi per la migrazione, il nostro approccio è suddiviso in passaggi, in modo da poter mitigare i rischi e soprattutto garantirvi sempre la continuità operativa:

  • Analizzare i vostri processi e aiutarvi a trasferirli nella nuova piattaforma;
  • Analizzare con voi i vostri progetti e valutare come ridurre l’entropia attuale del data model;
  • Definire un data model più snello da usare in DNG;
  • Aiutarvi a portarlo in DNG per creare un Project Template riutilizzabile;
  • Assistervi nelle prime migrazioni;
  • Creare template per l’export documentale da DNG;
  • Formazione su DNG e ELM.

Fornire  script DXL ad hoc che:

  • Creino automaticamente gli URI per le definizioni nel data model di IBM Rational DOORS 9
  • “Normalizzino” gli attributi nei dati da migrare
  • Assegnino coerentemente un attributo Object Type che mappi l’Artifact Type del data model DNG

 

Omninecs Europe Ltd

Mi chiamo Luca Sentimenti, ho venti anni di esperienza nell’ambito del system engineering e in particolare nelle discipline del Requirements Management, faccio parte del  dipartimento di Systems Engineering di Omninecs Europe come specialista di Prodotto e Docente.