Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key


Play button


Play button




Click to flip

8 Cards in this Set

  • Front
  • Back
Drastic Consequences?
Deceased Patients
X-ray machine delivered very high doese because of a timing problem in its control software

Crashed planes
Software prevented pilots from performing emergency maneuvers
Software had similar codes for different airports

Decreased national security
NSA computers down for four days due to a "software problem"
Boehm's top ten software risks?
1. Personnel shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong software functions
4. Developong the wrong user interface
5. "Gold Plating"
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer-science capabilities
Unmanageable Complexity?
Software cannot be easily abstracted
Only in very few domains
Diagrams, graphs, and other representations
Typically non-hierarchial
Far too many cross-references

Few concepts are available to use in an abstraction

Tension between high-level understanding and low-level detailed specification
High-level understanding leaves out important details
Aggregation often does not work
Environment cannot be changed?
Software has to adhere to the "world" it is placed in
Cannot change the hardware
Cannot change the way people do business

The 'world' is often not clearly specified
How can you change something that you cannot specify?
Leads to many software changes

Perception is that software is easier to change
Software as is cannot be viewed meaningfully
Stack of paper
Set of files

Software cannot be interpreted easily
How to read source code?
How to read a million lines of source code?
How to read a part of source code?

Invisibility affects process
How to measure progress?
Is a bigger stack of paper closer to the end-result than a smaller stack of paper?
Software life cycle models
Rapid prototyping
Major Changes?
Software is remarkably easy to change
Change the source code, recompile, rerun
"One line here, one line there"

Unfortunately, even small changes can have disastrous consequences
A single wrong character can surreptitiously change the behavior of the software
The effects of most changes are only visible in certain circumstances

Sometimes, the environment does change
Software is used in different organizations
Software is used for different purposes
Processes as a Remedy?
Institute processes through which software is engineered
Cover all steps from initial idea and requirements to delivery, maintenance, and final retirement
Make sure we do the right things/things right
Make sure we do not forget to do anything
Different processes for different kinds of software

Not a silver bullet
Software is still intrinsicallyh difficult to deal with
Processes help, but cannot guarantee anything