[an error occurred while processing this directive]

Software Engineering

   Main page   ||    Lecture   ||    Exercises   || Project


Project overview

The project for this course is called CSÁRDÁS: Computer Science Academic & Research Daily Advertising Service. It counts for 50% of the course grade (the other 50% is the exam).

The purpose of the project is to introduce you to the problems and techniques of software construction in industry, with constraints mimicking those of actual projects. It is not just a programming project but includes the four key aspects of software engineering as taught in this course: Description, Implementation, Assessment, Management.

The CSÁRDÁS application, to be developed by each group, is devoted to a Web application for advertising academic positions for Informatics Europe, on the model of the Computer Science Events List advertising page:


written by Marco Piccioni, and whose source code is available to you for guidance.

This is not an artificial exercise. CSÁRDÁS corresponds to a real need and we expect that the best student project will actually be deployed at the end of the semester.


The technologies are imposed by the customer:

  • Web application.

  • Web server: Apache

  • Operating system: Linux

  • Programming language: Eiffel

  •  Web framework: EiffelWeb

  • Database technology:mySQL



Marco Piccioni

More announcements about third assignment

  • We decided to extend the deadline for assignment 3 to Friday June 15, at 17:00. By that time you must have submitted your deliverables to your assistant and deployed your application on the server. To allow consistent tests for the group that will evaluate your application, we will forbid modifications to the server after 17:00.
  • We also want to clarify the extensiveness of unit tests: you should provide unit tests for the "business logic" of your application, i.e. the features that implement the logic of your application.
    For these features we require a meaningful amount of unit tests, depending on the complexity of the feature:
    • trivial features (e.g. setter methods) need no test cases
    • simple features need at least one test case
    • complex features need at least 3 test cases
    Use widely varying test inputs to cover interesting cases.
    You do not need to write unit tests for the features that only interact with the database or only produce HTML output.
  • Remember that in Eiffel you usually express the expectations for a method in its post-condition. The unit tests only express additional properties, that were not expressible in a contract, as assertions.
    You still need unit tests for methods that can express their expectations directly in contracts to ensure that most runtime contract violations are caught during development.

More announcements about second assignment

  • We moved the deadline in response to student requests. Deadline is now May 11, with submissions accepted until May 14 at 9 AM (firm).
  • A small clarification on the Test Specification (part of assignment 2): we are requesting a single document (although you may include more if you prefer). The IEEE Standard lists three documents making up a Test Specification: Test Design Specification, Test Case Specification and Test Procedure Specification. For the purposes of this project you can combine their key elements, starting from the list in section 4 of the description of Assignment 2, into a single one, the Test Specification.
    The beginning of section 4 of the assignment's description has been updated to make this point clearer.
  • This message introduces another project simplification resulting from student feedback.
    It has been pointed out that the with an ambitious SRS the number of test cases to specify can be very large; the observation is that beyond a certain size specifying test cases extensively (which, however tedious, has to be done in any case for a real project) will have a decreasing contribution to the learning experience.
    To keep the load reasonable we are as a consequence adding the following limit to the scope of Assignment 2:
    • You may limit the set of *functional requirements* to down to 10 core requirements from the target SRS. For those you should provide full test specification as described in the lectures and exercises.
    • For any remaining part of the requirements, you should still provide a general description of the corresponding tests, but it can be very short (a few lines) and doesn't need to be detailed or exhaustive.
    The goal for this second part is to provide a simple guideline for whoever would be writing the detailed test specification (in the same style as for those which you are describing in full) for the corresponding requirements.
    The grading will be adapted accordingly: it will take into account the importance of functionalities selected (to make sure you don't just pick the simplest functionalities).
  • The slides for the testing lectures have been updated on the course site (see http://se.inf.ethz.ch/teaching/ss2007/252-0204-00/lecture.html#schedule). Be sure in particular to check the last few slides (Part 7 on Test Management) which were covered iquickly in class and which may be useful for Assignment 2.
  • Q: How should we choose now the requirements to test. Should we test first the requirements with the highest priority, because they are the most important to test? Or should we choose a represantantive set of all the functional requirements?

    A: The idea is that you pick 10 of the most important functionalities (examples for such functionalities are creating a new entry, deleting an entry, or registering a new submitter). The selection should be based on the assigned priorities.
    Then you need to write test cases for these 10 functionalities based on *all* requirements you find in the SRS talking about these functionalities. That is, if deletion of an entry has 3 requirements in the SRS (not all of them necessarily with high priority) then you have to address all 3 requirements with a number of test cases.

More announcements about first assignment

  • You must submit the result of the first assignment (requirements document) by email to your assistant. Make sure that:
    • The body of the email identifies the project members
    • The document or documents, provided as attachements, do NOT identify the project members: remove names and any detail that would permit identification of the group. Such details are expressly prohibited. This allows for anonymous preparation of the corresponding QA plan (next assignment).
  • Requirements: GUI, DB, response time.


The project consists of 4 assignments:

Assignment Handed out on Due on Description
1 20 March (week 1) (week 5) Requirements capture
2 26 April (week 6) (week 8) Test Plan and Test Specification
3 10 May (week 8) Friday, 15 June 2007, 17:00 Design, Implementation & Documentation
4 14 June (week 13) Friday, 22 June 2007, 17:00 Test Execution and Reporting