Toward a Concern-Oriented Analysis Method for Enterprise Information Systems (2006)
Considero questo articolo un punto di partenza importante della mia ricerca su concerns, faccette e modellazione concettuale, sviluppata poi con Crenguța Bogdan mediante le ontologie. Il lavoro propone un metodo per individuare e analizzare gli interessi e le preoccupazioni degli attori di un sistema informativo secondo quattro prospettive: sociale, informativa, funzionale e tecnologica.
Dati bibliografici
Autori: Crenguța Bogdan, Luca Dan Șerbănați
Titolo originale: Toward a Concern-Oriented Analysis Method for Enterprise Information Systems
Pubblicazione: IEEE International Multi-Conference on Computing in the Global Information Technology (ICCGI 2006), Bucarest, Romania, IEEE Computer Society, pp. 30–35.
Contributo concettuale
- Definisce una specificazione di alto livello di una concern, collegando problema e ruolo del portatore di interesse.
- Propone quattro attività: identificazione, classificazione, analisi delle relazioni e definizione delle priorità delle concerns.
- Organizza l’analisi secondo le prospettive sociale, funzionale, informativa e tecnologica.
- Descrive un sistema informativo mediante quattro categorie fondamentali: agente, attività, strumento, oggetto.
- Illustra il metodo attraverso un caso di studio della pubblica amministrazione romena.
Descrizione approfondita
Il punto di partenza dell’articolo è che lo sviluppo di un sistema informativo non può essere interpretato esclusivamente come attività di programmazione. Ogni sistema viene concepito e installato all’interno di un’organizzazione reale — impresa o istituzione — nella quale esistono problemi, necessità, ostacoli e aspettative. Prima di formulare requisiti software è quindi indispensabile comprendere tale contesto.
Gli autori propongono di analizzare il sistema attraverso le concerns dei diversi stakeholder: interessi, responsabilità e preoccupazioni rispetto alla costruzione o all’evoluzione del sistema. Comprendere una concern significa riuscire a descriverla tramite una specificazione di alto livello, che associa il problema considerato ai ruoli delle persone che manifestano quella preoccupazione.
Un elemento particolarmente significativo è il modello di base del sistema informativo. Il lavoro distingue quattro tipi di entità: agente, attività, strumento e oggetto. È uno schema concettuale cui attribuisco un’importanza speciale, perché offre un quadro semplice ma rigoroso per collegare le preoccupazioni degli attori alla struttura e al funzionamento del sistema.
Il metodo comprende quattro passi: individuare le concerns, classificarle, identificare le relazioni che le legano e attribuire priorità alla loro risoluzione. L’articolo si concentra soprattutto sui primi due passi, cruciali quando si raccolgono e si organizzano i requisiti. La classificazione avviene attraverso quattro prospettive complementari, senza imporne una come decomposizione dominante.
La prospettiva sociale considera bisogni, interessi e responsabilità di dirigenti, utenti, progettisti e altri attori coinvolti nei processi organizzativi. La prospettiva funzionale riguarda le attività che il sistema deve sostenere o automatizzare. La prospettiva informativa lo interpreta come deposito distribuito di dati, informazioni e conoscenze. Infine, la prospettiva tecnologica prende in considerazione infrastrutture ICT, piattaforme e prodotti software necessari al funzionamento.
L’articolo mostra che una concern non è soltanto un’etichetta associata genericamente a un desiderio. La sua specificazione collega il problema, lo stato di partenza, il risultato atteso e il ruolo dello stakeholder. Un esempio riguarda l’introduzione di una nuova tecnologia informatica e le conseguenze che questa può avere sull’organizzazione del lavoro.
Il caso di studio è tratto dalla pubblica amministrazione romena e riguarda un ufficio incaricato della gestione dei certificati fiscali. Attraverso l’esempio vengono individuati gli attori interessati, gli obiettivi istituzionali e le concerns che emergono da ciascuna prospettiva. Per i limiti di spazio propri dell’articolo, alcune concerns sono elencate senza una specificazione completa; l’esempio dimostra comunque l’applicabilità del metodo a un problema operativo.
Nella parte conclusiva viene proposta anche una classificazione generale delle concerns in due categorie: quelle orientate a ottenere qualcosa di nuovo utilizzando il sistema e quelle orientate a verificare, convalidare o dimostrare proprietà e situazioni attese. La distinzione anticipa una tipologia dei diversi scopi dell’analisi dei requisiti.
Collocazione nella ricerca
Considerato retrospettivamente, questo articolo non è importante soltanto per il metodo che enuncia, ma anche per la linea di ricerca che prepara. Le nozioni di specificazione di alto livello, prospettiva, vocabolario degli stakeholder e classificazione delle concerns vengono riprese nei successivi studi svolti con Crenguța Bogdan sulle ontologie di dominio e sulla costruzione delle faccette dei sistemi informativi.
Vi riconosco tre principi che ho sostenuto a lungo nell’insegnamento dell’ingegneria del software: iniziare l’analisi dagli interessi degli attori; descrivere sistematicamente tali interessi; usare più prospettive complementari per comprendere un sistema complesso. Per questo considero il lavoro del 2006 il testo d’origine della serie che conduce alle ontologie e alle viste multifaccettate.
Collegamenti
Figure dell’articolo
Miniature: fare clic per ingrandire le immagini
Fig. 1. Relazioni di dipendenza fra le credenze relative alla concern C4.
Fig. 2. Classificazione secondo DOLCE + D&S dei concetti associati alle concerns C1–C4.
Fig. 3. Credenze che stanno alla base della concern C4.
Fig. 4. Estratto dell’ontologia dei criteri di selezione dei partecipanti.
