1. 3 possibilities: a run a number of waterfalls one after another b nesting: a waterfall is included in one step (e.g. design) of a higher level c the design and implementation phases overlap a can be used in any case b can be used for throwaway prototyping, if the goal is to clarify questions about one particular thing (e.g. design) c is typically evolutionary prototyping (you implement the well-known parts before/while designing the harder parts). Scores for incomplete answers Description of waterfall 1 Contrast evolutionary - throw-away 2 one variant 2p two or three variants 3p 2. Note that this question is about Chapter 6 (models during requirements engineering), not about (architectural) design. The difference is that system models need not have the same structure as the actual system. However, the role of an architectural design is partly the same. Some roles are: a system model gives something to "talk about" in requirements visualize system focusing on different aspects of the system (structure, dataflow, etc) a way to organize requirements and so to analyze them (for example to detect inconsistencies and duplicates) 3. (see page 123) alternatives: 1p each (dis)adv. : 2p 4. - design is *not* software engineering, the waterfall model, or something like that. - the question says: A software design, so it's not a process, it's the result of the process (but this is a minor distinction). A software design consists of several models of the system, showing different aspects in more and more detail. 2p parts: page 211. 3p 5. MTTF = 1/ROCOF. 1p MTTF - systems that are used for a longer timespan (editor, spreadsheet, CASE-tool, Web-browser) or continuously (thermostat). In the first case, MTTF should be significantly longer than mean usage time. 1p ROCOF - systems that receive regular requests (coffee machine, etc.) 1p 6. fault - error in program or documentation (static), may cause failure - undesired/unexpected behaviour of the system (dynamic) mishap - accident causing loss of life or severe damage hazard - the possibility of a mishap risk - probability of mishap X severity of its consequences (the expected damage) (see page 421) concepts: 0.5p each relation/example: 1.5p Example (don't forget): A fault: a missing test in a program A failure: due to the missing test, an extreme sensor value is not detected A mishap: the factory explodes A hazard - the possibility of the factory exploding if the system fails. A risk - probability of the explosion X the damage (risk values are not so interesting for very small probabilities and very large damages. They are more useful for comparing car theft and bicycle theft, for instance). 7. The system controls road trafic (by lights, bells, maybe gates) and train traffic (signal). The safest state is gates closed, bells ringing and trainsignal red. 1p In this state transitions are allowed to opening the gates or giving trains the green light (actually, the light is white). After 10 minutes, people get impatient and start crossing gates anyway. This state is less safe. The transition to giving trains the green light should no longer be allowed. 1p 8. output data and intended behaviour (speed, etc.) 2p sources: (formal) requirements, specification users (particularly for acceptance testing) earlier versions (back to back) (2 out of 3 OK: 1p each) 9. test cases are chosen according to the (expected) usage profile. the occurrence of an error has a certain probability, not because the system behaves nondeterministically, but because the user nondeterministically chooses interactions with the system. 2-3p Example (1-2p) In a ticket booking system, the request for a seat from Stockholm to Gothenburg occurs more often than from Skövde to Bastuträsk. In this case, the figures are quite well-known to SJ. 10. Physical products need maintenance to replace parts than are damaged by wear and tear. The goal is to restore the original performance and functionality. Software does not suffer from wear and tear. Software maintenance alters performance and/or functionality. 2p 11. technical - finding suitable components (catalogs, documentation) - adapting new parts to components - rapidly changing programming languages - lack of tool support nontechnical - programmers want to build their own product, they don't rely on others' work and always find something that can be improved. - legal rights may make reuse costly (and uncertainty about legal rights causes uncertainty aabout cost) - companies unable to make components reusable for lack of time/money. 12. see figure 30.1 and 30.10 (left= external). internal = can be measured (quite) easily and objectively external = aspects that define quality for the user. often hard to define and even harder to measure accurately. Quite impossible to measure on an unfinished product. You measure the internal attributes and through a (preferably statistically significant) relationship this leads to an estimate of external attributes, i.e. quality. 13. a. see page 648-649 b. focus on process, not product quality no place for risk analysis no place for level of technological advancedness unclear for what kind of organisations it is a good measure assessment - unclear if it works well and fair companies can put the paperwork in place without actually improving quality 70% is ranked initial companies are ranked level 1 even if 90% of their process is level 2 or better (1p each, max 4) 14. A Silver Bullet (by definition) speeds up the process by an order of magnitude (10x). In order to do that, it must take away a task that is now 90% or more of the work. (numerical reasoning) The work can be divided in essential tasks and accidental ones. Silver Bullets address accidental tasks. Accidental tasks are now less than 50% of the total task. 3p Weak points 1p each - Previous Silver Bullets addressed accidental tasks, could their be Silver Bullets for essential tasks? Different formulation: - What we see as essential tasks now may seem accidental once we discover the right Silver Bullet. (Compare AI: a task is no longer intelligent once we now the algorithm to solve it.) - When buying off the shelf, there is no visible software production process. But when previously ten companies all used their own programs, and now all buy the same one, the total development cost of their software may have dropped by (almost) a factor 10. (or any reasonable way to point out reuse)