Home exam for TDDD30
Code: TDDD30/TEN2
Credits: 2hp
Starting time: 2014-12-18 at 8:30
Deadline: 2014-12-22 at 17:00
Deliver via mail to kristian.sandahl@liu.se all solutions in one file in either English or Swedish, not a mix.
Allowed aids: Any publicly accessible written material, including LiU Library databases, plus documents in
the Lisam room for the course.
Explicitly forbidden aids: Consulting other people than the examiner, having someone else but yourself
reading or writing parts of your answers. This also prohibits any kind of copy-paste from other texts.
It is important that you motivate all answers, and that you cite sources, such as articles and chapters of
the SWEBOK v. 3.
The exam consists of 6 problems each giving 10 points. To pass you need at least 30 points.
Problems
1. Software quality work cross-cuts many different aspects of software engineering. Describe two quality
factors of software, and motivate with an example why they are important. For each quality factor,
describe how it can be obtained, improved and/or controlled by activities in different knowledge areas of
SWEBOK. A good answer includes references to at least five different knowledge areas.
2. Software development methods are always debated. Write a catalogue of potential advantages and
disadvantages of agile methods and the classic water-fall model respectively. If you need to, you may
describe a concrete method and use that as an example. The more perspectives of different roles 1,
quality factors, and SWEBOK knowledge areas, the better. It depends on the granularity, but I would
typically list 5-8 advantages and 3-4 disadvantages for each method type. Maybe there are some more
disadvantages with the water-fall model.
3. Research in software engineering is typically performed by people from many research paradigms.
Referring to the article by Sjøberg, et al., discuss why there are so relatively few controlled experiments
reported? Referring to the article by Runeson and Höst, why do you think that many people find casestudies useful in software engineering? Are there any problems with using the case-study method to
build a body of knowledge?
1
For example, analysts, programmers, customers…
4. Metrics is a valuable tool in software engineering management, but can be tricky theoretically.
Suppose you work in a project you measure the following things:
•
•
•
•
•
•
•
•
•
Total number of delivered, non-comment lines of code.
Average Cyclomatic number per module.
Average number of members’ years of industrial experience per team.
Amount of time spent in testing per module.
Amount of overtime worked per month per team.
Whether a software module is client, server, or middleware software.
Severity class of found faults (minor, average, serious) per module
The probability of a risk (on a scale 1-4) per risk
The degree of unit testing path coverage per module
For each of the measurements, classify them as product, process or resource measurements. Also
classify them as nominal, ordinal, interval or rational scale measurements. Which metric do you judge
can be most problematic when it comes to ensure its reliability if it is presented for the company
leadership as a basis for decision making? Don’t forget motivations.
5. We had a special seminar for creating system anatomies that can be useful to highlight the major
components and dependencies of a system. Create a System Anatomy of a university library
management system comprising at least 10 anatoms. Shortly describe each anatom and motivate the
relations you have drawn between the anatoms.
6. The list below contains challenges to Requirements Engineering (RE) found in the industrial survey
described in the article by Karlsson et al. Describe problem areas, trade-offs, or issues for 5 of the
challenges. For each of the challenges you chose, also argue if the challenge is unique for Market-Driven
RE or if it applies to RE in general.
•
•
•
•
•
•
•
•
•
Communication gap between marketing staff and developers
Writing understandable requirements
Managing the constant flow of new requirements
Requirements volatility
Requirements traceability and interdependencies
Requirements are invented rather than discovered
Resource allocation to RE
Selecting the right process
Release planning based on uncertain estimates