Mark Staples

The day after Christmas is Bottling Day!  Laying down the Dark Ale for Autumn and Winter.  I had racked it 4-5 days beforehand.  Final gravity was 1.01, so it will be just under 5.5% ABV.

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.

Louis has got a new article version of my earlier blog post on the Fractal V Lifecycle up on alinement.net magazine/community website. He’s also added some thoughts of his own on extending the concept into pre-project activities.  For these sorts of activities I tend to favor putting them on top, i.e. on the left but at a higher level – giving you a taller V.  But there’s no hard and fast rule… use it whatever way helps!

It’s been a madly busy year, with barely enough time to drink beer, let alone make any.  But on the weekend I managed to find an hour to put on a new batch.  Hopefully when the Christmas holidays come around in a couple of week I’ll find time to bottle it!

I’ve gone with a Cooper’s Dark Ale again – an old favorite, and nice in the winter when it will be ready.  I added cooper’s Brew Enhancer Type 2, and the original gravity was 1.038.