Skip to content

Mandatory Requirements for Project Work 2

Project Work 2 is not a new type of course and not a reset. It builds directly on what you already learned in Project Work 1 and in your other software engineering courses. You are expected to use that knowledge, not relearn it.

Process stays the same.

The process stays the same: team work, milestones, MVP vs quality, salary and price, deadlines, demos, and point-based grading all apply exactly as in Project Work 1. The difference is the level of expectation. In Project Work 2, you work on a more complex and more advanced project, and the required outcomes reflect that.

Everything that applies to Project Work 1 still applies here: deadlines are real, milestones are interdependent, points are earned as a team and split individually, and only visible, delivered work counts. This page defines where and how the expectations are raised for Project Work 2.

The advancement is mandatory.

The advancement is mandatory. Simply repeating Project Work 1–level solutions is not enough. Stagnation is not rewarded: if your work does not show clear progression in scope, technical depth, or execution quality, you will not earn passing grades — even if the project “works.”

Project Continuity and Ownership

In Project Work 1, you learned how to start a project from scratch.
In Project Work 2, the focus shifts to developing an already existing codebase.

You are expected to take responsibility for existing decisions — architecture, structure, tooling, and technical debt included. This is deliberate. Real projects rarely start clean, and professional work means improving what already exists, not discarding it when it becomes inconvenient.

Not your fault, still your responsibility

You open the project and immediately see problems.
The structure is messy. Something is undocumented. A test fails and nobody knows why.

None of this is your fault. You didn’t create it.

Responsibility starts at a different point: what you do next.
Do you ignore the problem because “it was already like this”?
Or do you try to understand it, clean up one part, add a comment, fix a test, or at least write down what you found?

In real projects, the difference matters.
When everyone focuses on who caused the problem, the project stalls and everyone loses.
When someone focuses on what can be done next, progress resumes — even if the situation is imperfect.

This does not mean accepting everything silently or becoming a doormat. Team issues, bad decisions, and missing work must be addressed. But endlessly pointing at past mistakes does not fix the task in front of you. Action does.

In Project Work 2, blame ends at the commit history. Responsibility starts with the code you touch.
Help offered but not used does not earn points. Effort without impact is not rewarded.
You are evaluated not on who caused the problem, but on whether the project is better when you leave it than when you found it.

“It’s not your fault, but it is your responsibility.”
— commonly attributed to commonly attributed to Jocko Willink (Extreme Ownership)

Teams must base their work on one of the following:

  • a Project Work 1 project that at least one current team member previously worked on
  • a project selected from a provided list (see below).

Teams in Project Work 2 do not have to match Project Work 1 teams. However, choosing a Project Work 1 codebase implies that someone on the team has first-hand experience with that project’s history, decisions, and limitations.

Starting a brand-new project is not allowed.

Provided Project List

  • CodeMetropolis – A codebase visualization tool that represents software systems as interactive 3D cities. Focuses on analyzing structure, size, and dependencies in existing codebases, with clear opportunities for extension, refactoring, and deeper technical exploration.
    https://github.com/codemetropolis/CodeMetropolis
    https://codemetropolis.github.io/CodeMetropolis/
  • bibHygeia – A bibliography and reference management tool focused on collecting, organizing, and maintaining structured academic sources. The project offers a realistic medium-sized codebase with opportunities for improving data models, workflows, usability, and long-term maintainability.
    https://github.com/geryxyz/bibHygeia
  • flatCraft – A lightweight crafting and simulation-style application built around composable rules and state changes. The project provides a non-trivial codebase with clear possibilities for extending core mechanics, improving architecture, and addressing design trade-offs made during early development.
    https://github.com/geryxyz/flatCraft
  • Schrödinger – A command-line tool for cloning and reorganizing directory structures based on file extensions or variants (e.g. .en, .hu). Designed for translation workflows and multi-variant documentation, the project offers a well-structured Python CLI codebase with opportunities to improve robustness, extensibility, logging, testing, and packaging rather than adding greenfield features.
    https://github.com/kayurh/Schrodinger

From a technical perspective, the chosen project must be imported into the team’s student GitLab as a new project. The Project Work 2 repository is the single source of truth from day one. History matters, but ownership starts here.

Single repository rule

Only work committed to the Project Work 2 repository will be evaluated and graded.
Changes made in the original Project Work 1 repository or in any other external repository are ignored, regardless of effort or quality.

Advanced Topic Selection

At team formation, each team must choose one advanced topic.
This choice must be documented in writing in the project README.md, with a clear link to the selected advanced topic description.

The advanced topic defines how your project work is stepped up in Project Work 2.

Choosing an advanced topic does not change the structure of the course: - deadlines stay the same, - the total amount of points stays the same, - the number of tasks stays the same, - no tasks may be merged, removed, or added.

What changes is the content and complexity of the work within those tasks.

The original task descriptions from Project Work 1 still apply. You still define features, plan them, implement them, test them, and document them.
The advanced topic extends these tasks with additional expectations. For example, you may still develop features — but a specific kind of feature, under specific constraints, or with additional technical depth.

You are not expected to become experts in everything. The reason you choose an advanced topic is precisely so you can focus on a direction that fits your interests or intended specialization. Depth in one area is maybe valued more than shallow coverage of many.

Working on an advanced topic also means working more independently. You are expected to actively seek information: read documentation, search for examples, ask informed questions, and experiment. This mirrors real software engineering work, where keeping your knowledge up to date is part of the job, and ready-made answers are rare. Software engineering is a creative profession, not a checklist exercise.

Tutors will support you by guiding your thinking, asking clarifying questions, and helping you evaluate options. We will help you understand what to look for, why certain choices matter, and how to recognize problems early.

At the same time, advanced topics mean that no one will hand you complete solutions. In real software engineering work, learning happens through exploration, reading documentation, discussion, and trial-and-error. Your tutors are here to support and challenge your growth, not to replace your learning process or make decisions on your behalf.