Kick-off: the course, the teams, the tools

In most courses you program alone, for yourself, against a deadline. In this one a team of three (at most four) builds one game together over a semester. Every team of the semester builds the same game from the same specification, and the way you build it counts as much as what you build. You will plan before you code, keep your work in GitLab issues and branches, review each other's code, and let a CI pipeline check every change.

This first session sets everything up: what the course wants from you, how the semester runs, how the team forms, which tools you use and how you are graded.

What the course is for

The practice part of Software Technology (Szoftvertechnológia) is about the software development process, not about one more programming language. By the end of the semester you should have been through every step of it once, in a team:

the process itself – the traditional (waterfall) model and the agile one, and why teams moved from the first to the second;
planning and modelling – use cases, user stories, class and database diagrams, before any code;
developing in a team – splitting work, version control, merge requests, code review;
industry tools – issue tracking, CI pipelines, unit testing, static analysis, releases.

The game is the vehicle, not the goal. A team with a smaller game and a clean history of issues, branches, reviews and green pipelines is doing better than a team with a beautiful game that one person pushed to main the night before the demo.

Waterfall and agile

The waterfall model runs the phases once, in order: collect every requirement, design the whole system, implement it, verify it, then maintain it. It is easy to plan and easy to explain. Its weakness is that the first working software appears at the very end – so a misunderstood requirement shows up when it is most expensive to fix.

An agile process (scrum is the most common variant) cuts the work into short sprints of two to three weeks. At the start of a sprint the team picks the most important items from the backlog; every day it holds a short daily scrum; at the end it shows a working increment – something that runs – and the feedback goes back into the backlog (Fig. 1).

Fig. 1 · Waterfall delivers once, at the end. Agile delivers a working increment every sprint, so mistakes surface while they are still cheap.

This course squeezes the agile loop into a semester. A milestone is a sprint: it ends with a demo of something that works. A weekly session is the daily scrum: short status, next steps, obstacles. The first milestone is the one waterfall-like step – you design before you code – because a team needs a shared picture of the game before it can split the work.

Backlog: Every known requirement and task, ordered by importance. In GitLab: the open issues.
Sprint: A fixed time box with a chosen slice of the backlog. Here: the weeks between two milestones.
Increment: The working software at the end of a sprint – something you can run and demo.
Scrum: A short status meeting with three questions per person. Here: weekly, at the session.
Product owner: The person who decides what the product needs. Here: your practice instructor.

The semester at a glance

There are four milestones (mérföldkő), in weeks 4, 7, 10 and 13. Every week in between is a scrum session (Fig. 2).

Fig. 2 · Four milestones, three weeks apart. The requirement grows each time: from a design, through 30% and 90% of the use cases, to a finished, tested game.

Milestone	Week	What has to be ready
M1 Requirements and design	4	Use cases, use-case diagram, class diagram, database diagram – as text and diagrams on the GitLab wiki. No implementation yet.
M2 Prototype I	7	Version control working and actively used by everyone. About 30% of the use cases work.
M3 Prototype II	10	CI set up and used on every merge request, with a static-analysis check. Unit tests exist. About 90% of the use cases work.
M4 Final product	13	Clean code, thorough unit tests including edge and failure cases, every feature works. A short gameplay video.

The jump from 30% to 90% between weeks 7 and 10 is the steepest part of the semester, and it coincides with tests in your other courses. Teams that leave it late arrive at M3 with half the game and no time. Each milestone has its own page here – M1, M2, M3 and M4.

Forming the team

Teams have three members, at most four, and you form them yourselves. Before the end of the first session, every team gives the instructor its members and a team name, and every member logs in once to the course GitLab server (szofttech.inf.elte.hu) with their faculty account – the account only exists after the first login. The team then gets its GitLab repository and a private Teams channel.

Before you start planning, look at the Hall of Fame on the course GitLab: the highlighted projects of earlier semesters – finished games together with their repositories, issues and pipelines.

A good team covers these competencies between its members – not every member needs all of them:

Competency	What it means in this project
Programming	In one language for the whole team. Java and C# get the most support.
UI	Windows, menus, drawing the game board, input handling.
Version control	Branches, merge requests, resolving conflicts – everyone does it, one person should be good at it.
CI	Writing and fixing the pipeline; knowing the build tool (Gradle, Maven, dotnet, Unity batch mode).
Testing	Unit tests for the model, edge cases, coverage.
Organisation	Keeping the board, the milestones and the wiki up to date.

To get the team talking, everyone answers four questions in the first session: Which language would you like to build the game in? Have you used version control before (git, SVN)? Have you used a CI tool (GitLab CI, GitHub Actions, Jenkins, Azure DevOps)? Have you built anything in a team?

The weekly scrum

Most sessions run as a scrum meeting per team, in person. Every member answers three questions, then the rest of the session is for technical discussion and working together (Fig. 3).

Fig. 3 · A week of the course. The scrum is short; what makes it useful is that the answers match what GitLab shows.

A useful answer is concrete: it names issues and merge requests, commits to something for next week, and raises a blocker while there is still time to remove it.

Two answers to the same question

Weak:   "I worked on the map."

Strong: "I closed #14 (load the map from a file); its MR is merged.
         This week I take #17 (collision with walls) and review the MR for #15.
         Blocked: we haven't agreed on the save format – can we settle it today?"

Tools

Tool	What you use it for
GitLab	The project hub: repository, issues, board, milestones, merge requests, CI pipelines – and the wiki, where the M1 design lives. One of the pillars of grading.
Teams channel	Private to your team and the instructor. Chat and calls outside the sessions; feedback arrives here.
UML editor	Any you like: StarUML or Enterprise Architect offline, diagrams.net or Creately online.
PlantUML	Diagrams written as text, rendered right on the GitLab wiki – so they live next to the documentation and can be reviewed like code.

Two GitLab rules matter from day one. Everyone works from their own account: only your own work can be graded, and GitLab attributes commits by the e-mail address git writes into them. And every piece of work is an issue, assigned to a person and a milestone – the repository setup guide shows how to prepare the project. Set your git identity once per machine:

Once per machine

git config --global user.name "Your Full Name"
git config --global user.email "<the e-mail address of your GitLab account>"
git config --list --show-origin | grep user.   # check what git will write into your commits

If git itself is new, read Git and GitHub: the mental model, in pictures first – commits, branches, merges and remotes in a dozen figures. Everything there applies to GitLab too.

How grading works

The instructor scores each milestone from a product owner's point of view – does it work, does it match the requirements, is the process healthy – and gives every member an individual score from 0 to 10 (Fig. 4). The criteria of a milestone can be announced before it.

Fig. 4 · Four individual scores, a minimum on each, an average at the end – and the lecture tests as a gate.

You need at least 4 points on every milestone. There is no milestone you can sit out.
The practice grade is the average of the four milestone scores.
From M2 on, GitLab activity weighs heavily: your issues, commits, branches, merge requests and reviews. It shows who did what – and the scrum answers should match it.
The milestone demo takes 5–10 minutes per team. Different members present at different milestones; one person can't present all four.
The lecture has a mid-term and an end-of-term test. You need two thirds right on each; they don't change the grade, but passing both is a condition of getting one.

Summary

The course is about the process: plan, model, develop as a team, use industry tools. The game is the vehicle.
Milestones simulate sprints, weekly sessions simulate the daily scrum with three questions per person.
M1 design (week 4), M2 30% of use cases with git (week 7), M3 90% with CI and tests (week 10), M4 finished and clean (week 13).
Scores are individual, 0–10 per milestone, at least 4 each; from M2 your GitLab activity weighs heavily.
Everyone uses their own account; every piece of work is an issue. Finish the core first; use placeholders for art.