Hide menu

Course Information


Warmly welcome to this introduction course in software engineering. Software engineering is a broad subject, covering many interesting aspects. But, what does software engineering actually mean? The following definition is taken from IEEE 100 (The Authoritative Dictionary of IEEE Standards Terms):

"The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software."

Hence, basically software engineering can be seen as systematic approach to create and maintain software in the "right way". This way is of course subjective, but learnings from last 60 years of experience have given us tools and methods that enable us to produce better software and avoid common mistakes.

In this course, we will give an overview of this large subject, by explaining well established knowledge and best practice (the theory) and combining this with practical parts that give the student "hands-on" experience of the subject (the project).

Goal of the course

The main goal of this course is to prepare the student for professional work in the industry, as a team leader, project manager, software engineer, test engineer etc. in the software area. This includes large-scale software development, where other issues than pure technical challenges are vital, e.g. resource constrains, customer relationships, and quality aspects. More precisely, this is summarized with the following course goals:
  • TDDC88 and TDDC93: To give a sound theoretical foundation of software engineering principles. This includes the areas of requirements, design and architecture, testing, planning and processes, and quality factors. The intended learning outcomes are that the student at the end of the course can:
      • explain and exemplify basic concepts in the area of large-scale software engineering.
      • explain how to specify, model, implement and test a software system.
      • explain how to execute a software development project.
  • TDDC88 only: To gain basic experience of being part of a larger software engineering project. This includes practical and pragmatic experience of for example project planning, requirements analysis, group communication, structured documentation, software design, implementation, system integration and testing. In particular, the focus is to learn and reflect upon organization, process, and communication challenges in a software engineering project. The intended learning outcomes are that the student at the end of the course can:
      • specify, model, implement, and test a smaller software system
      • define, plan and execute a development project in a group of about students, where several smaller groups can be formed.
      • elicit, analyze and document experience from the own development project
      • use basic functions from a selection of tools used in software industry

Parts of the course

The TDDC88 course is divided into three parts: theory, project and laboratory exercises. For TDDC93, only the theory part is applicable.

Theory

The lectures give a broad overview of important aspects and best practice within software engineering. Subjects such as project management, requirements engineering, architecture styles, design patterns, configuration management, software quality, software life-cycles, and testing are covered. For more information, see the following link:

Project

The project is organized in a company - customer scenario, where the students get hands-on experience on how it is to work in medium sized project (a simulated company with approx. 25-30 students). Practical experience covered in the theory part will be explored, such as challenges with specifying requirements, handling project deadlines, managing and planning resources, designing a software architecture, delivering and maintaining a functional system within stated time and budget frames. For more detailed information about the project, see the following link:

Laboratory Exercises

The goal of the laboratory exercises is to make the student familiar with and get some practical experience from a number of tools and techniques, which will be useful in the project work. This includes for example UML modeling tools, version handling systems, Eclipse, and fundamental debugging.

Examination

All three parts are examined separately. The theory part ends with a written exam, the project parts include several separate group and individual examinations, and the laboratory exercises are examined both orally and via hand in exercises to the lab assistant.

  • For detailed information about the examination, please the the examination page.

Course improvements and evaluation

You are more than welcome to communicate and give all kinds of feedback regarding the course, both during the course and after. The simplest way is to send me (Kristian Sandahl) an e-mail.

If you have more detailed things to discuss, I would be glad to sit down over a cup of coffee and discuss the matters.

At the lecture on September 14, we will have a so called Muddy card evaluation. You will here be asked to anonymously write down pros and cons about the course. I will collect the responses and publish the most frequently occurring comments on the web. By following this procedure, we can react on your feedback during the course and hopefully resolve minor issues in a short time frame.

Course language

The course is given in English because there are both exchange students and international master students among the participants. In exceptional cases, the lectures will be given in Swedish. In such a cases, this will be clearly announced in advance on the course page.

Furthermore, English should be used by all students both orally at presentation and for all written documentation.

Copy-paste and cheating

We take very seriously on cheating attempts, which includes copy-paste of any texts or code that is not produced within the group. By group we mean companies in the project, lab groups, and groups of students submitting exercises to the theory course. Note that communication between teams within a company in the project and reuse of third party software components are encouraged, as long as it fits into the stated project requirements. However, if any information is reused, it must be properly quoted and cited, so that we know exactly what you have produced.

Any discovered attempts of cheating will be directly reported to the discipline committee.


Page responsible: Kristian Sandahl
Last updated: 2012-08-17