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.
- 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
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.
- a. Explain the concepts validation and verification in a
b. What does it mean to do
(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
- version control is enforced (,,).
- documents are signed by the project manager and the customer.
- Give two concrete, verifiable examples each of:
(6 points, 1.5 page)
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
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.
- a. Describe the repository
b. What are the strong and
weak points of this architecture? (4 points, 1.5 page)
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.
- 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"
- maintenance issues (improper patching routines, version
- encryption methods that once were secure enough are now broken
- The following code computes
the number of positive elements in the array A.
i = A.length();
nr = 0;
while i > 0 do
> 0 then nr = nr+1 endif;
i = i-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
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
- 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
- How can the following kinds
of test be applied to a simple, interactive web page aimed at
the general public - give concrete examples:
State also the goal of each of
these tests. (8 points, 2 pages)
- a stress test,
- a statistical test,
- an acceptance test,
- a regression test?
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
- 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.
- Discuss the advantages and
risks of algorithmic cost modelling (such as the COCOMO
model). (3 points, 1 page)
+ 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
+ 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
- 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
- From an ethical viewpoint, what are the advantages
of agile development over plan-driven development? (4 points,
References: 1.2, War story, 3.1
From the organisation/employer point of view, there are two
"people before process", sustainable development pace
(avoiding deadline crunch), several ways to promote teamwork
(pair programming, scrum-meetings). The employees are
treated as competent professionals that have their own
responsibility (as individuals as well as teams). They are
not forced to follow a process that treats them as
"production units" that should be replaceable at any moment
(which requires that all their knowledge is documented at
Of course, any process intends to deliver a result that
makes the customer happy. In practice however, customer
involvement and embracing change give better results than
extensive documentation, in particular in the area of
usability. Example - the student portal: the customer is the
university, the users are administrators, teachers and
students. The customer has the ethical obligation to make
sure that the system is usable. Agile development is likely
more successfull than plan-driven development in achieving
- Describe briefly the 4 phases
of Rational Unified Process. (4 points, 1 page)
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.
- 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