-
#360
by
archipeppe68
on 07 Jun, 2022 11:26
-
My personal contribution to the matter.
-
#361
by
greybeardengineer
on 07 Jun, 2022 13:07
-
from a layman prospective, Isn't software part of the design?
The idea that software isn't a core, key functional element of an overall design, that it is "the other", a troublesome add-on after the fact is an old school hangover of metal bender mentality primarily in the defense sector but also prevalent in established industrial sector giants.
This is the attitude that gave us the 737 MAX MCAS fiasco, the OFT clown show, and numerous defense system programs with massive cost overruns and extended delays becoming operational, if not outright cancellation like the M247 Sergeant York.
Thankfully newer entrants into the aerospace sector are bringing in the far more enlightened attitudes towards software of the high tech, commercial, and consumer sectors with them.
-
#362
by
edzieba
on 07 Jun, 2022 14:07
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating. 
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
Emphasis mine.
No, it is was NOT an input error. ULA's Atlas V gave the correct inputs.
The INcorrect initialization of the MET timer was in fact a design error, just as GreyBeardEngineer had correctly indicated.
[snip]
That's a very long winded way to say the software implementation did not follow the software design. Software design occurs before coding (if you're getting into even psuedocode you're going too deep), and should be independant of the actual code written - so you could implement the same software design in a variety of different languages with the same desired outcome. The design was correct, but it was not implemented (coded) correctly.
The hardware analog make the distinction clear: if you specify a part X mm long to fit in an X mm deep hole, and the part is produced X m long, the design was correct but the implementation was not. If the design specifies an X m long part to fit in an X mm deep hole, that's a design flaw.
If you consider your implemented code as your software design, you're in the same situation as cutting hardware to fit as you build it: the days of individually fettled parts are long over and it is now bad practice due to lack of testability, repeatability, and documentation.
-
#363
by
Jim
on 07 Jun, 2022 16:27
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
Emphasis mine.
No, it is was NOT an input error. ULA's Atlas V gave the correct inputs.
The INcorrect initialization of the MET timer was in fact a design error, just as GreyBeardEngineer had correctly indicated.
That is wrong as well as the rest of the explanation.
-
#364
by
Jim
on 07 Jun, 2022 16:28
-
from a layman prospective, Isn't software part of the design?
The idea that software isn't a core, key functional element of an overall design, that it is "the other", a troublesome add-on after the fact is an old school hangover of metal bender mentality primarily in the defense sector but also prevalent in established industrial sector giants.
This is the attitude that gave us the 737 MAX MCAS fiasco, the OFT clown show, and numerous defense system programs with massive cost overruns and extended delays becoming operational, if not outright cancellation like the M247 Sergeant York.
Thankfully newer entrants into the aerospace sector are bringing in the far more enlightened attitudes towards software of the high tech, commercial, and consumer sectors with them.
Wrong take away again
-
#365
by
deadman1204
on 07 Jun, 2022 16:33
-
That is wrong as well as the rest of the explanation.
Wrong take away again
Care to elaborate instead of just claiming you know better and walking away again?
-
#366
by
Surfdaddy
on 07 Jun, 2022 17:32
-
from a layman prospective, Isn't software part of the design?
The idea that software isn't a core, key functional element of an overall design, that it is "the other", a troublesome add-on after the fact is an old school hangover of metal bender mentality primarily in the defense sector but also prevalent in established industrial sector giants.
This is the attitude that gave us the 737 MAX MCAS fiasco, the OFT clown show, and numerous defense system programs with massive cost overruns and extended delays becoming operational, if not outright cancellation like the M247 Sergeant York.
Thankfully newer entrants into the aerospace sector are bringing in the far more enlightened attitudes towards software of the high tech, commercial, and consumer sectors with them.
Wrong take away again
That's the sort of view that has created the problems we are facing.
Today, software executes many functions which used to be done more in hardware. That older hardware was designed.
So is today's software. If the software has failed, then it's just like hardware that failed in the past.
-
#367
by
Jim
on 07 Jun, 2022 17:36
-
from a layman prospective, Isn't software part of the design?
The idea that software isn't a core, key functional element of an overall design, that it is "the other", a troublesome add-on after the fact is an old school hangover of metal bender mentality primarily in the defense sector but also prevalent in established industrial sector giants.
This is the attitude that gave us the 737 MAX MCAS fiasco, the OFT clown show, and numerous defense system programs with massive cost overruns and extended delays becoming operational, if not outright cancellation like the M247 Sergeant York.
Thankfully newer entrants into the aerospace sector are bringing in the far more enlightened attitudes towards software of the high tech, commercial, and consumer sectors with them.
Wrong take away again
That's the sort of view that has created the problems we are facing.
Today, software executes many functions which used to be done more in hardware. That older hardware was designed.
So is today's software. If the software has failed, then it's just like hardware that failed in the past.
I was referring to the last two paragraphs and not software’s place in system development
-
#368
by
SoftwareDude
on 07 Jun, 2022 17:52
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
Emphasis mine.
No, it is was NOT an input error. ULA's Atlas V gave the correct inputs.
The INcorrect initialization of the MET timer was in fact a design error, just as GreyBeardEngineer had correctly indicated.
[snip]
That's a very long winded way to say the software implementation did not follow the software design. Software design occurs before coding (if you're getting into even psuedocode you're going too deep), and should be independant of the actual code written - so you could implement the same software design in a variety of different languages with the same desired outcome. The design was correct, but it was not implemented (coded) correctly.
The hardware analog make the distinction clear: if you specify a part X mm long to fit in an X mm deep hole, and the part is produced X m long, the design was correct but the implementation was not. If the design specifies an X m long part to fit in an X mm deep hole, that's a design flaw.
If you consider your implemented code as your software design, you're in the same situation as cutting hardware to fit as you build it: the days of individually fettled parts are long over and it is now bad practice due to lack of testability, repeatability, and documentation.
True for a waterfall software design.
-
#369
by
Eric Hedman
on 07 Jun, 2022 18:33
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
Emphasis mine.
No, it is was NOT an input error. ULA's Atlas V gave the correct inputs.
The INcorrect initialization of the MET timer was in fact a design error, just as GreyBeardEngineer had correctly indicated.
[snip]
That's a very long winded way to say the software implementation did not follow the software design. Software design occurs before coding (if you're getting into even psuedocode you're going too deep), and should be independant of the actual code written - so you could implement the same software design in a variety of different languages with the same desired outcome. The design was correct, but it was not implemented (coded) correctly.
The hardware analog make the distinction clear: if you specify a part X mm long to fit in an X mm deep hole, and the part is produced X m long, the design was correct but the implementation was not. If the design specifies an X m long part to fit in an X mm deep hole, that's a design flaw.
If you consider your implemented code as your software design, you're in the same situation as cutting hardware to fit as you build it: the days of individually fettled parts are long over and it is now bad practice due to lack of testability, repeatability, and documentation.
True for a waterfall software design.
I can't stand waterfall software design. You can't anticipate everything up front and you will take forever to get through the design process as you try to anticipate everything. Agile development with rapid prototyping has always worked the best for me.
-
#370
by
ccdengr
on 07 Jun, 2022 18:47
-
I can't stand waterfall software design.
Sure, but I find it hard to believe that true waterfall has ever been used. "Modified waterfall" where you can have feedback has always been used where I am. But fine distinctions about what methodology you're following can't substitute for code that works.
-
#371
by
meekGee
on 07 Jun, 2022 19:23
-
So much hair splitting.
The software was written wrong. The next Starliner would have had the same software, and would have acted the same.
This was not a process error where a particular vehicle's fabrication deviated from the design (e.g. the wrong software version was loaded into the computer)
*** Everything worked as designed. And failed. ***
Now the lawyer-types can go back to hair splitting.
-
#372
by
meekGee
on 07 Jun, 2022 19:32
-
That is wrong as well as the rest of the explanation.
Wrong take away again
Care to elaborate instead of just claiming you know better and walking away again?
It's kind of word sorcery...
See, the top-level requirements are always satisfied, or else you won't pass PDR even. So now you can claim that it's not a design mistake but an "implementation" mistake?
Of course not - the implementation is every bit as part of the design as top-level design.
Top level requirements can say "a valve is supposed to do this and that", but if the valve is then implemented badly, it's still a design mistake. The only other option is if the valve came in from the vendor in a flawed state, or if it was installed incorrectly or exposed to environments it was not supposed to be exposed to.
-
#373
by
Barley
on 07 Jun, 2022 19:33
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
Emphasis mine.
No, it is was NOT an input error. ULA's Atlas V gave the correct inputs.
The INcorrect initialization of the MET timer was in fact a design error, just as GreyBeardEngineer had correctly indicated.
[snip]
That's a very long winded way to say the software implementation did not follow the software design. Software design occurs before coding (if you're getting into even psuedocode you're going too deep), and should be independant of the actual code written - so you could implement the same software design in a variety of different languages with the same desired outcome. The design was correct, but it was not implemented (coded) correctly.
Coding is part of software design. It's something you do once, not for each deployment of the software.
The software equivalent of production is loading the image to PROM or FLASH or disk. This does get messed up occasionally, but by and large it's a solved problem.
The sooner all the people who think coding is a manufacturing process retire the better.
-
#374
by
Lee Jay
on 07 Jun, 2022 20:18
-
Coding is part of software design. It's something you do once, not for each deployment of the software.
The software equivalent of production is loading the image to PROM or FLASH or disk. This does get messed up occasionally, but by and large it's a solved problem.
The sooner all the people who think coding is a manufacturing process retire the better.
Coding isn't manufacturing or design (unless you do design and coding at the same time resulting in a bad product). First you design the software (architecture, language, specs, and so on), then you code it according to the design. Coding is implementation, which is between design and testing. Manufacturing and/or distribution is later.
-
#375
by
Tommyboy
on 07 Jun, 2022 20:48
-
from a layman prospective, Isn't software part of the design?
The idea that software isn't a core, key functional element of an overall design, that it is "the other", a troublesome add-on after the fact is an old school hangover of metal bender mentality primarily in the defense sector but also prevalent in established industrial sector giants.
This is the attitude that gave us the 737 MAX MCAS fiasco, the OFT clown show, and numerous defense system programs with massive cost overruns and extended delays becoming operational, if not outright cancellation like the M247 Sergeant York.
Thankfully newer entrants into the aerospace sector are bringing in the far more enlightened attitudes towards software of the high tech, commercial, and consumer sectors with them.
Wrong take away again
That's the sort of view that has created the problems we are facing.
Today, software executes many functions which used to be done more in hardware. That older hardware was designed.
So is today's software. If the software has failed, then it's just like hardware that failed in the past.
I was referring to the last two paragraphs and not software’s place in system development
Than maybe you should have been less smug and said so. That extra kB worth of database space your comment would have taken isn't worth the misunderstandings you keep causing.
-
#376
by
clongton
on 07 Jun, 2022 21:15
-
Did anyone here actually have a hand in writing the algorithms? No
Did anyone here actually have a hand in writing the software? No
Did anyone here actually have a hand in testing the software? No
Was anyone here actually involved in implementing the software? No
So what are we arguing about?
A bunch of people who were not actually involved in any way, shape or form arguing with other people who were not actually involved in any way shape or form, arguing about the semantics of each other's personal, uninformed opinions.
Enough already! Can we please move on to discussing what is ACTUALLY known about Starliner?
Thank you.
-
#377
by
Vettedrmr
on 07 Jun, 2022 21:19
-
Coding is part of software design. It's something you do once, not for each deployment of the software.
The software equivalent of production is loading the image to PROM or FLASH or disk. This does get messed up occasionally, but by and large it's a solved problem.
The sooner all the people who think coding is a manufacturing process retire the better.
Yes and No. Yes, once a product's code has been written, compiled, loaded, and tested, it then becomes part of the production configuration that's cranked out with each delivered unit.
No, in that code is NOT design. A proper software design is code-agnostic. IOW, I can implement a given design in one of several different languages that support the product hardware. Also, software requirements, high level design, and detail design documents all comprise what I'd call "software design."
-
#378
by
deadman1204
on 07 Jun, 2022 21:46
-
Did anyone here actually have a hand in writing the algorithms? No
Did anyone here actually have a hand in writing the software? No
Did anyone here actually have a hand in testing the software? No
Was anyone here actually involved in implementing the software? No
So what are we arguing about?
A bunch of people who were not actually involved in any way, shape or form arguing with other people who were not actually involved in any way shape or form, arguing about the semantics of each other's personal, uninformed opinions.
Enough already! Can we please move on to discussing what is ACTUALLY known about Starliner?
Thank you.
Honestly, isn't 95% of whats said on this forum speculation anyways?
This software thing is about 2 things really:
1. some people not understanding that software is an integral part of engineering and design concepts
2. Jim doing more 1 phrase dump posts.
-
#379
by
Jim
on 07 Jun, 2022 23:17
-
That is wrong as well as the rest of the explanation.
Wrong take away again
Care to elaborate instead of just claiming you know better and walking away again?
I can't share everything I know.
