Cascata richiede codice completo prima che il QA passi?

L'uso della metodologia Waterfall, come descritto su Wikipedia artic le, su qualsiasi progetto di scala significativa , è uno sforzo rischioso. Nella metodologia cascata comunemente insegnata, il test avviene alla fine. Non c'è discussione (di cui sono a conoscenza, comunque) di verifica o convalida che avvenga prima della fase di "test". Tuttavia, il metodo Waterfall comunemente insegnato è un esempio di come non costruire sistemi software, e viene da un documento di Winston Royce , in cui è descritto come:

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

La figura 10 del documento a cui ho fatto riferimento è il modello di sviluppo software proposto da Royce, che include esplicitamente i requisiti, la progettazione e le revisioni di implementazione. Sospetto che un team di assicurazione della qualità sarebbe coinvolto in queste revisioni, in una certa misura. E oltre a coinvolgere la garanzia della qualità, il cliente è coinvolto (come appropriato) nel processo di sviluppo in tutte le fasi, il che è contrario al modello Waterfall tradizionalmente insegnato.

Ora, le metodologie pianificate (come la metodologia proposta da Royce) non sono sbagliate o cattive, se usate nelle istanze appropriate. Ad esempio, in un progetto con requisiti volatili, non sono l'opzione migliore e sembra che questo sia il tuo caso. Quindi sì, quando non sai per certo che cosa è necessario costruire o cambiare è probabile, l'uso di una metodologia basata sul piano è costoso per i motivi maple_shaft ha scritto nella sua risposta .

Questo sembra abbastanza vero per la tradizionale metodologia Waterfall e hai già menzionato un significativo svantaggio di Waterfall in quanto il costo relativo di un bug o di un problema perse aumenta in modo esponenziale nel corso del progetto:

Il modo per minimizzarlo nello sviluppo di Waterfall è quello di fornire regolari aggiornamenti di stato con BA / QA per tutto il corso del progetto, quindi se vedono qualcosa andare fuori strada allora possono chiamarlo prima che abbia una possibilità di essere un bug o mancata richiesta successiva nello SDLC.

Forse dare un semplice sì / no è la risposta desiderata per questa domanda, ma non posso proprio farlo.

La cosa su Waterfall è che sembra fantastico sulla carta, ma non riesce quasi mai a corrispondere con la realtà del comportamento umano.

Alludi ad avere una certa dimestichezza con Agile e fai notare i problemi che si verificano nelle persone che cambiano idea, quindi presumo che tu abbia una certa familiarità con questo problema. Lo sviluppo del software non è abbastanza simile al bridge-building per procedere in modo gradevole e ordinato dalla fase 1 alla fase 2 alla fase 3. Impariamo di più man mano che le idee dei clienti crescono e maturano, le priorità cambiano.

Detto questo, dirò teoricamente sì, in base al processo rigido e spesso poco pratico delineato da Waterfall, il codice è completo prima di andare a testare. In realtà, però, spesso non funziona e porta a digrignare i denti.