È possibile lo sviluppo di documentazione iterativa e fornisce una documentazione efficace?

Ho un progetto per l'università che non comincerò immediatamente, ma ho pensato per un tempo ragionevolmente lungo. Capisco che lo sviluppo di progetti universitari non è come quello dell'industria (attualmente sono anch'io un tirocinante), quindi la situazione che sottolineerò al momento sembrerà probabilmente alquanto ridicola per gli sviluppatori di software reali. ^^'

Il progetto stesso richiede che documentiamo molto del nostro lavoro. Quindi, oltre a consegnare il codice, che conta per alcuni dei marchi, dobbiamo consegnare documenti tra cui:

Un documento di analisi dei requisiti
Un piano di progetto
Un elenco pianificato di casi d'uso, modelli di oggetti e dinamici e test di accettazione
Documentazione del processo di test e della riuscita dei test
Alcune altre discussioni e analisi sull'utilizzo del tempo, ecc.

Questi risultati devono essere consegnati nel modo seguente:

Prima RAD
Seguito da piano di progetto, casi d'uso, modelli e test (circa 3 settimane dopo)
Infine, la documentazione del programma attuale, il processo di test, ecc. + La programmazione stessa (circa 5 settimane dopo)

Quindi, da quello che ho capito, questo è davvero orientato verso un approccio in stile Waterfall al progetto. L'unico problema (a mio avviso) è che si tratta di un progetto universitario e gli studenti hanno già abbastanza pressione come nel tentativo di sviluppare progetti alla fine del semestre durante la settimana del progetto. Non voglio davvero programmare / sviluppare / testare tutto alla fine del semestre, quando avrò il panico con qualsiasi altra valutazione che dovrò affrontare.

Vorrei almeno provare a fare una sorta di ciclo di sviluppo iterativo, il che significa che possiamo iniziare presto a programmare / prototipare, avere un ciclo di sviluppo continuo che non è focalizzato sul fare tutto all'ultimo minuto e non avere così tanta pressione a la fine del semestre per terminare questo progetto. E ora arrivano le mie attuali domande:

Posso in qualche modo conciliare la necessità di fornire tutta quella documentazione con un ciclo di sviluppo rapido, iterativo / di prototipazione?
Esistono strategie per generare documentazione in modo iterativo?
Sono del tutto irragionevole chiedere questo e mi aspetto che sia fattibile all'università?

Inoltre, capisco che questa domanda è estremamente localizzata, quindi vorrei porre le stesse domande che ho posto sopra in termini di industria e se molti di questi tipi di problemi che i processi agili affrontano sono diversi per ogni squadra o compagnia.

Ad ogni modo, mi dispiace per quanto tempo è, e se hai finito di leggere fino in fondo, grazie! Se potessi prenderti il tempo di rispondere, te ne sarei molto grato! Grazie!

documentation iterative-development

— blahman
fonte

Questo non risponde, quindi non lo inserisco come risposta. Ma non farlo . Parte di ciò che il tuo istruttore vuole è che tu organizzi il tuo pensiero e sviluppi la tua capacità di pianificare e discutere un sistema che non hai ancora scritto. Quelle sono ottime capacità da avere e altamente commerciabili dopo qualche anno nel settore della programmazione.

— Ross Patterson,

Oh ok. Se posso chiedere, tuttavia, sembra che alcuni metodi di pianificazione per ottenere requisiti e concettualizzare le soluzioni client comportino la prototipazione di un possibile prodotto --- è un buon modo per aiutare a evolvere o aiutare la fase di pianificazione e documentazione? O è solo un desiderio irragionevole?

— blahman,

Certo, la prototipazione è valida. Infatti, in una grande azienda, potresti trovarti a costruire un prototipo per giustificare la R&S capitalizzata (è una cosa contabile, non una cosa tecnica), anche se non hai intenzione di utilizzare il prototipo come base per il sistema finale. In effetti, i migliori prototipi sono quelli che forniscono una guida e che vengono quindi scartati. Se avessi un nickel per ogni prototipo "prodotto" che necessitasse di una riscrittura totale un paio di anni dopo, avrei molti nickel.

— Ross Patterson,

La preoccupazione principale (ho un problema simile con il mio lavoro) è che se "Il processo" ti richiede di consegnare determinati artefatti in determinati momenti, e nessuno è autorizzato a sfidare l'onnipotente "processo", quindi se provi, tu perderà! Non è solo una questione di essere un modo migliore (quale è lo sviluppo di documenti iterativi).

Quindi quello che devi fare è lavorare all'interno del processo, ma trovare un modo di lavorare nel modo desiderato. Ad esempio, il processo consente la modifica del documento dopo l'invio? In caso contrario, non è possibile alcuno sviluppo iterativo. In tal caso, è necessario pensare al costo della consegna (in termini di tempo, credibilità, ecc.) E gestire tale costo. Se, ad esempio, si tratta di una copia di file e nient'altro, allora provaci. Se (come me) è una revisione tra pari, un rilascio di revisione, incide su decine di persone e costa migliaia di dollari, pensa attentamente e assicurati che il nuovo documento aggiunga davvero valore.

Un modo comune di lavorare è un minimo indispensabile, un documento minimo che soddisfi le esigenze di "The Process" all'inizio, seguito in seguito da un aggiornamento finale "come costruito" che non solo rifletta la realtà, ma abbia i dettagli dove necessario, ed è breve in cui il codice parla da solo.

— mattnz
fonte

Grazie per il tuo contributo! Ho pensato un po 'di più a quello che hai detto e come posso applicarlo ai miei progetti. Con molta della nostra documentazione, dovremmo avere un cliente con cui consultare, anche se dobbiamo presentarci entro una scadenza e non apportare modifiche significative successivamente. Lo sviluppo iterativo attraverso la consultazione del cliente è comunque possibile? Voglio dire, questo è il punto di svilupparsi in cicli, giusto?

— blahman,