Aufrufe
vor 3 Jahren

02 | 2015 public

  • Text
  • Verwaltung
  • Factory
  • Konsolidierung
  • Anforderungen
  • Einsatz
  • Frameworks
  • Anwendung
  • Systeme
  • Software
  • Unternehmen
Schwerpunkt: Konsolidierung der IT-DLZ

„Die Technologie ist

„Die Technologie ist ein hilfreicher Diener, aber ein gefährlicher Herr.“ Christian Lous Lange • Wie hoch ist die Lernkurve und wie umfangreich ist der Lernprozess für das Framework im Vergleich zur eingesparten Arbeit? • Sind die Fertigkeiten, die für dieses Framework benötigt werden, allgemeingültig und wie leicht können Mitarbeiter mit diesen Fähigkeiten gefunden werden? • Können das Framework und die gelernten Framework-Fähigkeiten in künftigen Software-Projekten wiederverwendet werden und ist der nötige Lernprozess dadurch gerechtfertigt? STOLPERSTEIN LIEFERANTEN-/TECHNOLOGIE-LOCK-IN Die Entscheidung für den Einsatz eines Frameworks in einem Prozess ist häufig auch die Entscheidung für einen bestimmten Technologie-Stack. Das heißt, einmal getroffen, lässt sie sich nicht so einfach wieder rückgängig machen. Während die Abstraktionsmechanismen eines Frameworks oft lose Kopplung und Systemflexibilität innerhalb des Frameworks bieten, kann sich der Ersatz eines bereits verwendeten Frameworks selbst als schwierig bis unmöglich erweisen. So bleibt eine Web-Anwendung, die ein ORM 2 -Framework für Persistenz, JSF im Frontend und EJBs in der Anwendungsschicht einsetzt, auf Dauer an diese Technologien gebunden. Einige schwergewichtige Frameworks, wie Oracle ADF, setzen sogar die Verwendung einer ganz bestimmten Version eines speziellen Tools voraus, um das Framework nutzen zu können. Die Aktualisierung der verwendeten Version des Frameworks zieht dann auch eine Aktualisierung dieser Tools nach sich – häufig ein zeitaufwendiges und kostspieliges Unterfangen. Damit stellen sich bei der Evaluierung eines Frameworks folgende Fragen: • Macht die Verwendung eines bestimmten Frameworks von einer Technologie oder einem Lieferanten abhängig? • Machen die Nachteile dieses Technologie-Lock-ins die Vorteile der Flexibilität durch das Framework zunichte? • Ist ein Lieferanten-Lock-in ein strategischer Vorteil oder eher ein potenzielles Risiko? FRAMEWORKS UND ENTWICKLERPRODUKTIVITÄT Die Einführung von Frameworks ist in der Regel vom Wunsch nach erhöhter Entwicklerproduktivität und leistungsfähigerer Entwicklung getrieben. Es lohnt sich in diesem Zusammenhang also, sich auch mit dem Thema „Entwicklerproduktivität“ auseinanderzusetzen. Was genau versteht man unter Entwicklerproduktivität? Kann sie durch ein Framework gesteigert werden? Und wenn ja, wie? WIE LÄSST SICH ENTWICKLERPRODUKTIVITÄT MESSEN? „Miss alles, was sich messen lässt, und mach alles messbar, was sich nicht messen lässt.“ Ob sich dieser Anspruch von Galileo Galilei auch auf die Entwicklerproduktivität übertragen lässt, darf bezweifelt werden. Denn weder die Anzahl der erstellten Code-Zeilen noch die produktiv zum Schreiben von Code benötigten Stunden geben wirklich Aufschluss über die Entwicklerproduktivität. Ein einfaches, aber komplex und redundant geschriebenes Programm besteht aus vielen Code-Zeilen. Aber weist es auch auf eine höhere Produktivität hin als eine kurze, klare und prägnante Implementierung? Und ist der Entwickler, der diese prägnante Version durch sieben Stunden Nachdenken und eine Stunde Code-Schreiben erstellt hat, nur eine Stunde „produktiv“ gewesen oder einen ganzen Arbeitstag? Solche und ähnliche Fragen haben zu der Erkenntnis geführt, dass „Code-Analyse und ähnliche Methoden (…) wenig Aufschluss über das (geben), was ein effektives Software-Team ausmacht“. 3 FOWLER: „PRODUKTIVITÄT LÄSST SICH NICHT MESSEN“ Martin Fowler behauptet, „Entwicklerproduktivität“ lasse sich nicht messen 4 , und belegt seine These mit der „Function-Point- Analyse“. Während ein Entwickler 100 Function Points (FP) in sechs Monaten programmiert, programmiert ein anderer im 2 Object-Relational Mapping = Abstraktionsschicht zwischen objektorientierter Anwendung und relationaler Datenbank 3 http://www.infoworld.com/d/application-development/the-futility-developer-productivity-metrics-179244 4 http://martinfowler.com/bliki/CannotMeasureProductivity.html 44 | .public 02-15 | Informationstechnologie

gleichen Zeitraum nur 30 FP. Doch genau diese 30 FP benötigt der Kunde, um ein weiteres Projekt an den gleichen Auftragnehmer zu vergeben, wodurch weiterer Ertrag und Gewinn generiert werden. Fowler macht darauf aufmerksam, dass die Herausforderung beim Messen der Produktivität darin liegt, den Begriff Output zu definieren und zu quantifizieren. Was gilt bei einem Softwaresystem als angemessener Output? Der Geschäftswert? Der Ertrag? Die eingesparten Kosten? Status und Image in der Branche? Strategische Vorteile? Es gibt keine einheitliche, objektive Berechnungsformel für Produktivität. ÜBER DEN NUTZEN VON PRODUKTIVITÄTSMASSNAHMEN Angesichts der oben beschriebenen Schwierigkeiten äußert sich der Softwareberater Steve McConnell skeptisch gegenüber den Möglichkeiten, individuelle Produktivität messen zu können. 5 Seiner Meinung nach gibt es weder einzelne Maßnahmen, die eine verlässliche Bemessung von Produktivität zulassen, noch liefern Maßnahmenbündel Einsichten über die feinen Unterschiede zwischen der Produktivität einzelner Personen. Produktivitätsmaßnahmen sind laut McConnell von geringem Nutzen für die Einschätzung von Projektaufwänden oder -dauer. SPOLSKY ÜBER SPITZENLEISTUNG Joel Spolsky führt in die Frage der Messung von Produktivität die Faktoren „Talent“ und „Kreativität“ ein. 6 Echte „Produktivität“, so Spolsky, habe nur wenig mit schnellerem Arbeiten oder vermehrter Erstellung von Code oder FPs innerhalb kürzerer Zeiträume zu tun, sondern vielmehr mit talentierten Spitzenentwicklern, die „die hohen Töne treffen können“ – Entwickler also, die in der Lage sind, „eine Vision von ‚richtig guter Software‘ zu entwickeln und diese dann auch umzusetzen“, die Software entwickeln, die „Stil, Freude und emotionelle Attraktivität“ verkörpert. Frameworks allerdings funktionieren genau gegenteilig. Sie sollen durch Industrialisierung des Entwicklungsprozesses die Notwendigkeit und Bedeutung von Spitzenentwicklern beseitigen helfen. FAZIT: DAS GESETZ DES ABNEHMENDEN ERTRAGSZUWACHSES Wenn bei der Suche nach einer Antwort auf die Frage, wie sich Entwicklerproduktivität steigern lässt, der Fokus nur auf Abstraktionen, Frameworks, Technologien gelegt wird, ohne die vielen anderen Faktoren zu berücksichtigten, erinnert das an das „Gesetz des abnehmenden Ertragszuwachses“ 7 , das besagt: Wenn der Einsatz nur eines Faktors der Produktion erhöht wird, während alle anderen Faktoren unverändert bleiben, steigt der Ertrag zuerst an, dann bleibt er gleich und schließlich sinkt er ab. Möglicherweise hat die Einführung von höheren Programmiersprachen und deren Abstraktionsschichten zunächst zu einem großen Anstieg der Produktivität geführt. Durch das ständige Hinzufügen von immer mehr Abstraktionsschichten ist der Zugewinn allerding kontinuierlich kleiner geworden, bis hin zu einem Absinken der Produktivität. Und die Ursache dafür? Die ist sehr häufig im „Einschleppen“ akzidentieller Komplexität und undichter Abstraktionsschichten zu finden.• ANSPRECHPARTNER – JOHN LOUTZENHISER Senior IT Consultant Public Sector • +49 173 859 4235 • john.loutzenhiser@msg-systems.com 5 http://www.joelonsoftware.com/articles/HighNotes.html 6 http://www.construx.com/10x_Software_Development/Measuring_Productivity_of_Individual_Programmers 7 https://de.wikipedia.org/wiki/Ertragsgesetz Informationstechnologie | .public 02-15 | 45

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum