SWM Kap. 4

Software-Management

Software-Management


Vivien Baguio
Diese Lernkarten bieten einen umfassenden Überblick über das Software-Management (SWM) auf Universitätsniveau, mit Fokus auf Kostenschätzung, Wirtschaftlichkeitsprinzipien und Qualitätsmerkmale. Sie erklären Modelle wie COCOMO II, Methoden zur Aufwandsschätzung und die Bedeutung der Früherkennung von Fehlern. Die Karteikarten sind besonders nützlich für Studierende und Fachleute, die sich mit der Planung und Steuerung von Softwareprojekten beschäftigen, um effizientere und kostengünstigere Entwicklungsprozesse zu gestalten.
Flashcards
14
Students
2
Language
German
Category
Computer Science
Level
University
Created / Updated
21.01.2014 / 12.01.2019

Flashcards

Was ist das besondere am SWM?

  • Software ist immateriell
    • Man misst nicht weil Aufwand so hoch ist wie Entwicklung selbst
  • Software ist nicht "fertig", man muss es ständig neu anpassen
  • Unteilbarkeit der Arbeit
    • Pair-Programming, 2 Leute an einem Programm!
  • keine Naturwissenschaft
    • beobachtende Wissenschaft >> beobachtet große Projekte
  • Entwicklungen sind einmalig! Sehr begrenzter Schatz an erlernten Sachen die man weitergeben kann.

Was sind Herausforderungen an das SWM?

  • Kürzere Entwicklungszeiten
    • time to market
  • Höhere Qualität
    • früher gabs noch Compiler Fehler
  • Bewältigung größerer Komplexität
  • Reduktion der Entwicklungskosten
    • Sehr personalintensiv

Nennen Sie mehrere Qualitätsmerkmale von Software!

  • Funktionalität
    • Angemessenheit: Eignung der Funktionen für spezifizierte Aufgaben
    • Richtigkeit: richtige Ergebnisse? Genauigkeit der Werte?
    • Interoperabilität: Fähigkeit mit vorgegebenen Systemn zusammenzuwirken
    • Sicherheit
  • Zuverässigkeit
    • Reife: Geringe Versagenshäufigkeit durch Fehlerzustände
    • Fehlertoleranz: Ergebnisse liefern, obwohl Fehler auftreten
    • Konformität: Grad der Erfüllung von Normalen zur Zuverlässigkeit

Was sind Auswirkungen der Früherkennung von Fehlern?

>> Qualität früh in die Entwicklung "rein tragen"!

Desto früher Fehler erkannt werden, desto weniger Zeit brauchen Sie um gelöst zu werden, und desto billiger ist es! Achtung, exponentiell!

Skizzieren Sie das Teufelsquadrat und erklären Sie seine Funktion anhand eines Beispiels!

  • Wechselwirkungen zwischen Qualität, Komplexität, Entwicklungsdauer und Kosten!
  • Produktivität = produkt/aufwand
  • blaue Fläche Produktivität bleibt konstant >> Wechselwirkungen

Was ist "wirtschaftlich arbeiten" oder Arbeitsproduktivität, bzw. wie wird es berechnet? Welche Maße gibt es dazu?

Produktivität = Erzeugnismenge / Arbeitsstunden

Erzeugnismenge:

  • LOC
    • steht insgesamt für den Aufwand der in Zeilen Code beschrieben ist
    • also auch Anforderung usw
  • Function-Points

Arbeitsstunden:

  • Manchmal ist man nur anwesend, ohne arbeiten zu knnen
  • wie gut ist Relation zw. geistige <> körperliche Anwesenheit

Welche 3 Wirtschaftlichkeitsprinzipien gibt es?

  • Maximumprinzip
    • Möglichst großer Erfolg mit gegebenen Mitteln
  • Minimumprinzip
    • Vorgegebenes Ziel mit möglichst minimalem Aufwand
  • Extremumprinzip
    • Maximieren des Verhältnisses von Erfolg zu Mitteleinsatz bei variablem Erfolgsziel und Mitteleinsatz

Übertragen Sie die Wirtschaftlichkeitsformel auf SWE!

Immernoch: Arbeitsproduktivität = Erzeugnismengen / Aufwendungen

Aufwendungen

  • Personalkosten (Hauptkosten!)
  • Kosten für Computerressourcen
  • Kosten für Hilfsmittel
  • häufig reduziert auf Arbeitsstunden / Personenstunden oder Personenmonate oder Personenjahre
  • Umweltfaktoren:
    • im Büro ungestörte Arbeitsstunden: 10%-40%

Erzeugnismengen

  • Abstraktes Maß LOC
  • Function-Points
    • Schätzen des Entwicklungsaufwandes
    • Messen des funktionalen Umfangs auf Basis der funktionalen Anforderungen
  • Story Points bei aginel SW Entwicklungsprozessen

Erklären Sie Kostenschätzung mit COCOMO!

Aufwand = C1 * EAF * (Umfang)^P1

Zeit = C2 * Aufwand^P2

  • Aufwand: Anzahl MA-Monate
  • C1: konstanter Skalierungsfaktor für den Aufwand
  • EAF (Efford Adjustment Factor): Kennzeichnung des Anwendungsbereiches, der Mitarbeiter, der Umgebung und der Werkzeuge
  • Umfang: Umfang des Endproduktes (DSI; LOC); Anzahl ausgelieferter Quellanweisungen
  • P1: Aufwand, den der Entwicklungsprozess verursacht
  • Zeit: Anzahl der Monate
  • C2: konstanter Skalierungsfaktor für Zeitplanung
  • P2: Kennzahl für Managementaufwand

Welche 3 Schätzarten werden bei COCOMO II unterschieden?

  • Application-Composition-Modell
  • Early-Design-Modell
  • Post-Architecture-Modell

 

Erklären Sie das die Kostenschätzung mit COCOMO II mit den Early Design-Modell.

Aufwand = 2,45 * Earch * Umfang^P

  • Aufwand: Anzahl MA-Monate
  • Earch: Produkt von 7 Aufwandsanpassungsfaktoren (z.B. Produktkomplexität, Grad der Wiederverwendung, MA-Qualifikation, ...); Werte: 0.5 <= Earch <= 1,5
  • Umfang: Anzahl der Function Points oder DSI
  • P: Prozess-Exponent: 1,01 <= P <= 1,26 mit fünf Parametern:
    • Neuartigkeit des Anwendungsbereiches
    • Prozess-Flexibilität
    • Risiko der Architektur
    • Team Zusammenhalt
    • Prozess-Reife (>> CMMI)

Erklären Sie die Kostenschätzung mit COCOMO II im Post-Architecture-Modell.

Aufwand = 2,45 * Eapp * Umfang^P

  • Aufwand: Anzahl MA-Monate
  • Eapp: Produkt von 17 Aufwandsanpassungsfaktoren unterteilt in 5 Klassen:
    • Produktbezogen
    • Personalbezogen
    • Plattformbezogen
    • Projektbezogen
    • Skalierungsbezogen
  • Werte: 0,5 <= Eapp <= 1,5
  • Umfang: Anzahl der Function Points oder DSI
  • P: Prozess-Exponent; 1,01 <= P <= 1,26

Wie lauten weitere Verfahren zur Kostenschätzung?

  • Function-Point-Methode
  • Analogie-Methode
    • Hohe Übereinstimmung der Projektinhalte
    • >> Faustregel: 1/4 des Aufwandes der Neuentwicklung
  • Relationsmethode
    • Formalisierter Vergleich (Faktorenlisten und Richtlinien) zur Bestimmung der Ähnlichkeit zu einem Projekt
  • Multiplikatormethode
    • Zerlegung in Teilprodukte bis Aufwandszuordnung möglich
    • Kategorisierung der Teilprodukte; Multiplikation mit Kategoriefaktor
  • Prozentsatzmethode
    • Prozentuale Verteilung der Aufwände bekannter Entwicklungen
    • Siehe Beispiel der Berechnung mit COCOMO II

Hier noch allgemeine Empfehlungen zur Software-Ökonomie!

  • Reduktion der Produkt-Anforderungen (wenn möglich)
  • Kein "vergolden" der Funktionen
  • Reduktion handgeschriebenen Codes durch Verwendung von Entwicklungssystemen, Wiederverwendung fertiger Komponenten und den Einsatz von Code-Generatoren
  • Verdeutlichung von Abhängigkeiten und Schnittstellen durch modelbasierte Entwicklungsmethoden (OOA-Modell)
    • UML Klassendiagramme >> für statische Daten
    • User Stories, Use Cases oder Zustandsautomaten >> für dynamische Inhalte
  • Wahl des richtigen (passenden) Prozessmodells (>> später)
  • Führen einer Top-Ten Risikoliste
  • Entscheidungen treffen und dann damit Leben!

Study