College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001
CEG 760: Advanced Software Engineering
This course is primarily about the specification, design and implementation of software systems. Prerequisite: CEG 660; see below.
This course has a home page at
http://www.cs.wright.edu/people/faculty/pmateti/Courses/760 Bookmark this and visit it periodically.
There are several running examples in the course. A few are presented in the Prerequisites section below. The Common Words Problem, and Pascal Pretty Printer are published (see the citations below). The Screen-Oriented Text Editor is well-known and may become the core of our project work. Lectures on these examples will be spread over the course, and these are not mentioned again in the topics below.
The textbook is
Software Engineering, by M. Dorfman (Editor), Richard H. Thayer (Contributor), IEEE Computer Society; ISBN: 0818676094, November 1999.
Many of the chapters will be reading assignments announced during the term. We will also be discussing a few classic papers not included in the book.
2. Eric S. Raymond, ``The Cathedral and the Bazaar'', www.kde.org/ food/cathedral/cathedral-paper.html 1997/11/12 (See also Eric Raymond's book "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary " (Sebastopol, Calif.: O'Reilly & Associates, 1999).
2b. Nikolai Bezroukov, A Second Look at the Cathedral and the Bazaar, FirstMonday.Org, 9 December 1999. A fairly harsh critique of Eric Raymond's seminal paper.
3. Bertrand Meyer, ``On Formalism in Specifications,'' IEEE Software, Jan 1985, 6-26.
4. Mateti, P., ``A Specification Schema for Indenting Programs,'' Software - Practice and Experience, Vol.13, 163-179, 1983. (Reprinted in Software Specification Techniques, McGettrick and Gehani (Eds.), Addison-Wesley 1986.)
5. ``Introduction to Software Patterns''
6. Donald E Knuth, ``A Literate Program [Most Common Words],'' Communications of the ACM, Vol. 29, No. 6, 471-483.
Homework and other problems are expected to be discussed in our newsgroup (wright.ceg.760).
Project work in this course consists of developing software and associated documents, and peer reviewing others software and documents. While you may consult with others in the project work, the specs, design and implementations must be your own personal work, not that of a group.
The percentages shown in this subsection add up to 100%, which is weighted to become 30% of the grade. To pass the course, you must receive at least 75% for the project.
|Your Own Work||Review 1||Review 2|
|Implementation+Testing 2 (deleted)||10||5||5|
Your project work consists of developing a spec, a design, two implementations, and reviewing two specs by others, two designs by others, and testing two implementations by others. You must turn in these referee reports within a week of being given the task. Referee reports are expected to be thorough, critical enough, not superficial, and not just nit-picking. Studying, critiquing, and revising specs and designs are essential skills in software development.
All the reports will be turned in (i.e., uploaded to your web site) as HTML files, and printed hard copies in a professional manner.
I will give the entire class the same "rough and incomplete description" of a program in the form of source code files of an existing program, and a man page for it. The project for the course is to take this description and develop specifications (20%), design (20%) and two implementations (10 + 10%) for it.
Each of you will get two specifications written by two of your fellow students based on the ``rough and incomplete description of a program'' to review (5%). A few weeks later, you will also get two designs based on these specs to review (5%).
You will be developing one implementation based on your own design and another based on one of the two designs you reviewed, my choice. You may choose for the implementations either Java or C++. These two implementations are encouraged to share as much code as you wish, but they must faithfully reflect their designs. Be aware that it is rare for specs and designs to be perfect. You are also encouraged to communicate with the designer of the second implementation to get `things' clarified, but all such clarifications must be carefully documented. Your final implementation based on your design is expected to be either 10% faster or 10% shorter in code size than the given program. With this goal in mind, decide if you wish to reuse the design that you may discern in the given source code or start from scratch.
Two implementations by others will be source-code reviewed, and tested (5%) by you.
At the end of the term, you will prepare and submit a comprehensive report/portfolio (5%) that includes all your work, and revisions that you made, especially the clarifications above, in the course project.
|Your Own Work||Reviews|
|Specification||April 20||April 27|
|Design||May 16||May 23|
|Implementation+Testing 1||May 23||May 30|
|Implementation+Testing 2 (deleted)|
|Final Report||June 1||--|
|Final Exam||June 6|