Modellazione del flusso di lavoro più interazione con un database: opzioni rapide e accessibili

3

Sto cercando di modellare una linea di produzione (proposta), con particolare attenzione all'interazione con un database di tracciabilità. Cioè, vari ingegneri di processo hanno già mappato il processo di produzione - sono interessato solo alle varie stazioni lungo la linea che devono parlare al DB.

Il pubblico previsto è una combinazione di project manager, ingegneri e personale IT: lo scopo è identificare:

  • punti in cui la linea interagisce con il DB (forse arrivando a indicare gli Store Proc chiamati in ogni punto, forse anche quali parametri vengono passati.)
  • la fonte di comunicazione (PC / dispositivo palmare / PLC)
  • il mezzo di comunicazione (wireless / fibra / rame)
  • controllo del flusso (se il test di tenuta fallisce, l'unità viene deviata verso la stazione di riparazione)

Fondamentalmente, il modello sarà usato come focus sui diversi gruppi sulle attività in sospeso; per esempio, sono interessato al DB e qualsiasi app di front-end necessaria, i tecnici di processo devono pensare al flusso di lavoro e ai contatti con i fornitori di PLC, gli altri IT devono assicurarsi di avere l'hardware e le comunicazioni in atto .

Ovviamente potrei improvvisare in Visio, ma mi chiedevo se esistesse una particolare tecnica di modellazione che potesse adattarsi in particolare alle mie esigenze o al mio pubblico. Sto pensando a un modello visivo con documentazione di supporto (il meno possibile, per quanto necessario).

Chiaramente, non voglio qualcosa che richiederà anni per imparare (efficacemente), né uno che possa alienare membri non tecnici del team di progetto.

Finora ho avuto un breve sguardo su BPMN, EPC Diagrams, diagrammi di flusso standard ... e ho dimenticato la maggior parte di ciò che conoscevo di UML ... E non sono contrario al picking e al mixing. .. finché è veloce, chiaro ed efficace.

Conclusione:
Alla fine, ho optato per un diagramma quasi-workflow / flusso di dati. Ho mappato le parti del processo di produzione che interagiscono con il DB di tracciabilità e indicato in una forma significativamente semplificata, i flussi di dati e l'attività del DB. Accanto a ciò, ho un documento di supporto che descrive ogni processo, i dati che vengono scambiati per ogni processo (un "dizionario di dati" di sorta) e dettagli sull'hardware e sulla connettività richiesti.

Non posso decidere se sia un prodotto di genio o un crimine contro le pratiche di sviluppo del software, ma io faccio penso che colpirà il bersaglio per questo particolare pubblico.

    
posta cjmUK 18.01.2011 - 16:49
fonte

4 risposte

2

Sarà difficile produrre un diagramma di dettagli sufficienti per soddisfare manager, ingegneri e personale IT. I tecnici IT vorranno conoscere i parametri sproc, gli ingegneri saranno preoccupati per i casi di guasto e i gestori saranno annoiati da tutti i dettagli e cominceranno a giocherellare con i loro Blackberrys.

Qual è il punto della presentazione? Hai detto -

the model will be used as a focus different groups on outstanding tasks; for example, I'm interested in the DB and any front-end app needed, process engineers need to be thinking about the workflow and liaising with the PLC suppliers, the other IT guys need to make sure we have the hardware and comms in place.

Innanzitutto, pensa alla presentazione come a una mappa, non a un piano di progetto . Rendilo abbastanza semplice da poter essere compreso dai manager, e puoi essere certo che anche gli ingegneri e gli addetti all'IT lo capiranno. (Il contrario non è vero.)

Secondo, usa il diagramma più semplice e più ovvio possibile . Annota il diagramma con note a piè di pagina per i dettagli, in modo che il diagramma non diventi ingombrante o cresca troppo.

Suppongo che lo scopo della presentazione iniziale sia per raggiungere una comprensione di gruppo comune del progetto generale . A tal fine, suggerisco di utilizzare le immagini di ogni componente con le linee di fulmine per indicare i punti dell'interazione DB (non ingombrare il diagramma con un gruppo di icone DB, o provare a legare tutte le linee di interazione a un'icona DB, che ingombrerà il diagramma e non aggiungerà alcun valore). Basta inserire un numero a piè di pagina su ciascuna linea di interazione e stampare le note a piè di pagina su una pagina separata come riferimento. Non visualizzare le note a piè di pagina sulle diapositive della presentazione, ma parlarne e fare riferimento allo schema. Rendi disponibili le note a piè di pagina come dispense o inseriscile / inviale via email. Mantieni il pubblico concentrato sulla comprensione del quadro generale. Lascia che i focus group elaborino i dettagli una volta raggiunta una comprensione comune.

    
risposta data 19.01.2011 - 05:04
fonte
1

Cercare di trovare un singolo modello per comunicare efficacemente un intero sistema è un compito da scemo. So che RUP è caduto in disgrazia con gli Agilisti. Ma penso che il vero problema sia lo stesso problema che vedo con alcuni progetti Agile. Le persone hanno tentato di utilizzare un approccio senza comprenderlo appieno.

Hai detto che vuoi solo creare tutta la documentazione necessaria per comunicare efficacemente il design al pubblico. Questo è RUP in poche parole. Non è necessario compilare tutti gli artefatti nel catalogo. Fornisce solo una serie di artefatti e modelli come punto di partenza per la comunicazione. Spetta all'individuo decidere quali sono necessari.

C'è un ottimo libro, Agile Modeling , che discute questo approccio (chiamato eXtreme Unified Process), scritto di Scott Ambler.

Modifica: non l'ho ancora letto, ma sembra esserci anche un libro gemello su Agile Modeling chiamato Documentazione agile

    
risposta data 18.01.2011 - 17:53
fonte
1

Sembra che tu voglia coprire sia l'architettura fisica che quella logica. Quindi usa semplicemente quello che ti è più semplice e assicurati che l'etichetta e i tasti siano chiari!

    
risposta data 18.01.2011 - 18:46
fonte
1

Omondo ha fatto un tentativo ambizioso di coprire l'integrazione fisica (ad es. database) e logica (ad esempio l'oggetto UML) creando un profilo Database. Ho usato lo strumento e devo ammettere che ha funzionato davvero bene. L'idea è di creare annotazioni java nel codice live sincronizzate con gli stereotipi del modello e del database.

Quello che mi piace di questo strumento è il supporto completo per il gioco. Dall'oggetto al database e dal database al modello. Semplicemente meraviglioso per me !!

    
risposta data 19.01.2011 - 10:51
fonte

Leggi altre domande sui tag