Software





welt-verstehen/Software+KONSENS+Vereinheitlichung+Steuerbehörden, stw5912SKONSENSVS

Wissenswertes zu Software Engineering

   





D i s k u s s i o n


 Beitrag 0-516
Was man als Manager großer IT-Projekte unbedingt wissen sollte

 
 

 
Wie schwierig kann Software-Sanierung sein?

 
 
KONSENS: Die 2007 begonnene Vereinheitlichung der Software der deutschen Steuerbehörden:
    Ziele des Vorhabens KONSENS (Koordinierte neue Software-Entwicklung der Steuer-verwaltung) sind die Entwicklung und der Einsatz einer bundesweit einheitlichen Software für die Steuerverwaltung.
     
    Bund und Länder arbeiten hierzu seit 2007 zusammen. Bis 2019 sind dabei Ausgaben von rund 1,2 Mrd. € angefallen, sie werden sich bis zum Jahr 2024 auf 2 Mrd. € erhöhen.
     
    Bund und Länder wollen mit KONSENS ihre Steuereinnahmen von jährlich 638 Mrd. Euro (Stand 2020) besser verwalten als bisher möglich ist.
     
    Derzeit (2020) werden für KONSENS 19 (Haupt-)Verfahren entwickelt. Obgleich fertiggestelle Module weitestgehend sofort zum Einsatz kommen, werden in den Ländern in unterschiedlichem Umfang immer noch insgesamt 193 Nicht-KONSENS-Anwendungen mit z.T. recht ähnlichem Funktionsumfang betrieben. Für zunächst nur 118 hiervon ist eine Ablösung durch ein KONSENS-Verfahren vorgesehen. Nach derzeitigen Planungen (Stand 2020) wird man dieses erste wichtige Teilziel aber sicher nicht vor 2029 erreicht haben.
     
    Quelle: Bayerischer Oberster Rechnungshof (eine beratende Äußerung vom Nov. 2020)

 
 
Die "Autobahn GmbH" des Bundes wird nicht am 1. Januar 2021 im Regelbetrieb starten können. Der Grund: fehlende IT-Infrastruktur und juristische Probleme bei laufenden Projekten.
    Zwar geht die Autobahngesellschaft mit zehn Niederlassungen und 41 Außenstellen zum Jahresbeginn an den Start, dennoch ist die neue Mammutbehörde mit Zentrale in Berlin bis auf weiteres nicht allein zuständig für die 13.000 Kilometer Autobahnen in Deutschland. Grund sind ungelöste Probleme. So dauere die Harmonisierung von 1.400 Softwaresystemen der Landesstraßenbauverwaltungen noch bis Anfang 2024, so das Verkehrsministerium.
     
    Quelle: Scheuers Fehlstart - noch lange kein Regelbetrieb für "Autobahn GmbH" (Bericht im ZDF, Dez 2020)

 
 
Über bisher erfolglose Versuche, Gehaltsabrechnungssysteme auf neue Technologie zu portieren:
 
Wie schnell man beim Versuch, Gehaltsabrechnungssysteme der öffentlichen Hand auf aktuelle Technologie zu portieren Dollarbeträge zwischen 0,4 und 1,2 Milliarden Dollar in den Sand setzen kann (und das ganz ohne, dass man dann ein brauchbares neues System hätte), zeigen Projekte in Kalifornien einerseits und Australien andererseits:

    (1) Kaliforniens Payroll System, mit dessen Hilfe 250.000 Bedienstete monatlich neu ihr Gehalt berechnet und überwiesen bekommen, versucht man schon seit 1999 neu zu implementieren: Bisher ohne jeden Erfolg — aber mit Kosten, die sich 2020 schon auf gut 400 Mio. US Dollar Lehrgeld aufsummiert haben.
     
    Man lese: Nun hin zum dritten Anlauf
     
     
    (2) Noch dramatischer schief gelaufen ist zwischen 2010 und 2018 — da hier nicht nur Software-Entwickler, sondern vor allem auch Politiker ganz unglaublich naiv gehandelt haben — in Queensland (Australien) ein erster Versuch, das Payroll System für den Gesundheitssektor (ca. 85.000 Bedienstete) neu zu implementieren.
     
    Der Auftragnehmer (IBM Australia) hatte sich nur 2 Wochen Zeit genommen, die Sollfunktionalität der Anwendung zu dokumentieren. Kein Wunder also, dass die neue Lösung jede dritte Gehaltsabrechnung mit z.T. höchst gravierenden Fehlern errechnet hat. Die zuständigen Entscheidungsträger haben die Anwendung — aus politischen Gründen — dennoch in Betrieb genommen. Konsequenz: Man hat hinterher über längere Zeit hinweg 1600 Beschäftigte benötigt, die vielen ständig vom neuen System errechneten Fehler mit Hilfe manueller Work Arounds zu korrigieren oder zu viel bezahlte Gelder wieder zurückzufordern und einzusammeln. Zahlreiche Angestellte haben gekündigt, da sie wochenlang der fehlerhaften neuen Anwendung wegen gar kein Gehalt erhielten.
     
    Auf diese Weise ist — bei einem Auftragswert von nur knapp 7 Mio. australischer Dollar — später (in den 3 Jahren nach dem fahrlässigen Rollout) für den Steuerzahler ein Gesamtschaden von ingesamt 1.2 Milliarden australischer Dollar entstanden. [ Man ist an das 2019 mindestens so fahrlässige Handeln des deutschen Verkehrsministers Andreas Scheuer in Sachen PKW-Maut erinnert. ]
     
    Quelle: The Queensland Health Payroll Fiasco + /short + /BPr
     
     
    Note: Dass in Kalifornien und Queensland eine erfolgreiche Portierung der Altanwendung auf SAP scheiterte, wird wohl daran gelegen haben, dass die SOLL-Funktionalität des jeweiligen Altsystems nicht ausreichend genug dokumentiert war.
     
    Bei Lidls abgebrochenem Versuch, das eigene Warenwirtschaftssystem nach SAP zu portieren, war der Grund aber (mindestens teilweise) ein ganz anderer: Basis aller Kalkulation in SAP sind Einkaufspreise. Lidls propietäres System aber kalkuliert auf Basis der Verkaufspreise. Am alten Geschäftsprozess konnte man mit Standard-SAP-Software also gar nicht festhalten. Man hat sozusagen eine zweite Variante der SAP-Plattform benötigt. Sie fertig zu implementieren erachtete Lidl dann aber als zu teuer.
     
    Details hier: 7 Jahre, 500 Millionen EUR — mehr wollte man nicht riskieren + /M

 
 
Man lese auch:
     
  • Beispiele schiefgelaufener großer IT-Projekte (auch solche einzelner Unternehmen)
     
  • Understanding and Managing Your Project’s Complexity
     
  • Project Failure Case Studies — Lessons learned
     
  • The following excuses for total project failure will never work in court:

     
      " I thought the buyer or supplier knew what they were doing " or
       
      " I thought the buyer or supplier was doing it, not me ".

     
    If you are the buyer and you do not have all the necessary skills and experience to be able to define and control important projects (which is perfectly understandable as in most companies they don’t happen very often), there is an easy fix for this problem:
     
    Hire a very experienced interim executive to act on your behalf, even if the supplier will still do most of the project management and other work. You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.
     
    But keep in mind: Responsibility for the project — including responsibility for it failing — always rests ultimately with you, the buyer.
     
    And never forget:

Risk are  known  unknowns
 
Uncertainty are  unknown  unknowns.


 

  Beitrag 1957-18
Erste Anzeichen einer neuen Software-Krise?

 
 


Payroll Systeme in Kalifornien und New York zeigen

völlig unerwartete Grenzen moderner Software-Entwicklungs-Methodik



Mitte 2006 vergab der Staat Kalifornien ein Projekt, dessen Inhalt es sein sollte, ein damals schon 30 Jahre altes Payroll System auf SAP-Basis neu zu implementieren.
Solche Neuentwicklung sollte das Problem beseitigen, dass kaum noch Programmierer zu finden waren, die die alte Technologie gut genug verstanden, volle Funktionsfähigkeit der Anwendung auf Jahre hinaus zu garantieren.

Die Kosten für die Neuentwicklung wurden auf 69 Mio. US-Dollar geschätzt,
und nach einer immerhin 3-jährigen Projektlaufzeit sollte das neue System 2009 einsatzfähig sein:

Zitat:
 
BearingPoint Inc. will put in place a new payroll and personnel system for California under a $69 million contract awarded by the state controller's office.

The McLean consulting company will work with SAP Public Services Inc. on an initiative the state calls the 21st Century Project.
The goal is to replace a 30-year-old system with one that is state of the art.

SAP will furnish software, maintenance and training for state employees to run the software, while BearingPoint will adapt SAP's software and implement it in state agencies.

The state selected SAP in April 2005 for the payroll and personnel software, and subsequently picked BearingPoint to handle the implementation. BearingPoint signed the contract in June 2006.

The system is scheduled to be online by November 2007, with full implementation expected by June 2009.


Nachdem sich dann aber 2009 (zum ursprünglich geplanten Projektende) herausstellte, dass BaringPoint mit dem Projekt hoffnungslos überfordert war, hat der Staat Kalifornien das Projekt abgebrochen und es dann erneut direkt an SAP vergeben.

Inzwischen vorsichtig geworden, sollte das Projekt unter dem neuen Auftragnehmer — SAP — in 5 Schritten implementiert werden. Schon der erste von ihnen — die sog. Pilotphase — ging so gründlich daneben, dass auch SAP gefeuert werden musste: Der durch SAP abgelieferte Prototyp versagte völlig, obgleich er doch nur etwa 5% der Gesamtfunktionalität abzudecken hatte:


Der Umfang, in dem selbst SAP versagt hat, macht sprachlos:

Zitat von State Controller John Chiang:
 
One fact is particularly troubling with respect to SAP’s lack of progress:

The pilot phase only covers 1,300 SCO employees and two bargaining agreements with fairly simple payroll requirements. After eight months and little progress, the SCO cannot responsibly proceed to the second phase as requested by SAP and expose thousands more State employees to payroll errors. Nor can the SCO have any confidence that SAP can scale the failed system to cover the State’s 240,000 employees, operating out of 160 different departments, under 21 different bargaining units.

The errors in the SAP system affect everyday lives: Not only have SCO employees been paid too much, or too little, they and their family members also have been denied medical services despite paying for the insurance coverage. Payments to the State’s dental, vision and deferred compensation partners have been incorrect and delivered late. Improper deductions have been taken, payments have been made to the wrong payee, payroll and pensionable wages have been incorrectly calculated, and union deductions incorrectly determined.

To stabilize payroll for its employees, the SCO is rolling back its 1,300 employees to the legacy system that is currently and reliably paying all other 240,000 State employees.


Es ist noch nicht mal klar, ob irgend ein Teil von SAPs Projektergebnis im neuen System Verwendung finden kann:

Zitat von State Controller:
 
On February 8, 2013, the State Controller’s Office (SCO) terminated its contract with SAP as the system integrator for the MyCalPAYS system, the largest payroll modernization effort in the nation.

At the same time, the Secretary of the California Technology Agency (CTA) suspended further work until ... an independent assessment of SAP’s system to determine whether any of SAP’s work can be used in the SCO’s go-forward plan to address the State’s business needs.


Dieses Projekt-Fiasko erinnert an einen ganz ähnlichen Fall in New York, in dem sich IBM fast so überfordert sah, wie SAP oben:

Zitat von März 2011:
 
... the New York CityTime project was planned in 1998 to cost around $63 million and take five years to complete.

It is now (March 2011) estimated to cost some $720 million before it is finished sometime this summer

Zitat von 2012:
 
CityTime originally had a $63 million budget, but costs since skyrocketed astonishingly, with total estimates reportedly reaching $760 million.


An beiden Fällen ist interessant, dass hier lediglich existierende, schon Jahrzehnte alte Systeme neu implementiert werden sollten, und dass
  • im einen Fall gleich 8 Jahre mehr als geplant benötigt wurden (mit 12 mal so hohen Kosten wie geplant),
  • man im anderen aber nach nunmehr 7 Jahren immer noch genau dort steht, wo man begonnen hat (obgleich schon jetzt 254 Mio USD ausgegeben wurden, also schon fast das 4-fache des ursprünglich angesetzten Bugdets).


Wie also kommt es, dass so extrem schwierig erscheint,

mit heutiger Technologie und Methodik zu erreichen, was man mit längst überholter doch schon mal erreicht hatte?



Muss man da nicht glauben, dass moderne Projektteams nicht mehr systematisch genug arbeiten?


Ein drittes Beispiel, dort mit IBM als Hauptverantwortlichen, scheint diesen Verdacht zu bestätigen.

Ein viertes Beispiel (2019) — hier mit Microsoft als Auftragnehmer.

Liste einiger in Deutschland mit SAP schief gelaufender Projekte — Gesamtschaden bei knapp 1 Milliarde:

Gescheitert mit ERP-System-Erneuerung sind z.B. Lidl, Deutsche Post, Deutsche Bank und Otto.

Noch mehr ERP-Katastrophen aus der ganzen Welt

 

Wie die beiden Zusammenstellungen » 10 biggest ERP Software Failures of 2011 « und » Six shocking ERP Failures « (2015) zeigen,

sind solche Beispiele keineswegs nur seltene Ausnahmen.


The biggest IT failure ever seen so far, was originally estimated to be £6.4 bn (6,4 Mrd. britische Pfund).

Auch allzu unvorsichtiger Update von Software hat schon Schäden in Millionenhöhe verursacht.




Lies auch:

 

 Beitrag 0-74
Warum Software-Tester in Konkurrenz zu einander eingesetzt sein sollten

 
 

 
Wie sich der Wert von Software-Testern optimieren lässt

 
 
Projekte, die eine Modernisierung unternehmenskritischer Software-Applikationen großer Unternehmen zum Ziel haben, werden größer und größer (und verursachen heute Kosten, die gar nicht so selten 3-stellige Millionenhöhe erreicht).
 
Einen ganz beträchtlichen Teil solcher Kosten verursacht der Test der neuen Lösungen: Typischerweise arbeitet daran ein großes Team (in den Fällen, die ich beobachten konnte, bis zu 50 Personen) über Jahre hinweg. Natürlich versucht der CIO des Auftraggebers dann hin und wieder, kostengünstigere Dientleister zu finden. Das gängige Verfahren: Eine neue Ausschreibung aufgesetzt mit dem Ziel, zu prüfen,
  • ob der gegenwärtige Dienstleister nicht zu teuer oder zu wenig kreativ geworden ist
     
  • oder ob es konkurrierende Anbieter gibt, die ihn zu unterbieten in der Lage sind.

Sehr oft steht am Ende einer solchen Ausschreibung der Austausch des Anbieters, d.h. der Austausch des gesamtem Teams von Testern und Testmanager.
Dies aber kann gefährlich sein, denn
  • erstens geht dabei eine große Menge von Knowhow verloren (die neuen Tester müssen sich ja erst wieder mit den zu testenden Applikationen bekannt machen)
     
  • und zweitens ist zunächst noch völlig offen, wie effektiv das neue Team denn nun wirklich arbeiten wird.

Mit anderen Worten: Die Wahrscheinlichkeit, dass der Befreiungsschlag gelingt, ist ebenso groß wie die Wahrscheinlichkeit, dass er misslingt. Rechnet man die Kosten der notwendigen Einarbeitung des neuen Teams hinzu — Kosten also, die gar nicht anfielen, wenn man beim alten Team geblieben wäre —, so ist die Wahrschein­lichkeit, dass solcher Wechsel unterm Strich eher Verlust denn Gewinn bedeutet, ziemlich hoch.
 
Andererseits:
 
Das Team über Jahre hinweg einfach arbeiten zu lassen, ohne zu versuchen, die Effektivität des Dienstleisters zu maximieren,
 
wäre ganz sicher auch nicht richtig.

 
Was also sollte man tun?
 
 
 
Die naheliegenste Lösung ist folgende:
 
Sobald ein Testteam über längere Zeit hinweg eine gewisse Größe haben muss, sollte man es aufteilen in zwei etwa gleich große Teams,
  • unter der Regie zueinander konkurrierender Dienstleister
     
  • u n a b h ä n g i g  voneinander  d i e s e l b e  Software testen.
     
  • Wenigstens eines dieser Teams sollte seine Testwerkzeuge selbst wählen dürfen.
Ihre Effektivität sollte einem strengen Monitoring durch den Auftraggeber unterliegen, so dass der z.B. alle 6 Monate beiden Teams mitteilen kann, wie effektiv jedes von ihnen im Vergleich zum jeweils anderen gearbeitet hat (Effektivität = Kosten dividiert durch die Summe der Gewichte vom Team aufgedeckter Fehler in den zu testenden Applikationen).
 
 
 
Vorteile dieser Lösung:
  • Keiner der beiden Auftragnehmer kann sich leisten, unerfahrende Leute einzusetzen oder ungeeignetes Werkzeug zu nutzen (denn täte er das, würde sofort erkennbar werden, wie seine Effektivität verglichen mit der seines Konkurrenten zurückgeht).
     
  • Sobald eines der beiden Teams deutlich weniger effizient arbeitet als das andere, sieht man, dass es höchste Zeit wird, es auszutauschen.
     
  • Kosten für den Neuaufbau von Knowhow werden so minimiert, und nie entsteht eine Situation, in der zu wenig gut eingearbeitete Tester verfügbar sind.
     
  • Schon im jeweils eigenen Interesse wird so jedes Team sich optimale Werkzeuge aussuchen und wird bestrebt sein, das eigene Vorgehen ständig zu überdenken und effektiver zu gestalten.
     
  • Diese Lösung ist kostenneutral.
     
  • Sie minimiert die Wahrscheinlichkeit, dass gelegentlicher Austausch des Dienstleisters zu einer gravierenden Fehlentscheidung wird.

 
Man bedenke: Da die Zahl beim Test gefundener Fehler nicht nur davon abhängt, wie geschickt die Tester vorgehen, sondern auch davon, wie gut die Entwickler gearbeitet haben, dürfte diese Lösung der einzige Weg sein, über den ein CIO erreichen kann, dass die Gelder, mit denen er den Test finanziert, optimal eingesetzt sind.

 

 Beitrag 0-415
Mit welcher hoher Inkompetenz von Software-Entwicklern muss man rechnen?

 
 

 
Wie unbeschreiblich inkompetent Software-Entwickler sein können

 
 
Wem diese Aussage als zu stark erscheint, betrachte folgendes Projektdesaster, bei dem es um eine Aufgabenstellung ging, die als gar nicht so schwierig anmutet:
 


Die COMPUTERWOCHE berichtet (Feb 2017):
 
Nach sieben Jahren Entwicklung hat die Bundesagentur für Arbeit das 60 Millionen Euro schwere IT-Projekt ROBASO gestoppt. Die Fehler ließen sich weder zeitnah noch wirtschaftlich genug beheben.
 
Ziel des 2010 begonnenen IT-Projekts ROBASO (Rollenbasierte Oberflächen) war es, den Mitarbeitern in den Arbeitsagenturen das Arbeiten auf einer einzigen IT-Plattform ohne Doppeleingaben und Programmwechsel zu ermöglichen und zu vereinfachen. Dazu sollte ROBASO die diversen IT-Verfahren SOA-basiert miteinander verbinden mit dem Ziel, den Anwendern eine medienbruchfreie Oberfläche mit genau den Informationen und Inhalten bieten, die für die jeweiligen Aufgaben und Rollen notwendig sind.
 
Im praktischen Einsatz im Kundengeschäft zeigte sich dann allerdings, dass die Software zu wenig flexibel war, um der Komplexität der Kundenanliegen gerecht zu werden. Medienberichten zufolge sei es in dem System nicht einmal möglich gewesen, nachträgliche Änderungen wie die Korrektur einer Kontonummer vorzunehmen. Vielmehr hätte man für eine solche kleine Änderung sämtliche Leistungs- und Vermittlungsdaten neu eingeben müssen, hieß es.
 
Die Schwachstellen der Software seien erst bei ihrer Verwendung unter realen Bedingungen erkannt worden, erklärte die BA, immerhin Betreiberin einer der größten IT-Landschaften Deutschlands, in einer Stellungnahme. Nachdem die Defizite nicht zeitnah und wirtschaftlich behoben werden können, habe man sich entschlossen, das Projekt,
 
 
in welches seit seinem Start 2010 insgesamt 60 Millionen Euro investiert wurden,

aufzugeben
.
 


 
Quelle: Bericht der COMPUTERWOCHE vom Feb 2017


 

 Beitrag 0-414
Über Programmierer, Informatiker und Software — Warum hervorragene Informatiker so notwendig gebraucht werden

 
 

 
Wie charakterisiert sich der Beruf des Software-Entwicklers?

 
 
Software-Entwickler sind Personen, die Software entwerfen, implementieren testen und modifizieren. Sie sehen sich — je nach Fähigkeit —
     
  • vorwiegend als Programmierer
     
  • oder vorwiegend als Informatiker.

Worin aber liegt denn nun der Unterschied zwischen beiden — und warum ist die Grenze zwischen ihnen so fließend? Warum gibt es solche, die nur eine Mindest­ausbildung haben (sog. Fachinformatiker) und andere, die studiert oder sogar promoviert haben (und nicht selten vorher Physiker oder Mathematiker waren)?
 
Nun, das ist einfach so:

 
Programmierer codieren, testen oder reparieren Code, den Software Designer (Informatiker) verantworten und spezifiziert haben.
 
Damit sind Programmierer — sofern sie sich ausschließlich für Code verantwortlich fühlen — sozusagen das Fußvolk in der IT-Branche.

 
 
Studierte Informatiker werden i.A. nur wenige Jahre nach Eintritt ins Berufsleben programmieren — anfangs, so 2-3 Jahre, aber auf jeden Fall.
 
Später werden sie vor allem Konzeptpapiere schreiben, d.h. Spezifikationen gewünschter Software erarbeiten oder Kunden helfen, ihre IT-Systeme neuen Anforderungen anzupassen. Sofern sie das auf Dauer nicht können — was leicht passieren kann, wenn sie sich zu wenig mit Softwartechnik beschäftigen —, werden sie vor allem als Manager arbeiten, d.h. als jemand, der organisiert, Kunden akquiriert und Budget verwaltet.
 
Manche enden als die Sorte von IT-Beratern, die nur noch sinnloses Zeug erzählen, was niemand mehr nützt. Das sind jene Personen, die zu wenig Management-Talent haben um als Manager zu arbeiten, sich aber auch technisch nicht mehr wirklich auskennen, da sie nur zu selten gezwungen waren, sich tatsächlich auch mit Code und praktischer Software-Architektur auseinanderzusetzen.
 
Studierte Informatiker sollten sich als Software-Ingenieure verstehen, d.h. als jemand, der beides beherrscht: Die Kunst des Programmierens, ebenso wie die Kunst des Konzipierens und Spezifizierens umfangreicher IT-Landschaften.
 
Von Informatikern erwartet man, dass sie problemlos umfangreiche Papiere in Deutsch ebenso wie in Englisch schreiben können und nie verlernt haben, auch mit Code gut umgehen zu können. Optimalerweise sollten sie sich zudem noch fließend in Englisch mit Ausländern unterhalten können.
 
Sie sollten sich nie zu fein dafür sein, auch selbst mal bei Bedarf ein kleines Hilfswerkzeug zu implementieren mit dem Ziel, ihre eigene Arbeit effizienter und fehlerfreier zu gestalten. Ja, und Management-Talent sollten sie darüber hinaus auch noch haben.
 
Auf jeden Fall sollten Informatiker die Fähigkeit haben, sich extrem schnell in jedes nur denkbare Anwendungsfeld von Software einzuarbeiten — mindestens dann, wenn sie nicht erwarten, lebenslang nur ein und dasselbe Unternehmen bedienen zu müssen. Wer für IT-Beratungs-Unternehmen arbeitet, muss damit rechnen, dass es Zeiten geben wird, wo er alle paar Monate in ein neues Projekt kommt, in dem es um Anwendungsproblematik geht, die er vorher noch nie angetroffen hat.
 
 
 
Wer hat das Zeug zum idealen Informatiker?

 
Wenn an IT interessierte Abiturienten sich überlegen, ob sie eine Lehre (eine sog. "Ausbildung") als Fachinformatiker machen oder doch besser gleich Informatik studieren sollen, sollten sie folgendes berücksichtigen:
 
Als Informatiker erfolgreich werden vor allem Menschen, denen es leicht fällt, auch sehr abstrakt zu denken (so abstrakt wie Mathematiker, aber anders als sie nicht nur in formaler Notation).
 
Man sollte Freude daran haben, Konzepte auch aufzuschreiben (zu spezifizieren und zu dokumentieren) und ständig neu zu verbessern, denn:
 
Gute Dokumentation (und durchdachte Dokumentationstechnik) sind ebenso wichtig wie Code. [ Wem das nicht kler ist, oder wer dem nicht Rechnung trägt, wird nie ein wirklich wertvoller Software-Entwickler sein. ]
 
Gute Informatiker können Code schreiben — aber bevor sie das tun, überlegen sie sich erst mal, welchen Teil davon man generieren könnte (statt ihn von Hand zu schreiben). Der generierbare Teil von all dem, was man bis vor wenigen Jahren noch von Hand schrieb, ist i.A. erstaunlich groß: typischerweise zwischen 50 und 60 Prozent.
 
Wird er wirklich generiert — also  n i c h t  von Hand geschrieben – erhöht das deutlich die Wartbarkeit des entstehenden Systems, senkt seine Entstehungskosten und macht den Code auch deutlich verständlicher, auf jeden Fall aber weit schneller neuen Anforderungen anpassbar.
 
 
Leider gibt es nur wenige Programmierer, die sich gute Code-Generatoren ausdenken und sie dann auch noch geschickt genug zu implementieren verstehen. Viele von ihnen denken zu projektspezifisch oder werden durch hohen Zeitdruck dazu gezwungen, wirklich immer nur Wege zu gehen, die zwar kurzfristig Sinn machen, aber schon mittelfristig eher Sackgasse sind.
 
In der Summe gilt:
 
 
Informatiker sind Software-Ingenieure:
 
Ihr Umgang mit Software ist theoretisch fundiert, zielgerichtet und weitsichtig

 
Es sind Personen, die
     
  • den Umgang mit sich ständig weiter entwickelnden, hoch komplexen Softwaresystemen souverän beherrschen,
     
  • projektübergreifend denken und handeln
     
  • und Detailwissen mit strategischer Weitsicht verbinden:

Sie wissen um den Wert guter, stets aktueller Dokumentation, bestehen auf ihrer Existenz, erhalten ihre Qualität, und können daher stets ganz genau zu sagen, was die von ihnen verantworteten Anwendungen an SOLL-Funktionalität zu welchem Zeitpunkt haben bzw. haben sollten. [ Insider wissen: Personen mit solchem Wissen in ausreichender Genauigkeit sind selten. Wo sie fehlen, kann die IT-Landschaft auf Dauer nicht gesund bleiben. ]

 

 Beitrag 0-145
Warum SCRUM — und undurchdachtes "Agile" — uns in den Abgrund führen

 
 

 
Was SCRUM
 
— von nur wenigen Ausnahmen abgesehen —
 
verdammenswert macht

 
 
In Reaktion auf die Ende der 60-er Jahre eingetretene Software-Krise kam es — zur immerhin ganze drei Jahrzehnte währenden — Blütezeit des Software Engineerings.
 
Ich bin heute noch dankbar, dass ich sie miterleben durfte als jemand, der einige ihrer Pioneere gut gekannt hat: Insbesondere F.L. Bauer und Ernst Denert.
 
Wofür ich sie — aber auch Parnas, Dijkstra und Boehm — heute immer noch bewundere, ist, welche unglaublich große, wirklich durchschlagende Wirkung sie mit ihren Lösungsvorschlägen erzielten:
 
    Jede dieser fünf Personen hat eine wichtige Schlüsselidee erfolgreichen Software Engineerings in die Welt gesetzt bzw. wurde — wie z.B. Ernst Denert —
    nicht müde, sie zu propagieren.
     
    Welch gewaltige, nachhaltige Wirkung gerade Denert damit erzielt hat, das Prinzip der Datenabstraktion auch in der Praxis hoch zu halten, konnte ich als damaliger Mitarbeiter von Softlab hautnah miterleben: Denert war nur etwa 5 Jahre für Softlab tätig (so etwa 1975-1980), hat jene Firma durch sein Wirken
    aber auf die richtige technologische Schiene gesetzt, was bewirkt hat, dass sie noch bis hin zur Jahrtausendwende deutlich erkennbar davon profitiert hat — natürlich auch in Mark und Pfennig, wie man so schön sagt.
     
    Denerts Prinzip » Die beste Praxis ist eine gute Theorie « fand und finde ich immer wieder bestätigt.

 
Gegeben also die großen Methodiker der Jahre 1965-2000, war es kaum zu verstehen, dass keiner von ihnen — ausgenommen vielleicht Tom Gilb — irgendwelche Versuche unternahm, die beispiellose Naivität des Agilen Manifests und all derer, die es wörtlich nehmen, als  p u r e s  G i f t  zu identifizieren.

     
    Sie alle haben tatenlos — und wohl sprachlos vor Verwunderung — zugesehen, wie alles, was sie an methodischem Fortschritt über gut 30 Jahre hinweg erarbeitet hatten, plötzlich unter Berufung auf das Agile Manifest als nicht weiter akzeptabel erklärt wurde.
     
    Unangetastet blieb nur, was schon eingeflossen war in die Konzepte moderner Programmiersprachen.
     
    Erst heute, etwa 20 Jahre nachdem die Agilisten, die Erfinder von SCRUM und die vielen Trainer, die "Agile" und SCRUM zu propagieren als ihre persönliche Goldgrube entdeckt haben, wird so manchem langsam klar, in welch beispiellose Sackgasse uns die unausgegorenen Ratschläge der Agilisten bereits geführt haben:

    Die agile Bewegung nämlich hat bewirkt, dass ein Großteil dessen, was in der Blütezeit des Software Engineerings an methodischem Fortschritt erarbeitet worden war — insbesondere das Wasserfallmodell — heute unter jungen Software-Entwicklern geradezu als  A n t i p a t t e r n  gilt.
     
    Ihnen wird nicht mehr klar, dass Kritik am Wasserfallmodell sich nicht auf das Modell selbst bezieht, sondern lediglich auf seine allzu starre Anwendung, die dann gegeben ist, wenn man sich weigert, einmal abgenommene Teilergebnisse bei Bedarf noch  v o r  Projektende zu revidieren.
     
    Die durch die agile Bewegung in ihrer Naivität verursachte "Entsorgung" methodischen Knowhows geht so weit, dass selbst die Vertreter der jungen Generation, die SCRUM inzwischen als  k o n t r a p r o d u k t i v  erkannt haben — der niederländische Informatik-Dozent Erik Meijer etwa, der mehrfach für seine gute Arbeit als Systemarchitekt bei Microsoft ausgezeichnet wurde —, heute genau das als Abhilfe propagieren, was Mitte der 60-er Jahre die damalige Softwarekrise ausgelöst hatte: der Glaube nämlich, dass es genüge und wünschenswert sei, einfach nur Code zu schreiben.

 
Michael O. Church — heute Manager von Entwicklungsteams bei Google — hat es geschafft, treffend zu charakterisieren, was speziell SCRUM — von seltenen Notfallsituationen mal abgesehen —  v e r d a m m e n s w e r t  macht. Er schreibt (im Juni 2015):
 
    So what are Scrum and “Agile”? I could get into the different kinds of meetings (“retrospective” and “backlog grooming” and “planning”) or the theory, but the fundamental unifying trait is violent transparency, often one-sided. Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.
     
    Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high). Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.
     
    In addition to being infantilizing and repellent, Scrum induces needless anxiety about microfluctuations in one’s own productivity. The violent transparency means that, in theory, each person’s hour-by-hour fluctuations are globally visible– and for no good reason, because there’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.

 
Seine ausführliche, das Problem genau identifizierende Analyse schließt mit der Feststellung:
    It’s time for most of "Agile" and especially Scrum to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and "user stories" are how things have always been done. This ought to be prevented; the future integrity of our industry may rely on it. "Agile" is a bucket of nonsense that has nothing to do with programming and certainly nothing to do with computer science, and it ought to be tossed back into the muck from which it came.


 

 Beitrag 0-Agile
Agilität ist unverzichtbar — in Form vom "Agile" und SCRUM aber sicher gefährlich

 
 

 
Über falsch verstandene "Agile" Methodik

 
 
Wer mich kennt der weiß:
 
Ich bin ein erklärter Gegner der im Manifesto postulierten Methodik
und der daraus entstandenen — völlig ungeeigneten — Software-Entwicklungs-Modelle,
für die heute SCRUM schon fast als repräsentativ gilt.

 
 
Am deutlichsten habe ich meine Warnung vor solch verwerflichen Formen von Agile wohl zusammengefasst auf den beiden Seiten
 
 
Man darf daraus nun aber nicht schließen, dass ich ein Gegner heute notwendig gewordener Agilität wäre. Ganz im Gegenteil: Mir ist klar, dass spätestens ab der Jahrtausendwende agiles Vorgehen unverzichtbar geworden ist — die im Manifesto vorgeschlagene Lösung allerdings kann nur ins Verderben führen (denn sie ist undurchdacht und beispiellos naiv).
 
Meine Ansicht darüber, wie Agilität verstanden und gelebt werden sollte, ist definiert auf den beiden Seiten:
 
 
Um zu zeigen, dass ich keineswegs der einzige bin, der "Agile" und SCRUM für absolut ungeeignet — ja sogar gefährlich — hält, seien hier Links hin zu Meinungen Dritter aufgelistet, die ebenso denken wie ich und die — das zählt wirklich — aus negativer Erfahrung heraus zu dieser Einstellung kamen:
 
Historisch gesehen, gilt:
 
Die extrem bürokratisch angelegten Vorgehensmodelle, die
 
  • zunächst in den USA durchs DoD (Department of Defence) zur Pflicht gemacht wurden,
     
  • dann aber — in Nachahmung davon — auch in Deutschland als sog. V-Modell (entwickelt von der IABG) sogar Behördenstandard wurden,

m u s s t e n  irgendwann zu einer Gegenreaktion führen. Sie kam in Form der Agilen Bewegung, war aber nicht durch entsprechende Forschung unterstützt, und hat daher zu einem geradezu lächerlichen Modell geführt, desssen Aushängeschild sich SCRUM nennt.
 
Erst nach 2000 wurde einigen wenigen klar, wie ernst man die Gefahren dieser neue Bewegung nehmen muss. Weltweit anerkannte Methodiker des Software-Engineerings, die ihre Stimme hätten erheben können, waren da aber just schon alle aus dem aktiven Berufsleben ausgeschieden. Nur so ist erklärbar, dass diesem ganzen Unsinn bis heute kein Einhalt geboten wurde ...
 
 
 
Gebhard Greiter, Jan 2016


 

 Beitrag 0-182
What is — and how long can you be — a competent Software Architect?

 
 

 
What is a Software Architect?

 
 
We agree with the opinion presented in Every Developer Should Be an Architect where we read:
 
Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).
     
  • Focus scope: Programmers focus on details while architects focus on "the big picture".
     
  • Leadership: Programmers are led, architects lead.
     
  • Seniority: Architects have been doing it longer than programmers.
     
  • Cachet: Architects are important visionaries while programmers do relative grunt work.
     
  • Tech Selection: Architects choose while programmers live with the choices.
     
  • Skill: Architects are more technically skilled than most programmers.
     
  • Organizational interaction: architects deal more with “the business” in meetings than programmers.
     
  • Pay: Architects make more than programmers.
     
  • Value: Architects understand why an architect is more valuable than a programmer.

This is how the industry at large perceives this distinction:
 
Architects are more tenured, more important, more valuable — they are technical people in high demand, but are often seen as being too important to do the things that earned them their stripe (writing code).
 
This is why compentent architects have to fight for time to keep up to date:
 
 
As soon as they do not write code anymore ( prototyping new solutions ),
 
they will no longer be competent architects (!).

 
 
Erik Dietrich & Gebh. Greiter, Jan 2016


 

 Beitrag 0-183
Why an Application Architect is more that just a competent Requirements Manager (Product Owner)

 
 

 
What is a compentent Solution Architect?

 
 
He/she should be
     
  • a competent Requirements Manager
     
  • as well as
     
    • a creative Software (Black Box) Architect
    • and end-to-end test designer.

Testability of an application, e.g., is something a perfect solution architect will have to guarantee.
 
Maintainability of the solution to be created — until far into the future — is important as well.
 
 
For this to achieve, the architect is to establish
     
  • a process to garantee an always up to date specification of requiremments as well as black box interface design,
     
    Both documents are to be implemented in a form showing clearly all the differences between the implemented and the not yet implemented version of the requirements and as well as the black box interface of the system. [ New text shown in red might be a suitable soltion. ]
     
  • a process to guarantee an always up to date regression test suite as well as nice, complete documentaion of the results of each end-to-end test run,
     
  • a bug tracking system with suitable reporting functionality,
     
  • documentation of all budget consumed so far for what purpose (in order to have reliable data on which cost estimates for the implementation of not yet implemented, though later on required changes or functionality can be based on).

 
Note: Creating documents showing only the difference between two versions of the system is definitely NOT a good thing (because then, to get a complete picture, readers will always have to consult documentaion of all the versions implemented so far.

 

 Beitrag 0-519
Beispiele im Notfall versageneder IT-Systeme im deutschen Bildungsbereich

 
 

 
Beispiele zu wenig professioneller deutscher IT-Systeme

     
  • Die Lernplattformen deutscher Bundesländer:
     
    Sie erwiesen sich, als man sie erstmals auf breiter Basis nutzen wollte, als für Schüler wie Lehrer kaum zumutbar:

     
    Ihre Qualität beim ersten Versuch, sie wirklich einzusetzen, war kaum die typischer Prototypen — Zu wenig professionall konfiguriert, allzu häufiger stundenlanger Ausfall ... und das bei so gut wie allen dieser länderspezifischen Lösungen.
     
    Bei all diesen Pannen drängt sich die Frage auf, ob ein einheitliches bundesweites System nicht besser und zuverlässiger wäre?
     
    Doch vor solch einer Kooperation scheuen die meisten Bundesländer zurück. Dennoch beauftragte das Bundesbildungsministerium 2017 das Potsdamer Hasso-Plattner-Institut (HPI) damit, eine nationale Cloud für Schulen zu entwickeln, mehrere Millionen Euro flossen.
     
    Der Zuspruch aus den Ländern war zunächst aus politischen, dann aber auch aus technischen Gründen gering, nachdem das Bundesbildungs­ministerium früher als geplant Corona-bedingt im Frühjahr allen 40 000 Schulen in Deutschland erlaubte, die HPI-Cloud zu nutzen. Denn auch dieses Renommierprojekt hatte — als es im Mai 2020 der COVID-19-Pandemie wegen seine große Chance bekam, sich zu bewähren — mit schier unglaublichen Datenschutzlücken zu kämpfen:
    Schon nach wenigen Klicks waren Namen von Schülern und Lehrern frei im Netz zu lesen (!).
     
    Neben der Politik haben also ganz klar auch die Software-Entwickler und das IT-Personal der Systembetreiber versagt.
     
    Klaglos funktionieren nur die entsprechenden Systeme der Hochschulen, welche US-amerikanische Software nutzen.


     

 Beitrag 0-520
Beispiele erfolgreicher, großer IT-Migrationsprojekte

 
 

 
Beispiele erfolgreicher, großer IT-Migrationsprojekte

 

 Beitrag 0-544
Woran sich zeigt, dass die IT-Industrie noch nicht gelernt hat, Software professionell genug zu testen

 
 

 
Was es bedeuten kann, wenn Software-Tester versagen

 
 
In ausgesprochen dramatischer Weise wird uns das vor Augen geführt durch den sog. "Postmaster-Skandal" in Großbritannieren.
 
Was war passiert:
 
Fast genau zur Jahrtausendwende hat die britische Post-Behörde ein neues ERP-System in Betrieb genommen: Das durch Fujitsu entwickelte Horizon-System.
 
Was — wegen damals ganz offenbar viel zu schlampig durchgeführtem Test — als Systemtest auf Seite des Herstellers, aber auch als Abnahmetest auf Kundenseite — damals nicht aufgedeckt worden ist war, dass dieses System im Rahmen automatisierter Buchhaltung ganz unglaublich viele gravierende Fehler gemacht hat.
 
Dieses Fehlverhalten des Systems hat dazu gefühtrt, dass man — über ganze 14 Jahre hinweg — immer wieder Postangestellte des Betrugs bezichtigt, angeklagt, znd verurteilt hat: < 2 Genauer. Im Durchschnitt ist fast jede Woch einer der Postmaster in diesem Sinne auf ganz dramatische Weise ungerecht behandelt worden:
     
  • Mindestens 70 von ihnen sind deswegen sogar zu längeren Haftstrafen verurteilt worden.
     
  • Erst ab 2019 gelang es einigen von ihnen, ihren Fall vor Gericht nochmals aufgerollt zu bekommen.
     
  • Derzeit (Ende 2021) sind 72 der weit mehr als 700 damals verurteilten Postmaster rehabilitiert worden.
     
  • Es wird erwartet, dass viele weitere ebenfalls reahabilitiert werden müssen.
     
  • Wie sich jetzt offenbart, hat man (als Folge der Fehler des Systems) wahrscheinlich mehr als 2400 Postbeamte zu Unrecht beschuldigt.

 
 
Dieser Bericht basiert auf folgenden Presseberichten:
 
Fragen wir uns jetzt aber, es zu dieser schrecklichen Situation kommen konnte:
 
Offensichtlich erscheint:
     
  • Im Zuge der Übergabe des ERP-Systems vom Hersteller (Fujitsu) an den Auftraggeber (die Post-Behörde in UK) ist jene Software ganz offensichtlich viel zu wenig und deutlich zu inkompetent getestet worden.
     
  • Der erst Jahre später zugegebenen ganz gravierenden Fehler des Systems wegen (von denen einige bis heute nicht behoben sein sollen) haben entweder die Tester oder die verantwortlichen Manager oder gar alle zusammen grob versagt.
     
  • An Testern müssen beteiligt gewesen sein:
       
    • ein Test-Team auf Seiten des Auftragnehmers
       
    • dann aber auch ein Test-Team, das im Auftrag des Auftraggebers (der Post) Abnahmetest durchzuführen hatte.
       
    • Wie soll man von der Kompetenz beider denken, nachdem sie derart gravierend versagt haben?
       
    • Und wie soll man die Aufrichtigkeit und Kompetenz der verantwortlichen Manager beider Seiten beurteilen, nachdem sie sich mindestens 14 Jahre geweigert haben, Fehler des Systems anzuerkennen, aber stattdessen Hunderte von kleiner Angestellten des Betrugs bezichtigt haben – was schließlich zu deren Verurteilung geführt hat? Und in Folge davon zum Auseinanderbrechen ganzer Familien.
       
      |
       
    • Dass man auch der Justiz den Vorwurf machen muss, nicht hinreichend genau ermittelt zu haben, ist natürlich ebenfalls richtig, hat jetzt aber nichts mit viel zu wenig professioneller Software-Entwicklung zu tun.
       
      In diesem Zusammenhang ist interessant, dass einigen Managern der Post der Vorwurf gemacht wird, Unterlagen geschreddered zu haben, um deren Einsicht von ihnen angeklagte Untergebene gebeten hatten mit dem Ziel sich verteidigen zu können. Das Prinzip "ImZweifel für den Angeklagten" scheint hier nicht funktioniert zu haben, da die Richter entweder befangene Gutachter zu Rate zogen oder niemand auch nur auf den Gedanken kam, dass ein nun schon über Jahre hinweg genutztes IT-System derart falsch arbeiten könnte.

 
 
Was ergibt sich hieraus an Anforderungen für
 
ausreichend professionell organisierten Software-Test?

 
 
Können die Kunden von Software-Entwicklern, insbesondere deren Großkunden, es wirklich noch länger akzeptieren, dass niemand versucht (und es bisher auch keine Methodik dafür gibt), die Effektivität von Software-Testern — angefangen bei einzelnen Personen bis hin zu ganzen auf Test spezialisierten Teams — irgendwie zuverlässig und aussagekräftig quantifizieren zu können?
 
Viel spricht dafür, dass es heute ausreichenden Test nur für Software gibt, die durch das sie implementierende Unternehmen selbst genutzt werden soll.
 
In jedem anderen Fall – so meine Beobachtung – gilt:
     
  • Erstens wird durch die Entwickler der Software viel zu wenig getestet, insbesondere, was die Korrektheit von System zu errechnender Daten betrifft.
       
    • Das liegt vor allem daran, dass sie für die Behebung auftretender Fehler nur bis hin zum Ende der Gewährleistungsfrist zur Kasse gebeten werden, danach aber an jedem Fehler verdienen, da sie ihn zu reparieren ja extra bezahlt werden.
       
    • Es liegt aber auch daran, dass sie stets nur für ihren Code verantwortlich zeichnen, aber niemals für Schäden, die sein falsches Funktionieren verursacht hat.

     
  • Zum zweiten aber ist der Kunde des Software-Entwicklers nicht selten mit Abnahmetest überfordert, ohne dass er sich dessen bewusst ist.
     
    Gerade bei ERP-Systemen ist das ganz offensichtlich.

 
Angesichts dieser Problematik bleibt zu fragen:
 
Warum gibt es bis heute – soweit ich sehen kann – nicht einen einzigen Lehrstuhl für Informatik, der sich dieser Problematik annimmt, sie also zu seinem wichtigsten Forschungsgegenstand macht?

 

 Beitrag 0-149
Microservices: The most extreme SOA Solution

 
 

 
What are Microservices?

 
 
The concept of microservices is probably best defined here or by Martin Fowler, or at any of the first google results for "microservices".
 
Mircoservices are separately deployable modules that communicate with each other in order to complete a business goal, and each microservice is limited to just a small, well-defined scope:
 
Product purchasing is one microservice, user registration is another one, "Current Promotions" may be a third one, and so on.
 
But Martin Fowler also says:

 
 
Don’t even consider microservices unless you have a system that’s too complex to manage as one piece.
 
 
The majority of software systems should be built as a single monolithic application.
 
If you pay attention to good modularity within that monolith, this may be enough.


 
 
Universally, if you are sure that the network and coordination overhead of microservices will be negligible compared to the amount of work being done and the flexibility gained, then microservices are a valid approach. But that may be rare. Martin Fowler talks about complexity vs productivity, so, in theory, if you know in advance how complex your project is going to be, you  m a y  have a valid microservices use case.
 
Separating a piece of functionality into a service of its own and communicating with it through web services should not be something that deserves so much attention. But apparently we have to say » No, it’s not for every project « and » Yes, the approach is not dumb by itself, there are cases when it is useful «.

 

  Beitrag 2027-8
Zur Fehlerdichte in durchaus brauchbarer Software

 
 
Bauhof aus 2027-6:
Grtgrt aus 2027-5:
 
Für beide Arten von Fehlern gilt, dass hinreichend ausführlicher Test sie entdeckt haben sollte, so dass man sie beseitigen konnte, noch bevor das Programm dem Anwender übergeben wurde.

Hallo Grtgrt, ...

Vor langer Zeit habe ich mal gelesen, dass die vollkommene Fehlerfreiheit einer hinreichend komplexen Software niemals bewiesen werden kann. Ist dir das nicht bekannt?


Ja, Eugen, das ist mir bekannt.

Und das ist schon allein deswegen so, weil die SOLL-Funktionalität gegebener Software i.A. gar nicht bis ins allerletzte Detail hinein vorweg definiert wurde (jedenfalls nicht hinsichtlich von Details, die man zunächst als nicht wichtig erachtet hat).

Aber ich schrieb ja auch "Für beide Arten von Fehlern gilt, dass hinreichend ausführlicher Test sie entdeckt haben  s o l l t e  ..." (womit dann klar sein sollte, dass es durchaus Fehler geben kann, die man nicht entdeckt  h a t ... Es werden i.A. aber nur wenige sein, oder solche, die ganz selten auftreten, so dass man mit ihnen leben kann).

Wissenschaftliche Untersuchungen (z.B. eine der Carnegie Mellon University aus 2003) belegen, dass moderne Software, wenn sie in Betrieb genommen wird, i.A. immer noch bis zu fünf Fehler pro 1000 Lines of Code enthält; sprich: etwa 1 Fehler auf je 3 DIN A4 Seiten manuell erstellten Source Codes. Selbst in den besten aller je untersuchten (größeren) Programme fand sich immer noch 1 Fehler in je 7500 Zeilen Code (durchschnittlich).

Beispiele von anderer Seite bestätigen das: Als Windows 2000 auf den Markt kam, enthielt sein Code — nach Microsofts eigener Schätzung — etwa ein wirkliches, aber zu dem Zeitpunkt noch gar nicht genau unter­suchtes Problem in je 1000 Lines of Code. Dennoch war Windows 2000 ein wirklich brauchbares System.


Gruß, grtgrt
 

 Beitrag 0-195
Software als ernst zu nehmende Gefahr

 
 

 
Software macht angreifbar

 
 
Der internationale Zahlungsverkehr zwischen Banken wird über Swift abgewickelt: ein Softwaresystem, welches weltweit etwa 2000 Mal installiert ist. Zentralbanken, Geschäftsbanken und Investmentfirmen nutzen es.
 
Lange galt Swift als sicher. Im Februar 2016 aber gelang es Cyber-Dieben per Swift 81 Mio Dollar von der Zentralbank in Bangladesh zu erbeuten (genauer: unberechtigterweise auf ein philippinisches Konto zu überweisen, von der das Geld dann weiter an Spielkasinos floß).
 
Diese Angreifer hatten eigentlich Zahlungen in Höhe von einer Milliarde Euro angewiesen. Doch ein Überweisungsauftrag, mit dem das Gros des Geldes transferiert werden sollte, war offenbar adressiert an eine "Shalika Fandation". Nur dieser Rechtschreibfehler im englischen Wort foundation (Stiftung) machte Mitarbeiter bei der Deutschen Bank misstrauisch. Ihre Anfrage bei der Zentralbank in Bangladesh hat den Angriff dann auffliegen lassen.
 
Die Behörden in Bangladesh gehen davon aus, dass die Hacker in die Computer der Notenbank eindrangen und sich so Zugang zu deren Swift-Installation verschafft haben.
 
Verdacht hatte man wohl schon vorher geschöpft, doch die Betrügersoftware verwischte die Spuren, so dass lange niemand etwas beweisen konnte. Über die Schadenshöhe insgesamt ist nichts bekannt.
 
 
Dieser Diebstahl beweist erneut die wachsende Gefahr von Hackerangriffen in der Bankenbranche. So gab die russische IT-Sicherheitsfirma Kaspersky Lab in 2015 bekannt, dass Cyberkriminelle innerhalb von zwei Jahren rund eine  M i l l i a r d e  Dollar von weltweit etwa hundert Geldhäusern gestohlen hätten. Sie hätten sich Zugang zu internen Netzwerken verschafft und so Geldautomaten manipuliert. (Quelle: fab/Reuters)
 
 
Ganz allgemein gilt:
     
  • Die Zahl gezielter Hacker-Attacken hat weltweit schon die Jahre vorher stark zugenommen. So haben etwa 2007 Cyberangriffe gegen Banken, Ministerien, das Parlament und die Rundfunkanstalten ganz Estland lahmgelegt.
     
    Das Netzwerk des Deutschen Bundestages ist 2015 gehackt worden — es hat Wochen gedauert, es neu zu installieren.

     
  • Aber auch kleine Firmen sind ernsthaft bedroht: Nach Aussage von BDI-Präsident Ulrich Grillo (im April 2016) ist inzwischen schon etwa jedes zweite Unternehmen attackiert worden — in 3 von 4 Fällen sei der Schaden groß bis existenzgefährdend gewesen.
     
    Nicht selten ging es um Sabotage und Spionage. Selbst Information über Kontakte, Organisationsstrukturen, Zulieferer und Mitarbeiter können für Angreifer großen Wert haben.

 
Der Gefahr zu begegnen, haben sich die großen deutschen Wirtschaftsverbände mit den Sicherheitsbehörden verbündet und die Initiative Wirtschaftsschutz ins Leben gerufen. Sie informiert und berät.
 
 
Quelle: SZ vom 27.4.2016, Wirtschaftsteil

 
 
Lies auch:
  • Folgenreiche Cyberangriffe auf Unternehmen — enorm hoher Schaden, Angreifer oft unbekannt
     
    Anfang Juli 2016 wurde ein Hacker-Angriff auf die US-Fastfood-Kette Wendy’s bekannt. Auf den Kassensystemen wurde Malware gefunden – zunächst war von weniger als 300 betroffenen Filialen die Rede, später von bis zu 1000. Wie sich dann herausstellte, waren die Malware-Attacken schon seit Herbst 2015 im Gange.