Software Engineering, Facit, April 16, 2008.

1. In this course, we have used the V-model. Accenture also uses the V-model. What are the advantages of the V-model, compared to other software engineering process models?
   (4 points, 1.5 page)
   
   • It is a simple/understandable model, which makes it relatively easy to follow and that increases the chance that it is actually followed.
   • It has good visibility - management can see what is "done".
   • It has a focus on testing and verification, inparticular on early test planning.
   • It supports to some extent parallel activities, in particular implementation and test planning. These activities can be done at different locations (offshoring, Accenture) and by different groups (SE - MP2).
     
   
   
2. Explain 
1. the concepts validation and verification,
2. which methods typically are used for validation, 
3. which methods typically are used for verification.
   (6 points, 2 pages)
   
• Validation is checking that the product will satisfy the needs of the customer, verification is that it is constructed according to the specification.
• Typical validation methods are prototyping (in particular evaluation of a prototype by the customer), customer participation during the project, and acceptance testing.
• Typical verification methods are inspections/reviews, defect testing, and formal methods.
  
  
3. Give three reasons why an engineer could be interested in tracing a requirement back to its stakeholder(s). (3 points, 1 page)
   
   • The engineer needs a clarification of the requirement
   • The engineer wishes to modify the requirement (possible reasons: conflicting requirements, reuse)
   • The engineer needs to establish a priority between requirements
   • The engineer needs to validate a test case based on the requirement
     
   
   
4. Some software is made for a single customer, while other software is developed to be sold on an open market. Explain the resulting differences in the requirements elicitation phase.
   (4 points, 1 page)
   
   • single customer: customer involvement, feasibility study, requirements specification can be a contract.
   • open market: market analysis, product must fit many customers (more versions), analyse competition
     
   
   
5. A logical three-tier architecture is to be implemented. What kind of requirements influence the choice between a physical three-tier architecture and a client-server architecture with a thin client? (5 points, 2 pages)
   
   • a physical three-tier architecture (data, computation and presentation on different machines) scores better on scaleability, performance, and maintainability (easier to exchange a part).
   • a thin client-server solution (data and computation on one server) is simpler to implement, cheaper and (as long as it can handle the load) faster, since it has one less communication latency.
   • Security depends on how the 3-tier would be implemented: if the connection between data and computation is through an open network, it may be less secure. If this connection is separate, it may be more secure because an attack on the computation server is still one step away from the database.
     
   
   
6. You are asked to develop a system with safety critical functions. What are the central design issues w.r.t. safety? In other words: what would you discuss with the customer (domain expert) regarding a safe design? (4 points, 1.5 pages)
   
   • Questions like "how safe should it be?" and "what are the risks?" belong more in the requirements phase.
   • In the design phase, one can think of
   • how can we isolate a minimal safety critical part from all the rest
   • is there a safe state?
   • can we apply (mechanical) safety devices to ensure safety?
     (for example, rather than measure pressure and open a valve if the measured pressure is too high, have a valve that opens if the pressure becomes too high)
   • do we need to implement fault tolerance? What faults? How: N-version, or ...
   
   
7. Give an example of a system that has different requirements for ROCOF (Rate of  OCcurrence Of Failure) for different kinds of failures. Give a concrete example of the system, the failures, and why they should have different ROCOF. (3 points, 1 page)
   
   • Important:
   • it is about why the requirements for ROCOF differ, not the system properties that cause the actual ROCOF to differ
     
   •  it should be a concrete example. I give one:
   • An ATM, failure 1: a card cannot be read and is returned. Failure 2: a card gets stuck.
     Failure 1 can have a higher ROCOF, because it only affects one customer (and maybe not even permanently, causing only a one minute delay). Failure 2 requires maintenance (costly!) and until then it affects all customers.
   • In general, the distinction is made by:
   • is the error permanent, or can you just try again?
   • does it affect all users, or just one?
   • does the error require people to fix it?
     
   
   
8. Describe (at least) five different test methods. For each method, mention
       * its goal, and
       * (briefly) how it is done, and
       * what CASE-tools are useful, or even necessary.
   (10 points, 4 pages)
   
   • Some test methods:
     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.
   • Some goals:
     finding defects - finding most important defects/finding most dangerous defects
     measuring (reliability, performance)
     is the user happy with the system?
   • Some specific case tools:
     scaffolding (code replacing an environment that does not yet exist)
     automatic test scripts (to run many cases, to re-run cases many times)
   • I leave it to you to match methods, goals and tools!
   • Inspection, formal verification, using LINT is not testing!
     
   
   
9. Consider the following piece of program (bubble sort):
   
   repeat
      sorted = true;
      for i = 1 to n-1 {
         if a[i] >= a[i+1] {
            tmp = a[i];
            a[i] = a[i+1];
            a[i+1] = tmp;
            sorted = false
         }
      }
   until sorted
   
   
   1. Show what steps you take in order to perform a branch coverage test for this program.
   2. Explain the following terms (in relation to your answer in a): "basic block", "infeasible path", "oracle problem".
   3. The program contains a fault: the comparison ">=" should be ">". Coverage testing can easily miss this error. What alternative verification method(s) are likely to reveal the error? Explain why.
      
   (4+3+2 points, 3 pages)
   
   1. • You draw a flow chart (you must actually do this, not write "you do this").
      • Identify paths through the flow chart that cover all branches.
        You can do with one path: in,1,2,3,4,6,7,8,1,2,5,6,7,out
        
      • Find input that makes the program follow these paths.
        n=2, a[1]=2, a[2]=1
      
   2. • A basic block is a piece of code without branching, that is always executed in sequence (like the block between 3 and 4).
      • An infeasible path is a path through the code for which no input exists, for instance 1,7,8
      • The oracle problem is: how to know if the output is correct?
        
   3. Inspection: checking that the right comparator is used is definitely on the checklist.
      Boundary value testing - a typical boundary case would be a list with identical elements.
      
   
   
10. Name at least five parameters that are likely to influence the cost of a software project.
    (3 points, 1 page)
    
    • See Figure 26.10 on page 633 (there are 15 or so there).
      
    
    
11. Discuss the concepts of "quality planning", "quality control" and "quality assurance" in relation to a project: when, who, how? (4 points, 1 page)
    
    • "quality assurance" (QA) defines standards and procedures that can be applied for different projects. This activity is at the organisational level, outside the project
    • "quality planning" selects the standards and procedures that are applicable, and decide when and how to apply them. At the beginning of the project, part of the project, but it may be that QA has to approve the plan.
    • "quality control" is during the project verifying and documenting that the project plan is followed. Part of the project. The documentation is made available to QA for review.
    
    
12. Consider the CMMI model.
    
    1. What are the 5 (or 6) stages of the model?
    2. What is the model supposed to measure?
    3. Why is it sometimes preferable to remain at "level 3" instead of aspiring to "level 5"?
    (2+1+2 points, 2 pages)
    
    1. See page 683-685. A "reasonably close" answer that captures the general idea is ok.
    2. Process maturity, i.e. quality of the process
    3. The extra effort (measurements and documentation) to reach level 5 may not pay off.
       Level 5 may reduce the adaptivity of the organisation by regulating too strictly how processes can be changed.