TDDC88 Software Engineering: project supervisor for architecture and integration
Supervising simulated software companies of 25–30 students that each build a product for a real industrial customer (Axis Communications in 2026). My area is architecture, design, configuration management and integration, which I also grade.
- Simulated companies of 25–30 students, competing in parallel
- Real industrial customer, fixed-price contract, public product launch
- Four artefacts reviewed in every meeting, from architecture to integration
TDDC88's project is not a typical course project. Students are employed in simulated software companies of 25–30 people, several running in parallel: competitors, but with some common interests. Each company works with its own customer and has to ship a real product by the end of the semester.
- Organisation: a Product & Sales and an R&D department, roles such as project manager, architect and configuration manager, and cross-functional teams of 5–8.
- Customer (2026): Axis Communications, asking for solutions that interpret what is happening in streamed or recorded video.
- Contract: fixed price, 160 hours per engineer, everything included.
- Delivery: a pre-study, then version 1.0 launched at the Valla Software and Systems Expo (VSSE'26) in December.
My area: architecture, design, configuration management and integration
Supervisors work like consultants: we ask questions and judge how a company handles problems, rather than hand out solutions. So I don't design their system. I set up the conditions for good architectural decisions, review the reasoning and flag risks, while the students own the architecture. One question frames the work from the first meeting:
How will you build a system that can evolve, be integrated by several teams, and be tested, configured and delivered within the project's constraints?
Every supervision meeting then revolves around four living artefacts:
| Artefact | What it has to show |
|---|---|
| Architecture description | What the system is and how it is structured |
| Design and decision record | Why it was designed this way |
| Configuration and version management | That they can reliably reproduce and evolve what they built |
| Integration evidence | That the architecture works as one complete system |
At the end I grade each company in this area, on the result and on how they got there.
The setting mirrors industry on purpose: a busy customer, a fixed budget and several teams building one system. It is the position I was in at Artillence, running a client project from requirements to delivery, now seen from the reviewer's side.