University of Turku Software Engineering Master’s Thesis Guide: DTEK1002, DTEK1102, 30 ECTS and UTUGradu

Quick answer: what is the University of Turku Software Engineering thesis route?

The current Software Engineering track in the University of Turku Master’s Degree Programme in Information and Communication Technology is a 120 ECTS, two-year Master of Science (Technology) programme in the Faculty of Technology. The controlling curriculum is DTEKOT2427 / programme 99296 for 2024-2027. The exact thesis is DTEK1002 Master’s Thesis in Technology, 30 ECTS, graded 0-5. TTDK1308 is the 0 ECTS maturity examination. The track-specific thesis seminar is DTEK1102, 5 ECTS, Pass/Fail, and it sits inside the 20 ECTS Common Studies block.

1. Start from DTEKOT2427 / programme 99296

Software Engineering is one of the ICT specialisation tracks, but its curriculum must be read as its own programme object. The current Peppi object is DTEKOT2427 / 99296. Use this object together with your personal HOPS. A sibling ICT track may share DTEK1002, but that does not make its seminar code, module placement or method emphasis transferable to Software Engineering.

2. The formal degree is 120 ECTS

Peppi shows a technical root range of 115-125 ECTS because thematic/minor and Other Studies modules allow choices within ranges. The formal degree remains 120 ECTS. Do not report the Peppi range as the degree size. Your approved study plan should resolve those optional ranges into the 120 ECTS degree that applies to your study right.

3. Understand the 80 ECTS Advanced Studies block

Peppi places 80 ECTS inside DTEKOHJELMISTO2427 Advanced Studies: a 20 ECTS Software Engineering Core Module, 10 ECTS Compulsory Advanced Studies, 20 ECTS Common Studies in ICT and the 30 ECTS thesis category. The first three coursework components total 50 ECTS, matching the public programme description of 50 ECTS advanced-level major studies plus a 30 ECTS thesis.

4. Know what sits inside the 20 ECTS core

The Software Engineering Core Module contains Requirements Engineering, Software Design and Architecture, Software Testing and Quality Assurance, and Usability, User Experience and Analytics, each 5 ECTS. These courses explain why Software Engineering theses often involve stakeholder evidence, architecture decisions, testing protocols, usability evaluation or product analytics. They provide method context but do not replace thesis-specific research design.

5. The 10 ECTS compulsory advanced block adds privacy, security and UI work

The compulsory advanced block contains DTEK8102 Privacy and Security for Software Systems and DTEK2090 Modern User Interfaces, each 5 ECTS. This means privacy, secure software engineering, vulnerabilities, data protection and interface design can be legitimate thesis contexts. It does not mean every Software Engineering thesis is a security, GDPR or UX thesis. Scope should follow the actual research question.

6. DTEK1102 is inside Common Studies

Unlike the Robotics seminar placement, DTEK1102 Master’s Thesis in Technology Seminar, Software Engineering is a 5 ECTS child of the 20 ECTS Common Studies in ICT block. The same block also contains Knowledge and Innovation Management, 5 ECTS, and a 10 ECTS choice between Capstone and Lean Digital Business Design. This placement should be reflected accurately in your HOPS and guide interpretation.

7. DTEK8104 is a different seminar

DTEK8104 Software Engineering Seminar is a separate 5 ECTS Pass/Fail course under Other Studies. It exposes students to contemporary software-engineering research, literature, presentations, industry visits and research discussion. It is not the same course as DTEK1102 and should not be substituted for the thesis seminar without an explicit current University decision. Keep the two course codes distinct in planning and reporting.

8. DTEK1002 is the exact 30 ECTS thesis course

DTEK1002 Master’s Thesis in Technology is 30 ECTS, Advanced Studies, graded 0-5 and available in Finnish or English. The course requires scientific work, command of research methods, knowledge of the research field and scientific writing. A software product, prototype, architecture or codebase becomes thesis evidence only when it is tied to a clear question, documented method, evaluation and bounded conclusion.

9. Build the thesis plan with supervisors

At the beginning of DTEK1002, prepare a thesis plan with the assigned supervisor or supervisors. If you need a topic, contact a professor of the main subject so supervision can be arranged. Define the research or engineering problem, system boundary, data or participants, implementation context, evaluation criteria, access constraints, ethical/privacy issues and expected contribution. Update the plan when evidence or supervisor feedback requires it.

10. Company and research-group theses are both possible

DTEK1002 explicitly allows thesis work around a company or organisation challenge and can include company co-supervision. It can also be completed within a University research group. For a company thesis, decide early what source code, issue data, telemetry, architecture documentation, customer material and security findings can be examined by supervisors and examiners and what may appear in the public thesis.

11. Know the examiner and approval chain

At least two examiners evaluate the thesis using University grading guidance. Final acceptance and grading are decided by the head of the department based on examiner evaluation. The thesis seminar, thesis examination and degree-plan completion are related but separate administrative objects. Keep the examiner-ready manuscript, DTEK1102 completion and HOPS status aligned before the final submission stage.

12. TTDK1308 is the 0 ECTS maturity examination

The thesis category also contains TTDK1308 Degree Qualifying Examination for Master’s Degree, 0 ECTS. Normally the thesis abstract or another suitable thesis part functions as the maturity test. A conditional written-exam route can apply depending on prior degree and Finnish or Swedish educational-language background. Verify your own route rather than copying another student’s submission process.

13. Use DTEK1102 as a research-method checkpoint

DTEK1102 is designed to support the thesis process. Students analyse a previous related thesis, present their own thesis near completion, participate in peer presentations and complete a written research-methods exercise. The planned workload is 135 hours. Use the seminar to test whether your question, method, implementation, evaluation and claimed contribution are aligned before the manuscript becomes difficult to change.

14. Define the evidence before choosing the framework

A Software Engineering thesis may involve requirements, architecture, testing, quality, usability, privacy, security, programming paradigms, developer tooling, repository mining or empirical evaluation. Define what evidence could answer the research question before committing to a framework, language, cloud platform, repository or AI tool. Technology choice should support the question rather than become the thesis simply because it is fashionable.

15. Requirements evidence must preserve stakeholder context

DTEK2089 emphasises stakeholder involvement, value creation, large-scale agile development and innovation. If requirements come from interviews, workshops, product owners or customers, document who contributed, in what role, under what project context and how requirements changed. Evidence from one stakeholder group does not automatically represent all users, markets or future customers.

16. A stated requirement is not proof of value

A requirement records an expressed need, constraint or design target. It does not prove that implementing the feature creates business value, user value or technical improvement. If the thesis claims value, define an additional evaluation such as adoption, task performance, stakeholder judgement, cost reduction or another relevant outcome. Keep requirement elicitation and outcome evaluation as distinct evidence stages.

17. Preserve requirements traceability where it matters

For requirements-centred work, maintain links between source, rationale, status, implementation and relevant verification or validation evidence. If the research question studies change, preserve change history rather than silently replacing earlier requirements. Traceability makes it possible to explain why a feature exists and whether the final implementation actually addresses the requirement used in the thesis argument.

18. Architecture choices need explicit quality attributes

DTEK0072 covers design principles, design patterns, architectural styles, large distributed systems and quality attributes. Do not justify an architecture only because a pattern or framework is popular. State the constraints and quality attributes the architecture is intended to address, such as performance, modifiability, availability, security or maintainability, then collect evidence that is relevant to those specific attributes.

19. Microservices or another pattern do not prove architecture quality

Using microservices, event-driven design, layered architecture or another style is a design decision, not empirical proof of quality. A microservice architecture can introduce network, deployment and operational complexity even when it provides useful modularity. Bound the conclusion to the measured system, workload and quality attributes. Avoid turning a technology label into a claim of superiority.

20. Document important design decisions

Keep architecture diagrams, interfaces and important decision rationale synchronized with the tested implementation. An architecture diagram that describes an earlier prototype can mislead the reader when components, data flows or deployment boundaries later changed. Architecture decision records or an equivalent traceable record can help connect design rationale, implementation revision and evaluation results.

21. Testing evidence exists at multiple levels

DTEK0073 covers testing and quality assurance in agile development, including UI testing, automation, behaviour-driven testing and exploratory approaches. Distinguish unit, integration, system, UI and acceptance evidence where relevant. Passing tests at one level does not imply that other levels are satisfactory. Report what the test suite actually exercises and what important risks remain outside its scope.

22. High coverage does not prove correctness

Coverage is a measurement of exercised code, branches or conditions under a particular metric. It does not show that assertions are correct, inputs are representative or hidden faults are absent. If coverage is used as a thesis outcome, report the metric and tool and pair it with evidence about test design, fault detection or another meaningful quality outcome rather than treating a percentage as correctness.

23. Diagnose test failures instead of counting them blindly

A failing test can indicate a product defect, a defect in the test, an environment problem, unstable external dependency or timing issue. A flaky test can pass and fail without a product change. If test outcomes are part of the analysis, define how failures are classified, how retries are handled and whether non-deterministic tests are excluded, fixed or analysed separately.

24. BDD, exploratory testing and automation answer different questions

Behaviour-driven tests, exploratory testing, UI automation and other approaches provide different evidence. BDD can connect expected behaviour to executable scenarios, exploratory work can expose unexpected risks, and automation can improve repeatability for known checks. Do not compare them solely by test count. Define the quality question and then select measures that make the comparison meaningful.

25. Heuristic UX evaluation is not the same as a user study

DTEK0069 covers usability heuristics, usability testing, quantitative analytics, accessibility and ethical principles. A heuristic evaluation is expert or rule-based evidence. A user test provides evidence from observed participants under a task protocol. Treat them separately. If a thesis combines them, explain what each contributes and why one cannot simply substitute for the other.

26. User studies need bounded samples and declared outcomes

For usability testing, report relevant participant characteristics, recruitment, tasks, interface version and outcome measures. Task completion, error rate, completion time and subjective satisfaction answer different questions. A small convenience sample may be appropriate for exploratory work, but it should not be presented as representing every future user of the software.

27. Accessibility and usability are related but distinct

A product may be generally usable for one participant group while still failing accessibility requirements, and formal accessibility checks do not automatically establish a good overall user experience. If accessibility is central, define the applicable criteria and evaluation process. If usability is central, define tasks and user evidence. Avoid one broad “UX quality” label that hides materially different outcomes.

28. Product analytics can be research data

Usage events, account identifiers, IP addresses, device identifiers, session logs and behavioural traces can be personal data depending on context. Removing names does not automatically anonymise the dataset. Before using production analytics, define lawful access, research purpose, minimisation, retention, protection and publication boundaries. Treat product telemetry as evidence with governance requirements, not merely as convenient logs.

29. Software security needs a defined threat scope

DTEK8102 covers software security, secure programming, vulnerabilities, privacy engineering and GDPR. A thesis should identify the asset, threat, vulnerability class or security property being evaluated. “The software is secure” is normally too broad. A bounded claim such as reduced exposure to a defined vulnerability class under a documented test protocol is much easier to defend.

30. No scanner finding does not prove no vulnerability exists

Static analysis, dynamic testing, dependency scanning and manual review have different visibility and false-positive or false-negative profiles. If a thesis uses security tools, record tool and version, rules, severity handling, software revision and deduplication method. Finding nothing with one tool means only that the tool produced no reported finding under that configuration.

31. Privacy engineering does not automatically prove legal compliance

DTEK8102 introduces GDPR, privacy engineering and anonymisation concepts, but coursework or one technical privacy control does not establish full legal compliance. k-anonymity, l-diversity and differential privacy also have different assumptions and guarantees. State exactly which privacy property is being evaluated and avoid converting a technical experiment into a universal compliance conclusion.

32. Repository-mining studies need a clear unit of analysis

If the thesis studies repositories, define whether each observation is a repository, project, commit, pull request, issue, file or developer. Multiple commits from the same project may not be independent observations. Define inclusion criteria, snapshot date and preprocessing. Otherwise, a large row count can create a misleading impression that the evidence comes from many independent software systems.

33. Prevent temporal and project leakage

Predictive software-engineering studies can leak information when future events influence earlier predictions or when closely related commits from one project appear in both training and test data. If the intended claim concerns new projects, developers or future time periods, split data accordingly. A random row split is not automatically valid for every repository-based prediction problem.

34. Observational software metrics do not establish causality

An association between code complexity, process metrics or test measures and defects does not by itself show that changing the metric will cause defect reduction. Project size, age, language, team composition and domain may confound the association. Phrase observational findings as associations unless the research design supports a stronger causal claim.

35. Performance benchmarks need a reproducible environment

Record the software revision, dependencies, configuration, workload, hardware or virtual environment and measurement procedure. Warm-up, caching, database state and background load can materially change results. Latency, throughput, memory and CPU use are separate outcomes. A microbenchmark speedup should not be described as end-to-end product performance unless the full application path is also evaluated.

36. Practical importance matters alongside statistical results

A statistically significant performance or quality difference may be too small to matter operationally. Report effect magnitude and uncertainty when the design supports them, and relate the difference to the engineering context. Conversely, a practically important effect may be difficult to detect in a tiny sample. Keep statistical evidence and engineering relevance connected but conceptually separate.

37. Advanced Software Project is useful context, not the thesis

DTEK2058 requires professional software-development practices such as version control, project management, unit testing and CI/CD and can produce a substantial software artifact. It remains a separate 5 ECTS project course. A project artifact may become a platform for thesis research, but DTEK1002 still needs its own scientific question, method, evaluation and written argument.

38. Capstone and Lean Digital Business Design are alternatives, not thesis substitutes

The 20 ECTS Common Studies block includes a 10 ECTS choice between DTEK0088 Capstone and DTEK2056 Lean Digital Business Design. Both provide valuable real-world project experience. Neither replaces DTEK1002. If a thesis grows from an earlier project, identify which artifact or problem is reused and what new research question and evidence belong specifically to the thesis.

39. Internship can provide access but does not satisfy DTEK1002

DTEK0045 Internship can provide company context, domain knowledge or access to systems and teams. It is an Other Studies option, not the thesis. If workplace material becomes thesis evidence, establish permission and confidentiality boundaries independently. Employment access does not automatically mean that source code, customer data or internal logs may be published in an academic manuscript.

40. Build a software reproducibility manifest

Preserve the repository commit, branch or tag, dependency lockfiles, compiler or runtime versions, containers or environment details, configuration, dataset or database snapshot, test commands, seeds where relevant and generated output paths. For performance work, include hardware and workload settings. The objective is to let a reviewer trace a headline result back to a precise software and data state.

41. Reproduce one headline result from a clean state

Before freezing the manuscript, regenerate one central benchmark, test-quality table, repository analysis, usability result or security finding from the preserved inputs. Confirm that code revision, query, preprocessing and aggregation match the thesis. If the result changes materially, investigate the cause rather than editing the final table manually to match an earlier draft.

42. Preserve negative and failed results

A failed hypothesis, benchmark that shows no improvement, usability problem or security control that does not work can still be scientifically important. Do not discard relevant runs solely because they weaken the desired conclusion. Report protocol-defined exclusions separately from unfavourable outcomes. This protects the thesis from selective reporting and often produces more useful engineering recommendations.

43. Protect confidential company material

Company software can contain proprietary source code, credentials, architecture diagrams, vulnerability details, customer data and internal telemetry. Decide what can be placed in the public manuscript, what may be shown only through an approved examination route and what must remain protected. Reproducibility can use synthetic fixtures, redacted examples or interface-level descriptions when the original material cannot be disclosed.

44. Use AI under the DTEK1002 disclosure rule

DTEK1002 allows generative AI but requires its use to be clearly documented so the student’s own contribution can be identified and graded. AI-generated code still needs testing and review. AI-generated references or technical claims need source verification. Do not upload protected source code, private logs, credentials, personal data or unpublished company information to an uncontrolled AI service.

45. Separate AI as a research object from AI as an assistant

A thesis may evaluate AI coding tools, generated tests or AI-supported requirements work while the student also uses an AI assistant to write code or prose. Document these roles separately. The research object needs model/version, prompt or task protocol and outcome measures. Assistant use needs disclosure, verification and academic-integrity control. One role does not validate the other.

46. Turnitin checks originality, not software validity

Turnitin is mandatory in the University thesis process, but similarity checking does not validate requirements quality, architecture, test adequacy, usability, security, performance or reproducibility. Treat originality and scientific validity as separate controls. A low similarity score cannot compensate for a weak experiment, and a strong experiment still needs correct attribution and source use.

47. UTUGradu is the institutional submission route

UTUGradu manages higher-degree thesis submission, originality checking, examination, approval, electronic publication and archiving. Before upload, make sure the examiner-ready manuscript matches the final evidence, the company/privacy publication boundary is settled and originality checking is complete. Recheck current UTUGradu operational instructions close to submission because workflow details can change independently of the 30 ECTS course rule.

48. Final Software Engineering checklist

Confirm DTEKOT2427 / programme 99296, the formal 120 ECTS degree, the 80 ECTS Advanced Studies structure, DTEK1002 30 ECTS, TTDK1308 0 ECTS and DTEK1102 5 ECTS Pass/Fail inside Common Studies. Keep DTEK8104 separate. Then audit supervisor/examiner steps, requirements traceability, architecture evidence, testing scope, UX participants, privacy/security, repository splits, benchmark environment, reproducibility, company confidentiality, AI disclosure, Turnitin and UTUGradu. Narrow any claim that exceeds the evidence.