Hintergrund

In den letzten Jahren hat die Bedeutung von Software enorm zugenommen. Beispielhaft dafür ist der Automobilbereich, in dem das Marktvolumen von Software von 25 Mrd. Euro im Jahr 2003 auf vorraussichtlich 133 Mrd. Euro im Jahr 2015 steigen wird [Bal09, S. 11]. Im Allgemeinen sind die Anwendungsgebiete unterschiedlichster Art und haben oft einen großen Einfluss auf unseren Alltag. Softwareprogramme bewältigen immer vielseitigere Funktionalitäten. Dies führt unvermeidlich zum kontinuierlich wachsenden Umfang und wachsender Komplexität von Software. Dies lässt sich u.a. an der steigenden Anzahl der Programmzeilen (sog. Lines of Code, LOC ) erkennen wie z.B. bei dem Linux Kernel; 2005 waren es 6, 62 Mio. LOC und 7 Jahre später bereits 15 Mio. LOC. Angefangen hat der Linux Kernel 1991 mit ca. 10.000 LOC [CKHM12]. Weitere, zwar indirekte Hinweise auf die steigende Komplexität in Software stellen das Wirthsche Gesetz [Wir95] und Mays Gesetz [May05] dar. Erstes besagt, dass die ?Software schneller langsamer wird als Hardware schneller wird ?. Das zweite Gesetz steht im Zusammenhang mit Moores Gesetz und sagt aus, dass ?Software Effizienz sich alle 18 Monate halbiert und damit Moores Gesetz kompensiert? . Der Grund für die Zunahme der Komplexität sind nicht nur die diffizilen funktionalen Anforderungen, sondern auch die Art der Entwicklung. Denn große Softwareprojekte werden häufig in logische Komponenten unterteilt, in mehreren getrennten Unternehmen entwickelt und zum Schluss wieder zusammengefügt. Diese Entwicklungsart fordert höchste Präzision in der zeitlichen Abstimmung und Organisation, um einen positiven Projektverlauf zu ermöglichen und die Zahl der scheiternden Softwareprojekte zu senken. In der Automobilindustrie wie auch der Avionik ist die Anzahl der Zulieferer an den Erstausrüster (OEM, original equipment manufacturer) besonders hoch, weswegen die Koordination der Einzelteile für den OEM nicht nur fachlich, sondern auch zeitlich herausfordernd ist [BFH+10].

Ausführliche Projektplanungs- und steuerungsmethoden unterstützen jeden Softwarehersteller bei der Entwicklung. Diese Hilfsmittel werden häufig während der Projektinitialisierungsphase eingesetzt und beinhalten Plankosten-Berechnungsmodelle wie z.B. CoBRA (Cost Estimation, Benchmarking and Risk Assessment) [BEEB98], CoCoMo I + II (Constructive Cost Model I+II) [Boe81], [DCCB97] oder FPA (Function-Point-Analyse). Ersteres ist eine hybride Methode zur Kostenschätzung, weil es sowohl die Erfahrung und das Wissen von Projektleitern (mittels Fragebogen) als auch Daten vergangener Projekte einschließt. Das CoCoMo I wurde bereits 1981 entwickelt und gehört zu den algorithmischen Kostenmodellen. Es unterscheidet zwischen drei verschiedenen Komplexitätsgraden und benötigt zudem firmenspezifische Parameter zur Kostenkalkulation. Im Gegennsatz zu CoBRA ist bei CoCoMo der Funktionsumfang des Projekts Teil der Berechnung. CoCoMo II (von 1997) verkörpert die Anpassung des Vorgängermodells an moderne Softwareentwicklungsmethodiken. FPA ist an sich kein Schätzmodell, es bewertet lediglich den funktionalen Umfang eines Systems und ist die Grundlage für Aufwandsschätzung oder für Schätzungen von Produktivität und Qualität.

Die genannten Methoden sind nur in der Planungsphase verwendbar. Bei besonders großen und verteilten Projekten kommt es jedoch nicht selten zu außerplanmäßigen Veränderungen, sodass Berechnungsmodelle hilfreich wären, die die aktuellen Werte wie z.B. bisher verbrauchte Kosten oder Produktivität der Mitarbeiter eines laufenden Projekts ermitteln. Darüber hinaus wären auch Lösungen hilfreich, die erfolgreiche wie auch gescheiterte Softwareprojekte mit den laufenden Projekten vergleichen und daraus prognostische Maßzahlen entwickeln. Prognosen bieten vielversprechende Möglichkeiten, denn Prognosen sind anders ausgedrückt das ?Wissen? über den zukünftigen Zustand eines Projekts (wann z.B. 70% des Projekts fertiggestellt sein werden). Das gibt wiederum dem Projektleiter mehr Handlungsspielraum bei der Koordination, sodass er nur bedingt mit überraschenden Ereignissen im Projekt rechnen muss. Zum Beispiel könnte der Projektleiter, in einem laufenden Projekt (je nach Verfügbarkeit und Projektphase) gezielt mehr oder weniger Mitarbeiter einsetzen oder im schlimmsten Fall ein Projekt aus ökonomischen Gründen vorzeitig abbrechen. Das frühzeitige Eingreifen in ein Projekt ist von enormer Bedeutung, denn sollte es zu Verzögerungen kommen, könnte dies zu Zeitdruck führen, der wiederum einen negativen Einfluss auf die Güte der Software nehmen kann. Die sinkende Qualität könnte nachträgliche Änderungen/Verbesserungen und ungewollte Kosten nach sich ziehen, da Änderungen und Fehler je später sie entdeckt werden höhere Kosten verursachen [GH08]. Genauso sind verspätet gelieferte sowie gescheiterte Software große Kostenverursacher, wie beispielsweise ?FISCUS (Föderales Integriertes Standardisiertes Computer-Unterstütztes Steuersystem)?, das Kosten im dreistelligen Millionen Euro Bereich verursachte und nie zum Einsatz kam [Bun12]. Solche Beispiele sollten als teure Lehrbeispiele genommen und in ihrer Anzahl möglichst gering gehalten werden.

Im Anwendungsgebiet des Projektmanagements sind Projektgrößen wie Kosten, Fortschritt, Restlaufzeit, Produktivität oder Entwicklungsdauer sehr abstrakte Daten und können kaum gemessen werden. Erschwerend sind auch die Abhängigkeiten von unterschiedlichen Personen (z.B. Entwicklungsteam oder Projektleiter), verwendeten Technologien oder funktionalen Anforderungen, da diese sich von Unternehmen zu Unternehmen oder zwischen unterschiedlichen Entwicklungsformen stark unterscheiden können. Diese Tatsache macht es unmöglich ein absolut allgemeingültiges Erklärungsmodell zu entwickeln, wie beispielsweise bei strikten physikalischen Größen. Aus diesem Grund könnte die Entwicklung eines Monitoringkonzepts für laufende Projekte vielversprechend sein. Da beim Monitoring vorraussichtliche viele Daten ermittelt werden, liegt es nahe Techniken des Data Minings zu verwenden.

Ein vorteilhaft erscheinendes Merkmal von Data Mining ist, dass es in der Lage ist innerhalb großer Datenmengen neue Muster zu erkennen. In diesem speziellen Fall legen neue Muster eventuell Zusammenhänge zwischen bestimmten Parametern offen wie z.B. besonders produktiven Teambesetzungen oder besonders geeigneter Technologie. Denkbar wären auch Muster die eine bestimmte Handlung/Intervention von Projektleitern erfordern.

Da Data Mining ein sehr großes eigenständiges Forschungsfeld ist, konzentriert sich diese Arbeit nur auf sogenannte ?Anytime Algorithms ? . Diese Algorithmenform liefert nach einer bestimmten Initialisierungsphase und darauffolgend nach jeder Unterbrechung ein brauchbares Ergebnis. Mit jeder neuen Dateneingabe, soll auch das Resultat verbessert werden. Ein einfaches Beispiel für einen Anytime Algorithmus ist bespielsweise die Ermittlung des nächsten Nachbarn eines Referenzpunktes aus einer beliebig großen Punktmenge. Je nach Unterbrechungspunkt können zwei unterschiedliche Punkte der nächste Punkt sein, wobei der zuletzt entdeckte Punkt, der nächste Punkt zum Referenzobjekt sein sollte.

Bezugnehmend auf den Kontext dieser Arbeit, scheinen Anytime Algorithms vom Ansatz her hilfreich bei der Realisierung eines Monitoringkonzepts für laufende Projekte. Es wäre vorstellbar vor Projektbeginn ältere Daten aus ähnlichen Projekten zu verwenden, um erste Schätzungen zu erhalten und anschließend aktuelle Daten einzubeziehen, um den aktuellen Stand und eventuell zuverlässige Prognosen zu bestimmn.

Forschungslücken

In der aktuellen Literatur finden sich viele Studien, die sich mit der Verwendung, Verbesserung und Individualisierung der eingangs kurz beschriebenen Methoden beschäftigen [MCH13] [MPK13] [Tre13]. Dies zeigt, dass diese Methoden trotz des Fortschritts in der Technik und des Programmierens weiterhin genutzt und erweitert werden. Allerdings ist die Anzahl der Forschungsarbeiten, die sich mit der Diskrepanz zwischen Plankosten und resultierenden Gesamtkosten befassen sehr eingeschränkt [CFDBO10], wobei der erste Schritt zur Lösungsannäherung die Ursachenforschung sein sollte.

Darüber hinaus bietet der Fortschritt in der Technik und im Data Mining heutzutage die Möglichkeit große Datenmengen zu generieren und zu verarbeiten. Diese Möglichkeit war zu Zeiten von der Entwicklung von bspw. CoCoMo nicht gegeben. Aus diesem Grund sind die Nachforschungen im Bereich Projektmangement/-planung mit Data Mining Methoden aktueller (wie z.B. [DVMB12]), aber dafür auch begrenzt. Durch die Charakteristiken des Kontexts ist es durchaus sinnvoll die Forschung in dem Bereich zu intensivieren.

Eine weitere Forschungslücke sehen wir im Vergleich von unterschiedlichen Projektverläufen. Da Softwareentwicklungsprojekte meistens aus den gleichen Phasen bestehen, könnten auffällige Eigenschaften von nicht planmäßigen Projektverläufen oder scheiternden Projekten helfen zukünftige Projekte besser zu koordinieren.

Mögliche Aufgaben

Bei den beschriebenen Herausforderungen in der modernen Softwareentwicklung, gilt es eine ausführliche Ursachenforschung zu betreiben, die herausfindet, welche potentiellen Gründe es gibt für die Differenz zwischen Plankosten und Gesamtkosten. Dies soll in erster Linie über eine ausführliche Literaturrecherche geschehen. Mit der gleichen Herangehensweise soll nach bereits existierenden Metriken gesucht werden, die die entsprechenden Eigenschaften erfassen. Dadurch lässt sich eventuell eine Lücke zwischen den Zielen und den verwendeten Metriken aufdecken.

Im nächsten Schritt soll eine praxisorientierte Recherche in realen Softwareunternehmen in Form von Informationsgesprächen geschehen. Insbesondere sollen möglichst Unternehmen befragt werden, die ihre Softwareprodukte nach dem CMMI (Capability Maturity Model Integration) Modell klassifizieren, da die Produkte und Prozesse ab Stufe zwei auf Metriken angewiesen sind. Die etwaigen verwendeten Werkzeuge und die verantwortlichen Mitarbeiter bieten sicherlich hilfreiche Erkenntnisse über Stärken und Schwächen in den aktuellen Methode. Damit wäre es möglich die Ergebnisse der Forschung mit gängigen Methoden der Praxis zu vergleichen.

Aufgrund der Beschaffenheit der abstrakten Daten im Projektmanagement sollen die Möglichkeiten des Data Minings und insbesondere eines Anytime Algorithmus betrachtet werden. Dafür soll wieder mittels Literaturrecherche geprüft werden, welche Vorteile Data Mining bringen kann und inwieweit es bereits in der Domäne des Projektmanagements erforscht ist bzw. verwendet wird.

Die Erstellung eines Monitoringkonzepts mit besonderem Fokus auf Anytime Algorithms soll das zweite große Anliegen dieser Arbeit, neben den Recherchen zum bisherigen Stand in der Forschung und Praxis sein. Die theoretisch entwickelten Methoden/Konzepte sollen auch implementiert und im besten Fall unter realen Bedingungen getestet werden. Da es eventuell problematisch werden kann ausreichend sinnvolle Daten aus echten Softwareprojekten zu erhalten, ist ein Kontextwechsel nicht auszuschließen. Denkbar wäre z.B. der Verlauf von wissenschaftlichen Arbeiten im Studium wie z.B. das Anfertigen von Seminaren oder Abschlussarbeiten. In diesen Prozessen kommt es nicht selten zu Unregelmäßigkeiten, die eventuell durch das Eingreifen des Betreuers verhindert werden könnten.

Literatur

[Bal09] Helmut Balzert. Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, volume 1. Springer DE, 2009.

[BEEB98] Lionel C. Briand, Khaled El Emam, and Frank Bomarius. Cobra: a hybrid method for software cost estimation, benchmarking, and risk assessment. In Proceedings of the 20th international conference on Software engineering, ICSE ?98, pages 390?399, Washington, DC, USA, 1998. IEEE Computer Society.

[BFH+10] Manfred Broy, Martin Feilkas, Markus Herrmannsdoerfer, Stefano Merenda, and Daniel Ratiu. Seamless model-based development: From isolated tools to integrated model engineering environments. Proceedings of the IEEE, 98(4):526?545, 2010.

[Boe81] Barry W. Boehm. An experiment in small-scale application software engineering. Software Engineering, IEEE Transactions on, (5):482?493, 1981.

[Bun12] Bundesrechnungshof. Modernisierung der software für das besteuerungsverfahren in den finanzämtern verzögert sich. website, 2012. Available online at http://www.bundesrechnungshof.de/de/veroeffentlichungen/bemerkungen-jahresberichte/2012/einzelplanbezogene-entwicklung-und-pruefungsergebnisse/bundesministerium-der-finanzen/2012-bemerkungen-nr-18-modernisierung-software; visited on June 9th 2013.

[CFDBO10] Nelly Condori-Fernandez, Maya Daneva, Luigi Buglione, and Olga Ormanjieva. Experimental study using functional size measurement in building estimation models for software project size. In Software Engineering Research, Management and Applications (SERA), 2010 Eighth ACIS International Conference on, pages 276?282. IEEE, 2010.

[CKHM12] Jonathan Corbet, Greg Kroah-Hartman, and Armanda McPherson. Linux kernel development: How fast it is going, who is doing it, what they are doing, and who is sponsoring it. Website, April 2012. Available online at http://www.linuxfoundation.org/publications/linux-foundation; visited on May 2nd 2013.

[DCCB97] Sunita Devnani-Chulani, Bradford Clark, and Barry Boehm. Calibrating the cocomo ii post-architecture model. In Proc. 22nd Ann. Software Eng. Workshop, Software Engineering Laboratory, pages 249?268, 1997.

[DVMB12] Karel Dejaeger, Wouter Verbeke, David Martens, and Bart Baesens. Data mining techniques for software effort estimation: a comparative study. Software Engineering, IEEE Transactions on, 38(2):375?397, 2012.

[GH08] Sven Gembbrys and Joachim Herrmann. Qualitätsmanagement. Haufe, 2008.

[May05] David May. Csp, occam and transputers. In Communicating Sequential Processes. The First 25 Years, pages 75?84. Springer, 2005.

[MCH13] Ekananta Manalif, Luiz F Capretz, and Danny Ho. Software project risk assessment and effort contingency model based on cocomo cost factors. Journal of Computations & Modelling, 3(1):113?132, 2013.

[MPK13] Ashita Malik, Varun Pandey, and Anupama Kaushik. An analysis of fuzzy approaches for cocomo ii. International Journal of Intelligent Systems and Applications (IJISA), 5(5):68, 2013.

[Tre13] Adam Trendowicz. Why Software Effort Estimation? Springer Berlin Heidelberg, Berlin, Heidelberg, 2013.

[Wir95] Niklaus Wirth. A plea for lean software. Computer, 28(2):64?68, 1995.