Come impostare una ricerca one-man nella differenza tra BDD e Waterfall?

È impossibile generare set di dati abbastanza grandi in un laboratorio di ricerca, per non parlare di soli, per convalidare i processi di sviluppo. Le tue opzioni sono:

1. Collaborazione con l'industria. Per i principianti, dovrai istruirlo su BDD all'inizio del progetto e devono essere disposti ad adottarlo - un compito arduo! Avrai anche bisogno di alcuni anni per eseguire i tuoi esperimenti su diversi progetti e possibili in diverse aziende, probabilmente in diversi settori! Per i progetti di controllo Waterfall, puoi semplicemente fare affidamento sui dati esistenti.

2. Utilizzare i progetti degli studenti. Questa opzione è pratica, ma non è affidabile come la scala dei progetti deve essere piccola. Ehi, devi fare quello che devi fare! Forse se hai accesso agli studenti universitari, potrebbe essere meglio.

Se devi continuare, l'opzione 2 sembra essere l'unica opzione pratica. Tuttavia, potresti voler riconsiderare il tuo argomento di ricerca!

Buona fortuna!

Ti sei prefissato un compito molto difficile!

Ogni progetto software è praticamente unico, un gruppo diverso di persone che implementa un diverso insieme di requisiti per un cliente diverso in un ambiente diverso.

Inoltre, le organizzazioni commerciali non renderanno pubblici i dati interni sui costi del progetto, sugli sforzi o persino sul successo o sul fallimento. In effetti, quasi tutti i progetti per le imprese hanno successo solo perché il "successo" viene ridefinito come qualsiasi cosa sia stata consegnata.

Le organizzazioni governative, d'altra parte, devono operare in pubblico e vengono pubblicate cifre su costi, risorse e successo / fallimento. Almeno all'inizio dei progetti tendono ad essere piuttosto aperti su ciò che stanno facendo e su come, quindi, tra comunicati stampa, rapporti di audit e account pubblicati (e richieste di libertà di informazione in ultima istanza) dovresti essere in grado di costruire un buon corpo di dati da analizzare.

L'avvertenza è che i progetti governativi (almeno quelli per cui pagano le tasse) hanno una lunga e sordida storia di insuccessi e generalmente seguono stili di gestione di progetti unici e incoerentemente incoerenti.

Cascata è un ALM , BDD-1 / BDD-2 è un metodo per il test di accettazione in corso in questo modo TDD è un metodo per il test delle unità in corso.

I due coprono aspetti diversi e non si escludono a vicenda.

es. Potresti utilizzare uno qualsiasi di questi ALM {Waterfall, UP, SCRUM} con o senza BDD.

Il vero valore di BDD è scoprire le situazioni difficili in cui gli scenari non sono ovvi: le incognite sconosciute di un progetto.

Dal momento che ogni progetto implica fare qualcosa di nuovo (altrimenti potresti semplicemente acquistarlo dallo scaffale o usare open-source) di solito ci sono alcune di queste scoperte. Sono la cosa che occupa più tempo nei progetti. ("Se un progetto non ha rischi, non farlo" - Waltzing with Bears).

Quindi mi dispero di poter mai confrontare un progetto con un altro, soprattutto se usi BDD per aiutarti a fare quelle scoperte, perché saranno radicalmente differenti per ogni progetto - e se proverai a rifare un progetto, avrai trovato tutte le scoperte già ed essere prevenuto di conseguenza. (Queste scoperte spiegano perché Waterfall non funziona così bene, a proposito.)

Al contrario, chiederei ai principali stakeholder quanto fossero felici con la qualità interna ed esterna del software che hanno ottenuto da un gruppo di progetti BDD e Waterfall su una scala da 1 a 10 e confrontare i risultati. Questo è tanto oggettivo quanto è probabile che tu possa essere in grado di ottenere, e dovrebbe funzionare su più progetti.

Sto semplicemente seguendo ciò che ho letto qui . Perché non paragoni BDD a TDD? Prendi un gruppo di major CS del primo anno e confronta la loro capacità di usare test unitari con e senza BDD. Sviluppano una migliore comprensione del processo?

C'è un merito nel cercare di ottenere alcuni dati su metodi agili in cascata, ma questo va oltre la tesi di laurea IMHO.

Penso che la seconda opzione di rrufai potrebbe essere la migliore da perseguire. Tuttavia, lo cambierei un po '.

Trova alcune classi di programmazione di livello medio-alto e dividi gli studenti in due gruppi: cascata e BDD. A seconda della dimensione della classe, potresti facilmente avere più team per ciascun approccio.

Successivamente, affronta sfide specifiche dal progetto CodeJam di Google. Assegnare le squadre in modo da avere almeno una cascata e un gruppo BDD per sfida. Aggiungi ulteriori requisiti come documentazione, indicatori di avanzamento, tracciabilità / registrazione, ecc ... per aumentare il numero di funzioni che devono essere progettate e integrate nel progetto.

Il vantaggio dell'utilizzo degli inceppamenti è che hai una convalida integrata per il loro codice. Dovrai determinare i criteri di valutazione per i requisiti aggiuntivi.

Idealmente, ogni team affronterà alcune delle sfide nel loro stile assegnato. Quindi puoi cambiare le metodologie di progettazione e farle affrontare alcune altre sfide.