links 94
E
s gibt Entscheidungen, denen Ent-
wickler in Softwareprojekten im-
mer wieder begegnen. Ein bekann-
tes Beispie...
95rechts
lich bietet C++ bereits eine Standardklas-
se für Zeichenketten an. Allerdings spie-
len hier gleich mehrere Gesi...
links 96
kauf bewährter Implementierungen an.
Bei produkt- oder domänenspezifischen
Artefakten hingegen ist im Regelfall d...
links 98
OSS-Gemeinde etwas zurückzugeben?
Existiert gar eine unternehmensweite Stra-
tegie zum Umgang mit dem Phänomen
Op...
99rechts
fügbar, um es erfolgreich in das neue Pro-
dukt zu integrieren?
In vielen Fällen sind die Urheber des
zur Wiederv...
Nächste SlideShare
Wird geladen in …5
×

Rad-Fragen (iX-Artikel von Daniel Mölle)

591 Aufrufe

Veröffentlicht am

Bei der Planung eines neuen Softwareprojekts taucht häufig die Frage auf, ob man alle Komponenten neu entwickeln, vorhandene wiederverwenden oder zusätliche Software kaufen soll.
In allen Fällen-Open Source-Software eingeschlossen - müssen auch versteckte Kosten bei der Planung berücksichtigt werden.
Leitfäden in Bezug auf "Reuse, Make or Buy" helfen, Stolperfallen zu erkennen und die richtige Entscheidung für das eigene Projekt zu treffen.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
591
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Rad-Fragen (iX-Artikel von Daniel Mölle)

  1. 1. links 94 E s gibt Entscheidungen, denen Ent- wickler in Softwareprojekten im- mer wieder begegnen. Ein bekann- tes Beispiel ist „Make or Buy?“ – also die Frage, ob man ein Softwareartefakt (etwa eine Komponente, eine Bibliothek oder ein Werkzeug) im eigenen Haus entwickeln oder von der Stange kaufen will. Ähnlich häufig stellt sich die Frage, ob sich ein existierendes Stück Software nicht einfach wiederverwenden lässt. Dieser Artikel untersucht Vor- und Nach- teile der drei Varianten „Reuse, Make or Buy“. Oberflächlich betrachtet scheint die Antwort trivial zu sein: Wenn es das be- nötigte Softwareartefakt schon gibt, wa- rum sollte man es noch einmal program- mieren? Eine Neuentwicklung ist kost- spielig und birgt Risiken, während eine Wiederverwendung oder ein Zukauf kal- kulierbar scheinen. Dieser naheliegende Schluss äußert sich in der gern zitierten Phrase „Wir müssen das Rad nicht neu erfinden“. Das Bild von der Erfindung des Rades ist allerdings keine glückliche Wahl. Hier geht es nämlich nicht um die Erfindung, sondern um die Entwicklung. Und wäh- rend die grundsätzliche Idee eines Rades in der Tat nur einmal erdacht werden musste, hat die Menschheit für verschie- dene Einsatzzwecke immer wieder neue Räder entwickeln müssen. Allein die Ge- schichte des Automobilbaus ist voll von speziell entworfenen Rädern für spezifi- sche Fahrzeugtypen oder Umweltbedin- gungen. Nicht nur die Funktion entscheidet Nicht anders verhält es sich mit Soft- wareartefakten. Ob sich eine existierende Implementierung in einem neuen Kontext einsetzen lässt, hängt von vielerlei As- pekten ab. Ein häufig zu beobachtender Irrtum besteht darin, ein existierendes Artefakt allein bezüglich seiner Funktionalität zu beurteilen. Allerdings klammert eine sol- che Bewertung sowohl die nichtfunktio- nalen Anforderungen als auch sämtliche Randbedingungen aus, beispielsweise re- gulatorische Vorgaben. Hat eine beste- hende Implementierung zum Beispiel ei- nen so hohen Ressourcenbedarf oder ist so schlecht testbar, dass ein Projektteam sie im neuen Umfeld unmöglich einset- zen kann, ist sie völlig wertlos. Diese Problematik soll ein plastisches Minimalbeispiel veranschaulichen: Eine in C++ umzusetzende Firmware für ein sicherheitsgerichtetes System (etwa eine Regelungsanlage im Eisenbahnumfeld oder ein Medizinprodukt) benötigt eine String-Klasse. Es mag zunächst überraschen, dass Entwickler sich überhaupt mit der Pro- grammierung solch grundlegender Soft- wareartefakte befassen sollten – schließ- 94 iX 6/2015 REPORT | SOFTWAREENTWICKLUNG Reuse, Make or Buy – Hilfen zur Entscheidungsfindung Rad-Fragen Daniel Mölle Falsche Entscheidungen in der Planung eines Softwareprojekts können teuer werden. Was auf den ersten Blick als offensicht- lich richtig erscheint, hat möglicherweise unerwünschte Konse- quenzen. Wer vor der Entscheidung steht, ein Softwareartefakt neu zu entwickeln, ein vorhandenes wiederzuverwenden oder Software neu zu kaufen, muss versteckte Kosten und andere Stolpersteine berücksichtigen. -TRACT ⚫ Bei der Planung eines neuen Softwareprojekts taucht häufig die Frage auf, ob man alle Komponenten neu entwickeln, vorhandene wiederverwenden oder zusätzliche Software kaufen soll. ⚫ In allen Fällen – Open-Source-Software eingeschlossen – müssen auch versteckte Kosten bei der Planung berücksichtigt werden. ⚫ Leitfäden in Bezug auf „Reuse, Make or Buy“ helfen, Stolperfallen zu erkennen und die richtige Entscheidung für das eigene Projekt zu treffen. ix.0615.094-099 15.05.15 08:33 Seite 94 © Copyright by Heise Medien
  2. 2. 95rechts lich bietet C++ bereits eine Standardklas- se für Zeichenketten an. Allerdings spie- len hier gleich mehrere Gesichtspunkte eine gewichtige Rolle. In sicherheitskritischen Systemen ist es üblich, jegliche Form dynamischer Speicherzuweisung zur Laufzeit zu ver- bieten. Weil es nicht passieren darf, dass das System im Betrieb in eine Out-of- Memory-Situation läuft, muss eine An- wendung den Speicher entweder statisch zuweisen oder dies direkt zu Beginn der Laufzeit tun. (Eine Ausnahme bildet der Laufzeit-Stack, dessen maximale Be- legung aber meist statische Analysen er- mitteln können.) Die String-Klasse der C++-Standardbibliothek hingegen ist auf dynamische Allokation ausgelegt – nicht nur im Konstruktor, sondern auch bei be- stimmten Operationen (append, insert, += und so weiter). Sicherheit und ihre Anforderungen Analog dazu verbietet sich in vielen si- cherheitsgerichteten Systemen die Ver- wendung von Exceptions. Zwar erlauben diese eine strukturierte und hierarchische Fehlerbehandlung, ihr Speicherbedarf al- lerdings ist nicht leicht vorherzusagen. Daher arbeiten viele Projektteams im si- cherheitskritischen Umfeld mit einfa- chen Fehlercodes, deren Footprint, also die Summe aller zu der Zeit belegten Ressourcen, kalkulierbar ist. Ein weiterer wichtiger Aspekt ist die interne Repräsentation. Je nach Sicher- heitsanforderungen kann es beispielswei- se erforderlich sein, dass Checksummen Zeichenketten absichern – ein Feature, das die Standardklasse nicht anbietet. Neben diesen vorwiegend technischen Gesichtspunkten gilt es, regulatorische Rahmenbedingungen zu beachten. So gelten etwa im Bereich der Medizintech- nik besondere Regeln für den Umgang mit zugekauften Softwareartefakten, die nicht speziell für den Einsatz in dieser Domäne entwickelt wurden (SOUP – Software of Unknown Provenance, siehe „Onlinequellen“ [a] sowie „Alle Links“ im blauen Balken). Es kommt tatsächlich vor, dass ein Entwickler deswegen sogar auf den Einsatz einer dem Compiler bei- liegenden Standardbibliothek verzichtet. Diese Liste ließe sich beliebig fortset- zen – auch um Aspekte, die nicht spezi- fisch für sicherheitsgerichtete Systeme sind. Man denke beispielsweise an Fra- gen der Installierbarkeit, an die Eignung der gegebenen Lizenzmodelle oder an die Performance einer Software. Um dem Problem der Entscheidungs- findung näherzukommen, geht es zu- nächst um die Frage „Make or Buy?“ – zu Deutsch: „Eigenfertigung oder Fremd- bezug?“. Selber machen oder lieber einkaufen Es ist nützlich zu wissen, dass diese Frage kein spezielles Phänomen der Software- entwicklung ist. Die Phrase „Make or Buy“ stammt vielmehr aus der Industrie- betriebslehre/Produktionswirtschaft und wurde dort bereits im größeren Umfang wissenschaftlich untersucht. Eine wesent- liche Erkenntnis, die sich daraus ergeben hat, ist, dass die sogenannten Transakti- onskosten eine entscheidende Einfluss- größe darstellen [b]. Darunter fallen die vorgelagerten Kosten der Anbahnung, In- formationsbeschaffung und Verhandlung, aber auch die nachgelagerten der Abwick- lung, Anpassung und Kontrolle. Zu beachten ist, dass sich Transak- tionskosten nicht nur extern – also im Zu- sammenspiel mit Lieferanten von Kom- ponenten nach einer Buy-Entscheidung – ergeben. Vielmehr entstehen bei einer Eigenfertigung, also nach einer Make- Entscheidung, interne Transaktionskos- ten, beispielsweise in der abteilungs- übergreifenden Kommunikation und Koordination. Im Rahmen der genannten wissen- schaftlichen Untersuchungen hat sich un- ter anderem gezeigt, welche Faktoren im Allgemeinen bedingen, dass eine Make- beziehungsweise Buy-Entscheidung vor- teilhaft ist. Zwei wesentliche Kriterien, die hierbei identifiziert wurden, sind Spe- zifität und Unsicherheit. Anders formu- liert: Je generischer eine Komponente ist und je weniger Risiken ihr Zukauf birgt, desto vorteilhafter erweist sich eine Buy- Entscheidung. Ist die Komponente hinge- gen hochgradig spezifisch für das Unter- nehmen und seine Kernkompetenzen oder birgt sie tief greifende technische Risiken etwa bezüglich der prinzipiellen Machbar- keit, ist eine Make-Entscheidung geboten. Diese Erkenntnis kann man weitge- hend unverändert auf Softwareartefakte übertragen. Bei generischen Komponenten wie Compilern, Betriebssystemen, GUI- Frameworks und weitverbreiteten Bib- liotheken bietet sich fast immer ein Zu- iX 6/2015 95 Sowohl der Fremdbezug als auch die Eigenfertigung eines Softwarepakets ist mit Kosten verbunden. Manche sind offensichtlich, andere – etwa versteckte Kosten, die durch Abhängigkeiten entstehen – zeigen sich erst nach Jahren (Abb.ˇ1). ix.0615.094-099 15.05.15 08:33 Seite 95 © Copyright by Heise Medien
  3. 3. links 96 kauf bewährter Implementierungen an. Bei produkt- oder domänenspezifischen Artefakten hingegen ist im Regelfall die Eigenfertigung sinnvoller – sei es im ei- genen Haus oder im Rahmen einer engen Kooperation mit einem geeigneten Ent- wicklungspartner. Die Transaktionskosten lassen sich al- lerdings im Softwareumfeld oft schwer beziffern, auch wenn das Team die Li- zenzkosten und das Lizenzmodell der Buy-Alternative verstanden hat. Es exis- tieren nämlich weitere Unsicherheitsfak- toren, beispielsweise bezüglich der Pro- dukthaftung, der Dauer des Supports oder versteckter Kosten. Abhängigkeiten im Vorfeld klären Besonders schwer vorherzusehen sind die Kosten der Abhängigkeit, in die sich ein Unternehmen begibt, wenn es sich für den Zukauf eines Softwareartefakts entschei- det. Das liegt unter anderem daran, dass das Unternehmen wenig Einfluss auf die technischen Grenzen des erworbenen Pro- dukts hat. Stellt sich etwa im Verlauf eines Entwicklungsprojekts heraus, dass einige der Limitationen des zugekauften GUI- Frameworks die Entwicklung des eigent- lichen Produkts behindern, gibt es kaum eine Chance, diese Einschränkungen auf- zuheben. Stattdessen muss das Entwickler- team sie durch Workarounds umschiffen, was potenziell mit erheblichen Mehrkos- ten verbunden ist. In schlimmen Fällen können solche zusätzlichen Ausgaben weit über die reinen Beschaffungskosten hi- nausgehen. Aus den hier aufgeführten Beobachtun- gen kann man den folgenden Leitfaden für Make-or-Buy-Entscheidungen ableiten: 1.ˇGrundsätzlich gilt: Bei generischen Softwareartefakten mit geringen Risiken ist fast immer die Buy-Entscheidung bes- ser. Geht es um spezifische Komponen- ten, die erfolgskritisch sind, erweist sich fast immer die Make-Entscheidung als richtig. Es muss natürlich erlaubt sein, diese Grundregeln im Einzelfall zu hin- terfragen – aber wer ihnen widerspricht, muss damit rechnen, die Beweislast zu tragen. Beispiel: Wer die interne Neu- entwicklung einer gänzlich generischen Softwarebibliothek fordert, sollte eine hieb- und stichfeste Argumentationskette parat haben. 2.ˇSelbst bei vermeintlich sonnenklaren Entscheidungen empfiehlt sich eine Un- tersuchung bezüglich der Transaktions- kosten der Make- und Buy-Optionen. Hierbei sollte das Bewertungsteam darauf achten, alle Arten vor- und nachgelager- ter Transaktionskosten zu berücksichti- gen (siehe oben). Außerdem muss die Be- trachtung den vollständigen Lebenszy- klus des Produktes umfassen. 3.ˇHinsichtlich der Make-Option emp- fiehlt es sich, zusätzlich zu untersuchen, ob die Schätzung der reinen Entwick- lungskosten realistisch ist. So gibt es bei- spielsweise die Tendenz, die Kosten für Inhouse-Entwicklungen übertrieben opti- mistisch zu veranschlagen – vor allem, wenn die dafür zuständigen Parteien ein akutes Eigeninteresse an der Make-Opti- on haben. In diesem Fall kann es für eine objektivere Kalkulation hilfreich sein, un- abhängige Dritte mit der Untersuchung zu betrauen. 4.ˇAuch in Bezug auf die Buy-Option ist eine zusätzliche Prüfung auf versteckte Kosten sinnvoll. In vielen Fällen setzt das eine genauere Betrachtung des zu kaufen- den Artefakts sowie des Herstellers vo- raus. Diese Maßnahme zur Risikomini- mierung kann den Auftraggeber unter Umständen vor Unheil bewahren. In dem Zusammenhang müssen auch mögliche Folgen beleuchtet werden: Begibt sich das eigene Unternehmen mit der Verwen- dung der ausgewählten Software in eine unvorteilhafte Abhängigkeit vom Herstel- ler? Falls ja: Kann man schon im Vorfeld Gegenmaßnahmen ergreifen? Open-Source-Software als Alternative Bevor der Artikel sich dem Thema Wie- derverwendung zuwendet, soll noch kurz die besondere Rolle von Open-Source- Software (OSS) angesprochen werden. Muss sich ein Unternehmen zwischen der Eigenentwicklung einerseits und der Nut- zung einer existierenden Open-Source-Im- plementierung andererseits entscheiden, wirkt der Begriff „Make or Buy“ unpas- send – schließlich kauft niemand etwas. Oder doch? Wie im Fall proprietärer Software gilt bei OSS, dass die Aufwen- dungen selten allein auf die reinen Ent- wicklungs- oder Lizenzierungskosten be- schränkt bleiben. Und so ist auch der Einsatz von Open-Source-Software mit Transaktionskosten behaftet. Im Vorfeld spielt vor allem die Infor- mationsbeschaffung eine wesentliche Rol- le. Dabei stellen sich eine Reihe von Fra- gen: Hat das Produkt die benötigten Eigenschaften? Passt es in die technischen Rahmenbedingungen des eigenen Pro- jekts? Wie steht es mit der Qualität und der Produktpflege? Was muss das Unter- nehmen tun, um den Lizenzbedingungen gerecht zu werden? Ist es überhaupt ver- tretbar, OSS zu verwenden, ohne der 96 iX 6/2015 REPORT | SOFTWAREENTWICKLUNG Unsicherheit Spezifizität sehr hoch hoch moderat niedrig sehr hochhochmoderatniedrig ⚫ Umsetzung neuer eigener Forschungsergebnisse in produktfähige Algorithmen ⚫ Gerätetreiber für selbst entwickelte Spezialhardware ⚫ Implementierung des unternehmenseigenen IP-Cores, z.B. Messlogik ⚫ domänenspezifische Middleware ⚫ Kommunikations- protokoll(-stack) für speziellen Feldbus ⚫ bewährtes GUI-Framework ⚫ Echtzeit- Betriebssystem Eigenfertigung (Make) günstiger! Fremdbezug (Buy) günstiger! Die Entscheidung der Frage „Make or Buy?“ hängt im Wesentlichen davon ab, wie spezi- fisch ein zu erstellendes Softwareartefakt und wie risikobehaftet seine Entwicklung ist. Die eingetragenen Punkte sind hier nur als grobe Beispiele zu verstehen (Abb.ˇ2). ix.0615.094-099 15.05.15 08:33 Seite 96 © Copyright by Heise Medien
  4. 4. links 98 OSS-Gemeinde etwas zurückzugeben? Existiert gar eine unternehmensweite Stra- tegie zum Umgang mit dem Phänomen Open Source? Kosten können sich vielfältig gestalten Nachgelagerte Kosten ergeben sich vor allem in den Bereichen Anpassung und Kontrolle. Soll das verwendete OSS-Arte- fakt weiterentwickelt oder angepasst wer- den, gibt es dazu verschiedene Modelle. So kann sich ein Unternehmen aktiv in die Open-Source-Gemeinde einbringen und die Software mitgestalten. Oder es kann, je nach Lizenz, einen eigenen Ableger der Software veröffentlichen, der den speziel- len Anforderungen des Unternehmens be- ziehungsweise des Projekts genügt. In die- sem Sinne muss sich ein Unternehmen, das Open-Source-Software in eigenen Pro- dukten einsetzen möchte, also die Fähig- keit erkaufen, diese Software informiert, gezielt und bewusst zu verwenden. Festzustellen ist allerdings, dass viele Organisationen dieses Thema ausgespro- chen emotional handhaben. In der Regel liegt das an einer erheblichen Verunsiche- rung bezüglich der Qualität, der Produkt- haftung und der Rechtssicherheit. Diese Verunsicherung lässt sich aber aufheben – getreu dem altbekannten Spruch „Angst ist nur ein Mangel an Information“. Aus diesen Überlegungen ergibt sich der folgende Leitfaden für den Umgang mit Open-Source-Lösungen: 1.ˇZunächst sollte jedes Unternehmen ei- ne grundsätzliche Strategie für den Ein- satz von Open-Source-Software in eige- nen Produkten etablieren. Zwei nicht zur Nachahmung empfohlene Ausprägungen sind „Wir verwenden keine OSS, Punkt“ (eine Entscheidung, die einem Unter- nehmen viele Chancen verbaut) und „Wir verwenden in unseren Produkten heim- lich OSS und ignorieren die Lizenzbedin- gungen“ (ein hochproblematisches Vor- gehen, das schon für viele Unternehmen ein teures Nachspiel hatte [c]). Wichtig ist eine informierte Entscheidung, die die gängigen Lizenzmodelle – etwa GPL ver- sus BSD – fachgerecht unterscheidet und den eigenen Entwicklungsabteilungen ei- nen klaren Weg weist. 2.ˇWer eine objektive Entscheidung für oder wider OSS treffen möchte, muss allgemeine Vorurteile durch spezifische Fakten ersetzen. Beispiel Qualität: Zahl- reiche OSS-Produkte erreichen den Rei- fegrad, die Qualität und die Fehlerbehe- bungszeit proprietärer Konkurrenten – oder schlagen sie sogar [d]. Im Einzelfall muss das Projektteam das fragliche Soft- wareartefakt wie jede kommerzielle Soft- ware hinsichtlich Qualität, Wartung, Er- weiterbarkeit und Lizenzbedingungen untersuchen. 3.ˇSelbstredend empfiehlt sich auch bei OSS eine umfassende Einschätzung so- wohl der Transaktionskosten inklusive versteckter Ausgaben (siehe oben) als auch der entstehenden Abhängigkeiten von externen Akteuren. In diesem Punkt sind Open-Source- und proprietäre Pro- dukte praktisch gleich zu behandeln. Der folgende Abschnitt betrachtet ei- nen weiteren typischen Fall bei der Pla- nung eines neuen Softwareprojekts: Ein Unternehmen erwägt, eine in einem ver- gangenen Projekt entwickelte Software- komponente in dem aktuellen wiederzu- verwenden – statt sie für den neuen Einsatzzweck noch einmal entwickeln zu lassen. Es ist leicht nachvollziehbar, dass die Option „Reuse“ unter solchen Bedin- gungen verführerisch klingt, während sich die Alternative „Rewrite“ tendenziell eher als sinnloses Risiko ohne Nutzen darstellt. Aber, wie in der Einleitung an- gedeutet: Wer die Fragestellung „Reuse or Rewrite?“ wirklich reflektiert beant- worten will, kommt um eine tiefer grei- fende Analyse nicht herum. Fragen zur Wiederverwendung lassen immer wieder einige Besonderheiten er- kennen, mit denen Entwickler bewusst umgehen müssen – und auf die ein Mit- arbeiter vorbereitet sein sollte, wenn er eine Diskussion darüber führt. Oft ist den Beteiligten gar nicht be- wusst, wie viele Voraussetzungen erfüllt sein müssen, damit man ein existieren- des Softwareartefakt in einem neuen Produkt nutzen kann. In der Regel ist der Blick nur auf die Funktionalität ge- richtet – oft unter der falschen An- nahme, dass die funktionalen Anfor- derungen identisch bleiben. Allerdings ergeben sich schnell ganz andere funk- tionale Anforderungen – zum Beispiel, wenn der „Intended Use“ (der vom Her- steller benannte Bestimmungszweck) des neuen Produkts von dem des alten abweicht. Die Verlockung der Wiederverwendung Bezüglich der Voraussetzungen für einen erfolgreichen Reuse ist es weiterhin nö- tig, versteckte Annahmen durch gezielte Fragen und Untersuchungen an die Ober- fläche zu befördern: –ˇGibt es eine Strategie für das weitere Vorgehen, wenn sich der Code im neuen Projekt anders als der Originalcode ent- wickelt, sobald die Anforderungen oder Randbedingungen auseinanderlaufen? Was anfänglich oft als Wiederverwen- dung einer zentral gepflegten und sich sonst nicht mehr verändernden Kom- ponente betrachtet wird, kann bei kon- zeptlosem Vorgehen schnell in eine simp- le Weiterverwendung mit verschiedenen Entwicklungszweigen münden. –ˇBerücksichtigt die Bewertung auch die nichtfunktionalen Anforderungen und die Randbedingungen ausreichend? –ˇIst der Code frei von projekt- oder com- pilerspezifischen Dialekten? –ˇWelche Abhängigkeiten wohnen dem altgedienten Quelltext inne? Sollen diese in das neue Produkt einfließen? –ˇGibt es eine adäquate Dokumentation sowie eine ausreichend breite Testbasis? –ˇWas ist zu tun, damit die Wiederver- wendung prozesskonform erfolgt? –ˇWäre es eventuell sinnvoll, das zum Reuse stehende Softwareartefakt gezielt in Richtung Wiederverwendbarkeit zu überarbeiten, bevor es in weitere Projek- te/Produkte eingeht? –ˇSind die Wissensträger, die das Soft- wareartefakt besonders gut kennen, ver- 98 iX 6/2015 REPORT | SOFTWAREENTWICKLUNG [a] SOUP – Software of Unknown Provenance https://www.johner-institut.de/blog/tag/soup [b] A Transaction Cost Approach to Make-or-Buy Decisions https://www2.bc.edu/~jonescq/mb851/Feb19/WalkerWeber_ASQ_1984.pdf [c] Open Source Compliance Trend sourceauditor.com/blog/tag/lawsuits-on-open-source/ [d] Jennifer Kuan; Open Source Software as Lead User’s Make or Buy Decision: A Study of Open and Closed Source Quality idei.fr/doc/conf/sic/papers_2002/osskuan.pdf [e] Joel Spolsky; In Defense of Not-Invented-Here Syndrome www.joelonsoftware.com/articles/fog0000000007.html Onlinequellen ix.0615.094-099 15.05.15 08:33 Seite 98 © Copyright by Heise Medien
  5. 5. 99rechts fügbar, um es erfolgreich in das neue Pro- dukt zu integrieren? In vielen Fällen sind die Urheber des zur Wiederverwendung stehenden Soft- warebausteins an der Reuse-Diskussion beteiligt. Dieser Umstand ist psycholo- gisch interessant: Zumindest anfangs neigen die meisten dazu, die Wieder- verwendbarkeit des eigenen Produkts zu überschätzen (die Kehrseite des NIHS – des „not invented here syndrome“ –, das zu einer erhöhten Skepsis gegenüber Ar- tefakten führt, die außerhalb der eigenen Organisation entstanden sind [e]). Objektivität ist nicht immer einfach Erschwerend kommt hinzu, dass die objektive Bewertung existierender Soft- ware kein einfaches Unterfangen ist. Zwar gibt es diverse Werkzeuge zur au- tomatisierten Erhebung von Codemetri- ken, aber diese sind nicht der Weisheit letzter Schluss: Einerseits ist es häufig zeitaufwendig, das zu untersuchende Ar- tefakt in eine für das Tool verwertbare Form zu bringen. Andererseits liefern die Metriken nur Anhaltspunkte; sie können kein inhaltliches Architektur- oder De- sign-Assessment ersetzen. Wer aussage- kräftige Erkenntnisse über ein Software- artefakt gewinnen möchte, um einer folgenschweren Fehlentscheidung vor- zubeugen, sollte deshalb eine derartige Bewertung vornehmen lassen. Assess- ments der hier genannten Art haben im- mer ein ausgezeichnetes Kosten-Nutzen- Verhältnis. Zusammenfassend lässt sich für Re- use-Entscheidungen der folgende dritte Leitfaden empfehlen: 1.ˇDie Beteiligten müssen sich klar vor Augen führen, dass die bloße Existenz ei- ner Software noch lange nicht ihre Wie- derverwendbarkeit garantiert. Hierzu ist im Regelfall eine gezielte, möglichst ob- jektive Untersuchung der Software er- forderlich – die deshalb nur schlecht die Personen durchführen können, die sie entwickelt haben. Ferner darf sich eine solche Untersuchung nicht allein auf Codemetriken oder gar auf persönliche Eindrücke der Codequalität stützen. Sie muss vielmehr auch die Anforderungen und Abhängigkeiten sowie die Vollstän- digkeit von Dokumentation und Testbasis beleuchten. 2.ˇBezüglich der Kostenfrage müssen die Entscheider erkennen, dass auch eine Wiederverwendung – ähnlich wie ein Ein- satz von Open-Source-Software – nur oberflächlich betrachtet kostenlos ist. Die Integration des existierenden Softwarear- tefakts in das neue Produkt ist selbstre- dend mit Aufwand verbunden. Ebenso können sich Mehrkosten für die zukünf- tige Pflege der Codebasis ergeben, wenn diese jetzt in mehreren verschiedenen Systemen zum Einsatz kommt. Ein weite- rer potenzieller Kostenfaktor sind unge- plante Nacharbeiten bezüglich Wiederver- wendbarkeit, Dokumentation und Test. Letztendlich sind dies wieder Spielarten von Transaktionskosten (siehe oben). 3.ˇInsgesamt kann es der Objektivität einer Entscheidungsdiskussion zuträglich sein, einen selbst entwickelten und nun zur Wiederverwendung stehenden Software- baustein denselben Bewertungskriterien zu unterwerfen, denen sich beispielsweise ei- ne zugekaufte Alternative stellen müsste. Allerdings besteht hierbei die Gefahr, dass die stringente Analyse der Gegebenheiten individuelle Empfindlichkeiten berührt. Deshalb empfehlen sich ein diskretes, res- pektvolles Vorgehen sowie eine sorgfäl- tige Besetzung des Bewertungsteams – etwa mit Personen, die nicht als Polarisa- toren verschrien, sondern gemeinhin als sachlich und ausgleichend akzeptiert sind. Fazit Die meisten Unternehmen, in deren Pro- dukten Software eine Rolle spielt, stehen immer wieder vor Reuse- beziehungs- weise Make-or-Buy-Entscheidungen. In solchen Momenten kommt es darauf an, die verschiedenen Optionen systematisch zu bewerten – und das geht nicht nach Bauchgefühl. Wer die in diesem Artikel aufgezeigten Stolperfallen meidet, oft ver- gessene Aspekte auf den Tisch bringt und die Kosten der einzelnen Alternativen rea- listisch bewerten lässt, wird als Belohnung eine wesentlich bessere Bewertungsgrund- lage erhalten und somit die bessere Ent- scheidung treffen können. (ka) Dr. Daniel Mölle arbeitet als Lead Software Architect mit dem Schwerpunkt Embedded Systems bei der Zühlke Engineering GmbH. iX 6/2015 99 Alle Links: www.ix.de/ix1506094 ix.0615.094-099 15.05.15 08:33 Seite 99 © Copyright by Heise Medien

×