Entwicklung

Warum sich die ISO/IEC/IEEE-Normen im Systems Engineering selbst widersprechen – und warum das kein Zufall ist. Wer im Systems Engineering arbeitet, kennt das Gefühl: Man kauft eine Norm für mehrere hundert Euro, liest sie durch, und stellt fest – das steht doch schon in der anderen Norm, die man letzten Monat gekauft hat. Nur anders formuliert. Und manchmal widersprüchlich. Ich habe mir die sieben Kernnormen des Requirements Engineering vorgenommen – ISO/IEC/IEEE 29148, 15288, 12207, IEEE 830, IEEE 1362, ISO/IEC/IEEE 24748 und 24765 – und systematisch verglichen. Das Ergebnis ist ernüchternd.

Oder: Warum wir für 30 Normen mehr ausgeben als für 400 Vorgaben Es gibt diese Momente in Unternehmen, in denen man sich fragt: Haben die eigentlich noch alle Latten am Zaun? Hier die Fakten: Im Finanzbereich geben Unternehmen zigtausende Euro für ERP-Systeme, WaWi-Software und Controlling-Tools aus. Der Grund? Sie müssen typischerweise etwa 30 maximal 110 Rechtsvorgaben im Steuerrecht. Klarheit und Wahrheit – so will es das Finanzamt. Jeden Beleg, jede Transaktion, jede Bewegung lückenlos dokumentiert, revisionssicher, GoBD-konform.

Immer wenn man denkt es geht nicht blöder, kommt man an “Experten”, welche da doch noch Potential zeigen. Der Text, welcher dort für eine Erkennungsmaßnahme und ebenso als Vermeidungsmaßnahme im Design verwendet und mit der Auftretenswahrscheinlichkeit 2 sowie Entdeckungswahrscheinlichkeit 2 bewertet wurde. TÖRÖ, TÖRÖ > **An weiteren Maßnahmen zur Risikominimierung wird gearbeitet. Dabei sollen erste Erfahrungen aus dem Prozess berücksichtigt werden und mit einfließen.** > > Abgeschlossene Maßnahmen aus einer FMEA (Sic!)

#AI, #KI, #Agile, #DevOps, #Startup, #Digitalisierung, #Unterbrechung, #Cloud, #IOT, #Industrie4.0, #VirtualReality, #Scrum, #RapidPrototyping, #DesignThinking, #Cyber, #Hashtag # Welches Buzzword fehlt in der Narrenkonferenz des Buszzword Bullshit Bingo noch? #SaneThinking, #SoundThinking, #SystemsEngineering, #ComplexSystems, #embedded # #GesunderMenschenVerstand # Es könnte sehr langweilig sein, es zu lesen, denn das Folgende ist allgemein bekannt. Es hilft jedoch nicht weiter, wenn Sie die Grundlagen ignorieren, auch wenn es heute durchaus üblich ist.

Ein Lösungsansatz zur Restrukturierung # © 2008-2021 Thomas Arends # Kurzbericht zur Lösung einer Gefahrensituation in einem Unternehmen Gefahrensituationen in Unternehmen Ein Lösungsansatz Schreibfehler in diese Seite werden nicht korrigiert Vorwort: # Zu aller erst etwas ganz ganz ganz Wichtiges.

30 (Software)-Engineering-Themen, die seit 30 Jahren konstant geblieben sind # Anfängliche Anforderungen sind selten zu mehr als 50% vollständig. Die Anforderungen wachsen während der Entwicklung mit etwa 2% pro Kalendermonat. Etwa 20 % der anfänglichen Anforderungen verzögern sich bis zu einem zweiten Release. Das Finden und Beheben von Fehlern ist die teuerste Software-Aktivität. Das Erstellen von Papierdokumenten ist die zweitteuerste Softwareaktivität. Codierung ist die drittteuerste Softwareaktivität. Meetings und Diskussionen sind die viertteuerste Aktivität. Die meisten Formen des Testens sind weniger als 35% effizient beim Finden von Fehlern. Die meisten Formen des Testens berühren weniger als 50% des zu testenden Codes. Es gibt mehr Fehler in den Anforderungen und im Design als im Quellcode. Es gibt mehr Fehler in Testfällen als in der Software selbst. Defekte in Anforderungen, Design und Code betragen durchschnittlich 5,0 pro Funktionspunkt. Die Gesamteffizienz der Fehlerbeseitigung vor der Freigabe beträgt im Durchschnitt nur etwa 85 %. Etwa 15 % der Softwaredefekte werden an Kunden ausgeliefert. Ausgelieferte Defekte sind teuer und verursachen Kundenunzufriedenheit und technische Schulden. Etwa 5% der Module in Anwendungen enthalten 50% aller Defekte. Etwa 7 % aller Fehlerreparaturen führen versehentlich zu neuen Fehlern. Software-Wiederverwendung ist nur bei Materialien effektiv, die sich Null-Fehler nähern. Etwa 5 % der Software-Outsourcing-Verträge enden in einem Rechtsstreit. Etwa 35% der Projekte > 10.000 Funktionspunkte werden abgebrochen. Ungefähr 50% der Projekte > 10.000 Funktionspunkte kommen ein Jahr zu spät. Der Fehlermodus für die meisten Kostenschätzungen ist, zu optimistisch zu sein. Die Produktivitätsrate in den USA liegt bei etwa 10 Funktionspunkten pro Mitarbeitermonat. Die Auftragsumfänge für die Entwicklung liegen bei etwa 150 Funktionspunkten. Der Auftragsumfang für die Wartung beträgt ca. 750 Funktionspunkte. Entwicklung kostet in den USA etwa 1200 $ pro Funktionspunkt (Bereich < $500 bis > $3000). Die Wartung kostet ca. 150 $ pro Funktionspunkt pro Kalenderjahr. Nach der Auslieferung wachsen Anwendungen während der Nutzung um etwa 8 % pro Kalenderjahr. Die durchschnittliche Fehlerbehebungsrate liegt bei etwa 10 Fehlern oder Defekten pro Monat. Programmierer und Manager benötigen jährlich etwa 10 Tage Schulung, um auf dem neuesten Stand zu bleiben.

Maschinelles Lernen # ist wohl der bessee Ausdruck. Einer Maschine werden immer wieder gleiche und ähnliche Dinge gezeigt und die Maschine entwickelt daraus Muster und errechnet Warscheinlichkeiten. Diese Ergebnisse werden mit jedem Durchlauf verändert. Politische Entscheidungen # Glauben Sie wirklich, das KI alles in der Zukunft steuern wird? # Wie in “Terminator” - Die Maschinen übernehmen die Kontrolle? Nun denn - in Anbetracht der Entscheidungen der “Eliten”, der “Politik” und der “Führungskräfte“ mag es wirklich intelligenter sein, Maschinen die Entscheidung zu überlassen… Das Problem ist jedoch – wer hat Sie programmiert – wer hat Sie gelehrt?

Sie ??müssen?? digitalisieren!! Müssen tun Sie gar nicht! Jeder weiß es wieder am Besten. Bei der Digitalisierung jedoch ist eines klar. Ohne Prozesse keine Digitalisierung. Wir haben so viele Dinge, welche wir „aus dem Bauch heraus“ tun, dass es uns schwerfällt das Ganze zu beschreiben. Aber ohne die Definition der Prozesse, können Sie nicht digitalisieren. Digitalisieren heißt Automatisieren. Aber was automatisieren Sie? Wenn Sie Ihre Prozesse nicht kennen und die zugehörigen „digitalisierungsfähigen Artefakte“ wird das nix.

Die Boeing 737 MAX 8 ist ein klassisches Beispiel für ausufernde Qualitätskosten. Das Dieselgate muss man auch nicht weiter ausführen. Das Desaster mit dem VW ID.3 (Verzögerte Auslieferung und Task Force) gehört auch dazu. Die Liste ist – mehr als lang. Das „magische Dreieck“ – Zeit, Qualität und Kosten wird immer wieder angesprochen. Da denkt man, dass es durch „Agilität“ besser wird, die Erfahrung stützt diese Theorie bis heute nicht. Absturz ## Ausgangssituation Die klassische Ausgangssituation in fast jedem Projekt heutzutage ist:

Jeder Verkäufer einer Software erklärt Ihnen, wie man mit seiner Software dafür sorgt, dass Geld gespart wird. Und es ist richtig, die Einführung von bestimmten IT-Systemen hat dafür gesorgt, dass Unmengen an Produkten schneller und oder besser hergestellt werden können. Aber viel wichtiger - die Prozesse müssen passen. Aber zunächst In der Produktion # ist durch entsprechende Logistiksysteme, Maschinensteueranlagen, Lagerverwaltungssystemen etc. ein signifikante Veränderung über die letzten Jahre eingetreten.