Liming has raised three points in reference to my Fractal V Lifecycle. His questions are probing the limits of the model in interesting ways. Before I discuss them, I’d like to introduce a concept and some terminology from an earlier paper I wrote.
The V model can accommodate as many levels of design abstraction as you like. For example, if you do high-level design/integration testing, add a layer for that between system architecture/system testing and low-level design/component testing. At each level of design abstraction, you have the same schema of activities: design the artifact (called “Plan” in the paper), pass it on for elaboration to a lower level of abstraction (called “Do” in the paper) and then verify that the design and implementation are consistent (called “Check” in the paper). There is also another kind of activity in the V model, “Plan-to-Check”, which can proceed concurrently with the “Do” step.
So, the left-hand side of the V is “Plan”, the horizontal dotted lines are “Plan-to-Check”, the pointy bit is “Do”, and the right-hand side is “Check”.
On to Liming’s points about situations quoted or paraphrased as follows…
1. “Left side of the V bends up before reaching the bottom”
Liming wonders – how can you “Check” a developed artifact if it hasn’t been built yet!? As Liming suggests, I want to argue that if you don’t have an implementation yet, you of course can’t test it, but you can certainly analyse the plan/design. Your “Check”ing activity will be a requirements review, or a model-based design simulation, or perhaps testing with stubs (or “mock objects” if you prefer). It depends on your level of design abstraction and what artifacts you already have from any previous iterations.
Liming thinks analysis is implicit in the left-hand-side of the V, because designers always carry out some sort of analysis immediately after creating artifacts. I agree designers often do that sort of analysis, but I disagree that it’s implicit in the left-hand-side of the V! I think it’s simpler and more consistent to think about it as being part of the right-hand-side of the V, with a null “Do” activity. So designers would do many mini design/analyse (“Plan”/”Check”) iterations at their level of design abstraction before sending it off to the lower level of abstraction for elaboration.
2. “Right side of the V dips down before reaching the top”
Liming observes that this isn’t just about avoiding end-customer contact. I didn’t highlight that in my original blog article, but I fully agree. For example, you might have unit tested iterations that you don’t send up for integration testing just yet. These are “internal iterations” at some level of deign abstraction, avoiding the “customer” at the next highest level of design abstraction.
3. “Early or continuous testing breaks the V”
Liming claims that as testing happens on the right-hand side of the V, early or continuous testing means you can’t have a V any more. I agree early and continuous testing breaks the V, but it doesn’t break the Fractal V! In the Fractal V, yes you do still carry out the testing on the right-hand side of the V, but the whole point of the Fractal V is that it can accommodate a variety of different kinds of internal iterations.
I’m not claiming that all software development will fit the Fractal V Lifecycle. For example, imagine a lifecycle with long-running requirements analysis performed concurrently with ongoing development, where you could pre-emptively abort a development iteration depending on the intermediate outcomes of that ongoing requirements analysis. I don’t know of any lifecycle that would capture that exactly. Maybe this is Liming’s point about continuous integration – the hairy reality is that developers won’t stop entirely while they’re waiting for feedback from continuous integration – they’ll probably already have started the next unit of work. I would rebut that the aim of continuous integration is to given “immediate” unit and integration test feedback to developers – to let them do many micro-iterations as quickly as possible. I say you should probably just work around that hairy reality for the sake of simplicity. No model is perfect, but some models are still useful.
Lifecycle models are used because they make it easier for large groups to understand and coordinate complex projects. The Fractal V provides more flexibility for iteration than the normal V lifecycle, but is still reasonably simple, and importantly retains the Plan/Do/Check schema that so many systems engineering disciplines and tools rely on.
It will be interesting to see the un-V lifecycle Liming mentions (I hope they find a better name!), and see how it deals with all of these issues.
agree with your points. 🙂 I think the difference comes from how much one can “re-interpret” the right side of the original V when making it into W or fractal V. The right side of the original V means testing and it also means “checking code against” early life cycle corresponding artifacts, NOT checking early life cycle artifacts themselves.
One can certainly relax that into a general “check” of anything. 🙂 In that case, maybe the model should be called the fractal PDC (Plan-Do-Check).
I don’t think of Plan-Do-Check as a lifecycle – it abstracts over levels of design abstraction, which are usually explicit in a lifecycle model. But OK, I agree with your point – in the original V model, there’s no explicit “Check Your Plan” activity, and if it’s implicit, it’s probably implicit within the “Plan” activity.
Still, I think if you admit the Fractal extensions to the V model, you are then free to think of a “Check Your Plan” activity as being either in the “Plan” activity (X)OR the “Check” activity. I think the better choice is to regard the original V model “Plan” activities as really being little micro-V Plan/Do/Check(-Your-Plan) iterations with null “Do” steps.
At this point I feel like I’m arguing about how many angels could fit on the head of a pin. Maybe that’s a sign that I’m pushing this point of view a little too far!