CS685, Software Engineering Research, Fall 2008
Logistics




Web Site: http://www.cs.virginia.edu/cs685f08
Instructor: Kevin Sullivan
Office: Olsson 211
Office Hours: 10:15-12:00 M/W
Prerequisites: You must have graduate standing in either Computer Science or
Computer Engineering to take this class. All students of Computer Science and
Engineering should read F.P. Brooks, Jr., The Mythical Man-Month: Essays on Software
Engineering (Anniversary Edition), Addison-Wesley, 1995. If you have not yet read this
book, please do so in preparation for this class. It will not be covered in class. If you did
not have an undergraduate class in software engineering, you might also wish to read
though one of the many software engineering textbooks, such as Hans van Vliet,
Software Engineering: Theory and Practice, John Wiley & Sons, Ltd, 2000.
Audience: The audience for this course is Ph.D. students in computer science and
engineering who need a basic understanding of software engineering as an area of
knowledge and research within the broader field of computer science and engineering.
While the course might well be useful to future practitioners of software development, it
is not meant primarily to equip students for such practice.
Goals:




Provide students with an understanding of foundational concepts, principals,
approaches, selected seminal works, and selected recent works in the field of
software engineering research
Introduce students to the state of the art in software engineering research in a few
selected areas
Help students to develop critical analysis abilities needed for research in software
engineering
Introduce students to notion of research methodology and evaluation of research
quality
Approach:



Class time will be spent largely in discussing papers from the research literature
Students will read papers outside of class and will prepare brief critical analyses
of papers, both to develop critical thinking abilities and to prepare for productive
in-class discussions
Students will complete several small homework assignments, individually or in
groups as the instructor permits, in order to develop and demonstrate
understanding of selected technical ideas

Students will undertake a modest semester-long project to be defined by the
instructor, primarily to develop concrete intuitions for the abstract concepts
discussed in class
Required Readings: See readings page
Evaluation:




Class participation (30%)
Homework assignments (30%)
Class project (30%)
Above and beyond (10%)
Students working in a group on an assignment will generally all receive the same grade.
The instructor reserves the right to make exceptions to this rule if circumstances indicate
that
it
is
appropriate
to
do
so.
HonorPolicy:
The University of Virginia Honor Code is in force in this class at all times. Cheating will
not be permitted. Unattributed use of the work of others is plagiarism. Plagiarism will be
construed as cheating. Possible consequences include failure on an assignment, summary
failure of the course, and referral to the Honor Committee for an Honor Trial, possibly
resulting in expulsion from the University of Virginia.
Reading
1. The Challenge of Software Engineering
The module is meant to introduce the field of software engineering research with a particular
emphasis on the difficulty of producing good software, and underlying principles explaining that
difficulty and why it's not likely to abate any time soon. Two papers from the popular literature
provide an informal view of the state of the art, and, in particular, mention the "software crisis," a
term that for years has characterized the state of practice in the field.





[Dijkstra 72] E.W. Dijkstra, The Humble Programmer, 1972 Turing Award
Lecture, Communications of the ACM vol. 15, no. 10, 1972, pp. 859-866.
[Gibbs 94] W. Gibbs, Software's Chronic Crisis (recently available here),
Scientific American 271, 3, pp. 72-81, 1994.
[Mann 2002] Charles Mann, "Why software is so bad", MIT Technology Review,
Jul/Aug 2002.
[Parnas 1985] D. L. Parnas, Communications of the ACM, Software aspects of
strategic defense systems,Volume 28 , Issue 12 (December 1985), pp. 1326 1335.
[Brooks 86] F. P. Brooks, "No Silver Bullet - Essence and Accident in Software
Engineering" (recently available here), Proceedings of the IFIP Tenth World
Computing Conference, pp. 1069-1076, 1986.
2. Software Development as an Engineering Profession with an Underlying
Science
The importance of software, the long-standing difficulties in improving its quality, the evident
technical and intellectual challenges in making progress, and the rapidly growing importance of
software to public welfare combine to produce a justification for both a research field and a
profession of software engineering. This module is meant to put the field in context with respect
to the development of other engineering research and professional disciplines. Among other
things, the readings will give an overview of the organization of the field, in the form of one
possible taxonomy, and of the significant breadth of knowledge that many people believe all
practicing software engineers should have acquired.

[Leveson 92] N. Leveson, "High-Pressure Steam Engines and Computer Software,"

Proceedings of the 14th international conference on Software engineering,
Melbourne, Australia, pp. 2 - 14, 1992.
[Shaw 90] Shaw, M. "Prospects for an Engineering Discipline of Software," IEEE

Software, November 1990, pp.15—24.
[Abran 2004] A. Abran et al., eds., Guide to the Software Engineering Body of


Knowledge, 2004. Please read the preface and Chapter 1, and just glance over
the rest of the document, both to get a sense of what's in the document, and to get
a quick, partial view of the breadth of knowledge being developed by and for the
field.
[Notkin et al., 2000] D. Notkin. M. Gorlick, M. Shaw, An Assessment of the
Software Engineering Body of Knowledge, A Report to the ACM Council, 2000.
[Finkelstein & Kramer, 2000] A. Finkelstein and J. Kramer, Software
engineering: a roadmap, International Conference on Software Engineering,
Proceedings of the Conference on The Future of Software Engineering, Limerick,
Ireland, pp. 3--22, 2000.
3. What Might Science of Software Actually Mean?





[Tichy 95] W.F. Tichy, P. Lukowicz, L. Prechelt, E.A. Heinz. Experimental
Evaluation in Computer Science: A Quantitative Study. Journal of Systems and
Software 28(1):9-18, January 1995.
[Tichy 98] W.F. Tichy. "Should Computer Scientists Experiment More?" IEEE
Computer, Volume 31, Issue 5, May 1998, pp. 32-40.
[Knight & Leveson 8] J. C. Knight , N. G. Leveson, An experimental evaluation
of the assumption of independence in multiversion programming, IEEE
Transactions on Software Engineering, v.12 n.1, p.96-109, Jan. 198.
[Murphy et al. 99] G.C. Murphy, R.J. Walker, and E.L.A. Baniassad, Evaluating
Emerging Software Development Technologies: Lessons Learned from Assessing
Aspect-oriented Programming, IEEE Transactions on Software Engineering 24, 4,
1999.
[McGrath 95] J. McGrath. Methodology Matters: Doing Research in the
Behavioral and Social Sciences (recently available here). In R. Baecker et al.,
Readings in human-computer interaction : toward the year 2000, Morgan
Kaufmann, 1995, pp. 152-169.


[Shaw 02] Mary Shaw, "What Makes Good Research in Software Engineering?,"
Presented as an invited lecture at the European Joint Conference on Theory and
Practice of Software, in April 2002 in Grenoble, France. Opinion corner
department, International Journal on Software Tools for Technology Transfer,
vol. 4, no. 1, Oct. 2002, pp. 1-7.
[Walker et al. 03] R. Walker et al., Panel: empirical validation: what, why, when,
and how, Proceedings of the 25th International Conference on Software
Engineering, Portland, Oregon, pp. 721 - 722, 2003.
4. Requirements and Specification
I will be adding to this category as we go.



M. Jackson and P. Zave, "Deriving specifications from requirements: an
example," Proceedings of the 17th international conference on Software
engineering, Seattle, Washington, United States, pp. 15 - 24, 1995.
M. Jackson and P. Zave, Four dark corners of requirements engineering,
ACM Transactions on Software Engineering and Methodology (TOSEM),
Volume 6 , Issue 1 (January 1997), pp. 1 - 30.
J.M. Spivey, The Z Notation: A Reference Manual, Prentice Hall (2001).
Chapter 1 is the required reading. BY the way, Z is pronounced "zed."
5. Design Architecture






W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems
Journal, 13 (2), 1974, pp. 115-139.
D.L. Parnas, On the criteria to be used in decomposing systems into modules,
Communications of the ACM, Volume 15 , Issue 12, pp. 1053 - 1058, 1972.
D. Perry and A. Wolf, Foundations for the study of software architecture, ACM
SIGSOFT Software Engineering Notes, Volume 17 , Issue 4, pp. 40 - 52, October
1992.
D. Garlan and M. Shaw, An Introduction to Software Architecture, Advances in
Software Engineering and Knowledge Engineering, Volume I, edited by
V.Ambriola and G.Tortora, World Scientific Publishing Company, New Jersey,
1993.
Coad, "Object-oriented patterns", CACM 35(9)[PDF]
Design Patterns: Abstraction and Reuse of Object-Oriented Design, Erich
Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Lecture Notes in
Computer Science, 707 (1993).