Sorry mate, but your comparison is akin to comparing chalk with cheese. How about making a quick 'wiki' comparison with the cost of a similarly complex commercial aircraft and the MRA4 ? Please don't take this to mean that I agree with what the MoD has done, because I don't.
I'm interested in your cost comparisons for normal versus safety related code. Would you happen to have a reference for that ? I would also be really interested in comparisons of the whole life costs if you have them ?
Cheers
S_H
My intention was to compare chalk and cheese - the only things in common were the fact they are both technically complex programmes and they both cost several billion pounds. It could be pointed out that "ah but yes Nimrod took alot longer and was therefore less well run" but actually the you could argue the funding profile available for Nimrod was not there to do it any quicker (whereas Microsoft probably threw money at VISTA to get it to market on time which was critical to get the revenue in, hence worth the upfront cost).
I could have compared it to A380 - EUR12 Billion in development, or over twice as much as Nimrod.
I'm not trying to defend Nimrod costs as I genuinely don't know if they are excessive or not, just putting them in some context as it is sometimes all to easy I think to think "mmm several £bn - we must be getting ripped off".
-----------
Re software metrics, its been a long time since I looked at this and my recollections are only anecdotal though the 4-10x estimate sticks in my mind. You could probably do some rundimentary comparative calculations on manhours required from say a given Software Reqt Spec to HW/SW integ test by comparing the mandatory development activities for non-critical and critical code (e.g. those listed in 00-55), though you'd really need to include much of the systems design & analysis that occurs prior to the SRS stage (and which would typically be more complex for aspects of critical systems - e.g flight control laws) to understand the true deltas. All the extra independant reviews, hazard analysis & code assurance activities, coupled with a much typically more rigourous testing / validation / certification etc. approach are the key cost drivers for safety critical code as I expect you well know.
Whole life cost the comparisons of critical and non-critical code would be interesting, as in effect they usually end up having quite different life cycles. The fact that critical code costs much more to develop in the first place typically results in projects trying to leave it alone during a life cycle unless it really really needs to change (e.g. through HW obsolescence or major system change). Non-critical code is typically where a well designed weapon system will have its mission functions, carefully partitioned from any critical code - as a result it will be changed more often to meet evolving operational reqts. Hence you'd probably find non-critical code actually has higher WLCs but this is driven by much higher software change traffic not by any inefficiency in its development process (which will always be cheaper, change for change, than critical code).
There is a theory/argument to say that you can reduce potential rework cycles in non-critical code by adopting the rigour of critical code processes, but I think the consensus of opinion is still that the cost benefit case for this has still not been established. As I say its been a while but I suspect that biggest gains in software productivity still lie in "optimising" the front end reqt engineering phases rather than focussing on the actual software development cycle post SRS (which when I last looked is where critical coding standards still tend to be focussed). I'd be very interested to learn if this emphasis has changed in recent years.
EDIT - on reflection 4-10x seems quite a high delta for sw aspects alone and if you were just to compare software process manhours it probably wouldn't be this much more. 4-10x probably includes all the wider cost impacts of developing/producing/delivering systems with safety cricital functionality.