Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
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
Formulas 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 |
|
|
Invisibility?
|
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
|
Build-and-fix
Waterfall Rapid prototyping Incremental Synchronize-and-stabilize Spiral |
|
|
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 |
