Recommended Schedule for the Project

The course has a submission every Saturday of weeks 1–6, and the deadlines can be found in the course calendar on Moodle.

Week 1

• Topic, Programming Language, and Scope Decided
  • Explore topic suggestions.
  • Discuss with the instructor if needed, especially if your planned topic is not on the suggested list.
  • The instructor will review the specification document and provide feedback if necessary.
• Exercise Repository Initialized and Registered in Labtool
  • Remember to enable issues.
• Project Management in Order
  • This means the repository should be set up and registered in Labtool.
  • Additionally, there should be a way to compile code and manage dependencies.
  • For Python, it is recommended to use Poetry, as other students commonly use it too, and it is a familiar tool for them.

Week 1. Submission (Check the date in the course calendar and instructions for submissions)

• Weekly Report 1
• Specification Document Important: Remember to include your study program and the project’s programming language in the specification document! Also, make sure to clearly define the core of your exercise project. More instructions can be found in the specification document guidelines.

Week 2

• Development of the core area of the project should begin this week.
  • For example, if you’re working on AI for a game, you should (preferably) start developing the AI itself this week.
  • If your project involves implementing data structures, you can initially use built-in structures from your programming language and replace them later.

• The project’s code is documented from the start.

• Development of project tests (including unit tests) using representative inputs has begun.
  • Develop tests alongside your code.
  • Tests should measure the correctness of your code. Don’t spend unnecessary time on excessive tests — first, consider what types of tests your project actually needs.
    • The Testing pages contain useful materials, but not all projects require everything found there.
  • The project’s test coverage should be tracked.

Week 2. Submission

• Weekly Report 2

Week 3

• Core Project Area Developed
  • The project has a working (not necessarily polished) user interface.
  • All supporting methods for core functionality are complete.
  • Ideally, by this week, the project should be runnable, and its functionality should be observable.

• Code quality is maintained using tools like Pylint.

• The main implemented methods are comprehensively unit-tested with representative inputs.

• Writing of the Testing Documentation has begun.
  • The document includes a test coverage report.

Week 3. Submission

• Weekly Report 3

Week 4

This week, focus on preparing your project for peer review.
Ensure that your code is in a state where meaningful feedback can be given.

• The core functionality of the program is nearly complete. Any custom data structures have been started.
• Code is well documented and thoroughly tested.
• Work on the Implementation Document has begun.
• Development of additional tests beyond unit tests has started.
  • Remember that not all types of tests are necessary—focus on those most relevant for validating your project.
  • Document these in the Testing Documentation.

Week 4. Submission

• Weekly Report 4
• The first peer review will be assigned after this week’s submission.
  • Find the link to the repository under review in Labtool.
  • Remember to enable issues.
  • The peer review deadline is the same as for Week 5’s submission.
  • Peer review instructions are available on Moodle.

Week 5

• The first peer review is completed.
• Incorporating feedback received on your project.
• Implementation Document and Testing Documentation are up to date.
• The core functionality is complete. Any custom data structures are nearly finished.
• Tests are comprehensive and adequately cover the project.

Week 5. Submission

• Weekly Report 5

Week 6

• Second peer review.
• Finalizing the program.
• Finalizing tests.
• Documentation refinement.
  • Remember to include the User Guide.

Week 6. Submission

• Weekly Report 6
• The second peer review will be assigned after this week’s submission, with a deadline a few days after the review is given.
  • Find the link to the repository under review in Labtool.
  • Remember to enable issues.
  • The peer review deadline is Thursday of Week 7.
  • Peer review instructions are available on Moodle.

Final Submission

(The exact date can be found in Moodle’s calendar.)

Documentation:

• 100% clear and well-commented code.
• Completed documents:
  • Specification Document (no need to update the original).
  • Implementation Document.
  • Testing Document.
  • Weekly Reports.
  • User Guide.

Program:

• An executable program.
• The defined scope in the Specification Document has been fully achieved.
• The project is complete and polished.

Testing:

• Comprehensive unit testing.
• The program’s testing process is documented in the Testing Document.

Fix this page

Make an suggestion for an improvement by editing this file in GitHub.