» Startseite
 » Inhalt
 » Wir über uns
 » Leistungen
 » Mitglieder
 » Mitgliedschaft
 » Arbeitsgruppen
 » Veranstaltungen
 » Informationen
 » Forum
 
 » Mitgliedsbereich
 


GI-Gachgruppe 2.1.10 - Software-Messung und -Bewertung

Software measurement Laboratory

Swiss Software & Services Metrics Association

United Kingdom Software Metrics Association

Niederländische Software Metrik Association

Finnish Software Measurement Association

das virtuelle Software Engineering Kompetenzzentrum

International Software Benchmarking Standards Group - Member-Zugangsdaten im DASMA-Mitgliedsbereich

International Function Point User Group - Member-Zugangsdaten im DASMA-Mitgliedsbereich

Online Portal für Projektmanagement - Member-Zugangsdaten im DASMA-Mitgliedsbereich
» Startseite / » Informationen / Metrik-Glossar / S

S

Schätzfehler
Grundlegende Probleme der Aufwandsschätzung sind Schätzfehler durch

  1. unklare oder nicht dokumentierte Voraussetzungen der Schätzung,
  2. nicht eingeplanten Aufwand für die Schätzung,
  3. keine Aktualisierung und keine Qualitätssicherung der Schätzung,
  4. politische Schätzungen (Verhandeln statt Aufwandschätzung) sowie
  5. die Überschätzung von Personalqualifikation und -produktivität,
  6. Personalaufstockung (adding more people to a late project delays it the more!) und
  7. die Unterschätzung von Kommunikations-, Schulungs-, Dokumentations- und Qualitätssicherungs-Aufwand.

Schätzkultur
Die Entwicklung einer Schätzkultur kann in folgende Phasen eingeteilt werden:

  1. Problem: Aufwandschätzung wird nicht positiv gesehen.
  2. Bewußtsein: Management und Mitarbeiter werden zunehmend aufmerksam auf das Thema Aufwandschätzung, gehen es aber noch nicht systematisch an.
  3. Übergang: Übergang von der Betrachtung der Aufwandschätzung als Managementaufgabe zur Teamaufgabe.
  4. Antizipation: Übergang von subjektiver Aufwandschätzung zu Messungen und dem Einsatz von IT-Metriken und Tools.
  5. Chancen: Positive Vision der Aufwandschätzung, jeder ist dafür verantwortlich.

Schätzobjekt
Grundlage der Aufwandschätzung sind Informationen über das zu schätzende Projekt, z.B.:

  1. Übersicht über die benötigten Daten (z.B. Objektkatalog oder relationales Datenmodell)
  2. Masken-, Listenlayout, etc.
  3. Anzahl und Umfang der Schnittstellen
  4. Abläufe aus Benutzersicht, Dialogablauf, z.B. alle Prozessflussmodelle mit den dazugehörigen Aktivitäten, Use Cases, etc.

Fehlende Informationen müssen durch dokumentierte Annahmen ersetzt werden, ansonsten gerät das Schätzen zum Raten. Die Bandbreite des Schätzergebnisses hängt dabei von der Sicherheit dieser Annahmen ab.

"Grundsätzlich gilt: Je mehr Informationen über das Schätzobjekt vorliegen, desto genauer wird die Schätzung."


Service Level Agreement (SLA)
Mit Service - Level - Agreements definieren Kunde und Dienstleister ihre wechselseitigen Rechte und Pflichten, indem sie die Qualität und den Service - Grad (zum Beispiel: Art, Umfang, Verfügbarkeit) von Dienstleistungen vereinbaren.
Sie umfassen als vertragliche Vereinbarungen Ziele, Kennzahlen, Messverfahren, Maßnahmen und Sanktionen bei Abweichungen und andere Merkmale.
Damit werden die wechselseitigen Erwartungen transparenter und eindeutiger beschrieben und können folglich auch effizienter gestaltet werden.


Software-Messung:
Die Fachliteratur definiert den Terminus der Software-Messung wie folgt: „Software-Messung (software measurement) ist der Prozess der Quantifizierung von Attributen der Objekte bzw. Komponenten des Software Engineering mit der Ausrichtung aufspezielle Messziele (measurement goals) und der ggf. Einbeziehung von Messwerkzeugen (measurement tools)."

Dabei können die Messziele mannigfaltiger Natur sein und sich auf alle Teilaspekte(Produkte, Prozesse, Ressourcen) der Software-Entwicklung beziehen. Die Auswahl der korrekten und adäquaten Messziele ist eine essentielle Voraussetzung und Grundlage für die erfolgreiche Merkmalsabschätzung und das Benchmarking.

Es werden bei der Software-Messung neben direkt oder auch physikalisch messbarenMerkmalen wie Größe und Zeit auch so genannte indirekt oder nur empirisch messbareMerkmale, wie zum Beispiel das Fehlerverhalten, die Benutzerfreundlichkeit oder dieZuverlässigkeit erhoben, die auf dem Hintergrund der Erfahrungen in der Software-Entwicklung und -Anwendung beruhen und unter Umständen mit Hilfe der GQM hergeleitetwerden.


Steuerungsfunktion
Verwendung von Kennzahlen zur Vereinfachung von Steuerungsprozessen.

» A

» B

» C

» D

» E

» F

» G

» H

» I

» K

» L

» M

» N

» P

» Q

» R

» S

» T

» U

» V

» W

» Z


(c) 2002-2016 DASMA e.V. Impressum
aktualisiert am: 23. Jan 2005