to respond to a thought on requirements, you respond with limitation of hardware vis-a-vis programs for rockets.
Wow. Is that what you read?
What I read was, that the single most carefully designed and specified software project in history had to deal with changes to its requirements throughout its 30 year lifespan.
Despite setting out with the goals of:
These lessons were applied to the Shuttle. One of the most important lessons was that software is more difficult to develop than hardware. As a result,
• software documentation is crucial,
• verification must proceed through a sequence of steps without skipping any to try to save time,
• requirements must be clearly defined and carefully managed,
• good development plans should be created and followed, and
• adding more programmers does not lead to faster development.
NASA also learned to assign experienced personnel to a project early, rather than using the start of a project for training inexperienced personnel.
And having 6 years of research & development time, and spending $200,000,000:
A second challenge involved requirements. The software requirements for the Shuttle were continually evolving and changing, even after the system became operational and throughout its 30-year operational lifetime. Although new hardware components were added to the Shuttle during its lifetime, such as GPS, the Shuttle hardware was basically fixed and most of the changes over time went into the computers and their software. NASA and its contractors made over 2,000 requirements changes between 1975 and the first flight in 1981. Even after first flight, requirements changes continued. The number of changes proposed and implemented required a strict process to be used or chaos would have resulted.
I guess its true what they say about those that will not see; or at least only see what they want to see.
| [reply] |
Is that what you read?
You linked to a long document without giving pointers past that. Further, you lightly insult in your posts. I wanted to just close it right there, but i respect you enough to at least skim the first few pages, and that indeed was what i saw. It's there, and quite relevant to the discussion.
While the "requirements" change here, as you point out "even after the system became operational and throughout its 30-year operational lifetime" That's a revision, not a requirements change. That's a revisions after the initial version came out and after the original requirements already produced a product. Agile will not help you there.
Now, if they started coding for the shuttle before it was done, in anticipation of the years required to write and test the software, perhaps the requirements could not be finished ahead of time, unless done piecemeal. If that was the case, i could hear the argument that Agile might be a viable alternative to piecemeal.
| [reply] |
While the "requirements" change here, as you point out "even after the system became operational and throughout its 30-year operational lifetime" That's a revision, not a requirements change.
Nancy G. Levenson, the same Nancy Leveson the US government chose to Chair the "COMMITTEE FOR REVIEW OF OVERSIGHT MECHANISMS FOR SPACE SHUTTLE FLIGHT SOFTWARE PROCESSES" that produced "An Assessment of Space Shuttle Flight Software Development Processes", chose to call this: "The Challenge of Changing Requirements".
You on the other say that she was wrong to do so. Let's see now, who's choice of phraseology do I take as authoritative?
Further, you lightly insult in your posts.
The I guess you don't want to know which box I put you in now.
| [reply] |