Come progettare/pianificare lo sviluppo di applicazioni Web?

Question

Sono interessato a imparare come progettare/pianificare lo sviluppo di applicazioni Web, in uno scenario di team di sviluppatori multipli.

Assumendo il ruolo di "Project Manager/Lead":

1. cosa "documenti" sono necessari per lo sviluppo di applicazioni web di successo?
2. Quali diagrammi UML sono necessari e in quale misura?
3. Nella fase di progettazione/pianificazione, ciascuno - come per caso d'uso - classe deve essere schematizzato?
4. Quanto dettagliato (profondità e larghezza) dovrebbero essere i diagrammi delle classi?

Se si dispone di consigli utili su libri/siti Web, si prega di condividere.

---

Follow-up (Aggiunto 11/18/09): Cosa codificatori/sviluppatori di utilizzare come guida durante la codifica vale a dire la creazione di classi, e le loro rispettive metodi & proprietà?

Se non esiste un elenco completo (ma mutevole) di classi con i loro metodi e proprietà, non è questa ambiguità a fare grande affidamento sulla conoscenza/esperienza di ogni codificatore, con conseguenti deviazioni in termini di qualità/usabilità/manutenibilità del codice ?

Answer 1

1. In tutti i casi è necessario disporre di una registrazione completa e aggiornata dei requisiti esatti. Ciò include sia i requisiti functional e nonfunctional. Può essere un documento Word, un foglio di calcolo o un sistema di requisiti specializzato. Hai solo bisogno di qualcosa che ti permetta di tenere traccia di tutti i requisiti e di come sono cambiati nel tempo. Here's a good source of info and discussion sui documenti dei requisiti Agile.
2. In base alla mia esperienza, i diagrammi dei casi d'uso si sono dimostrati importanti, poiché anche i diagrammi dei componenti e di implementazione sono utili. Anche i diagrammi di classe e di sequenza possono essere utili, ma nella maggior parte dei casi penso che dovrebbero essere usati più come linee guida mutabili di base rispetto ai requisiti di sviluppo immutabili. Classi e metodi sono in genere soggetti a modifiche (specialmente se si utilizza TDD) e, se si desidera realmente un diagramma, è meglio aggiornarlo dopo aver sviluppato il codice piuttosto che archiviare il codice per adattarlo ai diagrammi.
3. Non penso che ogni classe abbia bisogno di essere diagrammata. Penso che i diagrammi di classe dei modelli possano essere utili per tenere traccia di dove si trovano i dati, e occasionalmente anche alcuni diagrammi di controllori e classi di viste sono utili. Ma nella maggior parte delle mie esperienze, i requisiti e casi di test sono stati la principale fonte di direzione nel modo in cui le classi sono stati progettati, e sono refactoring come il sistema cresce e cambia.
4. Nelle classi modello, non penso che siano necessari di solito più degli attributi. Se modellate le classi di controller, è generalmente consigliabile includere sia i principali attributi sia i metodi.

Answer 2

dipende dal tipo e la dimensione del web app. Se stai facendo un piccolo sito web di e-commerce, con un carrello della spesa allora probabilmente spendere più sforzo sul lato progettazione di cose e meno sulla funzionalità "app". Al contrario, se si sta creando un sito Web interno di grandi dimensioni con molte schermate di immissione dei dati, la maggior parte del tempo verrà speso nella logica aziendale e nelle regole dei dati.

Personalmente, io non sono un credente in formati spec rigidi o processi.Personalizzerò per soddisfare il progetto e il cliente al fine di comunicare in modo chiaro.

Supponendo che i requisiti sono già documentati, due tipi di documenti che ho sempre cercare di produrre, come minimo, per le applicazioni web ad alta intensità di dati basato su workflow sono:

1. alto livello diagrammi di flusso di lavoro che indicano il flusso di schermo, lo stato cambiamenti e azioni importanti. Trovo questo molto utile come primo passo per arricchire i principali movimenti all'interno dell'applicazione. I flussi di lavoro sono in genere correlati ai diversi casi d'uso.

2. Specifiche dello schermo per ogni schermata di input che descrive il formato e il comportamento di ciascun campo. In genere include il tipo di campo, il valore predefinito, i valori di lista, le convalide dei dati, le regole di visibilità e le azioni che possono essere attivate, ecc. Fondamentalmente un grande tavolo che assicura che gli sviluppatori sappiano come costruire gli schermi.

Ho anche usato Balsamiq Mockups nel recente progetto di frusta insieme schermi app web e le mockup schermo hanno formato una parte vitale delle specifiche di progetto - molto veloce da produrre, e che trasmettono un sacco di informazioni su come dovrebbero funzionare gli schermi che è piuttosto difficile da trasmettere in un documento di testo.

Infine, Joel series on functional specs è utile per la lettura.

Answer 3

Tutte le casi d'uso devono essere ben dettagliata, continua cooperazione da parte del cliente sarà sempre un plus, ancora potrebbe germogliare imprevisti casi.

Se si sviluppa l'interazione tra server diversi che eseguiranno il polling/push dei messaggi in momenti diversi, si avrà sicuramente bisogno di Sequence Diagrams.

Evitare overdesigning esso, in diagrammi di classe classi non necessarie tendono a funghi, tagliarli giù, utilizzare più metodi, tenere traccia di quale ambiente ciascuna classe sarà davvero finire in esecuzione (un po 'verrà eseguito lato server, un po' di lato client - javascript: alcuni verranno programmati e verranno eseguiti sul server reale, alcuni saranno cgi (o moduli) incapsulati dal server web e eseguiti su richiesta, alcuni si interfacciano con il database

Definire i confini, renderli chiari. Il lato server/lato client/il lavoro del database sono animali diversi e potrebbero impiegare orari e persone diversi.

Answer 4

Mantenerlo il più semplice possibile ble.

Un documento che specifica i principali requisiti delle funzionalità è il primo passo.

Personalmente, poiché le applicazioni Web sono quasi sempre basate su database, avvio la modellazione del database in base ai requisiti di funzionalità. Le entità nella mappa del diagramma ERM di solito 1-1 con le classi nel diagramma UML e mostrano già le relazioni di base.

Assumendo un'architettura MVC e un codice ben documentato, le classi del modello si auto documentano man mano che si evolvono (ad esempio, phpdocumenter di ossigeno).

Trovo che qualcosa di semplice come un wiki funzioni meglio per la scrittura di documenti piuttosto che di documenti formali che richiedono più tempo per scrivere rispetto al rispettivo codice, in particolare in un ambiente agile.

Answer 5

1. I requisiti sono un set di documenti, che può includere elementi grafici, documenti di Word, messaggi di posta elettronica e altri modi per registrare elementi. Un elenco di ciò che è nell'ambiente di sviluppo (IDE, controllo del codice sorgente, bug tracking), stile di codifica e linee guida è un altro insieme di documenti che può essere utile per avere un team di sviluppo di applicazioni di successo. C'è un piano di progetto che è un grande diagramma di Gantt e le note di rilascio che sono un po 'più di documenti che creiamo.
2. Non ho visto molti diagrammi UML diversi da quello che i Gang of Four hanno sul loro sito per spiegare alcuni schemi di progettazione.
3. Abbiamo un arretrato di articoli da completare e stime di quanto sia complessa ogni storia. Questo potrebbe essere diverso dall'approccio che stai utilizzando. Con il nostro approccio Agile, potrebbe non esserci tanto design/piano quanto la tua situazione.
4. Raramente abbiamo diagrammi di classi, sebbene Visual Studio abbia un Visualizzatore oggetti utile per vedere ciò che è già stato creato.

Dove lavoro tendiamo a lavorare in coppia per creare oggetti di dominio e relativi membri, metodi e proprietà. Le classi vengono create come necessario per le storie o se stiamo ripulendo o refactoring un set di classi.

Non c'è una lista completa delle classi, ma ci sono alcuni modelli di progettazione in uso come MVP e la fede che da quando una coppia sta creando qualcosa, il codice si inserisce all'interno dello stile e le linee guida attuali. Man mano che i requisiti evolvono, le modifiche alle classi saranno abbastanza regolari, ma questo mi sembra un modo naturale di fare le cose per me.

Sfondo sull'ambiente in cui io sono solo nel caso in cui qualcuno vuole sapere:

Dove lavoro abbiamo 5 sviluppatori, una di piombo QA, un analista di business, un team leader, un architetto e un project manager come le persone principali nel progetto al momento. Usiamo Scrum, coppia la programmazione e alcune idee TDD nel nostro lavoro.

Stiamo utilizzando Visual Studio 2008, Subversion, HP Quality Center, ASP.Net 3.5, Sitecore 6.0 e MS-SQL Server 2005.