Quanto è comune la prototipazione come prima fase di sviluppo?

Ho seguito alcuni corsi di progettazione del software negli ultimi semestri e mentre vedo i benefici in gran parte del formalismo, sento che non mi dice nulla sul programma stesso:

• Non puoi dire come funzionerà il programma dalle specifiche del caso d'uso, anche se discute cosa può fare il programma.
• Non si può dire nulla sull'esperienza utente dal documento dei requisiti, anche se può includere requisiti di qualità.
• I diagrammi di sequenza sono una buona descrizione di come il software funziona come stack di chiamate, ma sono molto limitati e offrono una visione altamente parziale dell'intero sistema.
• I diagrammi di classe sono ottimi per descrivere come è costruito il sistema, ma sono assolutamente inutili per aiutarti a capire cosa deve essere il software.

Dov'è in tutto questo formalismo la linea di fondo: come appare il programma, come funziona e quale esperienza offre? Non ha più senso progettarlo? Non è meglio capire come il programma dovrebbe funzionare tramite un prototipo e sforzarsi di implementarlo davvero?

So che probabilmente sto soffrendo per l'insegnamento dell'ingegneria da parte dei teorici, ma devo chiederlo, lo fanno nel settore? Come fanno le persone a capire che cos'è effettivamente il programma, non a cosa dovrebbe conformarsi? Le persone prototipano molto o usano principalmente gli strumenti formali come UML e non ho ancora capito come usarli?

Se stiamo costruendo un'applicazione GUI, creiamo quasi SEMPRE un prototipo o POC (proof-of-concept). Stabiliremo quale sarà il vocabolario visivo dell'app. Di solito coinvolgiamo i nostri clienti a metà del POC e ci assicuriamo che capiscano qual è lo scopo e su cosa dovrebbero concentrarsi. Non mi è mai dispiaciuto di aver prodotto un prototipo. Assicurati solo di non provare a trasformare il codice prototipo nel codice di produzione, avvia il codice di produzione da zero in base a quanto appreso dal prototipo.

Detto questo, non prototipiamo quasi mai applicazioni lato server (servizi, middleware, ecc.). Non vedo davvero il ritorno sugli investimenti per questo (a meno che tu non stia facendo qualche nuova tecnologia e non hai bisogno di dimostrare diversi concetti).

Nel mondo degli affari, conta molto

Anch'io lo penso, fino a quando non colpisci il mondo degli affari. Quindi non è più abbastanza semplice solo per prendere i requisiti e andare avanti e costruire.

È nel business che i diagrammi "flow" dell'utente e i prototipi lo-fi hanno davvero senso.

Come funziona il "programma" è probabilmente la parte facile. Nelle app LOB (Line Of Business), la maggior parte è solo CRUD. La sfida sta nella logica e nelle regole aziendali . È qui che i diagrammi di flusso dell'utente e i flussi dei processi aziendali diventano estremamente importanti per comprendere e pianificare in modo efficace.

Cosa intendi per come "funziona" il programma? Sembra che tu stia cercando esatti dettagli di implementazione in qualcosa di diverso dalla specifica implementazione finale, il che non ha senso. Gli elementi di livello superiore dovrebbero guidare l'implementazione, non determinarla.

Dalla mia esperienza, la prototipazione è piuttosto rara. Mi è stato sicuramente insegnato insieme a specifiche, requisiti, architettura, ecc. E può essere molto utile.

Per quanto riguarda "ciò che il software deve essere", questo è i requisiti. Sembra che manchi l'intero punto.

Le interfacce sono spesso delineate in anticipo e i casi d'uso possono essere utilizzati per il "flusso" dell'interfaccia. L'esperienza utente non manca affatto. Se ritieni che manchi qualche elemento, fai qualcos'altro che i tuoi professori non hanno menzionato. Il design non consiste in un chiaro insieme di regole tramandate dal cielo.

La mia osservazione personale è che alla prototipazione viene dato molto servizio, ma troppo spesso il prototipo, una volta che mostra segni di vita, viene semplicemente rinominato come 'Beta' o, peggio ancora, v1.0.

ci sono due tipi di prototipazione - tre, in realtà:

1. costruiamo prototipi per perfezionare il design e ridurre i rischi prima di iniziare la codifica "reale" (Engineering)

2. costruiamo il progetto come una serie di raffinati prototipi (Agile)

3. costruiamo un prototipo e lo spediamo non appena funziona (Cowboy)

Quello che stai cercando si chiama spec. Puoi leggere una descrizione qui in uno degli articoli di Joel

http://www.joelonsoftware.com/articles/fog0000000035.html

Un prototipo può anche essere considerato "iterazione 0" di ciò che devi fare. Soddisfa diverse cose:

• Dimostra che il concetto può essere fatto. Questo può essere per il tuo capo o per un cliente pagante.
• Ti consente di identificare elementi che potrebbero essere difficili da raggiungere per la forza di produzione e di darti un'idea generale della quantità di lavoro necessaria.
• In realtà hai un codice che fa qualcosa . Questo è estremamente importante!

Tutto sommato il prototipo dovrebbe essere molto utile per costruire il prodotto finale, a meno che tu non abbia riscontrato che è necessario un approccio completamente diverso.