|
|
Thread Tools | Display Modes |
#81
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
stmx3 writes:
Jan C. Vorbrüggen wrote: The people writing the Shuttle avionics software are one of very few - maybe three to five - groups rated as "Level 5" by the Software Engineering Institute - in fact, they're somewhat of a role model for that level. No comparison to Redmond et al., who are around level 1 or 2. Impressive! That speaks volumes as to the complexity of the code they have had to deal with. Not really. This has more to do with your software development processes and how you continuously improve it. It doesn't really matter if you're applying these processes to shuttle avionics, a word processor, or an operating system. http://www.sei.cmu.edu/about/about.html Jeff -- Remove "no" and "spam" from email address to reply. If it says "This is not spam!", it's surely a lie. |
#82
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
From Jeff Findley:
stmx3 writes: Jan C. Vorbrüggen wrote: The people writing the Shuttle avionics software are one of very few - maybe three to five - groups rated as "Level 5" by the Software Engineering Institute - in fact, they're somewhat of a role model for that level. No comparison to Redmond et al., who are around level 1 or 2. Impressive! That speaks volumes as to the complexity of the code they have had to deal with. Not really. This has more to do with your software development processes and how you continuously improve it. It doesn't really matter if you're applying these processes to shuttle avionics, a word processor, or an operating system. http://www.sei.cmu.edu/about/about.html I would agree that the chances of a shuttle crashing due to a software glitch is very small. The point was why take a chance when you have proven flown software available? It becomes a risk trade with any potential safety gains in the new version. ~ CT |
#83
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
From stmx3:
Stuf4 wrote: [snip] I see it as a matter of confidence, as previously stated. I don't see much significant change in the level of risk during that period. Nor in NASA's perception of that risk. [snip] But don't say 12 flights is too conservative while 1 is not conservative enough...risk does not decrease with each successful launch. But our awareness of risk *does*. This was the warning from STS-112. It shouted out that SOFI needed more attention. It got ignored. Your statements appear contradictory. In the first, you imply NASA's perception of the risk during the 12 flights following Challenger did not change. In the 2nd, you say the awareness of the risk does change over time. *THAT* was my earlier point...perhaps NASA became complacent in assessing risk. Unless I am misreading you, you are not consistent in your point of view. To restate for clarity... Our awareness of risk doesn't change much when nothing goes wrong, but close calls *will* increase our awareness. This is why confidence building is needed. You may think that you have a handle on the risks, but empirical evidence can show you otherwise. *Confidence building* is almost as nebulous as *safety culture*. You should have the confidence before you risk lives. NASA's problem is that they became OVERCONFIDENT (not yelling, just emphasizing). Overconfidence comes from a successful flight, seemingly justifying the risks you've taken. 50 or more successful flights lead to a safety culture that doesn't insist on conducting stringent tests since this imposes a risk and budget and schedule and besides, "we have confidence that puny foam isn't going to bring down America's finest feat of engineering." I see it more as a matter of cold probability, along these lines: Q- "What are the odds that this foam shedding problem is going to hit the orbiter?" A- "We think that they are small and we are willing to take that risk." So I would agree with your assessment of overconfidence strictly from this probability aspect. I'm sure you've heard that the latest word from NASA (new since this thread) is that STS-114 *will* be treated as a test mission, a confidence builder if you will. snip Besides, there are worse ways to die. (Ed Givens comes to mind.) I take it he picked the leather upholstery over the antilock brakes. Ha. ~ CT |
#84
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
|
#85
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
stmx3 wrote
[...] I suppose...if you're feint hearted. This sounds like shadow boxing to me, which makes me faint. /dps (no aplogies intended) |
#86
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
From Jeff Findley:
(Stuf4) writes: I would agree that the chances of a shuttle crashing due to a software glitch is very small. The point was why take a chance when you have proven flown software available? It becomes a risk trade with any potential safety gains in the new version. Because the benefits of the bug fixes and enhancements to the software might just outweigh the risks, especially considering the high level of quality in this particular software development group. I acknowledge validity to that argument. But I hope you see that it also skirts an "if it isn't broken, fix it anyway" philosophy. ~ CT |
#88
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
From Jeff Findley:
I would agree that the chances of a shuttle crashing due to a software glitch is very small. The point was why take a chance when you have proven flown software available? It becomes a risk trade with any potential safety gains in the new version. Because the benefits of the bug fixes and enhancements to the software might just outweigh the risks, especially considering the high level of quality in this particular software development group. I acknowledge validity to that argument. But I hope you see that it also skirts an "if it isn't broken, fix it anyway" philosophy. The devil is in the details. My point is that you have to look at what fixes and functional enhancements are in the (extensively ground tested) new version and compare that to the existing flight tested version. The flight tested version may very well have known problems and functional deficiencies that directly or indirectly impact flight safety. In the end, you can never improve on the released verion of software unless you ship patches and/or new versions. When doing so, you typically run all sorts of "regression testing" and don't allow the new version to ship with known regressions. This "regression testing" suite would typically contain all of the tests possible. In the case of STS software, I'm sure the regression testing is extensive. Those sound like excellent points. I expect that all of this was taken into consideration by NASA. ~ CT |
#89
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
|
#90
|
|||
|
|||
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents
From Jeff Findley:
snip I'm sure NASA wouldn't release a new version of the shuttle flight software without many simulations involving actual astronauts at the controls of the simulators. I agree. But if given the choice of launching with software that has gone through many simulations versus software that has gone through many simulations *and* several flights, I know what I'd choose. ~ CT |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Unofficial Space Shuttle Launch Guide | Steven S. Pietrobon | Space Shuttle | 0 | April 2nd 04 12:01 AM |
Unofficial Space Shuttle Launch Guide | Steven S. Pietrobon | Space Shuttle | 0 | February 2nd 04 03:33 AM |
MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents | James Oberg | Space Shuttle | 106 | October 24th 03 04:45 AM |
Unofficial Space Shuttle Launch Guide | Steven S. Pietrobon | Space Shuttle | 0 | September 12th 03 01:37 AM |
NASA: Gases Breached Wing of Shuttle Atlantis in 2000 | Rusty Barton | Space Shuttle | 2 | July 10th 03 01:27 AM |