Team Member

Dr. Martin Feilkas

… is founder and managing partner of CQSE GmbH. He studied Computer Science at the Technische Universität München. He worked as a researcher at the chair for Software & Systems Engineering and led the Competence Center for Embedded Systems. He received a PhD for his work on program comprehension and the analysis of design constraints in software.

  • +49 space::176 space::10150005
  • @feilkas

Blog Posts

My colleague Martin already explained our journey to Git in his blog post. I would like to shed light on our motivation for that change and the experiences we made from a more methodological point of view. Furthermore, I would like to point out that we did not only exchange a versioning system but also changed our development process in a severe manner.


In this post I discuss the history of software quality analysis approaches and tools that focus on ensuring internal quality (maintainability, comprehensibility etc.). I will distinguish different generations of architectures of quality analysis tools and the quality assurance mindset behind them. This categorizations allows of course no clear cut. Furthermore, as managing partner of CQSE as a tool provider my point of view is certainly biased. So please regard this post as a very personal view onto the evolution of software quality analysis methods. Thus, the three generations I distinguish represent our own learning curve as a company (since 2009) and as researchers (since 2005 at TU Munich) in this area.

When we started developing Teamscale I was often asked by customers, former colleagues and friends why we are developing a new software quality analysis tool as several already existed (including our own tool ConQAT or the even more


Continuous Integration (CI) is one of the dominating terms when talking about software engineering methods with developers. The initial idea behind continuous integration was merging the changes performed on developers’ working copies several times a day, in order to prevent integration problems. By keeping the changes since the last integration small, new integration problems are much easier to analyze and to solve and thus the »integration hell« becomes less scary.


It is interesting to see the various organizational settings where software development takes place. Having a look at the different kinds of companies we have been working with in the last years reveals the many different settings: Completely internal development, internal development in a mix of internal and external developers, external development with internal project management/architects, completely outsourced development only providing a set of requirements to the supplier. Furthermore, throughout the lifecycle of a system, these settings are often changed: systems are handed over from an external initial development to internal maintenance or vice versa. Thus, a pure and stable development team developing and maintaining a system is rather an exception than the usual case.


In many domains software is a highly critical part of the products, especially in automotive and avionics systems, in medical equipment, and in military systems—software failures may cause severe damage to machines or even cost human lives. Thus, it is broadly accepted that software quality is the key to developing safe systems. Most people out there have deep trust in the quality of the software controlling the cars they drive, the planes they fly with, and the equipment that is keeping them alive during medical surgery. To be honest, most of this software works really well. However, when looking behind the curtains, I sometimes wonder why.

Safety critical systems need to be certified and thus undergo rigorous qualification processes. There are different kinds of standards, defining quality and safety regulations for different kinds of applications. Having a closer look reveals that most of these standards state that certain kinds of activities must be performed—usually


As the post ‘Tools Do Not Improve Quality’ by my colleague Nils already destroyed the naive dream of simply installing a tool and get all maintenance nightmare healed over night, I would like to address a follow-up question in this post: If tools are not sufficient, how can we improve quality then?

Several years ago when we still were blue-eyed researchers on software quality, we started out developing different kinds of quality analyses in the context of our tool ConQAT. We worked hard on eliminating false positives and achieved highly precise analyses at the end. We thought developers will love adressing each issue these tools emit. When we presented analysis results to developers, they usually agreed on the relevance of the deficits we identified. Thus, we integrated our tools into every nightly build we could find at our partners. However,


During our daily work as consultants for software quality, as auditors of different kinds of software systems and in our role as quality engineers in software engineering projects, we have the opportunity to see a large variety of software development organizations. We encounter a huge amount of different systems from different domains, written in different languages and using various technologies. But most importantly, we talk to many many people that face the challenge of developing and maintaining software day by day. As a result, we receive a big treasure of experiences, insights, anecdotes and war stories on how to (and how better not to) develop software.



Martin Feilkas:

Der interne Verfall von Software oder wie entschärft man eine Zeitbombe?

Vortrag bei Softwareforum Leipzig, 2015.

Martin Feilkas:

Evolving Codebases: How and why to Achieve Long-Term Software Quality?

Vortrag bei Vanlanthen, 2015.

Martin Feilkas:

High Quality Software and ugly Code.

Vortrag beim Euroforum, 2015.

Kai Schüler, Martin Feilkas:

Managing Product Quality in Complex Software Development Projects.

Talk at embedded world Conference 2015, 2015.

Martin Feilkas:

Haben wir unsere Änderungen eigentlich getestet? Möglichkeiten und Grenzen von Test-Gap Analyse.

Talk at the Softwareforen Leipzig, User Group Softwaretest und Qualitätssicherung, 2013.

Martin Feilkas:

Hochqualitative Software als Basis für korrekte Systeme: Schnappschüsse aus der Praxis.

Talk at Innovationsforum Embedded Systems, 2012.

Martin Feilkas:

Kontinuierliches Qualitäts-Controlling modellbasiert entwickelter Software.

Talk at Euroforum 2011, 2011.

Martin Feilkas:

The Loss of Architectural Knowledge during System Evolution: An Industrial Case Study.

Talk at the 17th IEEE International Conference on Program Comprehension (ICPC’09), 2009.

Martin Feilkas:

Ensuring Well-Behaved Usage of APIs through Syntactic Constraints.

Talk at International Conference on Program Comprehension, 2008.

Martin Feilkas:

Sprach- und bibliotheksbasierte Abstraktion.

Talk at Kolloquium Programmiersprachen und Grundlagen der Programmierung, 2007.

Martin Feilkas:

How to represent Models, Languages and Transformations?

Talk at the 6th OOPSLA Workshop on Domain-Specific Modeling, 2006.


Elmar Jürgens, Martin Feilkas, Markus Herrmannsdoerfer, Florian Deissenboeck, Rudolf Vaas, Karl-Heinz Prommer:

Feature Profiling for Evolving Systems.

Proceedings of the 19th IEEE International Conference on Program Comprehension (ICPC’11), 2011.

Elmar Jürgens, Benjamin Hummel, Florian Deissenboeck, Martin Feilkas, Christian Schlögel, Andreas Wübbeke:

Regression Test Selection of Manual System Tests in Practice.

Proceedings of the 15th European Conference on Software Maintenance and Reengineering (CSMR’11), 2011.

Sebastian Eder, Andreas Vogelsang, Martin Feilkas:

Seamless Modeling of an Automation Example Using the SPES Methodology.

Report TUM-I1110. Technische Universität München, 2011.

Elmar Juergens, Florian Deissenboeck, Martin Feilkas, Benjamin Hummel, Bernhard Schaetz, Stefan Wagner, Christoph Domann, Jonathan Streit:

Can Clone Detection Support Quality Assessments of Requirements Specifications?

Proceedings of the 32nd International Conference on Software Engineering (ICSE’10), 2010.

Manfred Broy, Martin Feilkas, Markus Herrmannsdoerfer, Stefano Merenda, Daniel Ratiu:

Seamless Model-Based Development: From Isolated Tools to Integrated Model Engineering Environments.

Proceedings of the IEEE, Vol. 98, 2010.

Martin Feilkas, Andreas Fleischmann, Florian Hölzl, Christian Pfaller, Kathrin Scheidemann, Maria Spichkova, David Trachtenherz:

A Top-Down Methodology for the Development of Automotive Software.

Report TUM-I0902. Technische Universität München, 2009.

Martin Feilkas, Daniel Ratiu, Elmar Jürgens:

The loss of architectural knowledge during system evolution: An industrial case study.

Proceedings of the 17th IEEE International Conference on Program Comprehension (ICPC’09), 2009.

Martin Feilkas, Daniel Ratiu:

Ensuring Well-Behaved Usage of APIs through Syntactic Constraints.

Proceedings of the 16th IEEE International Conference on Program Comprehension (ICPC’08), 2008.

Daniel Ratiu, Martin Feilkas, Jan Jürjens:

Extracting Domain Ontologies from Domain Specific APIs.

Proceedings of the 12th European Conference on Software Maintenance and Reengineering (CSMR’08), 2008.

Stefan Wagner, Florian Deißenböck, Martin Feilkas, Elmar Jürgens:

Software-Qualitätsmodelle in der Praxis: Erfahrungen mit aktivitätenbasierten Modellen.

In Proceedings of Workshop Software-Qualitätsmodellierung und -bewertung (SQMB ’08), 2008.

Daniel Raţiu, Martin Feilkas, Florian Deissenboeck, Radu Marinescu, Jan Jürjens:

Towards a Repository of Common Programming Technologies Knowledge.

Proceedings of the International Workshop on Semantic Technologies in System Maintenance, 2008.

Manfred Broy, Martin Feilkas, Johannes Grünbauer, Alexander Gruler, Alexander Harhurin, Judith Hartmann, Birgit Penzenstadler, Bernhard Schätz, Doris Wild:

Umfassendes Architekturmodell für das Engineering eingebetteter Software-intensiver Systeme.

Report TUM-I0816. Technische Universität München, 2008.

Martin Feilkas:

Sprach- und bibliotheksbasierte Abstraktion.

Kolloquium Programmiersprachen und Grundlagen der Programmierung, 2007.

Martin Feilkas:

How to represent Models, Languages and Transformations?

Proceedings of the 6th OOPSLA Workshop on Domain-Specific Modeling, 2006.