Wartung vs. Change Requests vs. Weiterentwicklungen

-
Während der Softwarewartung kommt es in den allermeisten Fällen auch zu fachlichen Änderungen oder Weiterentwicklungen. Diese werden unter dem Begriff Änderungsanforderungen bzw Change Request subsumiert, aber der Umgang mit ihnen in den seltensten Fällen in Wartungsverträgen behandelt. Dabei haben Fragen wie beispielsweise "Wer bezahlt / wartet diese Change Requests?" einen enormen Einfluss auf den Erfolg der Wartung einer Software.

Bei Standardsoftware sind Change Requests technisch und juristisch problematisch und gehören daher unbedingt frühzeitig bedacht und im Wartungsvertrag behandelt:

  • Spezifisch vs. allgemein sinnvoll: Es gibt Change Requests, die sind für alle Kunden einer Standardsoftware potentiell sinnvoll (bzw. haben zumindest keine negativen Auswirkungen) - und solche, die nur für einen oder wenige Käufer der Standardsoftware Sinn machen. Letztere müssen technisch derart vom Rest der Software getrennt werden, dass sie nur bei den Kunden bzw. Benutzern der Software wirksam werden, für die sie sinnvoll sind. Das wird leider oft mit Techniken wie Feature Flags, Branches oder Konfigurationen gemacht, die die Komplexität des Produktes steigern und daher ungeheuer negative Auswirkungen auf die Wartbarkeit der Software haben. → Change Requests, die nicht für alle Kunden sinnvoll sind, sollten in Plugins ausgelagert werden, damit eine unabhägige Weiterentwicklung des Kernproduktes gewährleistet wird (und Plugins muss die Software erstmal architektonisch unterstützen).
  • Einflussnahme: Nicht jeder Change Request ist wie gesagt für jeden Kunden sinnvoll, nicht jede Weiterentwicklung ist für die Standardsoftwaret sinnvoll. Damit rechtzeitig erkannt wird, welche wie oben beschrieben vom Rest der Software getrennt werden, ist eine diesbezügliche Einflussnahme für Kunden und somit auch den Hersteller der Software sinnvoll. → Geplante Change Requests und Weiterentwicklungen sollten langfristig für die Kunden verständlich vorangekündigt (z.B. im Rahmen einer Roadmap) und diesbezüglich Feedback der Kunden eingeholt werden.
  • Rechte: Wer Softwareentwicklungen beauftragt erwirbt in der Regel die Rechte an diesen. Das ist bei Change Requests von Standardsoftware aber nicht sinnvoll. Sämtliche Rechte (u.A. das Verwertungsrecht und der Sourcecode) sollten ausschließlich beim Standardsoftwarehersteller verbleiben, dafür aber dürfen die Umsetzungskosten eines Change Requests auch nicht (wie leider oft üblich) 1:1 an den Auftraggeber verrechnet werden oder für die Change Requests extra Wartungskosten verlangt werden. → Kosten und Rechte an Change Requests sollten frühzeitig derart vereinbart werden, dass beiden Parteien klar ist was diesbezüglich auf sie zukommt.

Für alle Arten von Software gilt, dass Change Requests und Weiterentwicklungen einen enormen Einfluss auf die Wartung haben, und der Umgang mit ihnen somit idealerweise bereits von Beginn an vertraglich festgelegt wird:

  • Pflichten: Wer Software wartet, gewährleistet und haftet auch für Mängel an der Software - z.B. auch Mängel hinsichtlich des Standes der Technik. Zur Wartung gehört aber auch die adaptive Wartung, die sicherstellt, dass die Software immer an veränderte Bedingungen der Umgebung - wie beispielsweise auch neue Systemanforderungen - angepasst wird. Letzteres ist den meisten IT-Firmen nicht bekannt, üblicherweise werden Change Requests und Weiterentwicklungen fälschlicherweise1 nicht in die Softwarewartung eingerechnet. → Es sollte vereinbart werden, wie und ob adaptive Wartung, insbesondere neue technische und fachliche Anforderungen, finanziell abgegolten wird.
  • Umsetzungskosten: Aufwände und Kosten für Change Requests können aus unterschiedlichen Gründen explodieren. Dutzende Personentage für triviale Änderungen, die bei Neuentwicklung nur wenige Stunden Aufwand benötigt hätten, sind keine Seltenheit. In den allermeisten Fällen liegt das an extrem hoher Komplexität von Architektur, Code, Dokumentation oder Prozessen - alles ein Zeichen dafür dass nicht gemäß Stand der Technik gearbeitet wurde und wird. → Es sollte frühzeitig vereinbart werden, wie derartiges verhindert, verbessert und finanziell abgegolten wird.
  • Wartungskosten: Die Wartungsaufwände und Kosten können durch Change Requests und insbesondere Weiterentwicklungen beeinflusst werden. Typischerweise in Relation zu der durch sie veränderten Größe und Komplexität der Software (und nicht wie oft verrechnet in Relation zu den Umsetzungsaufwänden). → Es sollte frühzeitig vereinbart werden, ob und wie veränderte Wartungsaufwände errechnet und finanziell abgegolten werden.

Fazit: Der Umgang mit Change Requests und Weiterentwicklungen während der Wartung sollte unbedingt schon lange vor der Abnahme einer Software vereinbart werden. Idealerweise schon vor der Entwicklung der Software, da er einen nicht zu unterschätzenden Einfluss auf die Architektur der Software haben kann.

Weitere typische Mängel von Wartungsverträgen siehe Was fehlt den meisten Wartungsverträgen?

___
1. vgl. International Organization for Standardization (Hrsg.): International Standard ISO/IEC/IEEE 14764 Software engineering - Software life cycle processes - Maintenance. 2022, Introduction, vi: “This maintenance effort also covers software improvements needed to meet new or modified user requirements.” bzw. S.3: “enhancement - software change that addresses and implements a new requirement. There are three types of software enhancements: adaptive, perfective and additive.”↩
CC BY-NC-SA 3.0 AT Sebastian Dietrich, e-movimento