Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle

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.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Comment on Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^7: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 23, 2015 at 18:09 UTC
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]
Re^8: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk (Patriarch) on Jul 23, 2015 at 18:37 UTC
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. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :) In the absence of evidence, opinion is indistinguishable from prejudice. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]
Re^9: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham (Prior) on Jul 23, 2015 at 18:44 UTC
who's choice of phraseology do I take as authoritative I don't care what you call it, it's only the facts that we care about. The I guess you don't want to know which box I put you in now. You are an intelligent person who elaborates well on points in posts, and will usually take the time to respond all the way through a thread. If only you would stop using insults, your posts would be even better, and more people would look forward to reading them.	[reply]
Re^10: Beyond Agile: Subsidiarity as a Team and Software Design Principle by Anonymous Monk on Jul 30, 2015 at 00:28 UTC
Re^11: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk (Patriarch) on Jul 30, 2015 at 01:07 UTC
Re^10: Beyond Agile: Subsidiarity as a Team and Software Design Principle by BrowserUk (Patriarch) on Jul 23, 2015 at 18:49 UTC


Clear questions and runnable code get the best and fastest answer
	PerlMonks