This is not a complete facit, it just mentions some points that I was looking for in your answers.
  1. a)

    b) Encryption is most important between the presentation layer and the business layer. Authentication (by password or cryptographic techniques) is needed for transactions mostly. The business layer should be the only way to access data (there may be other business layers, for instance for bank personel). The database access layer ensures database consistency: the ACID properties (atomicity, consistency, isolation, durability).

  2. a) Two things: 1. The control system is very safety critical, and in order to make it correct and verify it, it should be as small as possible. As much as possible should be kept outside.
    2. The two parts have different functions, and low coupling. So it is good design to keep them apart. This would for instance make it possible to reuse a traffic direction system in another country, with another control system.

    b)If it fails, the railway system will soon come to an almost complete standstill. This may cause significant economic damage. (It might even cause chaos on the roads, and accidents.) Note however that it will not create train collisions. It should not even create danger for track-workers, although in practice it might.

    1. Structural: An identifier (number), or any other way to find stakeholder, rationale, etc.
    2. Content: It does not specify what kind of failure. For a transient failure, the requirement is quite hard (these money changers fail quite often to recognize a note). For a permanent failure (service needed), the requirement is very weak.
    Note: using ROCOF is correct here, as is the unit "per request". Of course, there will be other requirements on the machine, also about reliability (notably AVAIL). Availability is related to the frequency of permanent failures.

  3. a)
    1. Draw a flow-chart, identify nodes and branches.
    2. Find a collection of paths that visits all nodes/branches
    3. Find input data that makes the program follow each path (if it turns out that there is no such data, the path is infeasible, go back to 2 and replace it by other paths).
    In this case, the difference is that branch coverage requires that the test A(i)>max is true sometimes, and false sometimes. For node coverage, it may always be true. In any case, only one test is necessary. Say C=3, and A=[5,2,3,6].

    Note: this method is not to be confused with boundary value testing, as described by Sommerville. Boundary value is a form of black-box testing: you need only the specification, not the code.

    b) The error is that A(1) is never checked. A statistical test has probability 1/C to detect this. From a) we can see that it is easy to achieve branch coverage and yet miss the error. A boundary value test might detect it, if you have a rather broad definition of "boundary". Such a definition will soon be unworkable. Inspection has a good chance (most of you found the bug). Formal verification, that can be done mostly automatically when loop invariants are provided, is another candidate.

  4. Important: realise that the bug is not fixed. A work-around is not a fix, and you cannot fix a serious, non-trivial bug in a day. It is not even given that the bug has been located exactly, maybe all we know is that a call with certain parameters results in a crash. So what we need to do is:

  5. For Cleanroom, read the book/articles. Two points that are worth taking up: 1. Would you like a working environment with such strict roles and rules? Do they limit your creativity, or do they save you wondering what you should do, so that you can concentrate on how you should do it? What roles would you like/not like? 2. Would you like to work with the kind of projects that are suitable for Cleanroom?

    1. Educated guess, experience, comparison with previous projects.
    2. Breakdown in smaller projects and phases, tasks, how many working hours needed. Multiply by "external hourly fee", which includes overhead and standard uncertainty.
    3. Apply some measures to estimate complexity, like COCOMO (still this is based on an estimated size).
    4. Whatever resources are available (customer budget, or man-months). Make as much functionality as is possible with the resources, as opposed to making a fixed required functionality whatever the cost.

  6. a)Since we planned to train 4 programmers, training 8 is not going to take much extra effort. But communication between 8 programmers will be substantially more than between 4. It is not clear if the work can be divided over 8 programmers.

    b)Intuitively it should. But if we compare the communication according to the C = 0.5*n*(n-1) estimate, we see:
    1 project, n=4 C=6 versus n=8 C=28, factor 5.
    2 subprojects, n=2x2, C=2x1 versus n=2x4, C=2x6, factor 6.
    So the factor of increased communication hardly differs, but the absolute amount of communication increases less with 2 subprojects.

  7. a) The following points you must do, or assume that you have done them already: For the other departments, you should

    b)To see certification as the goal, and quality as the medium, rather than the other way around. To impose your process on other departments. To impose a quality programme without support from "below".