# Software Technology > Teams of three (at most four) build the semester’s game – every team the same one – through four milestones: requirements and design, then three prototypes – with GitLab issues, feature branches, merge requests, CI, unit tests and code review the way industry teams use them. Source: https://laszlonemes.com/university/software-technology · Author: László Nemes Szoftvertechnológia The goal is to see a whole software development process, not just the programming: planning and modelling, version control as a team, continuous integration, testing and review. The game is the vehicle. The sessions simulate a scrum team: there are no separate exercises – everyone works on the team's game, each week every member answers three questions, and at each milestone the team demos its work. The pages below follow the milestones and add the guides the team needs along the way. `Teamwork` `Scrum` `GitLab` `CI/CD` `UML` `Unit testing` `Code review` Hall of Fame **Highlighted projects from earlier semesters** The best projects of the course on the course GitLab – see what a finished game, its repository, issues and pipeline look like before you plan yours. [Open](https://szofttech.inf.elte.hu/hall-of-fame) ## Requirements What it takes to complete the practice part. Dates and deadlines are on Canvas. Team project **Teams of three, at most four – every team builds the same game** One language per team. Java and C# get the most support; other languages and engines are possible, with less help. Milestones **Four milestones, each scored 0–10 per person** At least 4 points on every milestone. The practice grade is the average of the four. GitLab activity **Everyone works from their own account** Only your own work can be graded. From the second milestone your issues, commits, branches and merge requests weigh heavily. Weekly scrum **Three questions, every week, from everyone** What have you done since last week? What will you do by next week? Is anything blocking you? Lecture tests **A mid-semester and an end-of-semester test** Two thirds of the questions must be right. The result does not change the grade, but passing both is a condition of getting one. The final milestone also needs a short gameplay video, and from the third milestone the CI has to run a static-analysis code-quality check. ## Sessions Open a session here, or on its own page in a new tab. - Session 1 **[Kick-off: the course, the teams, the tools](https://laszlonemes.com/university/software-technology/kickoff)** How the semester runs: teams of three (at most four) build the same game through four milestones that simulate sprints, with a weekly three-question scrum, GitLab as the project hub and individual scores from 0 to 10. - Milestone 1 **[Requirements and design: use cases, class and database diagrams](https://laszlonemes.com/university/software-technology/requirements-design)** Milestone 1, without code: turn the specification into use cases and user stories with acceptance criteria, and design a model–view class diagram and a database diagram on the GitLab wiki. - Milestone 2 **[Working as a team in git: issues, branches, merge requests](https://laszlonemes.com/university/software-technology/version-control)** Milestone 2: the team workflow – protected main and develop, a branch per issue, commit messages checked by git hooks, labelled issues on a board, and reviewed merge requests merged with merge commits. - Milestone 3 **[Continuous integration: pipelines, unit tests, static analysis](https://laszlonemes.com/university/software-technology/continuous-integration)** Milestone 3: a pipeline on every merge request – format check, build, unit tests with coverage and static analysis – for Java, .NET and Unity, plus how to read a red job and run the same checks locally. - Milestone 4 **[The final product: clean code, tests, release](https://laszlonemes.com/university/software-technology/final-product)** Milestone 4: finish against the Definition of Done – clean code, edge- and failure-case tests, high model coverage – then release through a release branch and a tag, and present a demo and a gameplay video. ## Guides Stand-alone pages: references, background reading and fixes for common problems. - Guide **[Setting up the team repository](https://laszlonemes.com/university/software-technology/repository-setup)** A one-time checklist for the team's GitLab project: template, protected branches, merge request rules, labels, board, milestones, CI badges and a smoke test – with the GitHub equivalent of every setting. - Cheat sheet **[An issue from start to merge, with commands](https://laszlonemes.com/university/software-technology/issue-lifecycle)** A cheat sheet to keep open: every step from creating an issue to cleaning up after the merge, with the git commands, how to bring develop into your branch, and fixes for the usual accidents. - Guide **[Code review: how to write it and how to take it](https://laszlonemes.com/university/software-technology/code-review)** What a reviewer checks and in which order, how to write comments marked by weight, how to answer a review, how big a merge request should be, and how to rotate reviewers in a team of three. - Reading **[How this maps to industry practice](https://laszlonemes.com/university/software-technology/industry-context)** The course workflow next to real companies, from startups to enterprises: what is the same everywhere, what changes with size, trunk-based vs Gitflow-style branching, and the terms you will hear as an intern.