To summarize, implementing virtual services does not really require a process change, at least from the perspective of the person who usually asks me that - more often than not a program manager, a director or an executive who is trying to get a sense of the transformation their organization will have to go through to embrace Service Virtualization.
Most large scale enterprise releases are done the same way. Several development teams go through change processes, with many of them iterating in the scrum fall kind of thing. They do system testing and integration testing, which of course causes an explosion where nothing quite works and eventually we get into production, where it really catches on fire.
The Software Development Life Cycle process does not have to change when you introduce Service Virtualization. But, you will get more effective and higher quality development without increasing your staff. You will get system testing that is much more effective and automated. And you get much shorter and effective system integration testing.
But, no bombs and no fires will break out.
The overall process won’t change, but users of your Service Virtualization product will have process changes at their individual contributor level. Doing development with virtual services means not writing a stub. Setting up a system test environment means not procuring access for physical hardware. Doing integration testing might mean that some systems are live but the others are virtual services.
So of course individual service virtualization users will have a different process, but the overall Software Development Lifecycle will remain unchanged.
John Michelsen's Software Development Life Cycle Series