A Space & astronomy forum. SpaceBanter.com

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » SpaceBanter.com forum » Space Science » Space Station
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents



 
 
Thread Tools Display Modes
  #81  
Old October 6th 03, 06:48 PM
jeff findley
external usenet poster
 
Posts: n/a
Default 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.
Ads
  #82  
Old October 7th 03, 06:03 AM
Stuf4
external usenet poster
 
Posts: n/a
Default 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  
Old October 7th 03, 06:25 AM
Stuf4
external usenet poster
 
Posts: n/a
Default 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
  #85  
Old October 7th 03, 11:12 PM
dave schneider
external usenet poster
 
Posts: n/a
Default 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)
  #87  
Old October 8th 03, 03:40 PM
jeff findley
external usenet poster
 
Posts: n/a
Default MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents

(Stuf4) writes:

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.


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.

Jeff
--
Remove "no" and "spam" from email address to reply.
If it says "This is not spam!", it's surely a lie.
  #88  
Old October 9th 03, 05:40 AM
Stuf4
external usenet poster
 
Posts: n/a
Default 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  
Old October 9th 03, 02:57 PM
jeff findley
external usenet poster
 
Posts: n/a
Default MSNBC (JimO) Scoops more Inside-NASA Shuttle Documents

(Stuf4) writes:

Those sound like excellent points. I expect that all of this was
taken into consideration by NASA.


I know it is. They do extensive ground testing of the software by
running it on the same hardware found in the shuttle. The shuttle
flight software development process is one of the best to be found in
terms of high quality, bug free code.

The software development process I'm used to at work isn't anywhere
near a Level 5, but we have a fairly extensive suite of automated
tests that are run on every build of the software (you've got to do
something productive with your computers at night). Before releasing
to the customer, the complete suite of regression tests are run (these
take a weekend or more to run, even when running in parallel on as
many machines as we can lay our hands on). These are based on
covering functionality as well as past problems and issues encountered
(to prevent them from cropping up again). Any problems found are
flagged as "must-fix before release". We simply don't allow
regression in quality, it's not acceptable to our customers.

This is in addition to alpha and beta testing with both internal users
and actual customers. 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.

Jeff
--
Remove "no" and "spam" from email address to reply.
If it says "This is not spam!", it's surely a lie.
  #90  
Old October 9th 03, 11:39 PM
Stuf4
external usenet poster
 
Posts: n/a
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 06:10 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright ©2004-2020 SpaceBanter.com.
The comments are property of their posters.