6 ECTS credits
180 h study time

Offer 2 with catalog number 1020372BNR for all students in the 1st semester at a (B) Bachelor - advanced level.

Semester
1st semester
Enrollment based on exam contract
Impossible
Grading method
Grading (scale from 0 to 20)
Can retake in second session
Yes
Enrollment Requirements
Students who want to enroll for this course, must have passed for “Object-oriented Programming”.
Taught in
Dutch
Faculty
Faculty of Sciences and Bioengineering Sciences
Department
Computer Science
Educational team
Coen De Roover (course titular)
Activities and contact hours

26 contact hours Lecture
75 contact hours Seminar, Exercises or Practicals
135 contact hours Independent or External Form of Study
Course Content

Description

Software engineering is defined as the study and application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of large software products. We study the essentials of the software engineering discipline in the lectures, and gain expertise in their application during the exercise sessions. Your newly-gained knowledge and skills will be evaluated through an oral exam about the theory and through a group programming project in which an existing software system has to be extended. Scala is used as the object-oriented programming language. 
 
We begin our exploration with the typical phases in this software engineering process, starting with the initial gathering of customer requirements and ending with the maintenance of the software once it has been delivered. We discuss the drawbacks and advantages of traditional and contemporary models that have been proposed to organise and plan each phase. The remainder of the course discusses the design, implementation and testing phases in detail. The importance of empirical research to debunk or to confirm stubborn myths about what works and what does not work in software engineering is emphasised throughout the course.
 
The design phase is studied first. We use contracts to specify the invariants, pre-conditions, and post-conditions to which the interfaces of sub-designs need to conform. Next, we study the principles that govern the design of high-quality software. These principles are illustrated using the so-called "design patterns" which are patterns of proven solutions for recurring design problems. 
 
Next, we study how to manage the different artefacts produced by a development team. Changes to these artefacts have to be coordinated among developers who might edit them concurrently. We study common branching and merging strategies in distributed version control. Next, we study the setup of pipelines for continuous integration and for continuous delivery which have resulted in more dependable releases and in shorter release cycles. 
 
Testing is the last phase of the software engineering process that we will study. Here, we will investigate techniques for comparing the behavior of a software product against an oracle.  We will discuss how to test individual units in isolation using mocking, as well as how tests can be automatically generated from specifications. Finally, we study metrics that have been proposed to assess the quality of a given test suite. These range from metrics that quantify how much of the application under test is covered by the test suite, to metrics that quantify how well the test suite warns about defects that have been seeded on purpose in the system under test. 
 
 
Table of Contents
 
1. Software Engineering Process
  • Writing Programs versus Engineering Software
  • Process Models: Historical, Plan-driven (RUP), Agile (Scrum)  
  • Empirical Research in Software Engineering Practices
2. Object-Oriented Software Design 
  • Design-by-Contract: Contract Specification (Class Invariants, Method Pre-conditions and Post-conditions), Enforcement, Inheritance
  • Object-Oriented Design Principles: Single-Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
  • Design Patterns: Strategy, State, Decorator, Proxy, Template Method, Factory Method, Composite, Observer, Visitor, Abstract Factory 
3. Professional Software Construction
  • Configuration Management: Version Control Repositories, Branching and Merging Strategies, Artefact Repositories
  • Release Management: Pipelines for Continuous Integration, Continuous Delivery, Continuous Experimentation 
  • Quality Control: Manual and Tool-supported Code Inspection, Code Smells and Refactoring
4. Software Testing
  • Unit and Integration Tests: Oracles, Test Stubs and Mocks, Property-based Testing  
  • Functional Tests: Test Selection, Test Automation, Test Maintenance
  • Test Adequacy Metrics: Coverage (Block, Branch, Edge, Loop, Path, Definition-Use Pairs) and Fault-Seeding Metrics

5. Assessing Implementations

  • Defining Metrics: Measurement Framework, Goal-Question-Metric Approach 
  • Basic Design Metrics: Size and Complexity Metrics, Coupling and Cohesion Metrics, Object-Oriented Metrics
  • Applying Metrics: Overview Pyramid, Design Smells, Polymetric Views 
 

 

Course material
Handbook (Recommended) : Essentials of Software Engineering, Frank Tsui, Orlando Karam, Barbara Bernal, 4th, Jones & Bartlett Learning, 9781284106008, 2016
Digital course material (Recommended) : Slides from lectures, Learning platform
Handbook (Recommended) : Design Patterns, Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, 1st, Addison-Wesley Professional, 9780201633610, 1994
Handbook (Recommended) : Continuous Delivery, Reliable Software Releases through Build, Test, and Deployment Automation, Jez Humble, David Farley, 1st, Addison-Wesley Professional, 9780321601919, 2010
Additional info

  None

Learning Outcomes

General competencies

The learning goals of this course are:
  • Students obtain knowledge about the fundamentals of disciplined and quantifiable approaches to develop, operate, and maintain large-scale software through teams of engineers.
  • Students become skilled at applying instruments to develop such software, to measure the progress of the approach adhered to, and to measure the quality of the resulting software.
  • Students develop attitudes required to bring software projects, to industrial norms, to fruition in groups of engineers.
 
The corresponding learning results are:
w.r.t. knowledge:
- The student can enumerate, describe and motivate the main software engineering process models and methods.
- The student can, for every process model, describe the responsibilities of each professional role within the development team.
- The student can illustrate, through code examples, the situations in which the use of each design pattern is appropriate.
- The student can enumerate, describe and motivate the tools required for the practices of "continuous integration" and "continuous delivery".
- The student can explain the role of the different forms of testing within the software engineering process.
- The student can reproduce the definitions of the process metrics and the test coverage metrics to measure the development progress and the strength of the test suite.
 
w.r.t. applying knowledge:
- The student can independently apply the tools from the practical sessions that support developing software in teams.
 
* w.r.t. analysing:
- The student can recognise variations on and combinations of existing tools for the development of large-scale software in future incarnations.
- The student can recognise the risks associated with the development of large-scale software and mitigate them by recommending an appropriate development process and accompanying tools.
 
* w.r.t. evaluating:
- The student can understand software developed by third-parties and recognise and modify the design patterns instantiated therein. 
- The student can, within a concrete context, evaluate the quality of a given design and of a given software engineering process.
- The student can apply concrete tools for computing process metrics and test metrics and adjust the engineering process where necessary.
 
* w.r.t. creating:
- The student is capable of working in a team that adheres to an agile process model to extend existing software systems according to a customer's requirements.
- The student is able to report orally and in writing about a software project, including the motivation for technical choices as well as policy aspects.
 

Grading

The final grade is composed based on the following categories:
Oral Exam determines 50% of the final mark.
Practical Exam determines 50% of the final mark.

Within the Oral Exam category, the following assignments need to be completed:

  • Oral exam about theory with a relative weight of 100 which comprises 50% of the final mark.

    Note: Oral examination with written preparation about the theory.

Within the Practical Exam category, the following assignments need to be completed:

  • Group project with a relative weight of 100 which comprises 50% of the final mark.

    Note: Group programming project in which an existing software system has to be extended with features as requested by a customer.
    Design, implementation and testing phases need to be executed according to an agile software engineering process. The individual score for this group work is determined by: a) the extent to and the discipline with which the engineering process was adhered to, b) the quality of the resulting software, c) the quality of the written tests, d) a written report on the aforementioned, and e) an oral defence of the individual contribution to the project.Ontwerp, implementatie, en testen moet geschieden volgens een agile software engineering proces. Het individuele cijfer op dit groepswerk wordt bepaald door: a) de mate waarin de ontwikkelingsaanpak gedisciplineerd verliep, b) de kwaliteit van de opgeleverde software, c) de kwaliteit van de gebruikte testen, d) een schriftelijk rapport waarin de voorgaande punten aangesneden worden, en e) een mondelinge verdediging van de individuele bijdrage aan het project.

Additional info regarding evaluation
Students need to obtain a minimal score of 7/20 for the oral exam and of 7/20 for the programming project.
Otherwise, they will receive their lowest score as the end result for this course.
 
An absent mark for one of the exam components implies an absent mark for the overall exam.
 

 

Allowed unsatisfactory mark
The supplementary Teaching and Examination Regulations of your faculty stipulate whether an allowed unsatisfactory mark for this programme unit is permitted.

Academic context

This offer is part of the following study plans:
Bachelor of Computer Science: Default track (only offered in Dutch)