Software Engineering (Autumn 2021)

Abstract

The course introduces the organization of and activities in professional software engineering. Starting with the introduction of different life cycle models, the course then delves into software project management, delving in particular into agile development. Further, the course introduces the students to Requirements Engineering, Object-Oriented Analysis and Design, configuration management and software quality management. Special emphasis is put on how the choice and organisation of the software development process influences software product qualities and the software quality-in-use.

The course is taught as a project course: In lieu of exercises, the students will apply the methods, techniques and tools in a small project.

Description

Software engineering is the branch of computer science that addresses the organisation of and the methods, tools and techniques used in the whole software lifecycle: how do we get from an idea for some IT support to a piece of software used by the intended beneficiaries.

Modern software products are not developed by individual programmers, but by entire teams, which sometimes are very large. Collaboration both within the team and with the intended users is therefore at the core of software engineering.

The course introduces students to professional software engineering, enabling them to competently act as a project member as well as to take over management responsibility for minor projects. Special emphasis is put on how the choice and organisation of the software development process influences software product qualities and the software quality-in-use.

The course brings together a combination of central themes in software engineering. Specifically, it introduces students to:

• a process-based perspective on software engineering
• different ways of organizing the software engineering (development models)
• supporting process areas, such as project management, configuration management, and quality management
• object-oriented analysis and design, leading up to requirements specification and architectural design.
• different quality dimensions, such as software in use qualities, software product qualities, and how to address them.

Note that there will be NO coding activities in the course.

Formal prerequisites

The student must always meet the admission requirements of the IT University. 

Intended learning outcomes

After the course, the student should be able to:

• Characterise the organizational context in which professional software development takes place.
• Discuss major software process models and motivate the choice of a development approach based on project context.
• Discuss and apply major activities of project management, quality assurance and configuration management.
• Recognize the purpose of software analysis and design and develop basic models in UML to this end for a given case project..
• Account for the purpose requirements specifications, test specifications, and architectural design, and develop such specifications in the context of a given case project.
• Argue the importance of different quality dimensions in professional software development and reflect how they influence the choice of software processes, methods and tools.

Learning activities

The lectures will introduce different approaches, methods and tools for software engineering. Few exercises are considered to complement some of the lecture materials. The learning activities include two main components: 

1. Project Work: You will apply obtained knowledge from the course on a realistic case in groups of 6-8 students (all from SD program) acting as a project team. Your task is to explore the case, perform analysis and develop a set of documents that would typically be subject to a pre-study or – when applying an iterative or evolutionary process – the early iteration cycles or sprints. The set of documents should contain: 

• a project charter, including also:
• an initial analysis, including class diagrams and use case diagrams;
• a mock-up of the product to be developed; 
  
• a requirements specification; 
• a system test specification; 
• an overall architecture specification; 

This set of documents is referred to as the portfolio that you have to hand in to be able to take the exam. Partial hand-ins are submitted in two tollgates during the semester. The hand-ins are constituting the base for a review and evaluation. 

Each group of students will be assigned a supervisor (one of teaching team members) and provided supervision meetings. 

2. Presentation: Each group is expected to present part of their project at least once. 

Mandatory activities

The participation in at least 80% of the supervision meetings is mandatory. 

The submissions of the partial intermediate portfolios following the announcement and deadlines specified on the learnIT teaching platform constitute another mandatory course element. If the increment of the portfolio handed-in is not of acceptable quality, the group has 1 week to complement and improve it based on the feedback received. 

Students who didn´t participate in the group work can´t take the ordinary exam. To gain access to the re-exam those students must submit a portfolio. The case for the portfolio will be agreed with the course responsible by the end of the course. The portfolio must be submitted 2½ weeks after. The requirements for this portfolio are the same as for the ordinary portfolio, but it must be handed in as one. No supervision will be offered during this period. The portfolio must be made in groups assigned by the course responsible. If only one student is assigned to the portfolio work, he/she works alone. If the portfolio can´t be approved by the course responsible, the students have one week to complement it. Once the portfolio is approved, the student can take the re-exam.

The student will receive the grade NA (not approved) at the ordinary exam, if the mandatory activities are not approved and the student will use an exam attempt.

Course literature

Ian Sommerville, Software Engineering, 10th edition, Adisson Wesley 2015.

L. Mathiassen, A. Munk-Madsen, P.A. Nielsen and J. Stage. Object Oriented Analysis and Design. 2. edition. 2018.

Student Activity Budget

Estimated distribution of learning activities for the typical student

• Preparation for lectures and exercises: 10%
• Lectures: 15%
• Exercises: 15%
• Assignments: 10%
• Project work, supervision included: 30%
• Exam with preparation: 20%

Ordinary exam

Exam type:
D: Submission of written work with following oral, External (7-point scale)
Exam variation:
D2G: Submission for groups with following oral exam supplemented by the submission. Shared responsibility for the report.

reexam

Exam type:
D: Submission of written work with following oral, External (7-point scale)
Exam variation:
D2G: Submission for groups with following oral exam supplemented by the submission. Shared responsibility for the report.

Time and date