Software Engineering, Exam, December 9, 2011.Facit.

How to read this document.
"Reference" gives the section(s) in Sommerville most closely related to the question.
The answer is a rather short but correct answer to the question.
"Comment" is not part of the answer. It usually serves to clarify misconceptions that I found in the exam papers.

  1. In this course, we have used the V-model as a roadmap. Under what circumstances would it be reasonable to follow the V-model, rather than using agile development? (4 points, 1.5 page) 

    Reference: V-model: 2.2.3. Agile: 3, 23.4. Comparison: 3.2.

    Since the V-model is not incremental, it would have to be a relatively small project. (Indeed, agile methods also have their problems with larger project, so for a huge project neither would be preferable.) The project should be familiar to the team, preferably something they have done before and can plan well. It should not require much interaction with the customer. An example would be adding functionality to an existing system through well-defined API:s.
    The V-model can also be helpful if part of the project is outsourced (although distributed agile methods are starting to appear).

    Comment: so "a large project" is not correct. "A safety critical project" is somewhat correct in that companies in practice may be hesitant to use agile methods on safety critical projects. However, as agile becomes more common, I expect that it will be used successfully on safety critical projects as well. As long as you see "agile" as an experiment ... you may not want to experiment in a safety critical project.

  2. a. Explain the concepts validation and verification in a general context.
    b. What does it mean to do verification of a requirements specification?
    (6 points, 2 pages)

    Reference: 8 (page 207).

    a. Validation compares the product to the customer needs: are we building a product that is what the customer intended - are we building the right product?
    Verification compares the product and the process to the specification: are we following the correct process, quality plan, requirements specification, architectural design - are we building the product right?

    b. Verification of the requirements specification means that we check that it satisfies the standards and rules that apply for requirements specifications. For example
    - all terminology is defined in the glossary
    - all requirements are classified and numbered according to the predefined company scheme
    - traceability is ensured (again according to the predefined company scheme)
    - version control is enforced (,,).
    - documents are signed by the project manager and the customer.

  3. Give two concrete, verifiable examples each of:
       a. functional product requirements
       b. non-functional product requirements
       c. process requirements
    (6 points, 1.5 page)

    Reference: 4.1
    Comment: surprisingly many blanks on this question. Of course, I can just give some examples, a completely different example may be just as good.
    a. Functional requirements tell us what the system should do: what functionality it should provide.
    b. Non-functional product requirements tell us under what constraints the system operates.
    c. Process requirements are about how the system is produced.

    I'll use an html-editor as an example (since I'm using one right now).
    a1. The editor must provide a wysiwyg interface.
    a2. The editor must support nested lists.
    b1. Changing from the wysiwyg interface (a1) to the raw html interface (...) must be with one click.
    b2. The memory used by the editor must not exceed 20 MB.
    c1. The system shall be beta-tested by 1000 customers (appendix A) for one month.
    c2. System documentation shall be generated by Javadoc.

  4. a. Describe the repository architecture.
    b. What are the strong and weak points of this architecture? (4 points, 1.5 page)

    Reference: 6.3.2.

    a. A repository architecture consists of a central data store (in legacy systems this can be just a file system). Applications connect independently to this data store. (Picture: Fig. 6.9)
    b. Strong points: applications don't need to know about each other - easy to add new applications. No problems maintaining data-consistency over several data sources.
    Weak points: the repository is a single point of failure and can be a bottleneck. Hard to enforce security.

    Comment: Some answers refer specifically to the repository of a software engineering project that is maintained by a CASE-tool. This can indeed be a good example of a repository architecture. However, many CASE-tools opt for a client-server solution, where access to the repository is only possible through the server - in this way security and a rigorous version management can be enforced by the server.

  5. In order to keep a system secure, a perspective of the whole life-cycle of the system is required. Give at least three examples of security problems that can be introduced after the system development phase. (3 points, 1 page)

    Reference: 14.1.2, 14.2.3, security slides (21, 28)
    Comment: Read the question carefully: it's not about security mistakes that were made during development and that are found after installation, it's about problem introduced after development. Below are some classes of problems.

    - user behaviour (not logging out, revealing passwords, ... also: using the system for high security data, when it was developed only for medium security)
    - the system assumes an "outer shell" that is broken (physical access to server rooms, on-line access to file systems that were supposed to be off-line, ...)
    - installation issues (the system is not cleaned from test accounts, test code, etc.)
    - regular users running the system with "administrator" priviledge.
    - maintenance issues (improper patching routines, version management)
    - encryption methods that once were secure enough are now broken in seconds

  6. The following code computes the number of positive elements in the array A.

    i = A.length();
    nr = 0;
    while i > 0 do
        if A[i] > 0 then nr = nr+1 endif;
        i = i-1;
    done;
    return nr;

    1. Give an example of a single test input (an array A) that gives full branch coverage. Explain clearly how you found this test. (5 points, 2 pages)

      Reference: defect testing notes.
      A = [-1, 1].
      (Comment: or any other array with at least a positive number and a negative (or 0) number.)
      Draw a flow chart. You must traverse every arrow in the flow chart. So you need to pass the if twice, once with A[i] > 0 and once not. Also the test i>0 needs to be true at least once and false at least once, but any non-empty array will do that.

    2. This code is correct if the programming language indexes an array of length n from 1 to n, but it is incorrect if it indexes from 0 to n-1 (or in any other way). Give two methods of verification that you would expect to catch errors of this kind. Motivate your answer.  (4 points, 1 page)

      Code inspection: array bound errors are a standard item on the review checklist.
      Blackbox or galssbox testing using a compiler option that switches array bound checking on. (If this option is not on, there is always a probability that the scrap data in memory happens to make the result right. However, if you run many tests, the probability to always get it right deceases exponentially.)

  7. How can the following kinds of test be applied to a simple, interactive web page aimed at the general public - give concrete examples:
    1. a stress test,
    2. a statistical test,
    3. an acceptance test,
    4. a regression test?
    State also the goal of each of these tests. (8 points, 2 pages)

    a. (Ref: 8.3.3) The system is bombarded with an increasing load of requests. (This needs to be automated - having users do this is too costly and less reliable/measurable.) Goals: to measure the maximum load the system can handle, to measure the system behaviour under heavy load, to find defects that manifest themselves when the system breaks under the load.

    b. (Ref: 15.2) From a user profile, a statistical sample that constitutes "normal use" is generated and tested (automatically - should be repeatable for regression testing). Goals: measure system properties (e.g. reliability) under normal conditions. Find bugs that will manifest themselves most often in reality.

    c. (Ref: 8.4) This is a test for the customer to decide whether the system is acceptable. (Comment: this may include a usability test by beta-testing, but it is certainly not only a usability test.) The developer and customer together will test if the system satisfies the requirements specification (verification) and the customer's needs (validation). The customer might for instance want to test how easy it is to update the web page.

    d. (Ref: 8.2) When the system has been changed, a regression test should be run to see that the change has not broken test-cases that used to work. Regression testing can be applied at any level (unit, integration, system) but normally requires automated testing.

  8. Software Maintenance. Describe briefly the process from a change request to a new release of the software. (4 points, 1.5 page)

    Reference: this slide sums it up.
    The important issues, on top of any development model to implement the change, are: impact analysis, regression testing, configuration/version management, updating documentation.

  9. Discuss the advantages and risks of algorithmic cost modelling (such as the COCOMO model). (3 points, 1 page)

    Reference: 23.5.1
    Advantages:
    + even if you don't use the formulas, the method provides a checklist of factors that should be considered.
    + because of the many factors, uncertainties/misjudgement in some factors might cancel out each other (unless you are an incurable optimist)
    + it's based on requirements, you don't need a time plan
    + you might try to use it as a replacement for experience
    + you could use it with intervals to get an idea of your uncertainty
    Disadvantages:
    - it might give you a false sense of exactness
    - it needs to be calibrated for your organisation to be accurate
    - estimation of the factors is still subjective, and still requires experience.

  10. From an ethical viewpoint, what are the advantages of agile development over plan-driven development? (4 points, 1 page)

    References: 1.2, War story, 3.1
    From the organisation/employer point of view, there are two separate issues:

  11. Describe briefly the 4 phases of Rational Unified Process. (4 points, 1 page)

    Reference: 2.4
    The phases are Inception, Elaboration, Construction and Transition. See the book for short descriptions of each phase.
    Comment: if you simplify too much, it starts to sound like a waterfall model. In fact each phase and the whole model are incremental. For instance, prototypes can be constructed and tested during the elaboration phase.

  12. Give examples of internal and external attributes of software products. Compare their role in quality assessment. (5 points, 1.5 page).

    Reference: 24.4, Figure 24.10.
    Comment: your answer should give concrete examples, I refer to the book for those.
    External attributes are the properties that you care about as a customer (more examples in Fig. 24.2). These attributes are more or less measurable once the product is finished. To predict the quality of the final product during development, we can monitor the internal attributes. These are measurable properties of the code and the documentation. This works if we know the relation between internal and external attributes (requires experience from previous projects, calibration). Even without exact relations, extreme values for internal attributes can be a warning sign.