Puoi considerare la "documentazione linguistica onnipresente" come un progetto di personalizzazione del software: devi prendere del software per la gestione della documentazione e adattarlo alle tue esigenze specifiche. Nei progetti software di solito inizi a raccogliere le esigenze degli utenti, quindi sviluppi l'architettura delle informazioni e la soluzione di progettazione e poi procedi all'implementazione. Di seguito è riportato l'esempio di questo processo.
Di cosa hanno bisogno gli utenti? In alcune organizzazioni persone con funzioni diverse da domini diversi desiderano utilizzare il dialetto in linguaggio comune per descrivere i loro problemi e soluzioni. Questo dialetto sarà definito esclusivamente dal suo vocabolario (parole e figure retoriche), poiché la pronuncia probabilmente qui non è importante e la grammatica si baserà sulla forma letteraria della lingua. Per documentare il dialetto, è necessario progettare una struttura di documentazione che sarà la più adatta per la gestione di un vocabolario (glossario dei termini).
Le persone potrebbero voler utilizzare questa documentazione per apprendere il significato della parola o acronimo, per trovare la parola corretta dal suo sinonimo o definizione o per imparare tutte le parole che compongono il dominio.
Per queste esigenze degli utenti, wiki è davvero una buona scelta. Come si adatta? In un buon sistema wiki come Confluence o MediaWiki è possibile:
- Crea un articolo per ogni termine.
- Definire la struttura comune degli articoli in alcuni modelli, in modo che contengano alcune sezioni comuni, che possono essere utilizzate per l'aggregazione.
- Aggiungi facilmente collegamenti alle definizioni dei termini in altri articoli wiki.
- Crea tabelle aggregate con definizioni di termini e incorporale in altra documentazione.
Attualmente sto usando Confluence per documentare l'architettura dell'informazione e le definizioni di linguaggio onnipresente ne fanno parte. Il livello più alto di questa documentazione sono gli articoli di dominio. In ogni applicazione ci sono più domini, ad esempio sicurezza, pagamenti ecc. Questi domini sono definiti da una serie di interazioni dell'utente con il sistema, che possono essere descritte tramite un linguaggio onnipresente, quindi inserisco le definizioni di queste interazioni in pagine secondarie separate e definizioni dei termini introdotti da queste interazioni nelle sottopagine delle pagine di interazione. Ho inserito tabelle aggregate nelle pagine padre in modo che sia possibile vedere, ad esempio, quali scenari sono costituiti dal dominio e quali termini sono definiti in esso.
Quando questa struttura della documentazione è terminata e vado a specifiche di sistema più dettagliate, posso semplicemente fare riferimento alle definizioni IA e UL degli scenari, ad es. "Il componente A implementa l'integrazione con il sistema B per supportare l'interazione C (collegamento dello scenario IA) passando informazioni su Z (collegamento UL) ".