Guidelines for Student Projects

This page provides useful information for making a project at LAMS. We explain the requirements we have for student projects. These requirements capture industry and research best practices. We believe that following them will teach students some principles that will be very useful in their professional life. In case of questions, doubts or suggestions, do not hesitate to contact us.

If you are interested in doing a project with us please contact the head of Laboratoy Dr.Alain Wegmann

Process :

  • Iterative approach: The project should be done iteratively, using a time-box approach. A description of the principle can be found in the Extreme Programming. In short, you are expected to do three times the whole project in a semester. This leaves you 3 weeks to do the project “one time”. To do this, you have to reduce the number of things you do in each iteration to make sure you can do the whole process (from spec to implementation). The benefit of this approach is to avoid surprises and to build an understanding of the project between you and your assistant.
  • Intermediate presentation: The project has to have a presentation half-way. This is crucial to guarantee that no bad surprises will appear at the project end. Before the intermediate presentation, one full iteration should be made. The poster that presents the research and the report outline should also be presented.

Note: Quite often projects in companies are very much result centered and not much conceptualization or research is planned. It is important to stress the fact that you are doing a university project. As such the project has to have some theoretical part and cannot just be a plain development project. This would be not sufficient to get the “sufficient” grade. It is the responsibility of the student to highlight this point to the company where the student will work. In case of the problems, the professor can help in negotiating the topic.

Tools :

  • Bibliographic tool: We expect that all students, in their project, do a survey of the relevant literature and commercial products. The findings should be stored in a bibliographic tool such as BiblioExpress. Make sure you analyze what is published on the topic at the ACM digital library and IEEE digital library. While on-site at EPFL, you can access both sites freely. The goal of this analysis is to make sure you do not reinvent the wheel and to position your work relatively to the others.
  • Wiki page: It might be useful to have a wiki page to collaboratively write your project report (with your assistant). You can use the EPFL wiki web site (http://wiki.epfl.ch).
  • Blog: We recommend that you have a blog that tells your progress. This will help you to remember what did happen in the project when you will write your report. It will be also a tool to interact together. Last, it is quite in fashion to have a blog these days…. You can use the EPFL blog web site (http://blogs.epfl.ch).
  • Mind mapping tool: Mindmaps are always useful to summarize ideas.

Deliverables :

  • Running software: if the project requires it, one deliverable will be a running software. The software should include a small documentation (installation, start, stop and main functions).
  • Poster web page: presentation of the project on one A4 html page (portrait). Making a poster trains you in explaining in a synthetic way your project. The poster will remain on the web after the project.
  • Report: the project needs to be documented by a report. The report should be in PDF format as well as in the native format (Word or Latex). We recommend using Microsoft Word.
  • Presentations: all presentations made during the project are also part of the deliverables (intermediate presentation, final presentation). The presentations should be in native format. We recommend using Microsoft PowerPoint.
  • Bibliographic file: we wish to get the bibliographic file that contains all references to the publications read and web sites that are related to the project.

Note:

  • The report, the poster and possibly the presentations will be posted on the web. Quite often the report or the presentation might contain confidential data (related to a company in which the project is made). The student is responsible to generate documents that are meaningful but that are not confidential. In general this is always possible. If a problem appears, the professor in charge of the project should be informed immediately.
  • In some cases, articles were jointly published with a student on the result of a diploma or semester project.

Evaluation :

The following grid is used to evaluate projects.

  • 30%: Problem specification / state of the art analysis / verification & validation

How well the student understands and defines the project (problem, research) motivation. His approach for validating his work: technical knowledge, verification and validation, customer testing. Little hint on the difference between verification and validation given by BoehmValidation – Are we building the right product? and Verification – Are we building the product right?

  • 20%: Artifact design / realization of the solution

The design of his “solution” to the research problem. How inventive this design is.

  • 20%: Project management

The student’s ability to manage his project, the time he spent, his organization and initiatives to work, finishing the small tasks given from the supervisor well and on time.

  • 30%: Report and presentation

The presentation is the ability of the student to “sell” his work. He has to show the global story (“big picture”), which means that he understands the project, and pick one very important point of his work and show its details. By doing this he proves that he is credible to talk about the project’s subject. In total the presentation should last 20 minutes max. The report has to be delivered with respect to the School’s deadlines. The details of the report itself were explained in the previous section.

Great resource on how to make a presentation:http://research.microsoft.com/~simonpj/papers/giving-a-talk/giving-a-talk.htm