VUCA und die Herausforderung der IT

VUCA in der IT stellt Herausforderungen und Chancen am Beispiel einer Cloud-Migration

Die IT-Welt ist ein dynamisches, oft chaotisches Umfeld, das stark von VUCA geprägt ist.

VUCA steht für

  • Volatility (Volatilität)
  • Uncertainty (Unsicherheit)
  • Complexity (Komplexität)
  • Ambiguity (Mehrdeutigkeit)

Diese Begriffe beschreiben die Herausforderungen moderner IT-Landschaften, insbesondere in einer Ära, die von Digitalisierung, Automatisierung und globaler Vernetzung geprägt ist. Um zu verdeutlichen, wie VUCA die IT beeinflusst, betrachten wir die Cloud-Migration eines mittelständischen Unternehmens.

Volatilität: Schnelle Veränderungen

In der IT sind Technologien, Marktanforderungen und regulatorische Rahmenbedingungen ständig im Wandel. Bei der Entscheidung, von einer On-Premises-Infrastruktur zu einer Cloud-Lösung zu wechseln, muss das Unternehmen auf plötzliche Veränderungen reagieren. Ein Beispiel könnte die Ankündigung eines Cloud-Anbieters sein, eine bestimmte Technologie oder einen Service einzustellen. Diese Volatilität erfordert schnelle Entscheidungen und flexible Anpassungen, um den Geschäftsbetrieb nicht zu gefährden.

Beispiel: Während der Cloud-Migrationsphase kündigt der bevorzugte Anbieter neue Preisstrukturen an, die die Betriebskosten erheblich erhöhen könnten. Das Unternehmen muss nun alternative Anbieter evaluieren oder die Projektkosten neu kalkulieren.

Unsicherheit: Unvorhersehbare Ergebnisse

Die IT-Projekte sind häufig mit Unsicherheiten behaftet. Bei der Cloud-Migration können unterschiedliche Fragen aufkommen, wie

  • Werden die neuen Systeme reibungslos funktionieren?
  • Wird die Performance ausreichen?

Solche Unsicherheiten erschweren die Planung und die Definition klarer Projektziele.

Beispiel: Trotz umfangreicher Tests stellt sich nach der Migration heraus, dass eine unternehmenskritische Anwendung in der neuen Cloud-Umgebung langsamer läuft. Die IT-Abteilung muss ad hoc nach Lösungen suchen, ohne genau zu wissen, wie lange dies dauern wird.

Komplexität: Vielschichtige Abhängigkeiten

Die IT-Systeme sind heute hochgradig komplex und miteinander vernetzt. Bei der Cloud-Migration müssen nicht nur Daten und Anwendungen verschoben werden, sondern auch Sicherheitskonzepte, Netzwerkkonfigurationen und Compliance-Vorgaben berücksichtigt werden.

Beispiel: Während der Migration entdecken die IT-Teams, dass bestimmte ältere Anwendungen nicht mit der Cloud kompatibel sind. Um die Migration erfolgreich abzuschließen, müssen entweder die Anwendungen modernisiert oder alternative Lösungen entwickelt werden – eine komplexe Herausforderung.

Mehrdeutigkeit: Unklare Rahmenbedingungen

Mehrdeutigkeit entsteht, wenn Informationen oder Anweisungen nicht eindeutig sind. In der Cloud-Migration zeigt sich dies beispielsweise bei der Interpretation von Service-Level-Agreements (SLAs) oder Datenschutzanforderungen.

Beispiel: Der Cloud-Anbieter garantiert eine Verfügbarkeit von 99,9 %, was zunächst ausreichend klingt. Doch bei genauerer Analyse stellt sich heraus, dass dies nur für bestimmte Regionen gilt, die nicht mit den Anforderungen des Unternehmens übereinstimmen. Diese Mehrdeutigkeit kann zu Fehlentscheidungen führen.

Strategien zur Bewältigung von VUCA in der IT

Um mit VUCA effektiv umzugehen, gibt es bewährte Ansätze.

  • Agilität fördern: Ein agiles Projektmanagement ermöglicht schnelle Anpassungen an volatile Bedingungen.
  • Transparenz schaffen: Klare Kommunikation und umfassende Risikoanalysen können Unsicherheiten reduzieren.
  • Komplexität managen: Der Einsatz von spezialisierten Tools, wie automatisierten Monitoring-Systemen, hilft, den Überblick zu behalten.
  • Klarheit durch Schulungen: Mitarbeiter müssen regelmäßig geschult werden, um Mehrdeutigkeit in technischen und rechtlichen Fragen zu minimieren.

Fazit

Das Beispiel der Cloud-Migration zeigt, wie VUCA die IT-Welt prägt und welche Herausforderungen Unternehmen meistern müssen. Mit den richtigen Strategien können jedoch aus Unsicherheiten Chancen werden. Die Fähigkeit, schnell und flexibel auf Veränderungen zu reagieren, ist ein entscheidender Erfolgsfaktor in der digitalen Transformation. VUCA mag komplex erscheinen, doch es bietet auch die Möglichkeit, innovative Lösungen zu entwickeln und Wettbewerbsvorteile zu schaffen.

Netzneutralität des Internet in den USA aufgehoben

Das Urteil zur Netzneutralität des United States Court of Appeals for the Sixth Circuit vom 2. Januar 2025 bestätigt die Entscheidung der Federal Communications Commission (FCC), die Netzneutralität in den USA aufzuheben.

Die Netzneutralität gewährleistet seit Jahrzehnten, dass alle Daten im Internet gleich behandelt werden, unabhängig von Inhalt, Absender oder Empfänger. Durch die Aufhebung dieser Regelung können US-Internetdienstanbieter nun bestimmten Datenverkehr priorisieren oder verlangsamen oder mit Geofencing eingrenzen.

Mögliche Auswirkungen auf Nutzer von US-Diensten in Deutschland

  1. Änderungen bei US-Diensten: US-basierte Online-Dienste könnten ihre Datenübertragungsstrategien anpassen, um in den USA bevorzugte Behandlung zu erhalten. Dies könnte indirekt die Qualität oder Geschwindigkeit dieser Dienste für Nutzer in Deutschland beeinflussen.
  2. Wettbewerbsdruck auf europäische Anbieter: Sollten US-Dienste durch die neuen Regelungen Wettbewerbsvorteile erlangen, könnten europäische Anbieter unter Druck geraten, ähnliche Praktiken zu fordern, was die Debatte über die Netzneutralität in Europa beeinflussen könnte.
  3. Regulatorische Diskussionen in Europa: Obwohl die Netzneutralität in der EU gesetzlich verankert ist, könnten die Entwicklungen in den USA Diskussionen über die zukünftige Ausgestaltung der Netzneutralität in Europa anregen.


    Es ist jedoch wichtig zu betonen, dass die rechtlichen Rahmenbedingungen in Deutschland eigenständig sind. Die Aufhebung der Netzneutralität in den USA hat keine direkte rechtliche Wirkung, aber eine starke politische Wirkung auf auf die Regulierung im US-abhängigen Deutschland. Daher werden langfristig technische und marktbezogene Entwicklungen, die aus der US-Entscheidung resultieren, auch hierzulande spürbar werden

Technische Auswirkungen

  1. Verzögerungen im Datenfluss
    • US-Serverpriorisierung: Daten von US-Diensten, die in den USA gehostet werden, könnten bevorzugt behandelt werden, während andere Daten (z. B. aus Deutschland oder der EU) langsamer übertragen werden.
    • Erhöhter Ping und Latenz: Insbesondere bei Echtzeitanwendungen wie Online-Gaming oder Videoanrufen könnte es zu einer schlechteren Performance kommen, wenn diese Daten aus den USA langsamer bereitgestellt werden.
  2. Reduzierte Dienstqualität
    • Anbieter könnten gezwungen werden, für eine bevorzugte Behandlung ihrer Daten innerhalb der USA zusätzliche Gebühren an ISPs zu zahlen. Diese Kosten könnten auf Nutzer in Deutschland umgelegt werden, was zu höheren Preisen oder eingeschränkten Diensten führen könnte.
    • Begrenzte Verfügbarkeit: Einige US-Dienste könnten für europäische Nutzer in der Qualität eingeschränkt sein, da ISPs die Datenübertragung bewusst drosseln.
  3. Technische Umgehungen
    • VPN-Nutzung: Um Einschränkungen durch US-ISPs zu umgehen, könnten mehr Nutzer auf VPN-Dienste zurückgreifen, was zusätzliche Latenzen und Performanceeinbußen verursachen könnte.

Organisatorische Auswirkungen

  1. Geänderte Preisstrukturen
    • US-Unternehmen könnten gezwungen sein, neue Kostenmodelle einzuführen, um bevorzugte Datenübertragungen sicherzustellen. Diese Kosten könnten als Abonnementgebühren oder Preiserhöhungen an Nutzer in Deutschland weitergegeben werden.
  2. Serviceänderungen bei US-Anbietern
    • Anbieter könnten bestimmte Dienste oder Inhalte für Nutzer in Europa einschränken, um Kosten zu reduzieren. Dies könnte insbesondere für kleinere Anbieter relevant sein, die sich keine bevorzugten Datenübertragungsrechte leisten können.
  3. Beeinträchtigung der Datenintegrität
    • Unterschiedliche Priorisierung: Inhalte könnten durch US-basierte ISPs verändert oder in ihrer Reihenfolge priorisiert werden, was sich auf die Wahrnehmung und Nutzung von Diensten auswirken könnte.
  4. Komplexere regulatorische Abstimmungen
    • Unternehmen, die sowohl in den USA als auch in der EU operieren, müssten möglicherweise unterschiedliche Strategien entwickeln, um den jeweiligen lokalen Regelungen gerecht zu werden. Dies könnte die Effizienz und den Support für Nutzer in Deutschland beeinträchtigen.

Langfristige Auswirkungen

  1. Marktveränderungen
    • Europäische Anbieter könnten an Marktanteilen gewinnen, wenn US-Dienste schlechter zugänglich oder teurer werden.
    • US-Anbieter könnten ihren Fokus auf lokale Märkte legen, was zu einer geringeren Innovation und Verfügbarkeit für internationale Nutzer führen könnte.
  2. Politischer Druck
    • Die Entwicklungen in den USA könnten europäische Regulierungsbehörden dazu bewegen, ihre bestehenden Regeln zur Netzneutralität zu überprüfen, um sicherzustellen, dass europäische Nutzer nicht indirekt durch US-Entscheidungen benachteiligt werden.

Einfluss auf die Verbreitung von Informationen

  1. Priorisierung von Inhalten durch ISPs
    • Ohne Netzneutralität könnten ISPs in den USA (und potenziell in anderen Ländern, wenn diese Praktiken übernommen werden) Inhalte bevorzugen, die mit staatlichen oder regierungsfreundlichen Narrativen übereinstimmen.
      Unabhängige oder oppositionelle Stimmen könnten benachteiligt werden, da sie nicht für bevorzugte Übertragungsraten zahlen können.
    • Dies könnte eine effektivere Verbreitung von propagandistischen Inhalten und eine gleichzeitige Unterdrückung kritischer Informationen ermöglichen.
  2. Geofencing von Propaganda
    • Inhalte könnten gezielt in bestimmten Regionen priorisiert oder blockiert werden, um die gewünschte Zielgruppe effektiver zu erreichen oder von bestimmten Informationen abzuschneiden.

Auswirkungen auf Überwachungs- und Datenzugriffsmechanismen

  1. Einfacherer Zugriff auf Daten
    • Ohne Netzneutralität könnten ISPs verpflichtet oder ermutigt werden, Überwachungsdaten direkt mit Regierungsstellen zu teilen. Dies könnte dazu führen, dass Regierungen gezielt Inhalte beobachten und manipulieren können, um die öffentliche Meinung zu beeinflussen.
    • Solche Daten könnten auch verwendet werden, um die Wirkung von Propaganda-Kampagnen in Echtzeit zu messen und zu optimieren.
  2. Verhinderung von Verschlüsselungsdiensten
    • ISPs könnten den Zugang zu sicheren und anonymen Kommunikationsdiensten (z. B. Tor, VPNs) drosseln oder blockieren, was es einfacher macht, Propaganda durch ungeschützte Kanäle zu verbreiten und Gegenstimmen zu überwachen.

Fragmentierung der Informationslandschaft

  1. Förderung staatlich geförderter Inhalte
    • Regierungen könnten mit ISPs zusammenarbeiten, um propagandistische Inhalte zu priorisieren, indem sie hohe Gebühren zahlen oder direkte Partnerschaften eingehen.
    • Dies könnte dazu führen, dass Nutzer bevorzugt mit regierungsnahen Informationen konfrontiert werden, während unabhängige oder abweichende Informationen in den Hintergrund treten.
  2. Beeinflussung internationaler Diskurse
    • US-amerikanische Propaganda könnte durch die globale Verbreitung von US-Diensten (z. B. soziale Medien oder Streaming-Plattformen) weiterhin großen Einfluss haben, während Gegenpositionen von anderen Ländern möglicherweise schlechter verbreitet werden.

Auswirkungen auf Deutschland

  1. Import von Mechanismen
    • Wenn solche Praktiken in den USA erfolgreich implementiert werden, könnten sie als Vorbild für ähnliche Maßnahmen in Deutschland oder der EU dienen, insbesondere im Kontext von Desinformation und Informationskontrolle.
  2. Beeinflussung von Allianzen und geopolitischen Interessen
    • Die Aufhebung der Netzneutralität könnte genutzt werden, um gezielt Inhalte zu fördern, die transatlantische Beziehungen stärken oder europäische Bevölkerungen in eine bestimmte Richtung lenken.

Fazit

Die Aufhebung der Netzneutralität in den USA eröffnet theoretisch Möglichkeiten, wie Regierungen – sowohl in den USA als auch im abhängigen Deutschland gewünschte Inhalte effektiver verbreiten und alternative Meinungen unterdrücken könnten. Dies könnte durch Priorisierung bestimmter Daten, gezielte Überwachung und eine Fragmentierung der Informationslandschaft geschehen. Die konkreten Auswirkungen hängen davon ab, inwiefern staatliche Akteure diese neuen technischen und wirtschaftlichen Möglichkeiten nutzen.

Die Aufhebung der Netzneutralität in den USA könnte für deutsche Nutzer von US-Diensten technische Herausforderungen, wie schlechtere Performance und höhere Preise, Zensur, sowie organisatorische Änderungen wie Einschränkungen bestimmter Dienste mit sich bringen. Diese Auswirkungen hängen stark davon ab, wie US-Dienstanbieter ihre Strategien anpassen und ob diese Anpassungen global wirken.

Das Ergebnis ist „Teile und Herrsche“, das von den USA gewünscht wird. Das Internet wird zwar weiter existieren, aber seine tragende technologische, sowie weltweite Unterstützung und Nutzung verlieren. Denn der globale Süden wird konkurrierend weitere, zum Internet parallele, abgeschirmte, sowie unabhängige Netzwerke mit besseren Bedingungen betreiben. Diese Netze sind bereits in Teilen fertiggestellt. Dadurch wird der von den USA geführte Westen vor allen wirtschaftlich, sowie technologisch weiter verlieren und sich selbst dadurch weiter vernichten.

ITIL – Das Service Design

ITIL

Eines der wichtigsten Ziele des Service Designs von ITIL ist die Konzeption, Entwicklung, Integration und Bereitstellung von neuen oder geänderten Services, nach den Anforderungen des Auftraggebers und unter Berücksichtigung der Bedürfnisse der betroffenen Akteure.

Ziele des ITIL Service Design

  1. Für die Geschäftsanforderungen neue oder geänderte IT Dienste entwickeln
  2. Planung und Bereitstellung von hochwertigen Prozessen die Kunden und Auftraggeber gerecht werden
  3. Risiken identifizieren und minimieren
  4. Standardisierte, sichere und ausfallsichere IT-Infrastrukturen, Anwendungen, Organisationen entwerfen
  5. Erstellung und Pflege der Dokumentation der qualitätsgetriebenen Dienstleistungen, Architekturen, Richtlinien und Prozessen
  6. Weiterentwicklung der Fertigkeiten und Fähigkeiten

TCO im Kontekt des Service Design

Ein grundsätzliches Ziel des ITIL Service Design ist es,  die Total Cost of Ownership (TCO) zu minimieren. Dazu werden Kostenaspekte bei der Planung neuer oder geänderter Dienste frühzeitig berücksichtigt, um langfristig Effizienz und Wertschöpfung zu maximieren. Das TCO im Kontext des ITIL Service Design berücksichtigt die vollständigen Kosten eines IT-Dienstes über seinen gesamten Lebenszyklus hinweg und schliesst die Entwicklung, Implementierung, Betrieb, Wartung und Ausmusterung ein.

Die 4 P der IT-Service Managementplanung

Bei der Planung werden die 4 P berücksichtigt.

  1. People: Mitarbeiter mit den richtigen Fähigkeiten und Verantwortlichkeiten einsetzen.
  2. Processes: Effektive und effiziente Abläufe zur Bereitstellung und Unterstützung von IT-Services.
  3. Products: Technologien und Werkzeuge nutzen, die für die Erbringung der Services notwendig sind.
  4. Partners: Externe Anbieter oder Partner gewinnen, die die IT-Services unterstützen oder ergänzen.

ITIL - 4 P der IT-Service Management Planung

Diese 4 P’s gewährleisten eine ganzheitliche und erfolgreiche IT-Service-Planung.

Die fünf Hauptvorteile des IT Service Designs nach ITIL

  • Bessere Ausrichtung an Geschäftsanforderungen: Die IT-Services werden so gestaltet, dass sie die Geschäftsziele und -anforderungen optimal unterstützen.
  • Höhere Servicequalität: Durch klar definierte und standardisierte Prozesse wird die Qualität der Services gesteigert.
  • Kostenreduktion: Mit effektiven Service-Design-Prozessen minimieren sich unnötige Ausgaben und optimieren zudem die Ressourcennutzung.
  • Verbesserte Risikomanagement: Die Risiken in Bezug auf Verfügbarkeit, Sicherheit und Kapazität werden frühzeitig erkannt.
  • Effizientere Servicebereitstellung: Gut geplante Services ermöglichen eine schnellere und zuverlässigere Einführung neuer IT-Services.

Konzepte und Aktivitäten beim Service Level Management

Dazu gehört ein ausgefeiltes Konzept des Service Level Managements (SLM) mit wichtigen Aktivitäten des Service Level Managements.

  • Service Level Agreements (SLAs) erstellen und pflegen: Definition und Verwaltung von SLAs, um sicherzustellen, dass die IT-Services den Kundenanforderungen entsprechen.
  • Überwachung und Messung der Service-Performance: Regelmäßiges Überprüfen der erbrachten Services im Vergleich zu den vereinbarten SLAs.
  • Service Reviews: Durchführung von regelmäßigen Meetings mit Kunden und Stakeholdern, um die Einhaltung der SLAs zu bewerten und mit dem kontinuierlichen Verbesserungsprozess (KVP) Anpassungen vorzunehmen.
  • Management von Verbesserungsmaßnahmen: Fortlaufende Identifikation und Umsetzung von Verbesserungen zur Optimierung der Servicequalität.
  • Berichterstattung: Regelmäßige Berichte zur Service-Performance für Kunden und Management erstellen.

 

ITIL – Wie sind Prozesse definiert?

ITIL

Bei ITIL wird ein „Prozess“ als eine strukturierte Reihe von Aktivitäten definiert, die ein bestimmtes Ziel zu erreichen. Jeder Prozess hat spezifische Eingaben, Ausgaben, Kontrollen und Aktivitäten. Diese tragen dazu bei, ein gewünschtes Ergebnis zu erzielen.

Es gibt Eigenschaften, die ITIL-Prozesse definieren:

Messbarkeit

Ein Prozess sollte messbare Ergebnisse liefern, sodass seine Effektivität und Effizienz bewertet werden kann.

Ergebnisse

Ein Prozess liefert ein spezifisches Ergebnis. Dieses Ergebnis unterscheidet den Prozess von anderen Formen der Arbeit.

Kunde

Jeder Prozess hat einen Empfänger oder Kunden, der von dem Ergebnis des Prozesses profitiert.

Auslöser und Anpassung

Prozesse sollten über Mechanismen verfügen, um Feedback zu sammeln und Anpassungen basierend auf diesem Feedback vorzunehmen, um die Effektivität und Effizienz des Prozesses kontinuierlich zu verbessern.

Operativ

Prozesse sind operativ und wiederholbar, um konstante und vorhersehbare Ergebnisse zu liefern.

Fazit

Innerhalb von ITIL gibt es viele definierte Prozesse, die sich auf verschiedene Aspekte des IT-Service-Managements beziehen. Von der Service-Strategie, über das Service-Design und die Service-Transition, bis hin zum Service-Betrieb und der kontinuierlichen Service-Verbesserung.

Jeder dieser Prozesse hat spezifische Aufgaben, Werkzeuge und Ziele. Diese tragen dazu bei, den Gesamtwert des IT-Service-Managements für eine Organisation zu maximieren.

 

 

 

Agiles Projektmanagement mit Kanban

Kanban Logo

Kanban ist eine Methodik zur Optimierung von Arbeitsabläufen, die ursprünglich in der japanischen Automobilindustrie entwickelt wurde. Sie basiert auf dem Prinzip der visuellen Darstellung von Aufgaben, deren Status und Fortschritt, meist auf einem „Kanban-Board“. Dies hilft dabei, Engpässe zu identifizieren, die Arbeitslast zu regulieren und die Effizienz des Teams zu steigern

Wie funktioniert Kanban?

Ein Kanban-System ist ziemlich einfach aufgebaut. Es besteht normalerweise aus einem physischen oder digitalen Kanban-Board und darauf platzierten Kanban-Karten.

Kanban Tafel

Das Kanban-Board ist in mehrere Spalten unterteilt, die den unterschiedlichen Stadien des Arbeitsprozesses entsprechen. Die einfachste Form hat drei Spalten: „Zu erledigen“ (To Do), „In Arbeit“ (In Progress) und „Erledigt“ (Done).

Jede Aufgabe im Arbeitsprozess wird auf einer separaten Kanban-Karte dargestellt. Diese Karte enthält Informationen wie die Aufgabenbeschreibung, den verantwortlichen Mitarbeiter, das Startdatum und das Fälligkeitsdatum.

Wenn eine neue Aufgabe ansteht, wird sie als Karte in die „Zu erledigen„-Spalte eingefügt. Wenn jemand an der Aufgabe arbeitet, wird die Karte in die „In Arbeit„-Spalte verschoben. Sobald die Aufgabe abgeschlossen ist, wird die Karte in die „Erledigt„-Spalte verschoben.

Beispiel zur Nutzung von Kanban

Angenommen, Sie sind Teil eines Softwareentwicklungsteams. Die Kanbantafel des Teams könnte so aussehen:

Zu erledigen
1. Funktion zur Benutzeranmeldung erstellen
2. Datenbank für Benutzerinformationen einrichten
3. Design der Startseite entwerfen

In Arbeit
1. Backend für die Benutzeranmeldung entwickeln
2. Testen der Anmeldungs- und Abmeldefunktionen

Erledigt
1. Spezifikationen für die Anwendungsfälle erstellen
2. Entwurf des Anmeldeformulars

Jeder im Team kann den Status jeder Aufgabe auf der Kanbantafel sehen und so schnell erkennen, welche Aufgaben Priorität haben und wer gerade welche Aufgabe bearbeitet.

Die Grundregel des Kanban-Systems ist es, die Anzahl der gleichzeitig „in Arbeit“ befindlichen Aufgaben zu begrenzen. Diese Begrenzung wird als „Work in Progress“ (WIP) -Limit bezeichnet. Das hilft, Überlastung zu vermeiden und sicherzustellen, dass Aufgaben vollständig abgeschlossen werden, bevor neue Aufgaben in Angriff genommen werden.

Es können Engpässe während der Entwicklung schnell erkannt werden und dadurch können passende Gegenmaßnahmen zur Verbesserung umgesetzt werden.

Fazit

Der Einsatz von Kanban in der Softwareentwicklung bietet eine einfache, aber effektive Methode zur Visualisierung und Kontrolle des Arbeitsflusses. Es fördert Transparenz, Zusammenarbeit und unterstützt die kontinuierliche Verbesserung. Durch die Einführung von WIP-Limits kann Kanban dabei helfen, Multitasking zu vermeiden und die Produktivität zu steigern. Insgesamt kann Kanban wesentlich dazu beitragen, die Qualität der Softwareprodukte zu verbessern und die Entwicklungszeiten zu verkürzen.

 

 

Die Entwicklungsphasen von DevOps

DevOps Logo

DevOps wird genutzt, um die Zusammenarbeit zwischen den Teams für Softwareentwicklung und IT-Betrieb zu verbessern.  DevOps fördert einen kontinuierlichen, automatisierten und schnellen Entwicklungs- und Bereitstellungsprozess.

Es reduziert die Zeit bis zur Markteinführung und erhöht die Softwarequalität durch frühzeitige Fehlererkennung und schnelle Korrektur. Darüber hinaus ermöglicht es die kontinuierliche Überwachung und Optimierung der Systeme. Das führt zu einer höheren Kundenzufriedenheit und einer verbesserten Geschäftsleistung.

Phasen von DevOps

Planung: Definiere Ziele und skizziere den technischen und wirtschaftlichen Plan für das Projekt.
Codierung: Schreibe und überprüfe den Code unter Berücksichtigung der geplanten Spezifikationen und Standards.
Build: Kompiliere den Code, um die Lauffähigkeit herzustellen.
Test: Überprüfe und teste den Code auf Fehler und Leistungsprobleme.
Release: Setze die Änderungen in einer kontrollierten Umgebung frei. Überwache den Prozess, um sicherzustellen, dass es keine unvorhergesehenen Probleme gibt.
Deployment: Implementiere den Code in der Produktivumgebung, überwache seine Leistung und seine Auswirkungen.
Betrieb: Überwache und verwalte die Infrastruktur und die genutzten Anwendungen in der Produktionsumgebung.
Monitoring: Überwache die Leistung, sowie das Verhalten der Anwendung in der Produktionsumgebung und dokumentiere alle Probleme oder Ausfälle. Sie werden in zukünftigen Iterationen zu behoben. Sammle dabei Feedback und verwende es, um die Prozesse kontinuierlich zu verbessern (KVP).

Die Phasen bei DevOps wiederholen sich iterativ.

Fazit

DevOps stellt einen neuartigen Ansatz in der Softwareentwicklung und dem Operations Bereich dar, indem es eine nahtlose Integration und Zusammenarbeit zwischen den beiden Bereichen ermöglicht. Durch die Förderung von Geschwindigkeit, Effizienz und Qualität in der Softwarebereitstellung verbessert DevOps die Agilität und Reaktionsfähigkeit von Unternehmen. Das führt zu einer höheren Kundenzufriedenheit und verbesserten Geschäftsergebnissen. Trotz seiner Komplexität und der Notwendigkeit einer sorgfältigen Implementierung ist DevOps eine wertvolle agile Entwicklungsmethode, die den Weg für kontinuierliche Innovation und Verbesserung ebnet.

 

 

Requirements Mangement

Requirements Management Logo

Die Anfänge des Requirements Managements lassen sich auf die 1970er Jahre zurück verfolgen. Die Komplexität der Systeme begann, handgeschriebene Dokumentation und einfache Verwaltungstechniken zu übersteigen. In den 1980er und 1990er Jahren wurden strukturierte Methoden wie die Objektorientierung und spezialisierte Tools entwickelt, um die Verwaltung von IT Anforderungen zu formalisieren und die Nachverfolgbarkeit zu verbessern. In jüngerer Zeit hat der Aufstieg von agilen Entwicklungspraktiken das Requirements Management weiterentwickelt. Es wird ein kontinuierlicher, iterativer Ansatz zur Anforderungserfassung und -anpassung unterstützt.  So kann einfacher auf Änderungen reagieren werden.

Was ist Requirements Management?

Requirements Management bezieht sich im Bereich der Softwareentwicklung auf das Verstehen, Dokumentieren, Verfolgen und Aktualisieren von Anforderungen (engl. requirements). Diese Anforderungen können funktionale oder nichtfunktionale Eigenschaften sein. Ein Softwareprodukt muss diese Anforderungen erfüllen, um den Wünschen der Auftraggeber und Stakeholder zu entsprechen.

Aufgaben des Requirements Management

  • Erfassung und Dokumentation von Anforderungen in einem verständlichen und messbaren Format
  • Priorisierung von Anforderungen basierend auf den Bedürfnissen der Stakeholder
  • Verfolgen von Änderungen in den Anforderungen während des gesamten Projektzyklus
  • Sicherstellung, dass alle Anforderungen während der Entwicklung und beim Testen berücksichtigt werden
  • Verwaltung von Kommunikation und Übereinstimmung zwischen den Stakeholdern hinsichtlich der Anforderungen

Fazit

Gutes Requirements Management und Kommunikation kann dazu beitragen Missverständnisse zu minimieren, sowie das Risiko von Fehlern zu reduzieren und die Qualität der Produkte zu verbessern.

 

 

Der Blackbox Test und der Whitebox Test

Der Blackbox-Test und der Whitebox-Test dienen dazu, die Qualität und Zuverlässigkeit von Software- und Systemlösungen sicherzustellen. Die Tests decken verschiedene Aspekte wie Funktionalität, Benutzerfreundlichkeit, Zuverlässigkeit und Sicherheit ab. Sie werden von Anwendungsentwicklern, Systemintegratoren und weiteren Berufen in der IT Sparte eingesetzt.

Der Blackbox Test

Der Blackbox-Test wird auch manchmal als Black-Box-Test beschrieben und ist ein Testverfahren, bei dem die interne Struktur oder das Design des zu testenden Systems nicht bekannt ist oder nicht berücksichtigt wird. Der Tester betrachtet das System als eine „Blackbox“, bei der er nur die Eingaben (Input) und die Ausgaben (Output) kennt. Der Fokus liegt auf der Überprüfung der funktionalen Anforderungen des Systems, wie z. B. ob es die erwarteten Ergebnisse liefert und ob es korrekt mit verschiedenen Eingabeparametern umgeht. Der Tester kann verschiedene Techniken wie Äquivalenzklassenbildung, Grenzwertanalyse, Zustandsübergangstests und zufällige Tests verwenden, um die Wirksamkeit des Systems zu überprüfen. Der Blackbox-Test ermöglicht es, das System aus Sicht des Endbenutzers zu bewerten und kann unabhängig von der internen Implementierung des Systems durchgeführt werden.

Vorteile des Blackbox-Tests

  • Der Blackbox-Test stellt sicher, dass das System den Anforderungen und Erwartungen der Benutzer entspricht.
  • Der Blackbox-Test kann unabhängig von der internen Implementierung durchgeführt werden.
  • Durch den Blackbox-Test können Muster von Fehlern und unerwartetem Verhalten erkannt werden.

Nachteile des Blackbox-Tests

  • Der Blackbox-Test kann bestimmte interne Codepfade oder -bereiche nicht ausreichend testen.
  • Die Ursache von Fehlern kann aufgrund fehlenden Zugangs zur internen Implementierung schwierig zu identifizieren sein.
  • Der Blackbox-Test bezieht sich nicht auf die interne Effizienz oder Optimierung des Codes.

Der Whitebox Test

Der Whitebox-Test wird manchmal als White-Box-Test beschrieben und ist ein Testverfahren, bei dem der Tester Einblick in die interne Struktur, sowie in das Design des zu testenden Systems hat. Der Tester analysiert den Quellcode, die Algorithmen, die Datenstrukturen und andere technische Aspekte des Systems, um Tests zu erstellen, die auf diesen Informationen basieren. Der Whitebox-Test konzentriert sich sowohl auf die Überprüfung der funktionalen Anforderungen als auch auf die strukturelle Abdeckung des Codes. Es werden Techniken wie Pfadabdeckung, Anweisungsabdeckung, Zweigabdeckung und Bedingungsabdeckung verwendet, um sicherzustellen, dass alle möglichen Pfade und Szenarien im Code getestet werden. Der Whitebox-Test wird oft von Entwicklern durchgeführt, um sicherzustellen, dass der Code richtig implementiert ist und potenzielle Fehler und Schwachstellen identifiziert werden.

Vorteile des Whitebox-Tests

  • Der Whitebox-Test ermöglicht eine detaillierte Überprüfung des Codes und identifiziert potenzielle Fehler auf algorithmischer oder struktureller Ebene.
  • Durch den direkten Zugriff auf den Quellcode kann der Whitebox-Test eine umfassende Abdeckung der Code-Pfade und Szenarien erreichen.
  • Der Whitebox-Test ermöglicht es, ineffiziente Codebereiche zu erkennen und zu optimieren, um die Gesamtleistung des Systems zu verbessern.

Nachteile des Whitebox-Tests

  • Der Whitebox-Test erfordert Kenntnisse über die interne Implementierung, was zu Einschränkungen führen kann, wenn der Quellcode nicht verfügbar oder komplex ist.
  • Der Whitebox-Test fokussiert sich stark auf die interne Logik und kann die Perspektive eines Endbenutzers oder externe Schnittstellen möglicherweise nicht vollständig berücksichtigen.
  • Der Whitebox-Test erfordert tiefgreifende Kenntnisse der internen Struktur und erfordert mehr Zeit und Ressourcen im Vergleich zum Blackbox-Test.

Fazit

Der Blackbox-Test ermöglicht eine unabhängige Bewertung der funktionalen Anforderungen aus Benutzersicht, während der Whitebox-Test eine detaillierte Überprüfung der internen Implementierung und eine umfassendere Testabdeckung bietet. Beide Testarten sind wichtige Bestandteile der Qualitätssicherung.

 

 

Continuous Integration und Deployment – CI/CD

Softwareentwicklung geschieht vielfältig und CI/CD spielt bei Anwendungsentwicklern eine wichtige Rolle. Continuous Integration und Deployment (CI/CD) ist ein Prozess in der Softwareentwicklung. So werden Änderungen an einer Anwendung schnell und effizient in die Produktion zu überführt. Dies geschieht durch eine kontinuierliche Integration von Code-Änderungen und Tests, sowie eine automatisierte Bereitstellung von Software-Updates.

In der traditionellen Softwareentwicklung erfolgt die Integration von Code-Änderungen oft erst am Ende des Entwicklungsprozesses. Dies führt oft zu Problemen bei der Integration, da die einzelnen Komponenten der Anwendung nicht richtig miteinander funktionieren. Durch den Einsatz von CI/CD werden Code-Änderungen hingegen kontinuierlich und automatisiert in die Anwendung integriert und getestet.

Continuous Integration (CI)

Continuous Integration (CI) bezieht sich auf den Prozess der kontinuierlichen Integration von Code-Änderungen in ein zentrales Repository. Dabei werden alle Änderungen automatisch gebaut und getestet. So wird sichergestellt, dass sich die Änderungen problemlos in die bestehende Codebasis integrieren lassen. Dadurch können Probleme frühzeitig erkannt und behoben werden.

Continuous Deployment (CD)

Continuous Deployment (CD) geht noch einen Schritt weiter als CI. Es benutzt  Prozesse zur automatisierten Bereitstellung von Anwendungs-Updates. Dabei wird der Code automatisch auf die Produktionsumgebung übertragen und in Betrieb genommen, nachdem er erfolgreich getestet wurde. Dies ermöglicht eine schnelle und effiziente Bereitstellung von Software-Updates. Ausfallzeiten werden minimiert.

Durch den Einsatz von CI/CD können Entwickler die Qualität ihrer Anwendungen verbessern, die Entwicklungszeit verkürzen und die Auslieferung von Software-Updates beschleunigen. Dabei ist es wichtig, dass die Entwickler regelmäßig Änderungen am Code vornehmen und diese Änderungen automatisiert testen. Durch die kontinuierliche Integration und Bereitstellung von Code-Änderungen wird sichergestellt, dass die Anwendung zu jeder Zeit stabil und funktionsfähig bleibt.

Fazit

Zusammenfassend ist Continuous Integration und Deployment ein wichtiger Bestandteil der modernen Softwareentwicklung. Es ermöglicht eine schnelle, sowie effiziente Bereitstellung von Software-Updates. Es hilft Unternehmen, ihre Anwendungen schneller und mit höherer Qualität auf den Markt zu bringen.

 

Normalisierung bei relationalen Datenbanken

Für die Nutzung und Wartung eines relationalen Datenbanksystems (DBS) sind sauber strukturierte Daten von Vorteil.

Denn bei der Nutzung können Schwächen, also Anomalien auftreten, die es zu verhindern gilt. Das wären zum Beispiel

  • Die Einfügeanomalie tritt auf, wenn es aufgrund von fehlenden Attributwerten nicht möglich ist, neue Daten in die Tabelle einzufügen.
  • Die Änderungsanomalie tritt auf, wenn Änderungen an einem Attributwert in einer Zeile zu Inkonsistenzen in anderen Zeilen führen.
  • Die Löschungsanomalie tritt auf, wenn das Löschen von Daten in einer Tabelle versehentlich auch andere, relevante Daten löscht oder wenn das Löschen von Daten zu einer fehlenden Information führt.

Um die oben genannten Anomalien zu verhindern, wird der Normalisierungsprozess eingesetzt.

Normalisierung der 1. Normalform

Eine Relation ist in der 1. Normalform, wenn jeder Wert in jeder Spalte des Tabellenentwurfs atomar ist, d.h. keine mehrwertigen Attribute enthält. Es dürfen also keine Spalten mit mehreren Werten in einer Zeile vorhanden sein.

Normalisierung der 2. Normalform

Eine Relation ist in der 2. Normalform, wenn sie bereits in der 1. Normalform ist und kein Teil der Primärschlüssel-Funktionsabhängigkeit von einer Teilmenge der Attribute abhängt. Das bedeutet, dass jede Nichtschlüssel-Spalte von der gesamten Primärschlüssel abhängt, nicht von einem Teil davon.

Normalisierung der 3. Normalform

Eine Relation ist in der 3. Normalform, wenn sie bereits in der 2. Normalform ist und keine transitive Abhängigkeiten existieren. Das bedeutet, dass eine Nichtschlüsselspalte nicht von einer anderen Nichtschlüsselspalte abhängen kann, sondern nur von der Primärschlüsselspalte.

Die Normalformen sind wichtig, um Datenredundanz und -inkonsistenzen zu vermeiden und die Datenkonsistenz und -integrität sicherzustellen.

Beispiel zur Normalisierung

Angenommen, wir haben eine Tabelle „Studenten“ mit den folgenden Spalten:

  • Matrikelnummer (Primärschlüssel)
  • Name
  • Geburtsdatum
  • Studienfach
  • Modul1-Name
  • Modul1-Note
  • Modul2-Name
  • Modul2-Note
  • Modul3-Name
  • Modul3-Note

Diese Tabelle ist nicht in der 1. Normalform, da die Spalten „Modul1-Name“, „Modul1-Note“, „Modul2-Name“, „Modul2-Note“, „Modul3-Name“ und „Modul3-Note“ mehrwertige Attribute enthalten. Wir können die Tabelle in zwei separate Tabellen aufteilen: eine für die Studenteninformationen und eine für die Modulinformationen.

  • Tabelle „Studenten“ (Primärschlüssel: Matrikelnummer)
    • Matrikelnummer (Primärschlüssel)
    • Name
    • Geburtsdatum
    • Studienfach
  • Tabelle „Module“ (Primärschlüssel: Modul-ID, Fremdschlüssel: Matrikelnummer)
    • Modul-ID (Primärschlüssel)
    • Matrikelnummer (Fremdschlüssel)
    • Modul-Name
    • Modul-Note

Jetzt befindet sich die Tabelle „Studenten“ in der 1. Normalform, da alle Spalten atomar sind. Die Tabelle „Module“ ist in der 2. Normalform, da alle Nichtschlüsselspalten von der gesamten Primärschlüssel-Spalte „Modul-ID“ abhängig sind.

Die Tabelle „Module“ ist jedoch noch nicht in der 3. Normalform, da die Spalte „Modul-Name“ und „Modul-Note“ von der Teilmenge der Spalte „Modul-ID“ und „Matrikelnummer“ abhängen, anstatt von der gesamten Primärschlüsselspalte „Modul-ID“ abhängig zu sein. Wir können die Tabelle erneut aufteilen:

  • Tabelle „Module“ (Primärschlüssel: Modul-ID, Fremdschlüssel: Matrikelnummer)
    • Modul-ID (Primärschlüssel)
    • Modul-Name
  • Tabelle „Noten“ (Primärschlüssel: Modul-ID, Matrikelnummer)
    • Modul-ID (Primärschlüssel, Fremdschlüssel)
    • Matrikelnummer (Primärschlüssel, Fremdschlüssel)
    • Modul-Note

Jetzt hängen alle Nichtschlüsselspalten von der gesamten Primärschlüssel-Spalte „Modul-ID, Matrikelnummer“ ab, und die Tabelle „Module“ und „Noten“ befinden sich in der 3. Normalform.

 

 

Mindestanforderung an ein Qualitätsmanagement System

Qualitätsmanagement

Qualität ist die Erfüllung der Anforderungen des Kunden. Bei vielen qualitätsbewussten Unternehmen wird dazu als Standard die Norm EN ISO 9000ff eingesetzt.

Mindestanforderungen an ein Qualitätsmanagement System

  • Kundenorientierung
  • Einbeziehung der beteiligten Personen
  • Prozessorientierter Ansatz
  • Kontinuierlicher Verbesserungsprozess (KVP)
  • Am System orientiertes Management Konzept
  • Lieferantenbeziehung mit Win-Win Nutzen
  • Liegt in der Verantwortung der Führung

Unternehmen, die aktiv Qualitätsmanagement betreiben, haben ein besseres Image und gesicherte Prozesse, weil regelmäßige Audits ein hohes Qualitätsniveau sicherstellen. Dadurch erhöhen sich die Chancen bei der Gewinnung von Aufträgen.

 

Qualitätsanforderungen an Software

Standardsoftware wird nach unternehmensinternen Qualitätsrichtlinien programmiert und verkauft.
Wie ist das aber bei individuell erstellter Software?

Es gibt allgemeine Qualitätsrichtlinien, die aber vor der Auftragserteilung festgelegt sein sollten. Denn es gilt:

„Qualität ist die Erfüllung der Kundenanforderungen.“

8 Kriterien für Qualität bei Software Entwicklung

Es gibt wichtige Eigenschaften, die bei der Softwareentwicklung eine tragende Rolle spielen. Denn schließlich soll die Software während der Nutzungsdauer problemlos und kostengünstig eingesetzt werden können.

Benutzerfreundliche Bedienung

Ein Programm oder eine App sollen einfach zu bedienen sein. der Anwender soll möglichst ohne Hilfe zum Erfolg kommen.

Unempfindlich gegen Fehler

Eingabefehler sollen abgefangen werden, Fehlbedienung nicht möglich sein.

Integrität und Sicherheit

Die Daten und das System sollen gegen unberechtigte Zugriffe und Manipulation geschützt sein.

Korrekte Funktion

Bei der Eingabe, Verarbeitung und Ausgabe dürfen keine Fehler auftreten. Bei gleichen Eingeben muss stets das gleiche Ergebnis erscheinen.

Portable Verwendung

Die Software soll auf anderen Systemen nutzbar sein.

Überprüfbarkeit

Bei der Abnahme der Software soll der Prüfungsaufwand gering sein.

Kompatibel zu anderen Anwendungen

Die Software soll einfach mit weiterer Software verbunden werden können.

Erweiterbare und wiederverwendbare Eigenschaften

Die Software soll leicht mit neuer Funktionalität ausgestattet und vorhandene Funktionen erweitert werden können.

Fazit:

Software Qualität ist wichtig und entscheidet mit, wie die Nutzung im beruflichen Alltag stattfindet. Gerade bei den Projekten Industrie 4.0 und der zunehmenden Digitalisierung in allen beruflichen Bereichen ist fehlerfreie, hochwertige Software eine Basisvoraussetzung.

Fehlersuche in Java mit dem Eclipse Debugger

Um ein perfektes Produkt mit der Programmiersprache Java zu erstellen braucht es eine gründliche Qualitätskontrolle und methodisches Vorgehen.

Der Entwickler unterscheidet, ob ein logischer Fehler oder ein Schreibfehler vorliegt. Logische Fehler können mit Hilfe  einer genauen Beschreibung des Produkts oder Vorgangs durch Soll-Ist Vergleiche erkannt und beseitigt werden. Manchmal wäre es praktisch, wenn ein Programm zum Test Schritt für Schritt ausgeführt werden könnte und dabei die Werte der Variablen, Übergabeparameter und Attribute auslesen kann. Hier kann die Java Entwicklungsumgebung Eclipse durch den integrierten Debugger unterstützen. Durch setzen eines Breakpoints, einer temporären Haltestelle, können die gewünschten Werte geprüft werden. Das setzen des Breakpoints erzeugt einen kleinen blauen Punkt auf der linken Seite. Durch erneutes Klicken mit der Maus auf diesen Punkt wird der Breakpoint wieder entfernt.

Breakpoint im Eclipse Debugger

Mit der Taste F11 wird der Debugger in Eclipse gestartet.  Bei Punkt 1 wird die Breakpoint Markierung und der Java Quellcode angezeigt.  Bei dem rechten Fenster werden bei Punkt 2 die Breakpoints und nach dem klicken auf einen Breakpoint werden unten weitere Informationen angezeigt. Auf der linken Seite bei Punkt 3 die Aufrufhierarchie angezeigt.

Java Debugger bei Eclipse

Für die weitere Bearbeitung stehen weitere Funktionen zur Verfügung

  • F5 Step into
    Es können Methoden aufgerufen und in der ersten Zeile angehalten werden. Ansonsten wird der Debugger bis zum nächsten Methodenaufruf weiterlaufen.
  • F7 Step Return
    Mit Step Return kann der Sprung in eine Methode durch Step Into zurückgenommen werden und an der vorherigen Haltestelle wieder weiter analysiert werden.
  • F6 Step Over
    Step Over kann einen zu analysierenden Bereich überspringen.
  • F8 Resume
    Das Programm wird bis zum nächsten Breakpoint ausgeführt.
  • CTRL+R Run To Line
    Die Ausführung des Programms wird bis zu einer bestimmten Zeile durchgeführt.
  • CTRL+F2 Terminate
    Die Ausführung des Programms wird beendet.

Mit dem Debugger lassen sich während des Probelaufs eines Programms die Variablen, Schleifen, Abfragen, Methodenaufrufe beobachten und so können Fehler leichter gefunden werden.

 

Die PDCA Methode von William Edwards Deming

Dr. William Edwards Deming, der Mann der die Welt veränderte und den kaum einer kennt. Dr. Deming war ein Guru des Qualitätsmanagements, der neue Wege aufzeigte und umsetzte. Seine Methoden machten Toyota zum langjährigen Weltmarktführer im Automobilbau. Die US Autoindustrie wurde in den 80er Jahren durch mangelhafte Qualität und „This is good enough“ fast ruiniert.

Eine von Dr. Demings  grundlegenden Methoden ist die PDCA Methode.

PDCA Methode
Die Nutzung gestaltet sich in vier Schritten. Diese werden beliebig oft wiederholt.

  1. Plan: Plane den Vorgang
  2. Do: Führe den Vorgang wie geplant aus
  3. Check: Prüfe das Ergebnis, z.B.  mit einem Soll-Ist Vergleich
  4. Act: Handle und gestalte den Vorgang mit den neuen Erkentnissen um

Sie werden feststellen, dass sich ihr Produkt oder ihre Dienstleistung stetig verbessern.

Qualität bei Software messen

Wer kennt das nicht? Es wurde die Entwicklung einer Software in Auftrag gegeben. Bei der Übergabe ist das Produkt nicht so, wie Sie Anforderung definierten. Da kann im Vorfeld einiges getan werden, damit die unerwünschten Ergebnisse ausbleiben.

Die Produktbeschreibung im Lastenheft

Der erste Schritt ist eine ausreichende Beschreibung des Produkts oder der Dienstleistung in einem Lastenheft. Dieses Lastenheft enthält auch eine Abgrenzung. In der steht, was nicht zum Umfang der Entwicklung gehört. Das Lastenheft wird bei der Angebotsanforderung an potentielle Auftragnehmer weitergereicht.

Die lieferbare Leistung im Pflichtenheft

Es ist die Basis für das Pflichtenheft. Dort beschreibt ein möglicher Auftraggnehmer den Rahmen seines Angebotes. Es steht dort geschrieben, was der potentielle Auftragnehmer umsetzen kann und was nicht. Es ist ein Teil der Basisinformationen zur Entscheidungsfindung. Denn mit dem Pflichtenheft erfolgt die Entscheidung, wer den Auftrag erhält. Zudem sind Lastenheft und Pflichtenheft ein wichtiger Bestandteil der abschliesenden Abnahme des Produkts oder der Dienstleistung.

Der Soll-Ist Vergleich zur Ermittlung der Qualität

Der ausgewählte Auftragnehmer entwickelt nun die Software oder Dienstleistung. Dabei ist zu beachten, dass es sogenannte verdeckte Arbeiten geben kann. Diese lassen sich nur innerhalb eines bestimmten Zeitraumes prüfen. Diese verdeckten Arbeiten sind im Vorfeld zu ermitteln und rechtzeitig gesondert zu kontrollieren.

Mit Hilfe des Lastenhefts, des Pflichtenhefts und der Dokumentation kann am Ende des Projekts die Abnahme durch den Auftragnehmer erfolgen. Da in der genannten Dokumentation alle erforderlichen Daten vorhanden sind, ist eine sachgerechte Prüfung und Abnahme möglich.

Ein wichtiger Punkt ist unbedingt zu beachten

Jede Änderung oder Erweiterung ist ein gesonderter Auftrag und hat im aktuellen Projekt nichts zu suchen. Änderungen und Erweiterungen werden erst nachfolgend oder nach Vereinbarung bearbeitet.

Der Einsatz von KPI

Mit Key Performance Idikatoren (KPI) können standardisierte Kennzahlen zur wiederholten und dabei vereinfachten Prüfung erstellt werden. Dazu werden aussagekräftige Parameter ermittelt, die über den Zustand des Produkts, der Dienstleistung oder deren Umfeld etwas aussagen.

Fazit:

Software Qualität hängt von vielen Parametern ab und ist zu prüfen. Wer nicht das notwendige Know-How hat, sollte einen Spezialisten hinzuziehen. Denn fehlerhafte Produkte können zu hohen Folgekosten führen.

William Edwards Deming: Grundlegende Fehler, die Verbesserung in Unternehmen behindern

William Edwards Deming, ein weltbekannter Pionier des Qualitätsmanagement entwickelte die prozessorientierte Sicht bei Management Abläufen in Unternehmen. Daraus entstanden später verschiedene Normen und Lehren zur Qualität. Deming analysierte im Rahmen seiner Qualitätsmanagement Lehre unter anderem, welche Fehler sich negativ auf Unternehmen auswirken.

  • Wenn ein Unternehmen hauptsächlich auf kurzfristigen Gewinn aus ist, dann kann keine strategische Planung vorgenommen werden. Mittelfristig werden solche Unternehmen durch Ihre planloses Vorgehen anderen unterliegen. Denn ohne Plan gibt es ständig wechselnde Ziele.
  • Das Gleiche gilt, wenn der Zweck einer Organisation oder Abteilung ständig verändert wird. Mit “kreativer Buchhaltung” können Unternehmen durch Entlassungen, Fusionen, Devisenbewertungen und anderen Tätigkeiten ständig positive Zahlen erzeugen, bis ein Unternehmen zusammenbricht.
  • Durch Leistungsbewertung von Mitarbeitern wurden noch nie langfristig Verbesserungen erzielt. Vielmehr gibt es Mitarbeiter, die das System zu Ihren Gunsten manipulieren können. Besser ist es, die Mitarbeiter individuell auszubilden und zu fördern. Kein erstelltes Profil vermag den Menschen, seine Arbeitsleistung und -qualität richtig darzustellen.
  • Hier ist das “Weisse Ritter Syndrom” gemeint. Ein oder mehrere Manager treten in einem Unternehmen als Retter auf. Sie veranlassen viele Veränderungen und zeigen auf kurzfristig erreichte, positive Ergebnisse. Sie verlassen das Unternehmen mit einer persönlichen Gewinnmitnahme, bevor langfristig negative Auswirkungen Ihrer Tätigkeit zu sehen sind.
  • Wichtiger als die bekannten oder sichtbaren Zahlen (manchmal aus KPI genannt) sind die unsichtbaren Zahlen die Unternehmen nicht zur Verfügung stehen. Zum Beispiel die Softskills der Mitarbeiter, der entstandene Nutzen oder Schaden für Kunden. Vorhandene Zahlen bilden immer nur die Vergangenheit ab.
  • Gesunde und motivierte Mitarbeiter sorgen für geringe Kosten. Daher sollte die Erhaltung von Gesundheit und Motivation ein ständiges strategisches Ziel eines Unternehmens sein.
  • Es ist eine Belastung für die zukünftige Entwicklung, wenn Unternehmen durch unzureichende Recherche, mangelhafte Qualität oder durch Absichten die Verträge zu brechen. Dann sind nachfolgend hohe Kosten zu bezahlen. Daher sollten Unternehmen Geschäftsbeziehungen bevorzugen, die auf gegenseitigen Vertrauen beruhen.

Fazit:

Die Demingschen Regeln für ein erfolgreiches Management sind von der Unternehmenskultur abhängig. Was lebt, unterliegt der Veränderung. Bei richtiger Veränderung kann mittel- oder langfristig mit einer positiven Entwicklung gerechnet werden.

Demings Erkenntnisse als Statistiker und Qualitätsexperte haben vor allem Japans Top Manager seit den 1960-er Jahren geprägt und zeigen sich weltweit in vielen Produkten der heutigen Zeit. Um Demings Ideen nicht zu vergessen, wurde in der Schweiz das Deming Institut gegründet.