In business, invention is the conversion of cash into ideas, but innovation is the conversion of ideas into cash.

Nice.  I see this is also on wikipedia.  I wonder what’s the original source for this quote?

I wanted a desktop app, so I excluded Redmine, and dotProject because they’re webapps, exculded Project.net because it needs Oracle which I don’t have, and excluded the *nix-only application TaskJuggler.

That still left me with a short list of three: GanttProject, OpenProj, and Open Workbench.

Open Workbench hasn’t open sourced their internal scheduling alorithms, and requires a commercial Clarity (CA) product to do collaboration.  Neither of those are killer problems for me, but they do linger in the back of your mind…  Anyway, it installed OK, launched OK, but looks overly complex.  I want to be productive out of the box, but couldn’t even work out how to create tasks and dependencies.  (I guess maybe I could have read the manual.  Who has time?)  Uninstalled.

GanttProject installed OK, launched OK, and looks promising.  I think it could be used, but minor bugs in the UI proved annoying.  Naming tasks was hard in the UI, and linking tasks to milestones was painful.  Uninstalled.

OpenProj installed OK, launched OK, and looks easy enough to use for my purposes.  There are a few UI niggles – e.g. I’d like to be able to reorder tasks more easily, maybe with drag and drop.  The download is going to be a couple of years old soon – Wikipedia tells me its development status is uncertain since Serena acquired it, and also tells me to watch out for bugs if I start to use some of the more advanced features…  But, it looks “good enough”, and I’m using it for now.

When I was a PhD student, I kept hard copies of the papers I read, and a collection of bibtex files containing reference information.  The bibtex files were separate, each on a different topic.  Since getting back into research in 2004, I’ve gone digital and have tried a few solutions: Reference Manager, EndNote, bibtex again, and zotero.  After each one, I kept reverting to my clumsy manual approach: storing PDF documents in directories, with each directory representing a topic.  Often, papers relate to more than one topic – sometimes then I put a copy or soft link in each topic directory.  I said it was clumsy!  But at least I can work when I’m travelling and off-line.

As a result, I now have dozens of directories stuffed with thousands of PDFs.  (I have less than three thousand, but a colleague has more than ten thousand.)  These calcified directories represent a fixed collection of topics that, as my research focus evolves over the years, is increasingly inappropriate.  I suspect a lot of people work like this.

So I’ve been delighted to discover Mendeley Desktop.  It’s still in beta, but I like its approach.  It lets me keep my PDFs as they are, and works with me to index them and import their bibliographic information into a database, using text recognition and bibliographic web services.  The quality of both of those mechanisms are a bit patchy right now, but it has “needs review” status tracking so I can manually check and correct that bibliographic data over time.  What’s also cool is that I can tell it to “watch” my directories – if I dump more PDFs in there, it’ll incrementally import those too. Mendeley has all the normal features: reference-importing bookmarklets, exporting in bibtex/whatever, Word and Open Office plugins for creating reference lists, etc.  And of course it also has tagging: so now I can create tag topics for my references – organised into as many overlapping topic areas as I need.

I feel like my reference collection has opened up to me, and is becoming a much more useful resource.  That’s fun and exciting but I have to make sure I don’t spend so much time organising my references that I end up not actually doing research!

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.

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.

To the extent that Liming’s wry diagram is true, I think it’s more true of journals than conferences. In most academic disciplines, journals are regarded as the “proper” place to publish significant results.  Computer science is different – top conferences in computer science (and software engineering) can be more important than journals.  Citeseer statistics show most of the highest impact compsci venues are conferences, and even some workshops have more impact that some top journals!  But (or perhaps because!) in computer science, journals have longer review and publication lead times than conferences, so the results there can be more out-of-date and so less interesting.  (That is a bit odd when you think about it – journals are published several times a year, whereas each conference happens at most once a year – surely journals should be able to be more responsive than conferences in publishing new results?!)

Anyway, it makes me wonder how Ricky’s citemine system would work in the conference milieu.  I guess for maximum market efficiency in citemine, the evaluation for new papers should take place in public. So, no workshop or conference would ever have “new” results – everything that made it through “review” (weighted average market price over the period since the last conference greater than some threshold for papers within some discipline boundary?) would have been published for the best part of a year.  Conferences would be more like the Oscars – glorifying new exciting productions – rather than a way of learning about recent results.  Maybe that’s OK – I think the greatest value of conferences is networking and nuance, and you would still get that at a Computer Science discipline’s “Academy Awards”.  But these would be very different events, and norms of academic precedence would need to be re-conceptualised.

The achievement is important for two reasons. Firstly, it makes it possible to prove code-level functional correctness of whole computer systems based on the L4 microkernel. This means computer systems can carry a new kind of assurance, supporting strong arguments for safety and security for high-integrity software systems.

Secondly, it makes the creation of these proofs more feasible in practice. It should now be possible to formally verify properties of whole systems where only the key parts of the system are formally verified. This is critical for the practical application of formal verification. The verification of the L4 microkernel took more than 20 person years of effort to verify just 7500 lines of C source code. Modern embedded computer systems can have millions of lines of source – it’s not practical to formally verify all the code in such systems at these levels of productivity.

However, you don’t need to verify all the code! L4 provides rigorous separation between processes running in the microkernel, and that separation is guaranteed by the recent proof. If you can isolate the safety-critical or security-critical parts of an entire system to one small formally verified component running in an L4 process, it should be possible to lift the guarantees for that component to the whole system, even if the other components in the system haven’t been verified.

That is the challenge for a new project at NICTA – Trustworthy Embedded Systems. The plan is to develop technologies to support the creation and verification of entire systems running on top of the microkernel. This is a large project involving several NICTA labs and researchers from many disciplines (operating systems, formal methods, software architecture). I’m part-allocated to the project for the next few years. My PhD was in formal methods, and this is really the first time I’ve dipped my toe back into that area for the last decade. However, I won’t be doing too much theorem proving myself – my focus in the project will instead largely be on other software engineering issues in this context, such as configuration management, and how to use the component architecture to support product line development.