Goal

  Develop an application which assists the user in creating and managing the timetable of the faculty.

  Phase 1 - application development

  Specifications

• The program's task is not to create the timetable, but to provide support to the user in doing that.
• The elements that must be taken into account are:
  • the students (organized by study years and groups)
  • the teachers
  • the disciplines
  • the class types (course/seminary/laboratory)
  • the rooms
  • the time slots
• Some restrictions apply:
  • Classes may only be scheduled on weekdays (Monday-Friday), between hours 8-20.
  • Course classes may only be scheduled in the course rooms (due to the large number of students), while laboratory classes may only be scheduled in the laboratory rooms. There is no restriction regarding seminary classes.
  • Course classes are taught to whole study years, while seminary/laboratory classes are taught to groups.
• The program must assist the user:
  • by providing a graphical (not necessarily web-based) interface that eases the manipulation of the entities involved
  • by notifying the user about any issues: broken restrictions; overlappings (e.g., two classes at the same time in the same room; two classes taught by the same teacher at the same time); etc.
  • by generating the HTML files for publishing the timetable, in a manner that is similar to the current timetable of the faculty

  The implementation must not make use of library functions, i.e., the code must be written by the programmers. Exception: if a database server is used, it does not have to be implemented by the programmers.

  Permanent communication with the beneficiary is necessary, so feel free to ask any questions you may have about the requirements. Programs that do not do what they are supposed to, due to misunderstanding the requirements, will be penalized.

  Any programming language may be used, provided there are unit testing and mocking tools for it, as well as assertions (which must be language-specific, apart from unit testing assertions); all these will be necessary during the subsequent phases.

  It is recommended to design a program structure as simple as possible, without including any additional features than the ones mentioned above. The goal is to create a working version of the program, not necessarily fully stable or error-free, on which testing techniques will subsequently be applied.

  Throughout the project phases it is also necessary to sketch the documentation, which will be written and delivered in the final phase.

  Deadlines

• Set up the teams (3-4 persons): April 28
• Finalize program development: May 7-8

  Phase 2 - unit testing

  Specifications

• Use of unit testing tools to test the code developed during phase 1.
• Reminder: unit testing is about discovering if the module being tested can handle incorrect input data (provided by other modules or by application I/O). Error fixing is NOT required.
• Testing must provide code coverage as complete as possible. For indications regarding the conditions to be tested, read the courses.
• Each module must be tested independently. For simulating the interactions with other modules, where necessary, mocking will be used.

  Deadline

• Finalize the unit testing code: May 21-22

  Phase 3 - use of assertions

  Specifications

• Assertions will be inserted in the application code, in order to check the preconditions, postconditions, and invariants for the operations implemented during phase 1. The assertions are inserted directly into the application code, so this phase has nothing to do with unit testing.
• If the programming used for development has no built-in assertions, a function/method must be written to provide similar behaviour.

  Deadline

• Finalize the assertions code: May 28-29

  Phase 4 - documentation

  Specifications

• Write the documentation for phases 1-3.
• There is no specific requirement for the size of the documentation, but everything that has been done must be described clearly: program design and implementation, a brief user manual, testing, use of assertions.
• The contribution of each team member must be stated explicitly.

  Deadline

• The documentation will be discussed on June 4-5.