… ist Mitgründer und geschäftsführender Gesellschafter der CQSE GmbH. Er hat Informatik an der Technischen Universität München studiert. Er arbeitete als Forscher am Lehrstuhl für Software & Systems Engineering und leitete dort das Kompetenzzentrum für Eingebettete Systeme. Er promovierte im Bereich Programmverstehen und der Analyse von Entwurfsvorgaben in Softwaresystemen.
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.
Posted on 08.07.2015 by Dr. Martin Feilkas
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
Posted on 07.04.2015 by Dr. Martin Feilkas
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.
Posted on 02.04.2014 by Dr. Martin Feilkas
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.
Der interne Verfall von Software oder wie entschärft man eine Zeitbombe?
Vortrag bei Softwareforum Leipzig, 2015.
Evolving Codebases: How and why to Achieve Long-Term Software Quality?
Vortrag bei Vanlanthen, 2015.
Managing Product Quality in Complex Software Development Projects.
Talk at embedded world Conference 2015, 2015.
Talk at the Softwareforen Leipzig, User Group Softwaretest und Qualitätssicherung, 2013.
Hochqualitative Software als Basis für korrekte Systeme: Schnappschüsse aus der Praxis.
Talk at Innovationsforum Embedded Systems, 2012.
Kontinuierliches Qualitäts-Controlling modellbasiert entwickelter Software.
Talk at Euroforum 2011, 2011.
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.
Ensuring Well-Behaved Usage of APIs through Syntactic Constraints.
Talk at International Conference on Program Comprehension, 2008.
Sprach- und bibliotheksbasierte Abstraktion.
Talk at Kolloquium Programmiersprachen und Grundlagen der Programmierung, 2007.
embedded world Conference 2015, 2015.
Proceedings of the 19th IEEE International Conference on Program Comprehension (ICPC’11), 2011.
Proceedings of the 15th European Conference on Software Maintenance and Reengineering (CSMR’11), 2011.
Report TUM-I1110. Technische Universität München, 2011.
Proceedings of the 32nd International Conference on Software Engineering (ICSE’10), 2010.
Proceedings of the IEEE, Vol. 98, 2010.
Report TUM-I0902. Technische Universität München, 2009.
Proceedings of the 17th IEEE International Conference on Program Comprehension (ICPC’09), 2009.
Proceedings of the 16th IEEE International Conference on Program Comprehension (ICPC’08), 2008.
Proceedings of the 12th European Conference on Software Maintenance and Reengineering (CSMR’08), 2008.
In Proceedings of Workshop Software-Qualitätsmodellierung und -bewertung (SQMB ’08), 2008.
Proceedings of SE’08, 2008.
Proceedings of the International Workshop on Semantic Technologies in System Maintenance, 2008.
Report TUM-I0816. Technische Universität München, 2008.
Sprach- und bibliotheksbasierte Abstraktion.
Kolloquium Programmiersprachen und Grundlagen der Programmierung, 2007.
Proceedings of the 6th OOPSLA Workshop on Domain-Specific Modeling, 2006.