Un sistema può essere implementato con un processo a cascata e quindi implementato utilizzando un approccio graduale in un'organizzazione?

Esiste una relazione tra la metodologia di sviluppo e la distribuzione del sistema.

Can a system be implemented with a waterfall process and then be implemented using a phased approach into a organisation?

Sì, può essere. Ma può essere costoso, soprattutto per sistemi software su larga scala o sistemi mission-critical.

Is the building process such as waterfall or agile used to implement a system, linked to the way an enterprise system is rolled out in an organisation?

Può essere. In parte dipende dalla relazione tra l'organizzazione ricevente e l'organizzazione di consegna. La scelta della metodologia può dare opzioni o rendere più possibili alcune opzioni.

Ad un estremo, hai una cascata puramente sequenziale in cui non hai un sistema implementato, integrato e testato fino alla fine. Non hai codice fino a quando il tuo progetto non è "finito" e non hai codice testato fino a quando tutto il codice non è "finito" e non rilasci o distribuisci il codice fino a dopo che è stato testato.

Una volta che il software è stato consegnato, l'organizzazione ricevente ha un'opzione. In primo luogo, possono scegliere di passare immediatamente al nuovo sistema o implementare il nuovo sistema e passare lentamente dalla funzionalità ai processi e ai sistemi esistenti. Ci sono costi e rischi associati ad entrambi. Tagliare in un big bang può portare alla scoperta di problemi sconosciuti senza soluzione a breve termine. Il passaggio alla funzionalità lentamente significa che l'organizzazione deve pagare i costi associati all'uso e alla manutenzione di due sistemi durante il processo di transizione.

All'altro estremo, hai i metodi iterativo e incrementale (agile). Molti, come Scrum, richiedono software di lavoro alla fine di ogni incremento. Tuttavia, non richiedono necessariamente il rilascio di quel software funzionante. Nel processo di sviluppo più snello, è possibile (in teoria, comunque) rilasciare o distribuire software funzionante e testato più volte al giorno.

Dopo ogni incremento, l'organizzazione ricevente può scegliere se accettare o meno. Anche se l'incremento non è accettato, c'è la possibilità di mostrare pezzi del software in un ambiente di test e ottenere feedback da clienti e utenti. Questa è una riduzione del rischio globale sia per l'organizzazione ricevente che per l'organizzazione in via di sviluppo. Vi è un ulteriore vantaggio per l'organizzazione ricevente: nello sviluppo brownfield, è disponibile l'opzione per interfacciarsi con un sistema esistente per sostituire lentamente la funzionalità. In questo modo, l'organizzazione ricevente può anche rendersi conto che non hanno bisogno di tutte le funzionalità di un sistema esistente, provocando il completamento del progetto prima che il nuovo software abbia l'intero set di funzionalità del vecchio sistema (adattandosi ai requisiti in evoluzione, un obiettivo dei metodi agili).

La metodologia di implementazione e implementazione può essere diversa. La decisione dipende dalla situazione.

Tuttavia, se si utilizza una metodologia agile, una distribuzione incrementale (se possibile) renderà la metodologia agile molto più efficace. I dati di feedback della metodologia agile non verranno solo dal test, ma anche dall'uso reale.

No

Ho lavorato su progetti / programmi Waterfall che avevano molte fasi e sottoprogetti che venivano consegnati separatamente (non frequentemente come un tipico progetto agile ma non ancora un "Big Bang"). Ogni componente ha seguito in modo indipendente il proprio tipico approccio Waterfall .

I progetti agili non hanno bisogno di distribuire ogni iterazione alla produzione. Posso immaginare una situazione in cui nessuna iterazione viene distribuita alla produzione per un periodo significativo, causando di fatto un rilascio "Big Bang" al momento della realizzazione definitiva. Questo sarebbe un approccio perfettamente ragionevole alla creazione di un sito di e-commerce, ad esempio. Le prime iterazioni sarebbero state testate internamente e perfezionate prima del lancio completo. In questo modo ci sarebbero meno possibilità di schierare un sito mezzo cotto e perdere clienti. Naturalmente, si continuerà a sviluppare e implementare il lancio di AFTER anche se, sebbene inizialmente sembrerebbe a una parte esterna che il sito è stato sviluppato in modo monolitico, la velocità degli aggiornamenti successivi indica che il progetto viene eseguito in modo agile.

La scelta sull'opportunità di utilizzare un approccio del Big Bang ha, in base alla mia esperienza, molto più a che fare con l'architettura organizzativa e i requisiti di integrazione. Ad esempio, sarebbe sconsigliabile rilasciare in modo incrementale un ERP in un ambiente in cui un ERP esistente è destinato a essere sostituito. Ciò introdurrebbe un'intera gamma di problemi per gli utenti (quale sistema faccio ora questo processo? Come ottengo un quadro completo dei registri? Ecc.) E introdurrei un rischio significativo. Per una distribuzione ERP greenfield è possibile un approccio più incrementale. Certamente la distribuzione dei vari moduli di un grande ERP in modo incrementale è comune.