See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/234827714

Teaching operating systems: student assignments and the software engineering

perspective

Conference Paper · May 2008

DOI: 10.1145/1370868.1370881

CITATIONS READS
0 433

5 authors, including:

Lubomír Bulej Martin Děcký

Charles University in Prague Charles University in Prague
78 PUBLICATIONS   381 CITATIONS    12 PUBLICATIONS   46 CITATIONS   

SEE PROFILE SEE PROFILE

Viliam Holub Petr Tůma

University College Dublin Charles University in Prague
16 PUBLICATIONS   79 CITATIONS    124 PUBLICATIONS   661 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

HelenOS View project

All content following this page was uploaded by Martin Děcký on 19 August 2014.

The user has requested enhancement of the downloaded file.

 Teaching Operating Systems: Student Assignments and
the Software Engineering Perspective

Vlastimil Babka Lubomír Bulej Martin Děcký

[email protected] [email protected] [email protected]
Viliam Holub Petr Tůma
[email protected] [email protected]
Department of Software Engineering
Faculty of Mathematics and Physics, Charles University
Malostranské náměstí 25, Prague 1, 118 00, Czech Republic

ABSTRACT depth of the assignments, and also involves significant effort

This paper is an experience report outlining a transforma- spent on grading the assignments.
tion of an operating systems course in a systems oriented As far as assignments are concerned, software engineer-
master study program. We present the initial and cur- ing education presents a particular challenge in that it often
rent stages of the transformation and summarize the lessons deals with issues only present in large projects. These issues
learned throughout the process. To illustrate the effects of are notoriously difficult to demonstrate in smaller assign-
the transformation, we provide feedback gathered from the ments, which can lead to lectures acquiring the feel of beast
students who have completed the course during the transfor- fables – a lot of good advice is dealt out but never demon-
mation. We put emphasis on general software engineering strated in situations that the students experience first hand.
experience, which may prove useful in balancing the many One solution to this issue is introducing specialized courses
issues related to most courses with programming assign- with large assignments, or requiring industrial internship, as
ments. a part of the study program. This approach, however, is lim-
ited by the size of the study program – an especially painful
consideration in the two year master study programs fre-
Categories and Subject Descriptors quently created off previous five year integrated study pro-
K.3.2 [Computers and Education]: Computer and In- grams to comply with the Bologna Declaration [4].
formation Science Education; D.4.0 [Operating Systems]: We have therefore decided to put more emphasis on gene-
General ral software engineering issues even in specialized courses
with programming assignments. This experience report de-
General Terms scribes such a change on the example of the operating sys-
tems course taught within Charles University.
Human Factors The Charles University operating systems course has been
designed to not only provide a wide overview of major sys-
Keywords tem related concepts, such as process execution, process
teaching, operating systems, student assignments communication, memory management, memory virtualiza-
tion and device handling, but to also foster sometimes less
than perfect understanding of basic system related princi-
1. INTRODUCTION ples, such as the way in which machine code is executed by
A proverbial advice attributed to Confucius says: I hear, the processor or the way in which the processor communi-
I forget. I see, I remember. I do, I understand. The concept cates with devices.
of understanding through doing is very relevant to software We outline the course structure as it underwent a several
engineering education, which relies heavily on student as- years long transformation, adjusting various parameters of
signments to convey the understanding of technical details the assignments, and present the feedback gathered from the
that are typically difficult to present in lectures. students during the transformation. The feedback concerns
Such an arrangement requires proper timing of the assign- general software engineering experience and can help bal-
ments relative to the lectures, determining the appropriate ance many issues related to the operating systems course in
particular or similar courses with programming assignments
in general.
In the following sections, we first outline the initial course
Permission to make digital or hard copies of all or part of this work for structure, discuss our reasons for the transformation and
personal or classroom use is granted without fee provided that copies are
detail its outcome. We proceed by outlining selected results
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to of the several conducted student surveys. The summary of
republish, to post on servers or to redistribute to lists, requires prior specific our own experience follows, with due conclusion.
permission and/or a fee.
SEESE’08, May 13, 2008, Leipzig, Germany.
Copyright 2008 ACM 978-1-60558-076-0/08/05 ...$5.00.

71
2. INITIAL COURSE STRUCTURE 3. MODIFIED COURSE STRUCTURE
In the years prior to 2002, we have been using Nachos
[6] from University of California at Berkeley as the instruc- 3.1 Environment Realism
tional operating system, along with a subset of assignments To obtain a realistic environment while avoiding the major
corresponding to those originally published by the authors hassle with debugging, we have implemented a full system
of Nachos. simulator based on the MIPS R4000 CPU [9]. Compared to
Since writing even a minimum operating system from scr- a real hardware platform, the simulator is somewhat simpli-
atch is demanding, Nachos tries to avoid the danger of too fied – there is no firmware to interact with and the devices
difficult assignments by providing an operating system tem- (a keyboard, a console, and a hard drive) are mapped di-
plate in which the students are required to extend or replace rectly to memory.
the implementation of its individual parts. To shorten the The simulator does not support the 64-bit mode of the
lengthy and tedious compile-execute-debug cycle when de- R4000 CPU, floating point coprocessor, and memory caches.
veloping an operating system on real hardware, Nachos runs Other than that, the behavior of the R4000 CPU is preserved
the kernel of the operating system as a standard application as much as possible to create a fairly realistic setup for the
on a host computer. Nachos then provides as a part of the students to work with. This allows the students to use a
kernel a simulated processor on which the user level appli- stock GNU compiler toolchain1 to generate executable code
cations are executed. for the simulated MIPS platform. The simulator also sup-
While using Nachos, our assignments were specified rela- ports multiprocessor systems, which are becoming widely
tively vaguely, in terms of required functionality, and were available.
graded on meeting these loose requirements. Since the code Besides continuing the tradition of Nachos, the choice of
to demonstrate the functionality was written by the students the CPU was prompted by the fact that we wanted a real
themselves, and the code was reviewed mostly for potential but simple CPU. This not only helps keep the simulator
design errors, a window for overlooking some bugs existed. small, but also prevents students from getting lost in the
Software engineering concerns, such as team management peculiarities and complexity of CPU architectures such as
or coding quality, were not an essential part of the grading IA-32.
since they were deemed outside the scope of the course.
Geared at making the assignments easy for the students, 3.2 Design Freedom
the architecture of Nachos introduces several features that To avoid students plugging their work into an existing
are either rather unrealistic – such as the existence of dy- operating system template, we have modified the assign-
namic heap during bootstrap, or result in additional com- ments so that students have to write a full kernel almost
plexity not found on real hardware – such as different en- from scratch. To get around the need to code in assem-
coding of integers in user and kernel memory. bly language, we provide an example code that bootstraps
Over the several years of using Nachos, we felt that this and supports threads with primitive memory management
unrealistic setup, together with assignments that shielded and crude synchronization. Using the assembly language
students from low-level details by using high-level object- fragments basically as they are, students are then required
oriented interfaces, went contrary to our effort at making to implement synchronization primitives, complete thread
the assignments as close to practice as possible. support, virtual memory without swapping, and user mode
To deepen the understanding of the operating systems processes.
concepts and construction, as well as the general software From the software engineering perspective, this means
engineering experience, we have transformed the course by that more emphasis is put on the design phase of the as-
modifying the assignments with the following goals: signment. Using broad estimates for a project of about 5000
lines of code with no final deployment, the design phase can
• To create an environment that is more realistic than represent as much as 24 % of the overall development ef-
Nachos, but at the same time preserves some of the fort [3], which the students did not do previously.
ease of debugging arising from running the operating The assignment requirements have evolved from vague
system and user programs as a normal process on a functional requirements through a plain list of methods to
host machine. be implemented to a detailed specification of the required
in-kernel interface. We require the students to design their
• To remove the soft cushions of abstraction arising from solutions while considering various non-functional trade-offs.
a well structured operating system template covering In the assignment specification, we provide directions con-
most of the basic functionality, into which students cerning standard usage patterns for different parts of the
plug their enhancements without really having to think kernel to avoid trivial and unrealistic solutions. The quality
about many low-level issues. of the solution is then included in the grading of the imple-
• To put more emphasis on the software engineering as- mentation.
pects of the assignments, such as team management, From the software engineering perspective, this means
coding practice and assignment documentation, which that less emphasis is put on the requirements phase of the
in turn should help the students to better manage com- assignment, in exchange for the possibility of more rigorous
plexity. testing of the in-kernel interface. Using the same estimates,
the requirements phase can represent as much as 14 % of
In 2001, we have started to work on an alternative infras- the overall development effort [3], which the students do not
tructure for the student assignments and phased out Nachos do now.
in the following year. Later, we have found out that we were 1
GCC, GNU Assembler, GNU Linker, etc., typically built
not alone taking this decision [8, 11]. as a cross-compiler toolchain.

72
Figure 2: Present: Did the assignments help in your Figure 5: After the transformation: Did the tests
understanding of the principles of computers and help during the work on the assignments? (0 = not
operating systems? (0 = not at all, 7 = significantly) at all, 10 = irreplaceably)

Given the level of realism we wanted to impose on the stu- ture (both groups were comparable in size). Figure 1 shows
dents, even simple assignment solutions with all the techni- the perceived relevance of the assignments before and af-
cal details to take care of present a significant challenge. We ter the transformation. With the original structure, some
therefore give the assignments to teams of students rather 19 % of the students did not see the contribution of the
than individual students. The usual size of the team is three assignments to their understanding of operating systems as
students. useful (marks 0 to 4). This unsatisfied group is gone with
the modified structure of the course, where the overall aver-
3.3 Grading age has also shifted slightly, from 6.45 to 7.83. This trend
We have split our grading of the assignments into a sepa- stays in the survey from early 2008, as seen in Figure 2,
rate grading of the implementation functionality, a separate where the majority says the assignments have helped quite
grading of the coding quality, and a separate grading of the significantly.
design documentation and presentation. The three parts are As expected from the changes outlined in the previous sec-
given equal weight. To further our goal of making the grad- tions, the perceived overall difficulty of the assignments has
ing more consistent, we rely on having specific assignment increased after the transformation (see Figure 3). Most stu-
requirements accompanied by functional tests. As the in- dents consider the new assignments difficult given the size of
dividual parts of the assignments are completed during the the course, but surprisingly, practically no student suggested
semester, each part has to pass an automated suite of func- cutting down on the assignments (see Figure 4). Most ad-
tional tests, manual grading is only done at the end of the vocate extending the credit rating of the course instead and
semester. some would keep the course as it is. Later surveys, asking
The tests exercise the student solutions and report incon- on the scope of the entire lecture rather than just the as-
sistencies in expected and obtained results. Even though signments, also contain no majority suggestion for cutting
the CPU simulation is completely deterministic, the tests down the work.
are randomized to avoid static test cases. The randomiza- The introduction of tests, which are given to the students
tion is driven by a pseudo random generator which can be along with the assignment specification, was generally wel-
seeded by a user defined constant, which makes it possible to comed as extremely useful (see Figure 5). The role of tests
reproduce all bugs discovered by the tests in a deterministic has gradually shifted from a grading tool to a development
fashion, which is especially important when debugging race support tool, in an interesting agreement with Extreme Pro-
conditions. Since the tests are given to the students along gramming [1]. We consider supporting this trend by creat-
with the assignment specification, they also help to make ing more tests, ranging from simple functionality checks to
the requirements more precise. serious stress test, and automated daily runs with on-line
results.
An interesting aspect of the assignments was a sponta-
4. EVALUATION neous application of software engineering methods. Even
To evaluate the transformation, we use results from vol- though no software engineering technique was explicitly sug-
untary anonymous surveys among the students after com- gested, the 2008 survey shows students using and praising
pleting the course, conducted in several semesters. We are specific software engineering techniques – Pair Programming
aware that this is still a relatively small statistical sample [15] and Surgical Team [5], code proofreading and unit test-
taken under unstable conditions and would therefore cau- ing.
tion against drawing any far-reaching conclusions, but we A more thorough demonstration of software engineering
believe certain major trends can be observed, as follows. issues is also indicated for team coordination and assign-
The obvious question about the transformation from the ment debugging, which were reported in the early 2008 sur-
initial to the modified course structure is how did it influence vey as two most significant obstacles just after general lack of
the perceived relevance and difficulty of the assignments. time and understanding. We are still hesitant on the issue
Perceiving the assignments as relevant and doable is a major of debugging – we realize that our simulated environment
factor in course impact [13]. is not nearly comparable with contemporary interactive de-
In 2004, we have surveyed a mix of students who have buggers, but on the other hand, we often witness a lack of
passed the course in both its original and its modified struc- debugging skills that can hardly be attributed to tools alone.

73
Figure 1: Before (left) and after (right) the transformation: Did the assignments help in your understanding
of the principles of operating systems? (0 = not at all, 10 = irreplaceably)

Figure 3: Before (left) and after (right) the transformation: How does the amount of work compare with the
credit ranking? (0 = too much work, 5 = adequate, 10 = too many credits)

Figure 4: Before (left) and after (right) the transformation: How would you alter the ratio between the
amount of work and the credit ranking? (0 = less work, 5 = as is, 10 = more credits)

74
5. LESSONS LEARNED planning fallacy (tendency to systematically underestimate
During the transformation of the course, important issues task-completion times).
have appeared related to finding an appropriate workload As a final observation on the assignments, the introduc-
that can be imposed on the students, as well as the effect tion of the functional tests served to verify student progress
of the new arrangement on the workload imposed on the without increasing the workload on the grading staff. How-
grading staff. ever, we have also noted that some teams started to optimize
their work to pass the tests, rather than focusing on the more
5.1 Assignments general requirements.
Concerning assignments, we have initially tried to avoid 5.2 Grading
giving too much work to individual teams by splitting the
As far as the grading goes, the new arrangement resulted
assignment into three parts corresponding to kernel subsys-
in an increased workload on the grading staff. The existence
tems, with each part serving as a foundation for the next
of tests gives more confidence in the consistency of the grad-
part. The teams were then assigned one of the parts and –
ings of the implementation aspect of the assignment, but the
with the exception of teams responsible for the first part –
rest of the grading related to quality of the implementation
implemented their assignment on top of previous part im-
and coding practices has to be done manually by reviewing
plemented by another team. This required assigning strict
code and design documentation.
deadlines during the semester to each part and choosing only
Besides grading the assignments, we also wanted to give
the best implementations for the later teams.
the students useful feedback on their work, including both
We have perceived this arrangement as very useful, since
the architectural decisions and the coding quality. Initially,
students acquired experience with modifying code written
this was limited to a few sentences to point out flaws that
by someone else. As far as the specific work of individual
caught our eye, but gradually, it has evolved into a detailed
teams goes, the perceived disadvantage of teams working
list that pointed out what is wrong and why and what would
on later assignments was assumed to be balanced by the
be a better way to do it.
fact that they had more time to get acquainted with the
We have noted that many of our comments were related to
development environment, whereas the teams working on
coding quality. This confirmed our belief that grading non-
the first assignment had to start basically from scratch, in
functional aspects of student assignments is important. The
an unknown environment, and had a very strict deadline on
only drawback is effort that needs to be spent on reviewing
finishing their assignment.
student code to provide useful feedback. On average, one
Unfortunately, even though our functional tests exercised
person can spend about six hours reviewing the work of a
the assignments quite thoroughly, they could not ensure en-
single team.
tirely bug-free code and in several cases, students working on
This could be reduced if factors such as code quality were
the later assignments were bit by hidden bugs in code they
not graded too rigorously. While we would indeed rather
have not written. Moreover, we have assumed that students
focus at grading the operating-systems-specific aspects, we
would study and understand the code of their predecessors
believe that code quality is as important as the other as-
and extend the code base with the implementation of their
pects of grading. Without prior coding experience, students
own assignment. This assumption turned out to be wrong,
often have very little or no notion concerning good coding
students were in fact reluctant to study foreign code and
practices, which is why we believe that students should be
instead tried to touch it as little as possible and treat it as a
given some instruction on this aspect of software develop-
black box. In part, this was fueled by the fact that students
ment. However, we are also aware of the difficulty of includ-
were given code that passed the tests and thus tended to
ing a full sized course purely on code quality, as explained
consider it bug-free.
for example in [10], in the already tightly packed curricula.
Facing these issues, we have come to a conclusion that
while this approach is certainly good for getting experience 5.3 Topics
with extending foreign code, it is not entirely fair and our
Perhaps not quite a surprise, adjusting the assignments
expectations of student behavior were somewhat unrealistic.
to provide a more thorough demonstration of software engi-
We now require all teams to implement essential subset of
neering issues caused the students to encounter more prob-
all the kernel parts, and an extended version of one kernel
lems related to those issues. Since students tend to expect
part of their choice.
receiving instruction on any potential source of problems,
The deadlines, originally introduced to enforce a timely
this in turn creates pressure to include the software engi-
delivery of the code needed by other teams, were left in
neering issues among the topics presented during lectures,
place to encourage the teams to start working as soon as
somewhat diluting the focus on operating systems. We hope
possible. Since the assignments can be deceptively simple,
this problem can be solved by better synchronization be-
we have found it very important to make sure that the stu-
tween the operating system course and general software en-
dents realize the real complexity of the work early on. Still,
gineering courses.
the majority of the work on the assignments is done just a
few days before the particular deadline (as seen in Figure 6),
which leads to a strong pressure to postpone the deadlines. 6. RELATED WORK
Although the inequality of the workload during the time Using hardware simulators in operating system courses
period between the particular deadlines might have many has become quite common and there are several simulators
reasonable explanations, such as more focus on designing at designed specifically for educational purposes. They differ
the beginning and more focus on coding at the end of the mainly in the simulated processor architecture and the de-
period, other clues suggest that the real reason is the lack of gree of realism [7]. Even though we have developed our own
proper time management, discipline and a manifestation of system simulator, it was mainly because we could not find

75
 Kernel skeleton Memory management User space Final

500
400

Soft deadline
Hard deadline
300
Number of commits

Postponed deadlines
200
100
0

Oct 17 Oct 25 Nov 02 Nov 10 Nov 18 Nov 26 Dec 04 Dec 12 Dec 20 Dec 28 Jan 05 Jan 13 Jan 21

Date of commit

Figure 6: Frequency of daily commits to software repositories of 36 teams on the 2007/2008 assignments.

one to suit our needs at the time we needed it. Since the goal of OS/161, such as having to create certain subsystems in
of this paper is sharing experience from student feedback, we a primitive or outright faulty way in order to leave some
do not provide any comparison of simulator features. work for the students. In general, though, we seem to share
A common practice in teaching is to use an existing op- the same experience concerning undetected bugs carried over
erating system and give the students assignments to mod- from earlier assignments, resulting in difficult-to-debug prob-
ify the system. The operating system used for teaching is lems later.
typically a special purpose operating system that runs in a Finally, the authors also comment on poor state of the
simulator, such as Nachos [6] or OS/161 [8], or a general MIPS development toolchain, which made them consider
purpose operating system that runs on real hardware, such different processor architecture. While we have also expe-
as Minix [14] or Pintos [11]. Again, given the purpose of this rienced a few problems of this kind, neither of them were
paper, we want to avoid comparing different general purpose critical. Since the MIPS core seems to have gained popular-
and educational operating systems. We will, however, point ity in embedded devices, the support of the MIPS platform
out a few similarities and differences between their approach in the GNU compiler toolchain is being improved lately and
and ours. there are known workarounds for the remaining issues.2
The OS/161 along with its MIPS-based hardware plat- The Pintos instructional operating system [11] also origi-
form called System/161 [8] is particularly interesting be- nated as a Nachos replacement for an undergraduate course.
cause its development and deployment in teaching courses Unlike System/161, it runs on a standard simulator such as
occurred at roughly the same time. In case of OS/161, the Bochs [2] or QEMU [12], or on real hardware, and its sup-
main reasons seem to have been the deficiencies of Nachos, ported processor architecture is IA-32. While there are cer-
whereas in our case, the abstraction of the assignments from tain advantages in learning such a widely used architecture,
the hardware was a strong factor. we believe that a simpler RISC architecture such as MIPS is
The authors of OS/161 chose to replace Nachos with an- better for understanding the basic principles without dealing
other, more realistic implementation, but kept the concept with complicated architecture-specific details. Note that the
of assignments based on extending a fully featured operat- device support for such an architecture would be also more
ing system framework. The framework is quite large, 19000 difficult, but the Pintos course assignments do not seem to
commented lines of code in kernel space with 7000 addi- require implementing that, except for changes in the existing
tional lines in user space. Since this amount of code is hard timer device driver.
to understand in short time, students are directed to specific Similarly to Nachos and OS/161, Pintos also comes as
parts of the framework and required to read code relevant a semi-complete framework, with four smaller assignments
to the particular assignment before starting their work. that extend thread support, implement syscalls, add virtual
In contrast to OS/161, we only give students a minimal- memory swap support, and improve the filesystem imple-
istic example of a system that has trivial preemptive round- mentation. A reference solution of the assignments totals
robin scheduling of a fixed number of kernel threads and has 3000 lines of modifications. This means that the same dif-
a simple first-fit kernel memory allocator, roughly 3000 lines ference from our approach applies as in the case of OS/161.
of commented code in all. As a result, our assignments cover The grading system of Pintos assignments seems to be
fewer operating systems concepts – no file systems, no com- almost identical to ours – tests are provided both for devel-
plex device drivers, no networking – but the concepts we do opment support and grading, but the solutions have to be
cover have to be implemented basically from scratch, requir- general and not just pass the tests. Good design documen-
ing the students to perform architectural decisions. This is tation and source code quality is also required and graded.
consistent with the fact that our course is aimed at more ad- The assignment documentation provided to students not
vanced, master students, instead of undergraduate students. only covers the requirements, but also gives development
Simple bootstrap framework and incremental assignments
2
also allow us to avoid problems mentioned by the authors Mostly misoptimizations and unexpected linker behavior
when not using the default ELF output format.

76
 suggestions such as how to divide work among team mem- 8. REFERENCES
bers or the order of general steps needed to complete the [1] Beck, K.: Extreme Programming Explained: Embrace
assignment. A statistics of the reference solution in terms Change, Addison-Wesley Professional 1999
of number of changed lines in each file is also presented for [2] Bochs: The Open Source IA-32 Emulator Project,
the workload estimate. http://bochs.sourceforge.net/
[3] Boehm, B., Bradford, C., Horowitz, E., Madachy, R.,
7. CONCLUSION Shelby, R., and Westland, C.: Cost Models for Future
We have described an operating systems course transfor- Software Life Cycle Processes: COCOMO 2.0., Annals
mation, with the goals of deepening the understanding and of Software Engineering, Volume 1, 1995.
making the students perceive the course assignments as more [4] The Bologna Declaration,
relevant and useful. While this came at the cost of the as- http://ec.europa.eu/education/policies/educ/-
signments being seen as more difficult, our survey feedback bologna/bologna.pdf
suggests that the difficulty is seen not as a negative aspect [5] Brooks, F. P.: The Mythical Man-Month: Essays on
that needs to be removed, but as a necessary factor that Software Engineering, 2nd Edition, Addison-Wesley
should be preserved. This leads us to believe that it is worth Professional 1995
keeping the current course structure in the future, address- [6] Christopher, W. A., Procter, S. J. and Anderson,
ing some of the remaining problems. T.E.: The Nachos Instructional Operating System,
From a broader perspective, we would conclude that there USENIX Winter 1993
are drawbacks to using simplified programming assignments, [7] Davoli, R., Goldweber, M.: New Directions in
which are not related to the operating systems education Operating Systems Courses Using Hardware
or the software engineering education in particular. Even Simulators, ICSEE’03, SCS 2003
when the assignments are carefully tailored to simplify the [8] Holland, D. A., Lim, A. T., Seltzer, M. I.: A New
nonessential aspects of the problem, as was the case in our Instructional Operating System, ACM SIGCSE
course, the result can be perceived as more artificial and less Bulletin Volume 34, Issue 1, ACM 2002
useful for understanding.
[9] Holub, V.: Educational OS Simulator, Master Thesis,
Even with the waning position of operating systems among
Charles University 2003
the things a software engineer is expected to understand, our
experience can be generalized. In the times of shortening the [10] McConnell, S.: Code Complete, 2nd Edition, Microsoft
curricula in an attempt to cater to fast track education pro- Press, Redmond 2004
grams, it is worth knowing that unsimplified assignments [11] Pintos, Stanford University
serve better to foster understanding and that students seem http://www.scs.stanford.edu/07au-
to very much appreciate this. cs140/pintos/pintos.html
In the education context, this would advocate the need [12] Bellard, F.: QEMU: Open Source Processor Emulator,
for assignments that exercise multiple aspects of a discipline, http://fabrice.bellard.free.fr/qemu/
even if they are more difficult and require more effort than [13] Ramsden, P. Learning to Teach in Higher Education,
a scope of a single course would warrant. Second Edition, Routledge, London 1993
[14] Tanenbaum, A. S. and Woodhull, A. S.: Operating
7.1 Acknowledgments Systems: Design and Implementation, 2nd Edition,
This work was partially supported by the Grant Agency Prentice Hall 1997
of the Czech Republic project GD201/05/H014 and by the [15] Williams, L., Kessler, R.: Pair Programming
Ministry of Education of the Czech Republic (grant MSM- Illuminated, Addison-Wesley Professional 2002
0021620838).

77

View publication stats