Progettate / disegnate / disegnate prima una soluzione di sviluppo e poi la sviluppate? Se é cosi, come? [chiuso]

Question

Lavoro molto con i decisori che cercano di usare meglio la tecnologia nelle loro attività. Ho scoperto che un'immagine vale più di mille parole e la prototipazione di un sistema in un diagramma di qualche tipo presta sempre molto alla discussione. Ho usato Visio, UML (in qualche modo), mappe mentali, diagrammi di flusso e WinForms simulato per avviare la visione di questi sponsor per garantire che tutti fossero sulla stessa pagina. Mi sembra sempre di cercare quel processo comune che può essere utilizzato per intrecciare la visione aziendale al processo di sviluppo in modo che tutti finiamo alla stessa estremità, " Qualcosa di funzionale che risolve un problema " .

Sto cercando suggerimenti o note di Cliff su come affrontare il processo di progettazione in modo che funzioni per applicazioni che possono richiedere solo una settimana per essere sviluppate, ma possono anche essere utilizzate per includere anche progetti più grandi.

So che questo approfondisce l'area di UML, ma ho scoperto che non riesco a trovare una guida per utilizzare in modo appropriato i vari tipi di diagramma, per non parlare di aiutare gli utenti aziendali a capire i diagrammi e ad essi.

Cosa usi per catturare una visione di un sistema / applicazione da presentare agli sponsor di un progetto? (tutto prima di scrivere una singola riga di codice) ...

Answer 1

Carta o lavagna!

Per chi deve essere solo, consiglierei la carta. Almeno all'inizio, alla fine potresti voler formalizzare con UML, ma non credo sia necessario.

Per un gruppo di sviluppatori che lavorano insieme (fisicamente), consiglierei una lavagna. In questo modo è visibile a tutti e tutti possono migliorare e contribuire. Ancora una volta, potresti voler formalizzare a questo punto, ma ancora non penso che sia necessario

Quando ho iniziato a fare OOP (o progettando un algoritmo), facevo tutto nella mia testa durante la programmazione. Ma dopo aver fatto alcuni progetti ragionevolmente complessi, vedo sicuramente il vantaggio nel disegnare le interazioni tra diversi oggetti in un sistema.

Faccio progetti da solo, quindi uso molte schede per progettare classi e documenti per le loro interazioni. Il punto è che deve essere facile da cambiare. Ho giocato con Dia, un editor di diagrammi, per fare UML, ma apportare modifiche è troppo difficile. Voglio essere in grado di apportare modifiche rapide, così posso capire cosa funziona meglio.

Vale la pena ricordare che TDD e realizzare progetti "spike" [1] possono aiutare anche nella progettazione di un sistema.

[1] Da Extreme Programming Adventures in C #, pagina 8:

  

" Spike " è un termine di programmazione estrema   che significa "esperimento". Usiamo la parola   perché pensiamo a un picco come a   esperimento rapido, quasi a forza bruta   mirato ad imparare solo una cosa.   Pensa di farmi un grosso chiodo attraverso a   bordo.

Answer 2

Per compiti piccoli o molto limitati, penso che gli sviluppatori siano quasi universalmente d'accordo sul fatto che qualsiasi tipo di diagramma sia un passaggio non necessario.

Tuttavia, quando si ha a che fare con un sistema più grande e più complicato, specialmente quando due o più processi devono interagire o è necessaria una logica aziendale complessa, Diagrammi attività di processo può essere estremamente utile. Usiamo metodi agili abbastanza puri nello sviluppo e scopriamo che questi sono quasi l'unico tipo di diagrammi che usiamo. È incredibile quanto sia possibile ottimizzare un design di alto livello semplicemente avendo tutti i pezzi grandi di fronte a te e collegandoli con le linee di flusso. Non posso sottolineare abbastanza quanto sia importante personalizzare il diagramma per il tuo problema, non viceversa, quindi mentre il link fornisce un buon punto di partenza, aggiungi semplicemente ciò che ha senso rappresentare il tuo sistema / problema.

Per quanto riguarda l'archiviazione, la lavagna può essere ottima per il brainstorming e quando l'idea è ancora in fase di perfezionamento, ma direi che l'elettronica e una wiki sono migliori una volta che l'idea sta prendendo una forma abbastanza definitiva (OmniGraffle è il re dei diagrammi se sei abbastanza fortunato da poter usare un Mac al lavoro :). Avere un'area in cui scaricare tutti questi diagrammi può essere estremamente utile per qualcuno di nuovo per avere una rapida comprensione di un pezzo complessivo del sistema senza dover scavare attraverso il codice. Inoltre, poiché i diagrammi di attività rappresentano blocchi logici più grandi, non c'è il problema di doverli sempre aggiornare. Quando apporti una grande modifica a un sistema, allora sì, ma si spera che probabilmente usi il diagramma esistente per pianificare comunque la modifica.

Answer 3

Leggi le 4 + 1 Visualizzazioni di Kruchten.

Ecco un modo per procedere.

1. Raccogli i casi d'uso in un diagramma dei casi d'uso. Questo mostrerà attori e casi d'uso. Il diagramma non inizia con molti dettagli.

2. Dai la priorità ai casi d'uso di concentrarsi su casi d'uso di alto valore.

3. Scrivi narrazioni. Se lo desideri, puoi disegnare diagrammi di attività.

Quanto sopra è completamente non tecnico. UML impone alcune regole sulle forme da utilizzare, ma a parte ciò, puoi descrivere le cose nella terminologia dell'utente finale.

1. Puoi fare analisi dei nomi, disegnando diagrammi di classe per illustrare le entità e le relazioni. Inizialmente, questi saranno nella terminologia dell'utente. Nessun contenuto tecnico geek.

2. È possibile espandere i diagrammi di attività o aggiungere diagrammi di sequenza per mostrare il modello di elaborazione. Ciò inizierà con rappresentazioni di elaborazione non tecniche dell'utente finale.

3. È possibile scorrere i diagrammi di classe e attività per passare dall'analisi alla progettazione. Ad un certo punto, ti sarai spostato dall'analisi alla modalità di ingegneria. Gli utenti potrebbero non voler vedere tutte queste immagini.

4. È possibile disegnare diagrammi di componenti per la vista di sviluppo e diagrammi di distribuzione per la vista fisica. Queste verranno ripetute mentre la tua concezione del sistema si espande e si perfeziona.

Answer 4

Durante la progettazione di un'applicazione (creo principalmente applicazioni Web, ma questo vale per gli altri), in genere creo user story per determinare esattamente ciò di cui l'utente finale ha veramente bisogno. Questi costituiscono i "requisiti aziendali" tipici

Dopo che le storie utente sono state inchiodate, creo diagrammi di flusso per tracciare i percorsi che le persone seguiranno quando usano l'app.

Dopo quel passaggio (che a volte ottiene un processo di approvazione) creo schizzi di interfaccia (penna / matita e carta millimetrata) e inizio il layout dei database. Questo e il passaggio successivo sono in genere il processo che richiede più tempo.

Il prossimo passo è prendere gli schizzi e trasformarli in wireframe ripuliti. Uso OmniGraffle per questo passaggio: sono anni luce avanti rispetto a Visio.

Dopo questo, potresti voler fare diagrammi UML tipici o altri layout di oggetti / organizzazione di funzionalità, ma gli uomini d'affari non si preoccuperanno così tanto di quel tipo di dettagli :)

Answer 5

Quando sto mettendo insieme un design, mi occupo di trasmettere le idee in modo chiaro e semplice al pubblico. Quel pubblico è composto da (in genere) persone diverse con background diversi. Quello che non voglio fare è entrare in "modalità di insegnamento" per un particolare modello di design. Se devo dedicare molto tempo a dire al mio cliente cosa significa la freccia con la testa solida e come è diversa da quella che è vuota o cosa significa un quadrato rispetto a un cerchio, non sto facendo progressi - almeno non i progressi Voglio farlo.

Se è ragionevolmente informale, lo disegnerò su una lavagna o su un blocco di carta e al massimo con semplici frecce. Il punto del progetto approssimativo a questo punto è assicurarsi che siamo sulla stessa pagina. Tuttavia, varierà a seconda del cliente.

Se è più formale, potrei estrarre uno strumento UML e mettere insieme alcuni diagrammi, ma soprattutto i miei clienti non scrivono software e sono probabilmente solo marginalmente interessanti nelle viscere. Lo manteniamo alla "bolla e linea" livello e potrebbe mettere insieme alcuni elenchi puntati dove è necessario un chiarimento. Il mio cliente non vuole vedere diagrammi di classe o qualcosa del genere, in genere.

Se dobbiamo mostrare alcune interazioni con la GUI, metterò insieme alcuni semplici prototipi di finestre in Visual Studio: è semplice e veloce. Ho scoperto che il cliente può identificarsi abbastanza facilmente.

In breve, produco disegni semplici (in qualche formato) in grado di comunicare il disegno alle parti interessate e agli stakeholder. Mi assicuro di sapere cosa voglio che faccia e, cosa ancora più importante, di cosa HANNO BISOGNO di fare e di parlarne. In genere non entra nelle erbacce perché la gente si perde lì e non trovo il tempo ben speso per tracciare tutto all'ennesima potenza. Alla fine, se io e il cliente (e tutte le altre parti interessate) siamo sulla stessa pagina dopo aver parlato del progetto, sono un ragazzo felice.

Answer 6

Sono un ragazzo Agile, quindi tendo a non dedicare molto tempo alla creazione di diagrammi. Ci sono certamente momenti in cui disegnare qualcosa su una lavagna bianca o un tovagliolo ti aiuterà a capire un problema o requisito particolare, ma nulla è davvero meglio avere un software funzionante di fronte a un cliente in modo che possano vedere come funziona. Se ti trovi in ??una situazione in cui i tuoi clienti accetterebbero ripetute iterazioni e dimostrazioni sul design frontale, dico di provarci. È ancora meglio se vanno bene ottenere feedback in anticipo sotto forma di superamento di test unitari o di integrazione (qualcosa come Fit funziona bene qui).

In genere non mi piacciono i prototipi, perché troppo spesso il prototipo diventa il prodotto finale. Ho avuto la sfortuna di lavorare su un progetto che stava sostanzialmente estendendo un'offerta commerciale che si è rivelata una "prova del concetto" che è stato confezionato e venduto. Il progetto è stato annullato dopo che oltre 1000 difetti sono stati registrati sull'applicazione principale (senza contare i miglioramenti o le personalizzazioni su cui stiamo attualmente lavorando).

Ho provato a usare UML e ho scoperto che, a meno che la persona che guarda i diagrammi non capisca UML, sono di scarso aiuto. I mock-up dello schermo non sono generalmente una cattiva idea, ma mostrano solo il lato dell'applicazione che influenza direttamente l'utente, quindi non ottieni molto chilometraggio per tutto ciò che non è presentazione. Stranamente strumenti come il designer del flusso di lavoro in Visual Studio producono diagrammi abbastanza chiari che sono facili da comprendere per i non sviluppatori, quindi è un buon strumento per generare un flusso di lavoro delle applicazioni di base, se l'applicazione è abbastanza complessa da trarne vantaggio.

Tuttavia, di tutti gli approcci che ho usato nel corso degli anni, nulla batte un utente che mette le mani su qualcosa per farti sapere quanto bene capisci il problema.

Answer 7

Suggerisco di leggere gli articoli di Joel su " Specifiche funzionali indolori " ;. La parte 1 è intitolata " Why Bother? & Quot; .

Utilizziamo Mockup Screens al lavoro (" Prototipi di schermate facili e veloci "). È facile modificare gli schermi e gli scetch chiariscono che questo è solo un design.

I modelli sono quindi inclusi in un documento di Word contenente le specifiche.

Answer 8

Da Blockbusting concettuale: una guida per idee migliori di James L. Adams:

  

I blocchi intellettuali si traducono in un   scelta inefficiente di tattiche mentali   o una carenza di intellettuali   munizioni. . . . 1. Risolvere il   problema usando una lingua errata   (verbale, matematico, visivo) - come   nel tentativo di risolvere un problema   matematicamente quando può più facilmente   essere realizzato visivamente

(pag. 71, 3a edizione)

Inutile dire che se si sceglie di utilizzare diagrammi per catturare idee che potrebbero essere meglio catturate con la matematica, è altrettanto male. Il trucco, ovviamente, è trovare la lingua giusta per esprimere sia il problema che la soluzione. E, naturalmente, può essere appropriato usare più di una lingua per esprimere sia il problema che la soluzione.

Il mio punto è che stai assumendo che i diagrammi siano il modo migliore per andare. Non sono sicuro che sarei disposto a fare questa ipotesi. È possibile ottenere una risposta migliore (e il cliente potrebbe essere più felice del risultato) tramite altri metodi di definizione dei requisiti e progetti proposti.

A proposito, Conceptb Blockbusting è una lettura altamente raccomandata.

Answer 9

Il consiglio UML funziona bene se stai lavorando su un & amp; progetto avverso al rischio con molte parti interessate e molti collaboratori. Anche su quei progetti, aiuta davvero a sviluppare un prototipo da mostrare ai decisori. Di solito è sufficiente guidarli attraverso l'interfaccia utente e una tipica user story. Detto questo, devi stare attento che concentrarsi sull'interfaccia utente per i responsabili delle decisioni tenderà a far loro trascurare alcuni importanti problemi di backend come convalide, regole aziendali e integrità dei dati. Tenderanno a scrivere questi problemi come "tecnici" problemi piuttosto che decisioni commerciali.

Se invece stai lavorando a un progetto Agile in cui è possibile apportare rapidamente modifiche al codice (e errori di rollback rapidamente), potresti essere in grado di realizzare un prototipo evolutivo con tutte le opere. L'architettura dell'applicazione deve essere sufficientemente flessibile e flessibile da supportare il cambio rapido (ad es. Modello di progettazione di oggetti nudi o MVC in stile Rails). Aiuta ad avere una cultura dello sviluppo che incoraggia la sperimentazione e riconosce che BDUF non è un predittore di lavorare con software di successo.

Answer 10

Le visualizzazioni 4 + 1 sono valide solo per le persone tecniche. E solo se sono abbastanza interessati. Ricordi quelle ultime dozzine di volte in cui hai faticato a discutere i diagrammi dei casi d'uso con il cliente?

L'unica cosa che ho scoperto che funziona con tutti è infatti mostrare loro schermate della tua applicazione. Hai detto te stesso: un'immagine vale più di mille parole.

Curiosamente, ci sono due approcci che hanno funzionato per me:

1. Presenta agli utenti un manuale utente completo (prima ancora che inizi lo sviluppo), OPPURE
2. Usa mockup che non assomigliano per niente all'app finita: discuti prima le schermate principali della tua app. Quando sei soddisfatto, procedi discutendo dei modelli, ma uno scenario alla volta.

Per l'opzione (1) puoi usare quello che vuoi, non importa davvero.

Per l'opzione (2) è del tutto corretto iniziare con carta e penna. Ma presto starai meglio usando uno strumento di mockup specializzato (non appena devi modificare, mantenere o organizzare i tuoi mockup)

Ho finito per scrivere il mio strumento di simulazione nel 2005, è diventato piuttosto popolare: MockupScreens

Ed ecco l'elenco più completo di strumenti di simulazione che conosco. Molti di questi sono gratuiti: http://c2.com/cgi/wiki?GuiPrototypingTools