Zum Inhalt springen

Exkurse

Dieses Kapitel enthält Texte zur logischen Skalierung oder Links zum Lesen
Das Ignorieren wichtiger bekannter Fakten macht Dinge unlogisch oder sehr schwierig zu handhaben.
Daher weise ich hier auf einige bekannte Daten aus Studien oder eine Meinung hin, und ich bin mir sicher, dass diese Artikel direkt davon profitieren.

Entwicklungsmodell HYPE

Ein Bild, das Text enthält. Automatisch generierte Beschreibung

(Software) Defect Reduction Top 10 List

Das Folgende ist das Ergebnis einer Studie – sie stammt aus dem Jahr 1987 – so dass 30 Jahre vergingen, aber es scheint immer noch nicht verstanden worden zu sein

Barry Boehm, University of Southern California. Victor R. Basili, University of Maryland.

  1. Finden Sie die Probleme so früh wie möglich
  2. Reduzierung der vermeidbaren Nacharbeit
  3. Führen Sie gründliche Anforderungen und Testdefinitionen von Grund auf durch
  4. Fehleranfällige Module frühzeitig erkennen und mit Sorgfalt behandeln
  5. Risikobasierte Tests
  6. Peer Reviews erfassen 60 Prozent der Mängel.
  7. Bei perspektivischen Überprüfungen werden 35 Prozent mehr Mängel festgestellt als bei nicht gerichteten Überprüfungen.
  8. Disziplinierte persönliche Praktiken können die Fehler-Einführungsraten um bis zu 75 Prozent reduzieren.
  9. 50 Prozent der Kosten entfallen auf hochverfügbare Softwareprodukte
  10. Etwa 40 bis 50 Prozent der Anwenderprogramme enthalten nicht-triviale Mängel.

Dreißig (Software-)Engineering-Themen, die seit 30 Jahren konstant geblieben sind

Auch wenn die folgenden Daten in Software abgeleitet wurden – die Daten gelten für alle anderen Bereiche fast im gleichen Umfang

    1. Die anfänglichen Anforderungen sind selten zu mehr als 50% erfüllt.
    2. Die Anforderungen steigen während der Entwicklung um ca. 2% pro Kalendermonat.
    3. Etwa 20% der anfänglichen Anforderungen werden bis zu einer zweiten Version verzögert.
    4. Das Auffinden und Beheben von Fehlern ist die teuerste (Software-) Aktivität.
    5. Das Erstellen von Papierdokumenten ist die zweitteuerste Softwareaktivität.
    6. Codierung ist die drittteuerste Softwareaktivität.
    7. Besprechungen und Diskussionen sind die viertteuerste Aktivität.
    8. Die meisten Testformen sind weniger als 35% effizient bei der Suche nach Fehlern.
    9. Die meisten Testformen berühren weniger als 50% des getesteten Codes.
    10. Es gibt mehr Fehler in den Anforderungen und im Design als im Quellcode.
    11. In Testfällen gibt es mehr Fehler als in der Software selbst.
    12. Fehler in Anforderungen, Design und Code durchschnittlich 5,0 pro Funktionspunkt.
    13. Die Gesamtwirksamkeit der Fehlerbeseitigung vor der Freigabe beträgt durchschnittlich nur etwa 85%.
    14. Etwa 15% der Softwarefehler werden an Kunden geliefert.
    15. Gelieferte Mängel sind teuer und führen zu Unzufriedenheit und technischen Schulden der Kunden.
    16. Ungefähr 5% der Module in Anwendungen enthalten 50% aller Fehler.
    17. Etwa 7% aller Fehlerreparaturen führen versehentlich zu neuen Fehlern.
      (Verschlimmbessern)
    18. Die Wiederverwendung von Software ist nur für Materialien wirksam, die sich null Fehlern nähern.
    19. Etwa 5% der Software-Outsourcing-Verträge enden in Rechtsstreitigkeiten.
    20. Etwa 35% der Projekte> 10. 000 Funktionspunkte werden storniert.
    21. Etwa 50% der Projekte> 10. 000 Funktionspunkte werden ein Jahr zu spät sein.
    22. Der Fehlermodus für die meisten Kostenschätzungen ist zu optimistisch.
    23. Die Produktivitätsraten in den USA betragen ungefähr 10 Funktionspunkte pro Mitarbeitermonat.
    24. Zuweisungsbereiche für die Entwicklung betragen ca. 150 Funktionspunkte.
    25. Zuweisungsbereiche für die Wartung betragen ca. 750 Funktionspunkte.
    26. Die Entwicklung kostet in den USA ca. 1200 USD pro Funktionspunkt (Bereich <500 USD bis> 3000 USD).
    27. Die Wartung kostet ca. 150 USD pro Funktionspunkt und Kalenderjahr.
    28. Nach der Lieferung wachsen die Anwendungen während des Gebrauchs um ca. 8% pro Kalenderjahr.
    29. Die durchschnittliche Fehlerreparaturrate beträgt ca. 10 Fehler pro Monat.
    30. Programmierer und Manager benötigen etwa 10 Tage jährliche Schulung, um auf dem neuesten Stand zu bleiben. –

Methodenvergleich in der Entwicklung

Using Software Risk MasterTM for Methodology Comparisons

Source : http://www.namcook.com/srmMethodologyComparisons.Html

Ende 2011 sind etwa 55 benannte Software-Entwicklungsmethoden im Einsatz, und eine noch größere Anzahl von Hybriden. Einige der Entwicklungsmethoden umfassen den traditionellen Wasserfall-Ansatz, verschiedene Varianten der agilen Entwicklung, den Rational Unified Process (RUP), den Team Software Process (TSP), die V-Modell-Entwicklung, das Microsoft Solutions Framework, die Structured Analysis and Design Technique (SADT), Evolutionäre Entwicklung (EVO), Extreme Programming (XP), PRINCE2, Merise, modellbasierte Entwicklung und viele andere. Im Allgemeinen hat die Auswahl einer Softwareentwicklungsmethodik mehr mit dem Beitritt zu einer Sekte als mit einer technischen Entscheidung zu tun. Viele Unternehmen versuchen gar nicht erst, Methoden zu evaluieren, sondern übernehmen lediglich die populärsten, die heute die vielen Gesichter der Agilität ausmachen. Eines der Merkmale des Tools Software Risk MasterTM ist die Fähigkeit, die Ergebnisse aller bekannten Softwareentwicklungsmethoden sowohl zu messen als auch vorherzusagen. Die 61 hier gezeigten Vergleiche (für detaillierte Vergleiche klicken Sie bitte auf die Excel-Tabelle) sind in der Reihenfolge ihrer Wirksamkeit geordnet und in drei Hauptgruppen unterteilt. Die niedrig eingestuften Methoden sind gefährlich und führen oft zu sehr schlechter Qualität. Die Durchschnittsgruppe enthält viele weit verbreitete Methoden wie Agile und Extreme Programming. Die letzte Gruppe enthält Methoden, die oft für komplexe Software-Anwendungen verwendet werden, bei denen Qualität wichtig ist, wie z.B. der Team Software Process (TSP) und der Rational Unified Process (RUP). Allerdings führen die Methoden nicht immer zu identischen Ergebnissen. Im Allgemeinen können Expertenteams mit jeder Methode gute Software produzieren. Durchschnittliche oder unterdurchschnittliche Teams haben Schwierigkeiten, gute Software zu produzieren, egal welche Methoden verwendet werden. Die Leser werden darauf hingewiesen, dass die hier gezeigten Ergebnisse nicht immer auftreten können. Die Leser sollten alle Methoden bewerten, bevor sie eine Methode auswählen.

Quelle https://web. archive. org/web/20130915171920/http://namcookanalytics. com/evaluating-ten-software-development-methodologies/SUMMARY AND CONCLUSIONS

Zum Zeitpunkt der Abfassung dieses Artikels verfügt die Softwareindustrie über etwa 55 verschiedene Entwicklungsmethoden. Dies ist eine zu große Zahl, um sie in einem kurzen Artikel zu vergleichen. Bei den 10 Methoden, die hier verglichen werden, hatten die meisten einige Erfolge und die meisten hatten auch ein paar Misserfolge. Insgesamt haben die Agile-Familie und die Methoden, bei denen die Geschwindigkeit im Vordergrund steht, ihr Ziel erreicht, und sie sind ziemlich schnell. Die qualitätsbetonten Methoden wie TSP, RUP und CMMI 5 haben ihre Ziele ebenfalls erreicht und weisen nur sehr wenige Mängel auf. Keine einzelne Methode scheint ein universelles Allheilmittel zu sein, das bei jeder Art und Größe von Software-Anwendungen erfolgreich sein kann. Dieser Artikel versucht, die Methoden aufzuzeigen, die drei wichtigen Faktoren am besten gerecht werden: 1) Geschwindigkeit; 2) Qualität; 3) langfristiger wirtschaftlicher Wert.

Trace View

Trace bedeutet Spur.

Ich zeige Ihnen hier den Gesichtspunkt, welcher es für Sie dann so einfach macht.

Sie erinnern Sich sicherlich, weiter Oben hatte ich Ihnen eine Liste von Prozessen und deren Ziele aufgeführt.

Ich kann mir nicht vorstellen, dass Sie diese Ziele nicht wollen.

Die ISO 33071, ist so weit übersetzt und angepasst, dass Sie nun ein Gebilde haben

Prozess

Prozessziel

Zugehörige(r) Prozessschritt(e)

Welche Arbeitsprodukte benötigten Sie um diesen Prozessschritt auszuführen

Was ist Ergebnis (Arbeitsprodukt) des Prozessschritt

Vorbereitet für Sie

  • entweder als Tabelle
    • dann ist es extrem viel Handarbeit, oder auch
    • als Softwareprodukt gibt es für Sie:

Alles was hier Blau und Fett markiert ist – ist vorhanden

ISO 9001 Forderung

Zugehörige ISO 9001 Nachweis(e)

Zugehörige ISO 33071 Nachweis(e)

Zugehörige ISO 33071 Prozessschritt(e)

Zugehörige Arbeitsprodukte(e)

Zugehörige Digitalisierungsmöglichkeit(e)

Zugehörige (en)

Verantwortlich ausführende Abteilung/Rolle(e)

Vorgehen == Wie (Methodische Beschreibung)

Sie müssen also nur noch:

  1. Ihre Organisation beschreiben (Wie oben angegeben)
  2. Die Rollen in der Organisation festlegen
  3. Die Prozesschritte zu den Rollen /der Abteilung zuordnen.