This document defines a common rules for preparing, implementing and defending the projects. The committee can issue additional clarifications of thee rules.
The main goal of the NPRG023 course is to acquire principles of team-work on a bigger software project. Work on the project should as much as possible follow the real software development and cover the basic lifecycle of a software project, i.e., requirements collection, preparing a specification, implementation, testing, documentation creation and final delivery.
The committee controls all arrangements of the course. Namely:
Approves the projects topics.
Commences the projects.
Arranges the projects defences.
Assigns a reviewer for the project.
Based on the delivered projects and reviews of the reviewer and supervisor, votes about the project acceptance or rejection. Plus, the committee can award excellent project teams with additional credits.
Approves a project supervisor's proposal for a student exclusion from the project team
Issues documents that refine these rules
Has rights to decide all the issues
The committee is quorate when its majority is present.
Each project has its supervisor. Typically, a supervisor is an employee of the faculty/university or other universities/institutes. Nevertheless, external supervisors from software companies are strongly welcomed. In the case, an external supervisor supervises a project for the first time, the committee may select a consultant (which is the faculty employee) that helps with supervising the project and ensures the project satisfies all necessary criteria.
The supervisor assigns roles and tasks of individual team members. In the case, a team member systematically does not fulfill his/her duties, the supervisor can propose his/her exclusion from the team. The supervisor recommends (or does not recommend) the project fo the review.
The number of teh project team members has to correspond with size and expected complexity of the project. A common number of the team members is 5. The minimum number of the team members is 4. The maximum number of team members is not set, however it should not be over 8 (only in exceptional cases).
A part of the project proposal is an expected time of the project finalization. A common duration of the project is from 7 till 8 months. The project has to be submitted for the review at latest on the following working day after the approved project duration time expires (if it is not submitted on time, it is considered as not successfully reviewed). If the project is not successfully reviewed, the project committee specifies a new deadline to resubmit an updated version of the project. A common extension is 3 months. In a cases, the project is not successfully reviewed even after the extension, another extension is not allowed and the project is left as unsuccessful.
In exceptional cases (e.g., long-term disease fo a team member, withdrawal of a team members), the project supervisor can ask the committee for deadline extension.
The project is concluded by the review. The team members obtains the credits only after the project is successfully reviewed. Dates of the project reviews are set by the committee (with respect to ongoing projects). Typically, the review take place 14 days after the project submission.
For successfully reviewed projects, a common number of awarded credits is 15.
If the project actively runs for at least one semester, the supervisor can award 6 credits in advance. In such a case, the final amount of awarded credits is reduced by these in advance awarded credits. In a case the project is not successfully reviewed, the final amount of awarded credits of a new project is educed by these in advance awarded credits.
For extra good projects, the committee can allow the supervisor to award additional 3 credits to certain members of the project team.
In reasonable cases, the committee can approve a project, which does not conform with some of these rules. In such a case, the committee has to explicitly state, which rules are omitted and/or which new ones are added.
Projects can start at any time. It is recommended to start the project at beginning of a new academic year.
The supervisor of an intended project submits the project proposal to the committee. The proposal has to be prepared using the prescribed template — see the list of attached documents. Parts of the proposal are as follows:
A name of the project
A supervisor and his/her e-mail
A short description of the project together with the intended project's platform
A number of the team members (an interval is allowed), possibly with rationale (approximate assignment of members to project tasks)
Time of the project finalization
A list of related topics that are covered by the project (see the project proposal template)
It is recommended that a student works on a project that is close to his/her study plan.
Once the committee decides the proposal satisfies all the requirements, the project is announced. The committee may adjust the maximal possible number of the project team members.
The proposal together with its supervisor is announced at the project committee webpage.
The supervisor directly registers students for the particular project. In a case there are more concerned students trying to register to the project, the supervisor decides. The supervisor may refuse a student. Each student may be registered for a single project.
After the project team has required amount of members, the committee launches the project.
First phase of the launched project is preparation of a detailed specification of the project. The particular methodology and form of the specification is decided by the project supervisor (typically, the specification contains use-cases, functional and extra-functional requirements, tasks assignment, work schedule, etc.). The specification phase is 2 months in maximum. The finalized specification is submitted to the committee. The committee than arranges a specification review. At the review, the team members briefly present the specification and the committee either approves it or calls for corrections and determines the date for delivering the corrected specification. The specification review is public.
The supervisor has to assign tasks to particular team members. The supervisor may require the team members to attend the project meetings, maintain documentation, work on particular parts of the project, etc. The team members have to follow the supervisor's instructions and recommendations. Especially they have to finalize particular parts on time; this holds for the specification preparation, project implementation and also documentation creation.
Namely, the finalized project has to have:
The filled card of the project — see the list of attached documents
Development documentations
User documentation
Platform specification (required hardware, operating system, additional software, etc.)
The created software ready to be installed
All the source codes, files, and other assets
Documentation is submitted as a printable PDF. The created software is submitted on a portable memory device (CD, DVD,...) from which can be installed. If the project requires non-common installation (special hardware, special runtime environment, etc.), the submission form is individually agreed. In any case, the committee has to obtain executable software and its sources.
The card of the project and the review minutes will part of the documents available during the final state exam.
Created software has to satisfy all the requirements defined in the project specification. It has be installable and executable on the specified platform. It has to be usable, i.e., it has to be stable with appropriate response time. Software has to satisfy all the common requirements for the given platform.
Documentation can be in Czech, Slovak, or English language. Documentation has to follow typographic rules, has to be well-arranged and has to contain a minimal amount of errors and typos. Documentation should contain a list of cited literature and/or used software components.
In particular, documentation has to contain:
a short introduction to the project background
related work
a description of the project progress
evaluation and possible future work
In particular, user documentation has to contain:
a detailed description of the installation process with all the requirements
a description of the complete project functionality
project usage
Before the submission, the supervisor has to check that the project satisfies all the requirements. Namely, the software functionality, stability and documentation. Based on these check, the supervisor recommends (or does not recommend) the project for the review.
The supervisor has to provide a suitable internal date for the project finalization so he/she can thoroughly check the project and the students can perform possible corrections. The recommended internal date for finalization is two weeks before the project end.
Befor the review, the committee gets acquainted with the submitted project and checks its functionality. The committee may ask the team members to correct the project even before the review.
The project review is public. A suitable part of the team has to be present at the review so they can answer all the questions.
The supervisor has to prepare a written review (see the list of attached documents) and submit one copy to the committee. The supervisor has to attend the review or name someone to take his/her place.
The project reviewer (assigned by the committee) has to prepare a written review (see the list of attached documents) and submit one copy to the committee.
There have to be at least three committee members present during the review.
Before the review, the team members have to verify that they have all the necessary equipment for the project presentation (hardware, software, beamer, etc.). For the review, the software has to be already installed and ready to be executed and presented.
The team members present the project results. After the supervisor and reviewer evaluation, there is an open discussion.
The review duration is 30 minutes.
Project presentation — approx. 15 minutes
The supervisor evaluation — max 2 minutes
The review evaluation — max 2 minutes
Open discussion — 5 minutes
Non-public part of the review (only the committee, supervisor and reviewer) — approx. 2 minutes
Results presentation
The project presentation has the following parts (keeping the order of the parts is not mandatory)
a brief motivation for the project
a user-oriented view on the project
actual execution and presentation of the software
a developer-oriented view on the project
The committee considers the following aspects of the project:
amount of accomplishment of the specification
quality of the project
quality of the presentation during the review
After the successful review, the credits are awarded by the supervisor. In a case of extra credits, these are awarded by the study department based on the supervisor request.
In a cas the supervisor cannot award the credits, these are awarded by the committee chair or secretary, based on the project report.
(in Czech only, English versions will be added soon)
posudek-projektu-sablona.docx
posudek-projektu-sablona.odt
zadani-projektu-sablona.docx
zadani-projektu-sablona.odt
zapis-z-obhajoby-sablona.docx
zapis-z-obhajoby-sablona.odt