Defence Select Committee - Cut Nimrod
What is expensive?
Now I don't know any details on Nimrod, nor do I seek to defend BAES and its commercial behaviour, however, when bemoaning cost escalations and what seem like massive costs, it must be bourne in mind that complex engineering is always expensive - this is a harsh reality & not something you can pretend can be avoided.
As a quick comparison, which is a bit rough around the edges, compare some of the costs bourne by Microsoft. It spends $7Bn / £3.5Bn per year on R&D. For the sake of argument, lets guess that say 1/3 of that is spent on their core product - PC operating systems. MS VISTA took 5 years to develop, from 2001 to 2006, hence taking approximately £6Bn to development. It contains 50 million lines of code.
Compare now to Nimrod MRA4, which apparently has 6 millions lines of code - OK not as much as VISTA, but then again each copy of the software comes with quite a large free aeroplane. Total cost is £3.6Bn. Now this is alot of money, but I think this perception is particularly exaggerated when it equates to £300m per copy, when you only buy 12.
By comparison, if Microsoft only sold 12 copies of VISTA, each one would cost £500m - with no aeroplane.
Now I don't know any details on Nimrod, nor do I seek to defend BAES and its commercial behaviour, however, when bemoaning cost escalations and what seem like massive costs, it must be bourne in mind that complex engineering is always expensive - this is a harsh reality & not something you can pretend can be avoided.
As a quick comparison, which is a bit rough around the edges, compare some of the costs bourne by Microsoft. It spends $7Bn / £3.5Bn per year on R&D. For the sake of argument, lets guess that say 1/3 of that is spent on their core product - PC operating systems. MS VISTA took 5 years to develop, from 2001 to 2006, hence taking approximately £6Bn to development. It contains 50 million lines of code.
Compare now to Nimrod MRA4, which apparently has 6 millions lines of code - OK not as much as VISTA, but then again each copy of the software comes with quite a large free aeroplane. Total cost is £3.6Bn. Now this is alot of money, but I think this perception is particularly exaggerated when it equates to £300m per copy, when you only buy 12.
By comparison, if Microsoft only sold 12 copies of VISTA, each one would cost £500m - with no aeroplane.
And how many of those 50 million lines of code are safety critical, which makes them more expensive per line of code. (Clue - ZERO), whereas Nimrod MRA 4 has more than a few.
Join Date: Apr 2002
Location: ecosse
Posts: 714
Likes: 0
Received 0 Likes
on
0 Posts
How about cutting the size of the House of Commons and the self serving B*stards that occupy it plus their present appeal scam to stop them being exposed to the fraudulent exploitation of taxpayers
If they've nothing to fear, they've nothing to hide
The millions they are defrauding from the system could support many threatened Defence projects
If they've nothing to fear, they've nothing to hide
The millions they are defrauding from the system could support many threatened Defence projects
Join Date: Nov 2007
Location: The Fletcher Memorial Home
Age: 59
Posts: 303
Likes: 0
Received 0 Likes
on
0 Posts
I just wanted to back up some of what JFZ90 was saying. I've been working for a major defence contractor for a number of years now and have been involved in several projects. While I've never touched Nimrod I know a number of the people who are on the project and the principles are the same on any aircraft.
With ANY aircraft engineering project you always have the same cycle: you design something, the customer looks at it and likes it so you build it. Then the customer sees what you've built and decides he wants to change it. So you have to re-design it or source a stock of a new part that will do waht the customer wants, then amend the drawings to record the change in design, fit the new parts, test them to make sure it works and it's not a hazard or a safety risk, organising manufacture of sufficient spares for the life of the item you've just changed and finally updating the maintenance manuals. Changing just one small part of any aircraft is expensive, purely because of the amount of time and paperwork involved.
The longer a project takes, the more chance the customer has to change his mind or decide he wants something else added. What started off as a simple "Lets update the ASW platform" has snowballed and the customer wants to get more than just something to find submarines. the last time I looked there was no major threat to shipping in the mountains of Afghanistan, so why are they flying there?
Ogre
With ANY aircraft engineering project you always have the same cycle: you design something, the customer looks at it and likes it so you build it. Then the customer sees what you've built and decides he wants to change it. So you have to re-design it or source a stock of a new part that will do waht the customer wants, then amend the drawings to record the change in design, fit the new parts, test them to make sure it works and it's not a hazard or a safety risk, organising manufacture of sufficient spares for the life of the item you've just changed and finally updating the maintenance manuals. Changing just one small part of any aircraft is expensive, purely because of the amount of time and paperwork involved.
The longer a project takes, the more chance the customer has to change his mind or decide he wants something else added. What started off as a simple "Lets update the ASW platform" has snowballed and the customer wants to get more than just something to find submarines. the last time I looked there was no major threat to shipping in the mountains of Afghanistan, so why are they flying there?
Ogre
Ogre
Excellent post. But to qualify some of the points you made, as applied to MoD aircraft projects.
“Then the customer sees what you've built and decides he wants to change it”.
This is where firm leadership in the project team and, perhaps more importantly, oversight at Project Director level and above is important. (It’s what they’re paid for). Minigundiplomat made a perceptive post when he simply said “Chinook Mk3”. That project has been slated by the Defence Committee for “poor management oversight”. No attempt is made to actually identify that “management” (as usual), but a cursory glance tells you it’s precisely the same few people as Nimrod MRA4, particularly at 2 Star. You mention the dreaded “Change”. To change requires Configuration Control, a key component of Airworthiness. Same management – “Configuration Control Boards are unnecessary”. “Critical Design Reviews may be waived”. (This should be a criminal offence). A weak project manager or director will permit all and sundry access to the Contractor, and delegate to them authority to demand such changes, regardless of time, cost or performance issues. Control of, in effect the whole project is lost; and so maintaining the correct build standard becomes almost impossible. Same management said this was ok. This is THE fundamental weakness in MoD.
“…. then amend the drawings to record the change in design”
Same management – “not required”. If you insist on doing it, fine, but you’re not getting funds so make a cut somewhere else. Same effect – airworthiness compromised. Increasingly, as MoD’s experience has been diluted, maintaining up-to-date drawings is viewed as a waste of money. Ask BAeS.
“….fit the new parts, test them to make sure it works and it's not a hazard or a safety risk”
You must be joking! Same 2 Star completely rejected this notion. Or, to be precise, he ruled by all means fit them but Integration and Trials are unnecessary, and don’t worry about hazards and safety. If it doesn’t work, and Boscombe reject it as unsafe, ignore it, pay off the contract and run. Led indirectly to Tornado/Patriot.
“…..organising manufacture of sufficient spares for the life of the item you've just changed”
In our dreams. If you want spares, there’s plenty of potential Xmas Trees in the hangars. See Apache.
“….and finally updating the maintenance manuals”. (And I could add training).
Ditto. Read the QQ report, which merely reiterates what we’ve known since 1991, when the policy decision was made to chop this.
I say this often. It is one thing to Attain a standard or airworthiness, but quite a different matter to Maintain it. My opinion is that, if you’ve never done the latter you’re unlikely to be a success at the former; in project management terms. Compare the MoD’s success stories (of which there are many) with the cock-ups and you’ll see what I mean. Trouble is, MoD refused to drink from the well of experience, the same management referring to such people as “an embarrassment to the Department” and “tainted”. The well has run dry and the perpetrators are retired now.
Excellent post. But to qualify some of the points you made, as applied to MoD aircraft projects.
“Then the customer sees what you've built and decides he wants to change it”.
This is where firm leadership in the project team and, perhaps more importantly, oversight at Project Director level and above is important. (It’s what they’re paid for). Minigundiplomat made a perceptive post when he simply said “Chinook Mk3”. That project has been slated by the Defence Committee for “poor management oversight”. No attempt is made to actually identify that “management” (as usual), but a cursory glance tells you it’s precisely the same few people as Nimrod MRA4, particularly at 2 Star. You mention the dreaded “Change”. To change requires Configuration Control, a key component of Airworthiness. Same management – “Configuration Control Boards are unnecessary”. “Critical Design Reviews may be waived”. (This should be a criminal offence). A weak project manager or director will permit all and sundry access to the Contractor, and delegate to them authority to demand such changes, regardless of time, cost or performance issues. Control of, in effect the whole project is lost; and so maintaining the correct build standard becomes almost impossible. Same management said this was ok. This is THE fundamental weakness in MoD.
“…. then amend the drawings to record the change in design”
Same management – “not required”. If you insist on doing it, fine, but you’re not getting funds so make a cut somewhere else. Same effect – airworthiness compromised. Increasingly, as MoD’s experience has been diluted, maintaining up-to-date drawings is viewed as a waste of money. Ask BAeS.
“….fit the new parts, test them to make sure it works and it's not a hazard or a safety risk”
You must be joking! Same 2 Star completely rejected this notion. Or, to be precise, he ruled by all means fit them but Integration and Trials are unnecessary, and don’t worry about hazards and safety. If it doesn’t work, and Boscombe reject it as unsafe, ignore it, pay off the contract and run. Led indirectly to Tornado/Patriot.
“…..organising manufacture of sufficient spares for the life of the item you've just changed”
In our dreams. If you want spares, there’s plenty of potential Xmas Trees in the hangars. See Apache.
“….and finally updating the maintenance manuals”. (And I could add training).
Ditto. Read the QQ report, which merely reiterates what we’ve known since 1991, when the policy decision was made to chop this.
I say this often. It is one thing to Attain a standard or airworthiness, but quite a different matter to Maintain it. My opinion is that, if you’ve never done the latter you’re unlikely to be a success at the former; in project management terms. Compare the MoD’s success stories (of which there are many) with the cock-ups and you’ll see what I mean. Trouble is, MoD refused to drink from the well of experience, the same management referring to such people as “an embarrassment to the Department” and “tainted”. The well has run dry and the perpetrators are retired now.
A pint of whatever JFZ90 is on please barman !
S_H
S_H
And how many of those 50 million lines of code are safety critical, which makes them more expensive per line of code. (Clue - ZERO), whereas Nimrod MRA 4 has more than a few.
Registered User **
Join Date: Mar 2005
Location: Cambridge
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
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
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
Hellbound
Join Date: Mar 2006
Location: Blighty
Posts: 554
Likes: 0
Received 0 Likes
on
0 Posts
The beauty of a thread like this is that it makes it obvious how difficult procurement decisions and priorities are. Everyone has a different opinion, they are all valid and all need to be considered; however, what is missing is the top-level guidance to allow informed decisions to be made.
There is no doubt that all the equipment/capability mentioned previously is important to what we aspire to do, but the problem is with knowing whether or not our aspirations are appropriate. By that I mean are they needed, technologically feasible and affordable.
Need is always subjective and should be defined by a clear statement from Government what effect the MoD must be able to provide in order to support its Foreign & Domestic policies.
Technology moves on, granted, but there must be a balance of simple kit that works when asked (clothing, vehicles, radios ((and arguably SH!!!)) etc) against high-tech kit that is absolutely essential to overcome a potential adversary's capability.
Affordability is, of course, the key to all of this. When I buy a car I can do it 2 ways. I can either; determine what spec of vehicle I require and then see what I can buy with the money (this might lead to me buying something a couple of years older or from the far east, rather than Bavaria), or I can go shopping knowing my budget and balance what it will get me against the less essential items on my wishlist. Presently, the MoD does neither - it walks around with a wishlist of capabilities without a real priority list (that it repeatedly adds to and faffs with) and no real idea of what something should cost and wonders why it gets itself into financial strife.
What is required is a fundamental line in the sand that says - 'MoD, HMG requires you to support policy in this way - please tell me how much it is going to cost and we will decide if it is affordable' or 'MoD, you have this much money, how safe can you keep us?'. With neither clearly defined, the in-fghting, confusion and division within the MoD about what is required will continue to be counter productive and divert more money away from where it is most needed.
I do not argue for or against any capability/platform; rather argue that something has to give and that we should cut capabilities that are nice to have in favour of the essential ones at the top of the non-existant priority list until we match the budget provided. This is unpalatable, definitely, but we must provide to Government a realistic assessment of the effect we can provide with the budget they give us, and we must draw a line in the sand and say 'no more scrimping and saving to deliver more - that is what you funded, that is what you have'. Then we would all know where we stand and be able to move forward.
Not holding my breath...
There is no doubt that all the equipment/capability mentioned previously is important to what we aspire to do, but the problem is with knowing whether or not our aspirations are appropriate. By that I mean are they needed, technologically feasible and affordable.
Need is always subjective and should be defined by a clear statement from Government what effect the MoD must be able to provide in order to support its Foreign & Domestic policies.
Technology moves on, granted, but there must be a balance of simple kit that works when asked (clothing, vehicles, radios ((and arguably SH!!!)) etc) against high-tech kit that is absolutely essential to overcome a potential adversary's capability.
Affordability is, of course, the key to all of this. When I buy a car I can do it 2 ways. I can either; determine what spec of vehicle I require and then see what I can buy with the money (this might lead to me buying something a couple of years older or from the far east, rather than Bavaria), or I can go shopping knowing my budget and balance what it will get me against the less essential items on my wishlist. Presently, the MoD does neither - it walks around with a wishlist of capabilities without a real priority list (that it repeatedly adds to and faffs with) and no real idea of what something should cost and wonders why it gets itself into financial strife.
What is required is a fundamental line in the sand that says - 'MoD, HMG requires you to support policy in this way - please tell me how much it is going to cost and we will decide if it is affordable' or 'MoD, you have this much money, how safe can you keep us?'. With neither clearly defined, the in-fghting, confusion and division within the MoD about what is required will continue to be counter productive and divert more money away from where it is most needed.
I do not argue for or against any capability/platform; rather argue that something has to give and that we should cut capabilities that are nice to have in favour of the essential ones at the top of the non-existant priority list until we match the budget provided. This is unpalatable, definitely, but we must provide to Government a realistic assessment of the effect we can provide with the budget they give us, and we must draw a line in the sand and say 'no more scrimping and saving to deliver more - that is what you funded, that is what you have'. Then we would all know where we stand and be able to move forward.
Not holding my breath...
Southbound
I agree in general terms with what you say, but would say that the processes you describe exist. The problem, as seen by those who actually commit the money, is that the decision making process is not transparent. So, if a decision is technologically impossible (the old BOWMAN chestnut of high quality real-time video via an ancient VHF radio is a good one) or unaffordable (I want 20 systems at £1M each, here’s £3M), then it’s difficult to regress. The Gods have pronounced, so get on with it.
I may be an old dinosaur (it’s official, it’s in an annual report) but the old Long Term Costings system worked for me. First Order Assumptions (We need an Army of this size, to do this………). Second Order Assumptions (In effect, the reply; that being so, you need xx tanks, aircraft, ships, and they need to be placed here, there…. And be able to do this….. And be maintained thus….). Third Order Assumptions (The aircraft must have the following kit, spares, test equipment, trained staff, facilities, pubs ….. and it all must be maintained through-life). And this is how much it’ll cost………..
And then the “basket weaving” started………… Basket 1 – Critical requirement, not tradeable at any cost. Basket 2 – We’ll take the hit if you insist, but here’s the unpalatable impact. Sign if you dare. Basket 3 – We think we need it, but we’ll take the hit. In other words, a strict prioritisation process with an opportunity to state your case. In practice (in my day) anything in Basket 3 was at risk. To set this in the current context, these days Basket 1 is constantly at risk.
The golden rule was – if there’s not a Second, there can be no Third. If the Third is not endorsed and approved, resubmit the Second and take the hit. Or go back to the top and have the First amended. That concentrated the mind of what is now DEC. The system was completely transparent to all involved. Responsibilities and authority was well defined. For example, the Thirds could only be amended by an Engineer, who was permitted to do so using engineering judgement; but he had to explain himself and demonstrate the change was cost neutral. If he needed more money, he had the authority to juggle within his remit (say, avionic systems across the RAF). If this didn’t work, he prepared a Business Case (Submission).
If you ask nowadays who is meant to do this, the Requirements Managers have the nearest Terms of Reference. None have the slightest scoobie what I’m talking about; and few are engineers, so are automatically restricted in their role anyway. The reason I know how to do it is because it used to be a junior CS task (broadly equivalent to an SO3), and a stepping stone to promotion into project management. It follows that, if you’ve done this and understand it, you avoid most of the common pitfalls that one encounters in procurement. As ever, I can only speak from experience.
Sorry, long post, but the perfectly good, and still extant (only because they’ve never been cancelled) permanent LTC (EP) instructions explain all this. Best job I’ve ever had. This may seem strange to most here, but to have good teachers, and to understand and have control over what you do, and see the end result is a fine thing.
I agree in general terms with what you say, but would say that the processes you describe exist. The problem, as seen by those who actually commit the money, is that the decision making process is not transparent. So, if a decision is technologically impossible (the old BOWMAN chestnut of high quality real-time video via an ancient VHF radio is a good one) or unaffordable (I want 20 systems at £1M each, here’s £3M), then it’s difficult to regress. The Gods have pronounced, so get on with it.
I may be an old dinosaur (it’s official, it’s in an annual report) but the old Long Term Costings system worked for me. First Order Assumptions (We need an Army of this size, to do this………). Second Order Assumptions (In effect, the reply; that being so, you need xx tanks, aircraft, ships, and they need to be placed here, there…. And be able to do this….. And be maintained thus….). Third Order Assumptions (The aircraft must have the following kit, spares, test equipment, trained staff, facilities, pubs ….. and it all must be maintained through-life). And this is how much it’ll cost………..
And then the “basket weaving” started………… Basket 1 – Critical requirement, not tradeable at any cost. Basket 2 – We’ll take the hit if you insist, but here’s the unpalatable impact. Sign if you dare. Basket 3 – We think we need it, but we’ll take the hit. In other words, a strict prioritisation process with an opportunity to state your case. In practice (in my day) anything in Basket 3 was at risk. To set this in the current context, these days Basket 1 is constantly at risk.
The golden rule was – if there’s not a Second, there can be no Third. If the Third is not endorsed and approved, resubmit the Second and take the hit. Or go back to the top and have the First amended. That concentrated the mind of what is now DEC. The system was completely transparent to all involved. Responsibilities and authority was well defined. For example, the Thirds could only be amended by an Engineer, who was permitted to do so using engineering judgement; but he had to explain himself and demonstrate the change was cost neutral. If he needed more money, he had the authority to juggle within his remit (say, avionic systems across the RAF). If this didn’t work, he prepared a Business Case (Submission).
If you ask nowadays who is meant to do this, the Requirements Managers have the nearest Terms of Reference. None have the slightest scoobie what I’m talking about; and few are engineers, so are automatically restricted in their role anyway. The reason I know how to do it is because it used to be a junior CS task (broadly equivalent to an SO3), and a stepping stone to promotion into project management. It follows that, if you’ve done this and understand it, you avoid most of the common pitfalls that one encounters in procurement. As ever, I can only speak from experience.
Sorry, long post, but the perfectly good, and still extant (only because they’ve never been cancelled) permanent LTC (EP) instructions explain all this. Best job I’ve ever had. This may seem strange to most here, but to have good teachers, and to understand and have control over what you do, and see the end result is a fine thing.
Hellbound
Join Date: Mar 2006
Location: Blighty
Posts: 554
Likes: 0
Received 0 Likes
on
0 Posts
Tuc
absolutely spot on. There was a process that was the same for all and there were sufficient people dedicated to the task. With our DECs and IPTs shrunk drastically, the workload on our requirements managers has increased. With funding shrinking in real terms, our teams rely on conflict funds to finance core capability through the back door, but there is so much of this going on that no-one is keeping track of what is/isn't/should be core capability. It is all a mess.
Until someone sorts out what items in basket one are essential, we are condemned to making do, planning blight and sub-optimal solutions for everything (except Typhoon!). God, I 've depressed myself now.
absolutely spot on. There was a process that was the same for all and there were sufficient people dedicated to the task. With our DECs and IPTs shrunk drastically, the workload on our requirements managers has increased. With funding shrinking in real terms, our teams rely on conflict funds to finance core capability through the back door, but there is so much of this going on that no-one is keeping track of what is/isn't/should be core capability. It is all a mess.
Until someone sorts out what items in basket one are essential, we are condemned to making do, planning blight and sub-optimal solutions for everything (except Typhoon!). God, I 've depressed myself now.
Join Date: Nov 2000
Location: Lincs
Posts: 453
Likes: 0
Received 0 Likes
on
0 Posts
Ogre,
In my humble opinion, very few problems with the MRA4 are down to requirement creep. Focus has rightly remained very tightly on ASW/ASuW, not least because it falls under Director Equipment Capability Under Water Effect (DEC UWE) rather than DEC ISTAR.
Regards,
MM
In my humble opinion, very few problems with the MRA4 are down to requirement creep. Focus has rightly remained very tightly on ASW/ASuW, not least because it falls under Director Equipment Capability Under Water Effect (DEC UWE) rather than DEC ISTAR.
Regards,
MM
MM,
You might find Airpower's comments here of some interest.
Also, Boeing says (Jackonicko notwithstanding) that they are the good guys on MRA4, see page 17 of this document...
And while there are a few 1960s bits and pieces in the P-8A, the 737's been through a couple of major overhauls since then; and it's not just the age of the design, but the fact that there are 5000 of them flying around.
I'll leave the doubts about twin engines to the professionals except for pointing out that today's engines are far more reliable than the engines of the 1960s... and that the US Navy is no doubt glad that it passed up BAE's proposal to sell them MRA4s for MMA.
You might find Airpower's comments here of some interest.
Also, Boeing says (Jackonicko notwithstanding) that they are the good guys on MRA4, see page 17 of this document...
And while there are a few 1960s bits and pieces in the P-8A, the 737's been through a couple of major overhauls since then; and it's not just the age of the design, but the fact that there are 5000 of them flying around.
I'll leave the doubts about twin engines to the professionals except for pointing out that today's engines are far more reliable than the engines of the 1960s... and that the US Navy is no doubt glad that it passed up BAE's proposal to sell them MRA4s for MMA.
While one sometimes asks questions knowing the answer, in the hope of getting a 'bite', my question about Boeing's share of the 'blame' for MRA4's woes (if it has such woes.... 
) was quite genuine.
It would be interesting to hear whether those who criticise elements of the MRA4 mission system would agree with Boeing's contention on p.17 that "Boeing’s Nimrod MRA-4 maritime mission system sets the standard - Developed and delivered ahead of schedule and below cost". It may be that it is entirely non-Boeing kit that is causing the problems, though given the reported problems, it's hard to see how Boeing's role (didn't it include some integration?) could be considered to have been completed on MRA4.
It's interesting that on the same page, Boeing touts its "Successful history of developing, integrating, and updating mission systems for numerous large scale programs", and then includes the 737 AEW&C among the examples.
That said, Boeing has a long track record of doing things really well (I'd view Wedgetail and KC-767 as being exceptions to a very respectable rule), and without problems. I'd therefore be quite prepared to believe that the company has a squeaky clean record on MRA4. Indeed, if it were otherwise, I'd have expected to hear bitching about their performance, and I haven't.
I didn't think it was the 737's number of engines that was the problem - rather with the unsuitability of the configuration to do the kind of 'yanking and banking' at low level that is usually associated with ASW ops by P-3s and Nimrods.
As to Bill Sweetman's blog, no-one could be a bigger fan of Bill than I am (if Av Week now hire Nick Cook they will have the triumverate of milavjournogods), but I'm still smarting that he single-handedly convinced me that a KC-330 victory in KC-X was not just unlikely, but impossible, so I'm now taking him with pinches of salt.
And the man clearly needs a holiday, you don't spell it ares 
, bill, it's arse......
Coat, hat, I know the drill.
) was quite genuine.It would be interesting to hear whether those who criticise elements of the MRA4 mission system would agree with Boeing's contention on p.17 that "Boeing’s Nimrod MRA-4 maritime mission system sets the standard - Developed and delivered ahead of schedule and below cost". It may be that it is entirely non-Boeing kit that is causing the problems, though given the reported problems, it's hard to see how Boeing's role (didn't it include some integration?) could be considered to have been completed on MRA4.
It's interesting that on the same page, Boeing touts its "Successful history of developing, integrating, and updating mission systems for numerous large scale programs", and then includes the 737 AEW&C among the examples.
That said, Boeing has a long track record of doing things really well (I'd view Wedgetail and KC-767 as being exceptions to a very respectable rule), and without problems. I'd therefore be quite prepared to believe that the company has a squeaky clean record on MRA4. Indeed, if it were otherwise, I'd have expected to hear bitching about their performance, and I haven't.
I didn't think it was the 737's number of engines that was the problem - rather with the unsuitability of the configuration to do the kind of 'yanking and banking' at low level that is usually associated with ASW ops by P-3s and Nimrods.
As to Bill Sweetman's blog, no-one could be a bigger fan of Bill than I am (if Av Week now hire Nick Cook they will have the triumverate of milavjournogods), but I'm still smarting that he single-handedly convinced me that a KC-330 victory in KC-X was not just unlikely, but impossible, so I'm now taking him with pinches of salt.
And the man clearly needs a holiday, you don't spell it ares , bill, it's arse......Coat, hat, I know the drill.
Last edited by Jackonicko; 28th Mar 2008 at 14:09.
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
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
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.
Last edited by JFZ90; 28th Mar 2008 at 18:23.
Join Date: Jun 2007
Location: Colditz young offenders centre
Posts: 220
Likes: 0
Received 0 Likes
on
0 Posts
JFZ90 This is all jolly interesting ...
and it would be pertinent to Nimrod MRA4, if that A/C had a digital flight control system, as per A320, B777 and on.
Comparisons of software costs with aircraft of that class just don't apply here.
and which would typically be more complex for aspects of critical systems - e.g flight control laws)
Comparisons of software costs with aircraft of that class just don't apply here.
JFZ90 This is all jolly interesting ...
Quote:
and which would typically be more complex for aspects of critical systems - e.g flight control laws)
and it would be pertinent to Nimrod MRA4, if that A/C had a digital flight control system, as per A320, B777 and on.
Comparisons of software costs with aircraft of that class just don't apply here.
Quote:
and which would typically be more complex for aspects of critical systems - e.g flight control laws)
and it would be pertinent to Nimrod MRA4, if that A/C had a digital flight control system, as per A320, B777 and on.
Comparisons of software costs with aircraft of that class just don't apply here.