Start by reading all the questions, to see if
anything is
unclear. I plan to visit around 9:30 to clarify questions.
Answers may be written in Swedish
or English, or any reasonable mixture of those.
Dictionaries may be
used.
Start each
answer on a new page.
Please hand in the pages in the
correct order.
For each question, I give its points and a maximal
length of the answer. The optimal length is usually around
half of this maximum. (This does not include drawings.)
A checklist of common mistakes that cost points:
Answer all 12 questions. A bad
answer never gives
less points than no answer.
Read the question again after you have
written the answer.
Verify that you have actually answered the question. Verify that you
answered all parts. Verify that you have not hidden
the answer between many other irrelevant comments about the topic.
In particular, don't forget to give an
example if that is
requested, and make it a concrete one.
When a question asks you to compare two
things A and B, make
sure to highlight the contrasts: their differences. I do not
want a full description of A and a full
description of B, leaving it to
me to find the differences.
Good luck!
References are to Sommerville, 9th edition.
During the course we discussed
some software engineering
processes (V-model, RUP, etc.). They all have advantages and
disadvantages. What are desirable
properties for a process?
(5
points,
2
pages)
Reference: Figure 26.2.
So that the process is actually used as intended, it should be understandable, acceptable and supported.
So that the process is managable, it should be visible, robust and preferably also
measurable.
So that the process gives good results, it should be reliable, and rapid
(other good points are user involvement, allow parallism, incremental,
manage risks).
Note: some answers start to explain the V-model, or the phases
requirements, design, ... and so on.
That is not answering the
question.
During the development of a new
system, a throw-away prototype is
being evaluated. The users like the system, and want to start using it
immediately. Give 3 reasons why this may be a bad idea. (3
points, 1.5 page)
Reference: Section 2.3.1
Normally, the prototype is not made to satisfy all
non-functional requirements. Users may not initially be aware of the
requirements that are not fulfilled, such as scaleability or security.
The prototype might not satisfy the (functional or
non-functional) requirements of all stakeholders.
The prototype is not made to be maintained. It need not be
well-structured, it need not satisfy quality standards, and it is not
properly documented.
How does reuse-oriented software
engineering differ from a
development-oriented process (like the V-model)
Reference: Figure 17.7, section 17.2.2 (not exclusively though)
in the requirements phase? In development-oriented SE,
the requirements need to be
decided in sufficient detail to build the system. In reuse-oriented SE, the
requirements are less detailed. Then there is a phase of identifying
candidate components. These components will provide further detail.
Usually, the requirements need to be adapted/negociated so that the
components can fit in.
in design and implementation? In development-oriented SE,
the design is mostly
top-down (divide and conquer problem solving). Much work is spent on
implementing components. In reuse-oriented SE,
there is a framework architectural design, but many parts of the design
are bottom-up, fitting components together using glue code and
wrappers. Realtively little work is spent on implementing components,
but more on analysing them.
in integration and testing? In reuse-oriented SE, there
is less focus on unit testing. The components must be tested, but the
tests focus on verifying if the component works in the new environment,
in particular aspects like error-handling.(This may also be verified by other means
than testing).So there is
more focus on integration and system testing.
(9 points, 3 pages)
Note: I have not been selective in where you make your arguments. For
instance "glue code" can be mentioned in implementation or integration.
Describe and motivate
at least 5 key principles of extreme programming (XP). (5 points,
2 pages) By "motivate" I mean: describe the expected benefit of
this principle within XP.
Reference: Figure 3.4 lists 10 principles and some motivation. Some
central issues are Customer involvement to
make sure that we are making the right system (validation) Short feedback loops to
correct mistakes as soon as possible (small increments, pair
programming, test-driven, continuous integration) Simplicity (make the
simplest solution that works, handle change when it comes, refactoring)
- avoid spending time and money on anticipated changes that never occur. People - keep them happy,
healthy and "together" (sustainable pace, collective ownership, pair
programming)
While not wrong, refering to principles from "the agile manifesto" only
is too general.
What are the general purposes of
making system models during
requirements engineering? (4 points, 2 pages
Reference: Chapter 5, introduction (and the rest ...)
The general purposes are
to make various (simple) abstractions of
the (complex) system,
to focus on a single perspective
to visualise the system or parts of it,
to communicate the above, and
to have something to refer to in the requirements
specification.
For formal models, the answers to
question 7 may also apply.
Sometimes the safety of a system
requires its availability.
Sometimes safety and availability are conflicting requirements.
Give an example of each case.
Point out the crucial difference between the two cases.
(4 points, 1.5 page)
b. If the system has a safe state,
then
when
a
problem
arises
you can bring the system to this state. In
the safe state, availability may be low, but safety is ensured. If the
system has no safe state, then a minimum of operations must be
available in order to control the system.
a. (Of course, many examples are possible here.)
In a railway signalling system, you can switch all signals to red (and
if there is no electricity, a signal that is unlit must be interpreted
as red by the driver). This state is safe (at least for a few hours:
trains cannot collide, but passengers may start to
freeze/overheat/panic eventually), but the railway is not available for
transportation. In an airplane, a basic landing system must be
available, because at the end of a flight you cannot keep circling for
very long.
A nuclear reactor of the Fukushima/Forsmark type needs available power
(electric or emergency diesel) to keep the cooling going (safety
requires availability). There are reactor designs where the heat of the
core itself keeps the cooling going. Such a reactor can be switched
off, it's no longer available to generate power, but it's safe.
Note: most examples that involve security are flawed in some way:
A system is available if it is ready to perform the functions that it
is supposed to perform.
Since a system is not supposed to be accessible (available??) for
hackers, there is no inherent conflict between security and
availability. There may occur such a conflict, for instance if the
system detects an intrusion and shuts down (= goes to a secure state).
Secondly, security is not safety. Some students argue that a security
system (like a camera) needs to be available to ensure safety. Well, it
may be needed to ensure security, but since the camera itself cannot
cause any damage, it has no effect on safety. (An extreme case would be
a security system that automatically shoots intruders. Its "secure
state" would be to shoot everyone, but its "safe state" would be not to
shoot.)
What benefits can the making of
a formal requirements
specification have? Name at least three benefits and motivate why they
can be achieved through formal specification. (3 points, 1
page)
Reference: guest lecture slides (slide 9 in particular), Section 12.5
improve understanding of the requirements: there is no
handwaving in formal requirements, in particular you need to think
through all cases, not just the expected ones.
improve communication of the requirements: it provides an
unambiguous language
you can automatically derive tests from the specification
(and cover all formal requirements)
you need it if you want to make a formal proof that your
system is correct (formal verification).
Explain what is meant by
statistical testing, and why it is
meaningful to perform statistical testing on a deterministic
system. Use a concrete example. (4p, 1 page)
Reference: 15.2
Statistical testing draws its test cases from a usage profile in a statistically
valid way. That is, we assume that we know how users "normally" use the
system, and our test cases should represent such "normal" behaviour. So
the system may be deterministic, but the usage is not. The two goals of
statistical testing are
to measure the system (e.g. reliability) under "normal"
circumstances
to find the defects that will most commonly occur (the most
"bugging" bugs).
(Plenty of examples possible, as long as there is user interaction.
Word processor, reservation system ...)
Consider this function written
in JAIL (Just Another
Imperative Language):
real function exponent(real
a, int b); // compute ab real result := 1.0; if b < 0 then
b
:=
-b;
a
:=
1.0/a; end if; while b > 0 loop
b
:=
b-1;
result
:=
result*a; end loop; return result
Show what steps must be taken to find test cases for coverage
testing, using this program as an example. Show the distinction between
statement coverage and branch coverage. (5 points, 2 pages)
Find inputs that make
the program follow the paths (if this fails, go back to 3 and choose
different paths).
In the example, only the
choice of input b determines the path.
Statement coverage requires only one test case, with b < 0.
Branch coverage requires two test cases, one with b < 0 and one with
b >= 0.
Explain briefly the concept of boundary value testing, and
show that
it would probably reveal an error (or shortcoming) in the
program. (3 points, 1 page)
Reference: 8.1.2
Boundary value testing is a black
box method. From the
specification, it derives different cases, and tests values that are
close to the boundaries of these cases. In the current example, we
could choose a: -<high number>, -1,
-<small fraction> 0, <small fraction>, 1, <high
number>
b: -<high number>,
-1, 0, 1, <high number>
One can point out 3 different errors/shortcomings - note that there are
no assumptions on a and b:
overflow could easily occur (a and b are high numbers)
division by 0 (a = 0, b < 0)
the result of 00 = 1.0 (a = 0, b = 0).
Explain why inspection would probably reveal the error.
(1
point, 2 lines)
Reference: 24.3.2
Inspection certainly has "division by 0" and "overflow" on the
inspection checklist, as they are common errors.
The specification should state how to handle 0b when b =<
0.
Describe four
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)
Reference: 23.5-in:
If the cost is determined by the requirements, we have
expert/analogy: some
experts (maybe you) have experience from similar projects and their
cost - requires knowledge about similar projects, and enough knowledge
about te current project to decide what is "similar"
algorithmic cost modelling:
use
a formula that takes into account size (functional requirements),
non-functional requirements (reliability, schedule), organizational
factors, and so on, to compute a cost (or an interval).
plan-based: if you
already have a plan stating how many people will work on the project
for how long, you can use that. Don't forget overhead costs!
If the cost is determined by the available resources (we try to make as
good a product as we can):
if the limiting factor is
people: Parkinson's law: the project will cost as much as the
available people cost (again including overhead).
if the limiting factor is
money: you have a budget, price minus profit. Keep it!
Consider the CMMI model.
What are the 5 (or 6) stages of the model?
What is the model supposed to measure?
Why is it sometimes preferable to remain at "level 3" instead
of aiming for "level 5"?
(6 points, 2 pages)
Reference: 26.5
a. Initial/Incomplete, (Performed), Managed, Defined, Quantitatively
managed, Optimizing
(I don't require that you remember the exact terminology, a reasonable
description of the levels (as on page 724) is good enough.)
b. The maturity of an organisation in managing its processes.
c. There is a cost involved in moving up to level 5, both in actual
work and in "acceptance" by the employees. This cost should be
motivated, either by a better running operation, or by customers
requiring this level of maturity. If neither motivation exist, you may
be better off at level 3. In the continuous model, you should set goals
for each "area of operation".
Quality management standards and
processes often have their roots
in manufacturing industry. Discuss what assumptions underlie such
standards and processes, and to what extent these assumptions are valid
in software engineering. (4 points, 2 pages)
Reference: 26-in
The main assumptions are that product quality is determined by process
quality, and that a standardized process leads to a stable product
quality. There are differences between manufacturing and software
engineering that undermine these assumptions.
in manufacturing, we make often many copies of a product, and
the process is mechanical. In SE, we make one copy, and the process is
run by people.
during manufacturing, requirements don't change much (in the
production phase), in SE they always change.
in manufacturing, the product is visible, and quality is
relatively easy to recognise and measure during production. In SE the
product is intangible, and quality is hard to judge before delivery.