Translated using DeepL

Machine-translated page for increased accessibility for English questioners.

Student research and development projects FI MU

By supporting student research and development projects, the Faculty of Informatics tries to stimulate the development of high-quality, generally applicable and freely distributable software. The aim of the programme is to contribute to the development of free software and at the same time to make the creative potential and professional skills of the Faculty's students visible in a national and international context.

The student projects are mainly carried out by students of Bachelor and/or Master studies under the guidance of a faculty member who is the professional guarantor responsible for the project, its coordination, the management of funds and the public presentation of the achieved results. The project can also be led by a PhD student. In the event that the student is not also an employee of the Faculty of Informatics, a member of staff, e.g. the supervisor of the PhD student, must take formal responsibility for the project.

The objectives of the project may or may not be of a scientific nature and may or may not be carried out within one of the Faculty's existing laboratories. The allocated funds may be used for regular monthly remuneration of students or to cover other costs necessary for the realisation of the objectives of the project. Funds may be requested for a maximum of one year at any one time. Long-term projects may be supported repeatedly if their objectives are adequately pursued. In such a case, it is desirable to mention the expectation of future requests for repeated support (with justification) in the first project and to refer to this mention in subsequent requests for repeated support.

Institutional support is intended for the further development of projects that already show results (e.g. a development version of the programme is available) and have a web presence. Institutional support cannot be obtained solely on the basis of a project plan that is not further supported by at least partial results. An important aspect of successful projects is the longevity of their results, which should persist beyond the end of the project itself and beyond the researcher's studies. It is recommended to publish all project results (including source code and data) on the faculty gitlab or similar repository of the sponsoring laboratory.

A statement regarding overlap with thesis work is required as part of the application. In general, overlap with thesis work is not recommended. This program does not serve to fund theses.

Project design and solution

A project proposal may be submitted based on the current call. Fill in the project proposal electronically in Inet (ISEP): title, proposer, date of solution, investor - Masaryk University, project type - FI internal projects, subprogramme - Programme for support of student research and development projects, tick yes/no - applied research, GDPR, ethics, project role - beneficiary, HS - Faculty of Informatics, department, write a brief annotation and save. After that, other tabs will expand, which you also fill in (program for support of student R&D projects, budget, people). Finally, in the approval tab, you put close and approve electronically. You can see the generated pdf proposal in the approval tab.

You can consult the FI Research Support staff in advance about the intention of the project and any uncertainties about filling in the proposal.

If the project is funded, the sponsor will be informed by email, the proposal will be transferred in ISEP to the projects in progress and the project will be awarded. At this point you can start the project and submit a proposal (via INET) for the award of the grant.

At 3-month intervals during the project, the investigator will upload a short interim report on the project to ISEP (projects in progress).

Upon completion of the project, a final report should be prepared on the appropriate form and signed by the supervisor and delivered to the Research and Project Support Unit of the Faculty of Informatics and also uploaded (in pdf) to ISEP . The researcher then presents and defends the project solution at a public presentation and defence, which takes place twice a year at FI.

Current call for student research and development projects

Common mistakes in the project proposal

Based on experience with previous proposals, we recommend avoiding in particular the following mistakes, which will most likely lead to the project being rejected:

  • Vague specification of project objectives. It is not enough to state the general objectives (e.g. "development of software for working with pdf files for Linux"), it is necessary to describe the specific outputs and/or functionality of the software to be achieved (together with the corresponding timetable). It must be clear from the project proposal what is actually to be accomplished and subsequently monitored in each stage. It must also be clear what the current status is (e.g. existing software functionality) and what amount of work will be done in the project.
  • Insufficient justification of financial costs. The main item in the project costs is usually the stipends for the members of the project team. It should be clearly stated how the individual team members will be involved in the project and what the expected volume of their work is. The members of the selection committee must assess whether the funding requested is proportionate to the expected benefits of the project. Funding for travel may only be requested in very exceptional and well justified cases (in particular, student projects are not intended to fund student participation in scientific conferences; other sources should be used for this purpose).
  • Formal errors. The project proposal must be submitted on the appropriate form and contain all the required information. A strict distinction must be made between the description of the current situation and the description of the objectives of the project (e.g. if the project is to create a new plugin for an existing program, it is not sufficient to state that the existing program is distributed under a free license. What is important is the license under which the newly created plugin will be distributed). The committee members cannot "infer" missing data from the context; the only basis for their decision is the explicitly stated facts.

Projects approved for funding