ELECTRONIC RECORDS MANAGEMENT SOFTWARE APPLICATIONS DESIGN CRITERIA STANDARD Pasquale Puzio

1. ELECTRONIC RECORDS MANAGEMENT SOFTWARE APPLICATIONS DESIGN CRITERIA STANDARDPasquale Puzio

2. INTRODUZIONE Si tratta di un documento rilasciato dal Dipartimento della Difesa degli Stati Uniti contenente una dettagliata analisi dei requisiti per lo sviluppo di software gestionale da utilizzare all'interno delle agenzie del Dipartimento. Nome ufficiale: DoD 5015.02-STD I requisiti sono divisi in due categorie principali: Requisiti obbligatori Requisiti facoltativi

3. DEFINIZIONI Ciclo di vita: ai dati viene associato un periodo all'interno del quale sono validi e vengono utilizzati, dopo di che vengono considerati obsoleti e non sono più utilizzabili Congelamento: periodo nel quale uno o più record vengono resi inutilizzabili e non cancellabili a causa della necessità di eseguire degli approfondimenti o investigazioni Ritenzione: periodo nel quale un record deve essere “conservato” prima di poter essere eliminato

4. ACRONIMI COTS (Commercial off the shelf): prodotti software pronti all'utilizzo e acquistabili al dettaglio SOA (Service Oriented Architecture): architettura software orientata ai servizi NARA (National Archives and Records Administration): organismo Statunitense che si occupa di promuovere standard interni per la gestione dei dati RMA (Records Management Application): software per la gestione dei dati, in altre parole l'oggetto di questa analisi dei requisiti

5. Obiettivi principali (1) Gestione dei dati e dei metadati Retrocompatibilità con i software di tipo RMA utilizzati in precedenza Interoperabilità con altri software e web services Sicurezza (Controllo degli accessi, livelli di privilegio, ecc.) Gestione degli eventi e azioni pianificate Supporto all'importazione e alla metadatazione dei formati più diffusi (JPEG, PNG, PDF, DOC, ecc.)

6. Obiettivi principali (2) Backup e Recovery Alta tolleranza ai guasti (anche in caso di danni fisici) Supporto all'esportazione (importazione) nei (dai) formati non proprietari più diffusi e human-readable (es. XML) Supporto al versioning dei dati

7. Gestione dei dati e dei metadati Un utente può (tramite interfaccia desktop o web) selezionare, ordinare, cancellare, aggregare, stampare qualsiasi record (ovviamente sempre nel rispetto dei diritti che gli sono stati accordati). Un utente (se ne ha il diritto) può modificare, creare, eliminare qualsiasi metadato associato ai record.

8. Retrocompatibilità I file ottenuti dall'esportazione dei dati da altri RMA devono essere utilizzabili dall'RMA utilizzato attualmente senza perdere alcuna informazione. E' ammessa la perdita di alcune informazioni solo relativamente alla gestione degli eventi.

10. Interoperabilità Avere un software che sia in grado di interoperare sia con altri software interni con lo scopo di garantire la condivisione delle informazioni tra tutti i settori del dipartimento e delle varie agenzie, che con servizi esterni come ad esempio web services. Deve essere possibile infatti creare delle “pipe” di servizi con cui componendo l'input e l'output dei vari servizi si ottiene un servizio più complesso.

14. Sicurezza Con un sistema sofisticato deve essere possibile definire ruoli e diritti per ciascun utente autorizzato ad accedere al sistema, riducendo al minimo la granularità dei diritti concessi. E' espressamente richiesta infatti l'autenticazione mediante username e password ma è consigliato l'utilizzo di altre forme di autenticazione, ad esempio di tipo biometrico.

16. Attività pianificate Deve essere possibile pianificare alcuni attività in modo ricorrente (es. ogni giorni, ogni settimana, ecc.) oppure in relazione all'occorrenza di un altro evento. In questo requisito rientra anche il supporto ai trigger.

17. Attività pianificate Eliminazione record non più validi Backup Trigger

18. Metadatazione dei file Per ciascun tipo di file (tra quelli più comunemente utilizzati) è richiesta una specifica metadatazione.

19. Metadatazione dei file Ad esempio per un Web record (es. file scaricato dalla rete): Record Identifier File name Web Platform (es. browser utilizzato) Website name Website URL Capture method Capture date Contact

20. Backup L'RMA deve prevedere backup periodici in varie locazioni in modo tale da permettere il ripristino anche dopo un guasto molto grave causato ad esempio da un disastro naturale. Inoltre l'RMA deve essere in grado qualora non riesca a recuperare il 100% dei dati di individuare con precisione i dati che ha recuperato con successo e i dati che sono andati persi totalmente o parzialmente.

23. Supporto ai formati human readable non prorietari L'RMA deve essere in grado di esportare e importare i dati utilizzando formati human readable e non proprietari (es. XML, HTML, ecc.) per garantire una maggiore interoperabilità e indipendenza dalla piattaforma.

25. Versioning L'RMA deve fornire un'interfaccia per l'accesso alla versione più recente dei dati ma anche alle versioni precedente.

27. Requisiti facoltativi (1) Visualizzazione dello spazio di memoria (secondaria) ancora a disposizione Documentazione per l'utilizzo del software Performance tali da ritenersi “soddisfacenti” (nessuna indicazione precisa) Supporto ai più comuni protocolli di comunicazione per il trasferimento dei file (SMTP, HTTP, ecc.) Gestione e archiviazione delle caselle email degli utenti Documentazione e supporto reperibile e consultabile anche online Supporto all'utilizzo di codici a barre per la codifica delle operazioni interne

28. Requisiti facoltativi (2) Descrizione dei processi di business e del flusso di lavoro (workflow) utilizzando strumenti standard quali UML Possibilità di gestione dei dati non solo con un software desktop ma anche con un'applicazione web based.

29. Verifica di conformità allo standard JITC (Joint Interoperability Test Command), un'agenzia governativa con lo scopo di promuovere l'affidabilità e l'interoperabilità del software, ha stabilito una serie di test per certificare il possesso da parte di un software di tipo RMA di alcuni requisiti. Queste procedure sono indicate in specifici documenti reperibili online e consistono in particolari benchmark che devono soddisfare alcuni risultati minimi. Un RMA prima di poter essere proposto deve dimostrare di aver superato con successo questi test.

30. Software Standard Compliant (1) E' reperibile online anche una lista aggiornata al mese di Dicembre del 2010 di alcuni software che hanno superato con successo i test citati in precedenza. Ne sono circa 35/40 e tra tutti spiccano i nomi di Hawlett-Packard, IBM, Alfresco, SAP e Oracle oltre che numerose altre aziende meno “diffuse”. Emerge con chiarezza che oltre il 90% di questi software è sviluppato su piattaforme con sistema operativo MS Windows Server, DBMS MSSQL Server (eccezion fatta per IBM e Oracle con i rispettivi DB2 e Oracle 11g) e client di posta MS Outlook.

31. Standard Software Compliant (2) Si distinguono solo le aziende: Alfresco Software che propone una soluzione con sistema operativo Red Hat Linux e DBMS MySQL. SAP che propone una soluzione con sistema operativo Sun OS e DBMS MaxDB.

32. Esempio di ciclo di vita di un record (1) • In questo esempio prenderemo in considerazione un dossier su una possibile minaccia internazionale analizzando il suo ciclo di vita attraverso le varie fasi di cui abbiamo parlato in precedenza. • Il documento in questione è una presentazione PDF che descrive la minaccia WikiLeaks.

33. Esempio del ciclo di vita di un record (2)

34. Esempio del ciclo di vita di un record (3) • Il record viene catalogato:

35. Esempio del ciclo di vita di un record (4) • Il file relativo al record viene archiviato su una memoria permanente:

36. Esempio del ciclo di vita di un record (5) • Il record viene classificato:

37. Esempio del ciclo di vita di un record (6) • Si crea l’evento di distruzione del record: • “Elimina il record dopo 10 anni dalla sua declassifcazione”

38. Esempio del ciclo di vita di un record (7) • Il record viene trasmesso da un soggetto ad un altro:

39. Esempio del ciclo di vita di un record (8) • Il record viene declassificato in base all’evento creato al momento della sua creazione.

40. Esempio del ciclo di vita di un record (9) • Il record viene eliminato

41. Considerazioni Si tratta sicuramente di un insieme di requisiti che, se correttamente implementati, permettono di avere a disposizione un sistema completo e complesso per la gestione di tutti i dati gestiti all'interno di un'azienda. Quindi si tratta di requisiti che sono applicabili non solo alle esigenze delle agenzie del Dipartimento della Difesa Americano ma anche di qualsiasi azienda di notevoli dimensioni con grandi moli di dati da gestire e controllare.

42. Riferimenti Tutto il materiale di cui si è parlato è reperibile ai seguenti indirizzi: Electronic Records Management Software Applications Design CriteriaStandard (il documento di cui si è parlato in questa presentazione): http://jitc.fhu.disa.mil/recmgt/ JITC Testing (un insieme di test per verificare la conformità di un RMA ai requisiti di cui abbiamo parlato):http://jitc.fhu.disa.mil/recmgt/pp.html Lista dei Software Standard Compliant:http://jitc.fhu.disa.mil/recmgt/register.html Una raccolta delle direttive del Pentagono in ambito informatico: http://www.js.pentagon.mil/whs/directives/corres/dir.html

43. Domande Grazie per l'attenzione. DOMANDE ?