2009-06-19 13 views
7

Vorrei sapere quali strumenti e standard sono utilizzati dai miei colleghi per i documenti tecnici di progettazione al giorno d'oggi.Strumenti e norme per il documento di progettazione tecnica

In passato, quando nella mia azienda fornivamo solo win-app client-server, avevamo i modelli di parole per i nostri documenti di progettazione. I nostri modelli iniziarono sempre con il diagramma Database, poi i mockup UI, i mapping dei campi, la descrizione delle funzionalità, ecc ... Con Word e Visio ne avevamo abbastanza. Ma ultimamente stiamo combinando wiki, diagrammi UML, strumenti di prototipazione, ecc. Senza una politica veramente forte per gli standard e gli strumenti. Pensi che sia un bene dare agli architetti la libertà di scegliere l'insieme di strumenti e standard che trovano adatti in un dato momento per progetto o l'azienda dovrebbe far valere e affermare su questo?

+0

Sfortunatamente, nessuno ha risposto alla tua domanda. Sono qui a navigare per qualcosa di più nuovo e più bello di Visio :) –

risposta

1

Il motivo alla base di qualsiasi documentazione di progettazione è la comunicazione chiara a tutti i soggetti coinvolti. Quindi da quel punto di vista, qualunque strumento tu scelga come architetto, il prodotto finito deve essere letto sia da tutti i soggetti coinvolti, sia dai manutentori. Ha quindi senso selezionare almeno alcuni strumenti abbastanza standard, che saranno ancora in giro in pochi anni.

Detto questo, i documenti di progettazione vengono generalmente utilizzati per far funzionare il progetto o il sistema. Successivamente, codice ben documentato e alcuni documenti di base dovrebbero essere sufficienti. Probabilmente farei più attenzione all'organizzazione della tua documentazione, in modo che le persone possano trovare facilmente ciò che stanno cercando in futuro. Può aiutare a rafforzare una sorta di struttura/sistema di archivio standard per l'archiviazione della documentazione, ma non necessariamente insistere su tutti i tipi di modelli per la documentazione. Concentrati sul contenuto e non sugli strumenti.

0

A meno che i tuoi progetti non siano cookie cutter, ha senso solo applicare la migliore combinazione di strumenti per il lavoro da svolgere. Detto questo, sono probabilmente giustificate alcune norme vaghe (linee guida approssimative) o strette (applicate a circostanze specifiche).

1

Una discussione approfondita tra i principali sviluppatori o membri del team (probabilmente registrati per dopo) è molto più preziosa di qualsiasi documento, a mio parere. Offri loro la libertà di scegliere i loro strumenti e chiedi loro solo di scrivere un breve riassunto delle decisioni tecniche di alto livello all'inizio. Questo può essere il fondamento della documentazione più avanti nel progetto. Un documento di progettazione tecnica diventa obsoleto troppo presto e richiede troppo tempo per scrivere.

1

Penso che ci dovrebbe essere un set di strumenti e standard che sono specificati in fase di architettura che descrive come la progettazione dovrebbe essere documentata. È molto importante avere uno standard per documentare queste cose; altrimenti, tendono a cadere sul ciglio della strada; e se la documentazione di progettazione è eterogenea, c'è il pericolo che le persone che hanno davvero bisogno di sapere di più sul design possano non essere in grado di trovare le informazioni di progettazione di cui hanno realmente bisogno quando ne hanno davvero bisogno.

Detto questo, la scelta degli strumenti e degli standard dipende interamente da ciascuna organizzazione; qualunque cosa funzioni per un'organizzazione è giusta per loro. Finché c'è coerenza negli standard (e gli strumenti, in una certa misura), tutto ciò che viene scelto per una singola organizzazione è giusto per loro. Deve solo essere deciso e applicato.

Problemi correlati