Course syllabus

Course-PM: DAT266 / DIT265 Software Evolution Project — HT26

Course instance: 2026
Study periods: LP1–LP2, HT26
Course period: 2026-08-31–2027-01-17
Credits: 15 hp
Department: Computer Science and Engineering
Institutions: Chalmers University of Technology and University of Gothenburg

This Course-PM applies to the 2026 course offering of DAT266 / DIT265 Software Evolution Project.

Contact Details

Course Leadership

Teaching Assistants and Supervisors

The HT26 teaching and supervision team consists of:

Group-supervisor allocations and any additional contact details will be published in Canvas.

For groups assigned to Linda Erlenhov and Amna Pir Muhammad, Linda supervises the group during September and Amna takes over from October. The course team coordinates the handoff so that decisions, progress, contribution information, and unresolved issues follow the group; students are not expected to repeat completed work.

Student Representatives

Course Purpose

The aim of this course is to enable students to synthesize and apply knowledge from previous compulsory courses in the program while addressing the activities that take place after the initial release of a software product.

The course familiarizes students with typical situations, activities, and techniques in software evolution, such as adding new features, refactoring, automating variability or testing, improving performance, and balancing non-functional requirements. In addition, students will learn to plan, implement, and critically reflect on software evolution scenarios and improvements.

Schedule

See the course schedule in TimeEdit and here.

The concise HT26 course map shows how each deliverable feeds the next phase. Detailed deadlines and supervision weeks are listed in the student-facing schedule distributed in Canvas.

Course Literature

The course literature is found here.

Course Design

The course is structured around a group project and individual assignments. A series of lectures and one workshop support this work.

The course corresponds to approximately 20 hours of work per student per week across LP1 and LP2. This includes scheduled activities, individual assignments, group work, supervision, reading, implementation, testing, documentation, and preparation for presentations.

Project Work

Students organize themselves into project groups of 5–7 students. The groups remain intact throughout the course.

Each group:

  • Is assigned a dedicated supervisor.
  • Must provide a short written status update before each assessed supervision meeting. The update should normally be no more than five lines covering completed work, next work, blockers, decisions needed, and responsibility changes, and it serves as the meeting agenda. No separate written supervisor response is provided when the group is on track. Between meetings, groups must contact their supervisor promptly if they encounter a material blocker, participation problem, or need for an approved change of scope.
  • Has eight assessed supervision meetings across the course. The group and its supervisor agree the times between them; by default a meeting is held every second week, starting once group membership is confirmed, with at least one meeting each month held in person.
  • May arrange additional optional meetings when useful. Optional meetings do not change the attendance or participation denominator.

The project work is divided into four phases, each ending with a delivery milestone:

  1. Phase 1: Introduction, program comprehension, and integration selection.
  2. Phase 2: Validated code analysis and tested software improvement.
  3. Phase 3: Evolvable extension design and initial implementation.
  4. Phase 4: Implementation completion, verification, documentation, and product finalization.

Each phase includes one group assignment.

Groups normally continue with the same approved Home Assistant integration throughout Phases 1–4. This continuity allows the output of one phase to become the input to the next. A change of integration requires prior written approval from the supervisor.

Integration selection happens early and outside the supervision schedule. Groups propose an integration as soon as they have formed and should hold written approval by 2026-09-11; approval is a short written confirmation by email or Canvas, not a scheduled agenda item. Assessed supervision meeting 1 confirms and refines the approved scope rather than granting it. Supervisors respond within two working days, so propose a first and a second choice to avoid a second round.

A suitable integration is one the group can realistically work with for the whole course. It should be small enough to understand and large enough to analyse, have existing tests, run without hardware or credentials the group does not have, offer a plausible extension for Phases 3–4, and carry a declared Integration Quality Scale tier, which Individual Assignment 3 relies on. The supervisor judges suitability.

Repository and Contribution Model

The group chooses how to organize its work in Git. The course states what the result must support, not how to achieve it:

  • One shared repository holds the group project and is its source of truth. Every member can contribute to it, and the course team can read it. Individual Assignment 1 is done in the student's own repository.
  • Individual contributions are visible. The history must show who did what, and the group must be able to demonstrate that work was reviewed by someone other than its author.
  • The work is reproducible. It must be clear which version of Home Assistant Core each phase's analysis and implementation is based on, and that basis should stay stable within a phase so that findings and changes remain comparable.
  • What is assessed is what was submitted. Assessment uses the state of the repository at the submission deadline. Later work counts only through an approved supplementation.
  • The evidence remains available to the course team until all grades and any review are final.
  • Nothing is contributed upstream without approval. Opening an issue or pull request in a Home Assistant or Open Home Foundation repository as part of the course requires prior supervisor approval, and the contribution must then be submitted and maintained by a student rather than an autonomous agent, following the upstream project's contribution and AI policies.

Group Assignments 2–4 require automated tests. Follow the testing conventions of the integration you are working in; each assignment states the level of test evidence it expects. Being blocked on test infrastructure is not what these assignments assess, so raise it with your supervisor early.

At the end of Phases 1, 2, and 3, each project group will:

  • Present the results of its assignments to other project groups.
  • Oppose, or provide feedback on, another group’s presentation.

For each Phase 1–3 presentation, the prepared presentation is delivered by a maximum of three designated group members. Every group member must deliver part of the presentation on at least one of the three occasions — this is a course pass requirement, and answering questions during the Q&A does not satisfy it. Three occasions with up to three presenters gives nine speaking slots, so a group of seven has only two slots of slack. Agree the rotation across all three phases at the start of the course.

All group members must attend their assigned session and remain responsible for understanding the submitted work; any member may answer questions during the Q&A. Opposition is delivered by one to three representatives at each session, and all group members must help prepare or review it. Every group member must be one of the speaking representatives on at least one of the three occasions — also a course pass requirement. Presentation and opposition use separate speaking slots, so a member can do both at the same session.

At the end of Phase 4, each group will:

  • Present its finalized product through a short pitch and a project-fair demonstration.
  • Submit a Final Group Report at the end of the course.

Individual Work

Students will submit three mandatory individual assignments.

Individual Assignment 1 carries no points and is assessed as Approved/Disapproved

Lectures and Workshop

A lecture series and a workshop are provided to ensure that students have the knowledge required to complete the project and individual assignments. Regular lectures are not mandatory and attendance does not affect the grade, but students are strongly encouraged to participate.

The course includes two guest lectures by experienced practitioners. Dates, speakers, and topics are announced in Canvas.

Attending them is a graded learning activity worth 2 points in total as part of the individual-contribution assessment, divided equally over the guest lectures actually held. Attendance is recorded through the check-in method announced in Canvas.

Guest lectures are not recorded, and there is no substitute task. A student who is absent does not earn that share of the points. Approved accommodations and documented exceptional circumstances are handled according to university regulations.

Guest lectures include a moderated Q&A. Come prepared to ask something: the value of the session depends on the questions the audience brings.

Group Difficulties and Membership Changes

Groups are expected to raise participation problems early rather than waiting for a deadline. If agreed work is repeatedly not completed, communication breaks down, or a member leaves the course, the group must notify its supervisor within two working days and provide a factual summary of responsibilities, completed work, and immediate risks. The supervisor will first facilitate a concrete recovery plan. If the problem cannot be resolved, the course responsible decides whether membership, scope, responsibilities, or the assessment arrangement must change. No student is automatically awarded credit for work completed by the rest of the group.

Use of AI-Assisted Tools

AI-assisted tools may be used in this course. They are treated as software-engineering tools that must be evaluated critically, not as authoritative sources.

The following rules apply:

  • Students remain responsible for the correctness, quality, attribution, security, and licensing of everything they submit.
  • Students must review, understand, and be able to explain all submitted code, analysis, diagrams, and text.
  • AI-generated claims are not evidence. They must be verified against source code, execution results, tests, official documentation, or primary literature.
  • Meaningful AI use must be disclosed in a concise, assignment-specific AI decision log stating the task, assistance used, whether the output was accepted, modified, or rejected, and how it was verified. The log belongs in the report appendix and is excluded from the page limit. Full chat transcripts are not required.
  • AI tools must not receive secrets, credentials, personal data, or other sensitive information.
  • AI may improve language and clarity, but citations and factual claims must be checked against the original sources.
  • Autonomous agents may not create issues or pull requests in upstream Home Assistant repositories. Any upstream contribution must follow the Home Assistant AI Policy.

Undisclosed AI use, plagiarism, fabricated evidence, or other attempted deception is handled under the applicable institutional rules. Suspected cases may be referred through the Chalmers disciplinary process or the University of Gothenburg process, depending on the student’s registration. Academic-misconduct review is separate from ordinary assessment and supplementation.

Supervisors and examiners may ask any group member to explain a submitted artifact, design decision, test, or code change. The student must answer in their own words without consulting AI during the explanation.

Assignments may require a specific AI-assisted comparison or audit. If a student cannot access a suitable tool, the student must contact the course team for an approved alternative.

A suitable AI decision log has the following form:

Task or Question AI Assistance Used Accepted, Modified, or Rejected Verification Evidence

The course also treats AI as a phenomenon that changes software evolution—not only as a productivity tool. Students will consider how AI-assisted maintenance affects code review, traceability, maintainability, responsibility, and the economics of software change.

Course-Wide Submission and Document Conventions

Unless an assignment or Canvas explicitly states otherwise:

  • Individual assignments are submitted once by the individual student. Group deliverables are submitted once per group by a designated member; all members remain responsible for checking that the correct files and links were submitted.
  • Use the file name assignment-id_group-or-student_identifier.pdf, for example GA2_group07.pdf or IA2_cidada.pdf. Canvas instructions may replace the identifier format where needed.
  • Reports use a readable font of at least 11 pt, margins of at least 20 mm, and legible tables and figures.
  • The page limit applies to the report body. An optional title page, references, contribution table, assignment-specific AI decision log, and explicitly permitted evidence appendix are excluded. Material essential to the argument must remain in the report body; appendices cannot replace required analysis.
  • The contribution table identifies substantive responsibility for analysis, implementation, tests, review, writing, and presentation preparation. Commit counts alone are not evidence of contribution quality.
  • Deadlines are firm. Work submitted after the deadline without an approved extension is not assessed in the ordinary round; the student or group is referred to supplementation or to the next assessment opportunity, and an approved supplementation is capped at the assignment's pass threshold. If you foresee a problem, request an extension from the course responsible before the deadline; documented illness and other exceptional circumstances are handled according to university regulations.

    This matters most for the Group Assignment 1–3 reports and slide packs, because another group needs the report in order to prepare its opposition. A group that misses one of those deadlines must notify the course team immediately. The opposing group is reassigned or assessed on the material available and is never penalized for another group's delay.
  • When supplementation is permitted, the feedback will identify the unmet criteria. The supplementary submission is made through Canvas; the stated deadline will normally give the student or group at least five working days to respond. An approved supplementation remains capped at the assignment’s pass threshold. A substantially missing submission or one requiring a different task may instead be referred to the next assessment opportunity.

Feedback and Reassessment

  • The course team aims to return rubric-based feedback within 15 working days and, where the result feeds the next phase, before that phase’s submission deadline.
  • The Approved/Disapproved result of an IA2 or IA3 oral checkpoint is recorded in Canvas by the supervisor who held it, on the day it is held. The checkpoint is a pass gate that is tracked separately from the written rubric score and may be completed before the written work has been assessed.
  • A limited gap in a written report, code artifact, repository evidence, or IA1/IA2/IA3 checkpoint may normally be supplemented during HT26 when the examiner determines that the original attempt is sufficiently complete.
  • Fixed-date presentation, opposition, pitch, or project-fair requirements cannot normally be recreated in the original session. A student or group with an approved absence or an insufficient result completes an equivalent oral or demonstrative task at the reassessment opportunity published in Canvas.
  • Active Individual Contribution represents sustained work and cannot be replaced by a single retrospective text or oral task. An insufficient result may require additional supervised project work at a future assessment opportunity determined by the examiner.
  • A substantially missing project phase, an implementation requiring major new work, or an exhausted supplementation opportunity is referred to the next formal reassessment opportunity. Canvas will state the date and format; depending on the component and available project context, this may occur after HT26 or with a later course offering.
  • All reassessment decisions remain subject to the applicable Chalmers or University of Gothenburg examination regulations and approved accommodations.

Learning Objectives

Knowledge and understanding
  • explain the notion of software evolution.
  • summarize state of the art in methods and tools for software evolution tasks, such as program comprehension and software refactoring.
  • discuss the challenges associated with software evolution.
  • explain current research trends in program comprehension and refactoring.
Skills and abilities
  • extract a software product's architecture from a given code base and evaluate the quality of the software product.
  • implement one software evolution scenario.
  • implement changes to a software product that lead to an improvement of the product's quality.
  • make use of synergies between different improvements goals for the same product.
Judgement and approach
  • detect and judge needs for quality improvement or evolution in an authentic software product.
  • plan the use of appropriate methods and techniques for performing a software evolution scenario and a quality improvement task.
  • judge needs for improvement of methods and tools to support software evolution.
  • plan and evaluate ideas for new or improved tools.

The course is a joint course (Chalmers and Göteborgs Universitet).

Assessment Alignment

Learning-objective area Principal assessment evidence
Explaining software evolution, its challenges, and its research trends Final Group Report learning-outcome matrix, which must address each Knowledge and Understanding objective explicitly; supported by the IA2 literature connection
Program comprehension and architecture recovery GA1 and IA2
State of the art and research trends IA2 literature connection, guest lectures, and Final Group Report literature synthesis
Detecting and prioritizing quality-improvement needs GA2
Planning and implementing an evolution scenario GA3 and GA4
Combining improvement goals for the same product GA3 multi-goal design decision and GA4 verification
Improving and evaluating methods or tools IA2 tooling-improvement proposal and the verification strategy used in GA2
Evolvability judgment and quality trade-offs IA3, GA3, GA4, and Final Group Report
Human–AI collaboration in software evolution IA2, GA1–GA2, supervision checks, and Final Group Report

The course has no written examination. The Knowledge and Understanding objectives are therefore assessed through applied and reflective evidence rather than through recall: students demonstrate them by explaining their own project decisions orally without preparation, and by addressing each objective explicitly, with concrete course evidence, in the Final Group Report learning-outcome matrix. This is a deliberate choice for a project course, where the ability to explain and apply a concept in an authentic system is stronger evidence of understanding than a written account of it.

Examination and Grade Thresholds

The course is examined through project work and individual assignments. There is no written examination.

The course corresponds to 15 hp in total:

  • The group-project examination block corresponds to 12 hp and contributes 80% of the final grade.
  • The individual-assignment examination block corresponds to 3 hp and contributes 20% of the final grade.

The 80/20 split describes the two formal examination blocks, not whether a score is individual. The group-project block includes the 8-point Active Individual Contribution assessment. Consequently, 17 of 45 points are assessed directly at individual level: 9 points from Individual Assignments 2–3 and 8 points from Active Individual Contribution.

To pass the course, the following is required by each student:

  • The individual, group, and active individual contribution assignments are approved. An assignment is approved when all included deliverables have been submitted/completed with an acceptable quality (specified in the assignment rubric).
  • Has not missed more than:
    • two of the eight assessed supervision meetings, and
    • one of the four group-presentation occasions (i.e., the three Phase 1–3 presentation and opposition sessions and the Phase 4 final pitch and project fair).
  • Has delivered a meaningful part of the group's presentation on at least one Phase 1–3 occasion. Answering questions during the Q&A does not satisfy this requirement.
  • Has contributed to delivering the group's opposition on at least one Phase 1–3 occasion, as one of the group's speaking representatives.
  • Approved oral checkpoints for IA2 and IA3.

Approved accommodations and documented exceptional circumstances are handled according to university regulations.

A student or group whose assignment is not approved may be asked to supplement the missing requirements. An approved supplementation is capped at the assignment’s pass threshold (50% of the points).

The maximum score is 45 points.

Grade Minimum Points Approximate Percentage
3 22 50%
4 31 70%
5 40 90%

Point Distribution

Group Project — 36 Points

Component Total
Phase 1 6.0
Phase 2 6.0
Phase 3 6.0
Phase 4 10.0
Active individual contribution to the group project 8.0
Total 36.0

Active individual contribution includes activities such as coding, participation in supervision meetings, and documentation. To approve Active Individual Contribution, the student must earn at least 4 of 8 points, reach at least the Acceptable level for Individual Contribution, and satisfy the course-level attendance, presentation, and opposition requirements. Attendance points cannot substitute for the absence of a substantive project contribution.

Individual Assignments — 9 Points

Assignment Points
Assignment 1 Approved/Disapproved
Assignment 2 4.5
Assignment 3 4.5
Total 9.0