Software Engineering, Exam, April 17, 2007. Facit.

  1. In this course, we have used the V-model. Accenture and Prevas also use models close to the V-model. What are the advantages of the V-model, compared to other software engineering process models? ..... (4 points, 1.5 page)

    The V-model is simple. It is understandable (for the employees and the customer) and provides good visibility (for the customer and management). The V-model has a strong focus on testing. It allows that test development and implementation are done in parallel(possibly by different teams).

    Common misconception: the V-model is iterative.

  2. If a change is made to a requirements specification, then what about this change should be traceable, and why? (4 points, 1 page)



  3. Sometimes the safety of a system requires its availability. Sometimes safety and availability are conflicting requirements.
    1. Give an example of each case.
      (2 points, 1 page)
    2. Point out the crucial difference between the two cases.
      (2 points, 2 lines)
    Typically, safety requires availability in systems that cannot shut down (like air traffic control, vital hospital equipment). Safety and availability might conflict in systems that can shut down (perhaps to avoid greater damage): railway signalling, ATMs and many more. These systems have a safe state where they cannot cause damage (but probably don't provide the full service intended. E.g. all signals are red).

    Availability is about malfunction. A common mistake was to classify keeping unauthorized people out as low availability. A copier that has jammed the paper is not available. A copier that you cannot use because you don't have the code is working ok. It is available (but not to you).

  4. Describe the reliability metrics Probability of Failure on Demand (POFOD) and Rate of OCcurrence Of Failure (ROCOF). Give a concrete example that shows how they are used for different purposes.
    (4 points, 1 page)

    POFOD is used for systems that are used irregularly and rarely, like alarm systems. It is a probability. The measure is used in risk analysis (if there is a fire, what is the probabilitythat the automatic sprinklers don't come on).
    ROCOF is used for systems that are regularly used, like coffee machines. It is used for economic calculations (how often do we have to send a repair man? - we get an expected value of the repair cost over time). ROCOF = 1/MTTF.

  5. Overall software design:
    1. What are the steps of designing a software system? (5 points, 1.5 page)
    2. Why is there no hard border between requirements specification and design?
      (2 points, 0.5 page)
    3. How is the design process altered if many reusable components are available?
      (3 points, 1 page)

    1. This question is about design only, not about the whole process! The steps are:
      • Architectural design
      • Abstract specification
      • Interface design
      • Component design
      • Data structures
      • Algorithms
      (For explanation of each step, see the course book.)
    2. Usually we need to start the design in order to be able to finish the requirements. First of all we probably want to have some confidence that the requirements can be fulfilled, and some idea how. Secondly, we may want to formulate requirements on the parts of the system, once we know what they are (= architectural design).
    3. We need to identify the reusable components and understand their interfaces. We may need to adapt the architecture, and probably also the requirements, so that the components fit. We may need "glue code" or "wrappers" around the reused components (interface design). We will have less work in detailed design and implementation.


  6. A logical three-tier architecture is to be implemented. Give an example where it would be a reasonable choice to implement it by a client-server architecture with a fat client. Motivate why a fat client would be reasonable in this case. (4 points, 1.5 pages)

    (For a general explanation of the 3 tiers see the book.) A fat client makes good use of the computing power of the client computers. This has to outweigh the disadvantages of a fat client. These are 1. the client has to install special software. 2. Raw data is sent over the network (security risk). Also the amount of data sent over the network must be reasonable. Two good examples are 1. on-line games (much graphics computation, no security problem with game data, game data is smaller than game graphics, customers are willing to install software). 2. In-house CAD application (again much computation, the network is secure (closed) and the company IT-support can take care of installing and updating the clients.)

  7. a) What conditions should be satisfied before an effective and meaningful code inspection?
    b) Explain at least 4 roles in the code inspection process.
    (4 points, 1.5 page)

  8. a)
    The code must be a reasonable size (say 250 lines, but that is language dependent).
    The code must be finished (not: almost finished) and syntactically correct.
    There is a list of checks (common errors, required standards).
    There is a specification.
    There must be time and space allocated.
    The goal is to find faults, not to question the overall design or cast blame.
    The results are used to fix bugs, not for personel evaluation.
    b)
    Moderator: chairs the meetings, responsible that everything is in place.
    Programmer: to explain the code
    Reader: to read out the code line by line.
    Inspector: to raise questions about the correctness.
    Scribe: to take notes (moderator or reader could do this)


  9. Describe (at least) five different test methods. For each method, mention
    (10 points, 4 pages)

    For example:
    Unit testing (black box -> boundary value, glass box -> coverage -> statement/branch coverage)
    Integration/interface testing.
    System tests (acceptance test (alpha/beta, FAT/SAT, stress test, statistical test)
    Regression test, back-to-back testing.

    Common misconception: code inspection. This is not testing.

  10. You receive a change request for software that you maintain. Explain the process of handling and implementing the request. You can assume that you can use the normal procedure, i.e., no emergency action is necessary. ..... (4 points, 1.5 page)

    Impact analysis: is the request consistent with requirements, is it feasible, what does it cost, what are the benefits? Outcome: yes(+urgency)/no.
    Design and implementation (not much different from the usual).
    Regression testing.
    Update documentation.
    Version management.

  11. Describe three different methods to estimate the cost of a project. What input does each method need (i.e., what information do you need in order to apply each method)? (4 points, 1.5 page)

    (For details see the book)
    Algorithmic cost modeling.
    From previous experiences (ones own, or an expert's).
    From a time- and personnel plan.
    Parkinsons Law.
    Price - profit.

  12. Summarized from a Dutch newspaper (Friday, April 13):

    Delayed trains caused by computer problems can be expected for one more year, according ProRail, the authority responsible for railway infrastructure. This transpired during a hearing in Parliament on Thursday. ProRail is currently modernising its computer system; in 2008 all systems will be duplicated, which will reduce the probability of problems drastically.

    Members of parliament pleaded to speed up the work, to avoid problems sooner. According to ProRail, this is not possible. Member of parliament S. said "it is our common task to solve these problems as soon as possible. If necessary, more money or manpower must be dedicated to ProRail."

    Questions.

    1. What would be the two main reasons why speeding up the work is not possible? Elaborate: write a paragraph to support each reason. (4 points, 1 page)
    2. Assume that it is the hardware of the system that is duplicated. Which problems become much less likely, which ones not? (4 points, 1 page)

    1. 1. Adding more manpower to a late project makes it later. Educating new people might require more time (from new and existing project members) than it pays off. 2. Such projects have a very strict time plan. You cannot just stop all trains for half a year. Long stops are possible during vacations only. Agreements have been made with train operators, time-tables have been published, etc.
    2. Hardware-related problems become less likely with a back-up system. Of course, the handover to the back-up can cause its own problems. If both systems run the same software, software problems will be unchanged. If both systems use the same electricity source, power problems will remain.
    (Source: http://www.nrc.nl/binnenland/article687655.ece/Nog_zeker_jaar_vertraging_op_spoor)