» 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 / » Veranstaltungen / MetriKon-Tagungen (Rückschau) / MetriKon 2003 / Abstracts (10. November)

Abstracts (10. November)


Hauptvortrag I

Thomas Fehlmann: "Six Sigma für Software"

Six Sigma ist eine in der Industrie bekannte und erfolgreiche Managementstrategie. Durch gezielte Reduktion von Fehlern und Ausschuss werden Kosten dramatisch reduziert. Das Konzept funktioniert ausschliesslich über Metriken, welche an den Bedürfnissen der Kunden orientiert sind.

In der Vergangenheit gab es viele Versuche, Six Sigma für Software nutzbar zu machen. Einige davon gelangen, aber alle mussten das Problem lösen, welche Metriken letztlich für die in der Entwicklung Beteiligten brauchbar sind, um den tatsächlichen "Ausschuss" zu messen.

Ein erfolgreicher Ansatz geht über das Projektmanagement. Gemessen wird der Konsens zwischen den am Software-Projekt Beteiligten. Die Messverfahren werden durch den Qualitätsplan festgelegt. Anhand der in vielen Projekten gewonnenen Erfahrungen wird gezeigt, wie das Verfahren funktioniert. Dieser Ansatz gilt nicht nur für Softwareentwicklung, sondern für jede Art von Projekten mit hohem Anteil an Dienstleistungen.

Ein zweiter Ansatz geht über Quality Function Deployment (QFD). Mit Hilfe von QFD werden Messnetze erstellt, die es ermöglichen, Messungen der Kundenzufriedenheit, des Markterfolgs, der Software-Fehlerdichte sowie Assessments des Reifegrades gemäss einem geeigneten Capability Maturity Model (CMM) mit Hilfe von Kombinatorischen Metriken zu verknüpfen. Ein solches Messnetz ermöglicht es, allen Stellen in der Softwareentwicklung geeignete, auf den Projekterfolg geeichte Metriken zur Verfügung zu stellen. Mit Hilfe solcher geeichten Metriken lassen sich in der Softwareentwicklung kurze und einfache Rückkoppelungszyklen über Soll/Ist-Vergleiche und damit letztlich bedeutende Produktivitätsverbesserungen realisieren.

Das Verfahren wurde am Beispiel des Metrikprogramms eines Softwarehauses vorgestellt.

Die beiden Ansätze lassen sich ohne weiteres kombinieren. Doch gibt es einen dritten Ansatz, der bereits für sich allein ausserordentlich erfolgreich ist: Proposal Management. Darunter versteht man dedizierte Prozesse und spezialisierte Organisationseinheiten ("Proposal Centers"), die auf die Initialisierung von Projekten fokussiert sind. Proposal Management funktioniert auch dann, wenn vorwiegend interne Projekte durchgeführt werden.



Goal Question Metrics

Thomas Gantner: Zwei Anwendungen, aber nicht gleich

Erstellung eines Zielbaums für die Software-Entwicklung für PKW führt zu einem Kriterium für sinnvolle Qualitätssicherungs-massnahmen. Mit "Abstraction Sheets" (eine Art "7 Why’s") wurden die Fragen formuliert, die als Grundlage für die Metriken dienen sollen. Dabei entstand ein eher zu umfangreiche Fragenkatalog.

Dessen Reduktion gelang durch eine Ursache-Wirkungsanalyse., sowie durch die Berücksichtigung der Belastung der Projektmitarbeiter durch die Messungen. Ein Messplan leistete gute Dienste.

Für die PKW und die LKW-Entwicklung ergaben sich jedoch unterschiedliche Messkataloge. Dies scheint unausweichlich zu sein.

Der Umfang und die Umgebung des GQM-Projekts ist entscheidend. Trotz den "Abstraction Sheets" gab es keine eindeutige Lösung. Eine stärkere Formalisierung von GQM oder gar deren Automatisierung erscheint nicht sinnvoll.


Teade Punter: SW Messungen mit "GQM Light"

Was gibt es Neues nach 19 Jahren GQM? Warum wird es nicht häufiger angewandt?

In Deutschland wird Software vorwiegend von Kleinstunternehmen (<10 Mitarbeiter) erstellt. Das ist z.B. in Brasilien anders. Qualitätsverbesserungs-initiativen richten sich grossenteils jedoch an grössere Organisationen.

Agile Methoden verbessern den Kontakt zwischen Kunden und Programmierer, was Kommunikationsverlust vermindert, eignet sich jedoch weniger für die Produktentwicklung, schon gar nicht bei grossen Projekten mit Unteraufträgen oder sicherheitskritischen Komponenten. Disziplinierte Vorgehensweisen (Boehm, Turner 2003). Auch bei agilen Methoden braucht es Kontrolle.

Dafür eignet sich zielorientiertes Messen mit GQM, sofern die Definition auch mit Interpretation verbunden wird.

Aufwand entsteht vor allem bei der Planung und der Analyse. Bei einem "klassischen" GQM-Projekt muss man mit 6-7 Personenwochen rechnen. Mit GQM-Light konnten bedeutende Kosteneinsparungen realisiert werden, durch Standardisierung der Questions und Metrics. Ausserdem konnten durch Wiederverwendung Kosten eingespart werden. Eigentlich ist GQM-Light ein Kochrezept für GQM.

Im Grunde sollte aber am Schluss das Produkt gemessen sein, resp. das Ergebnis. Dabei sollte doch eigentlich die Produktqualität entscheidend sein.



Produktinformationen

Dirk Meyerhoff: Automatisierte Statusberichte

Das Management Dashboard funktioniert über einen Satz von Daten-Kollektoren, welche die Daten in den unterschiedlichen Ablagen (Excel, Access, etc.) sammeln und aufbereiten. Das Ergebnis steht dann als Web-Service dem Management, oder auch den Teamkollegen, zur Verfügung. Die Darstellung ist unabhängig vom für die Datensammlung verwendeten Werkzeug; die Daten werden über Feeders eingelesen und mittels einem eigenen Reporting-Werkzeug verdichtet und dargestellt.


QuantiMetrics:

QuantiMetrics ist ein Spin-Off von CSC und bietet Unterstützung von Verbesserungsprogrammen mit Metriken an. Sie bietet QPeP-Assessments an, die auf Parametrics aufbauen. Die Ergebnisse und Befunde des Assessments werden als Radar-Diagramm dargestellt und mit dem Median ähnlicher Projekte verglichen. Mit einem Sample von über 5000 Projekten ist eine sehr gute Vergleichsbasis gegeben.


Sotograph:

Sotograph ist eine Software-Analyseumgebung, die komplexe Java/ C/ C++ Systeme durchleuchtet und ihre inneren Strukturen aufzeigt.

Der Software-Tomograph erfasst Strukturinformationen von Softwaresystemen und bietet darauf ein breites Spektrum von Analysen und Visualisierungen an, etwa so, wie ein Computer-Tomograph bei menschlichen Patienten.



Metriken in der SW – Wartung

Björn Wolle: ABAP und Java in der Wartung

Viele neue Systeme werden in diesen Sprachen geschrieben, und doch ist es weitgehend unbekannt, welche Metriken sich hier bewähren.

Es ist schwierig, klare Aussagen dazu zu bekommen. Deswegen wurde die Studie unternommen, den Nutzen von LOC und Halstead-Metriken zu bestimmen. In der Regel hat man zuwenig Daten; dadurch ist die Unsicherheit bei Methoden wie COCOMO II zu gross.

Bei LOC sind allerdings einige kritische Anmerkungen angebracht als Metrik für die Bestimmung der Fehlerdichte, zur Definition und überhaupt bestehen messtheoretische Probleme.

Bis auf 10% sind LOC und Halstead austauschbar für Java und ABAP.

Halstead ergibt gute Prognosewerte für den zu erwartenden Wartungsaufwand, denn die Halstead-Metrik misst die zu erwartenden Aufwände und damit die Kosten.


Ton Dekkers: Funktionsmetriken in der Wartungsphase

Sogeti ist ein holländisches Beratungsunternehmen mit einem Metrik-Expertisezentrum. Dieses Zentrum erstellt Aufwandschätzungen für Kunden von Sogeti.

Wartung geschieht sowohl auf technischer wie auch auf funktioneller Ebene. In beiden Bereichen unterscheidet man Korrektur, Pflege und Anpassung an neue Bedürfnisse. Die Schätzmethode beruht auf einer Grössenmetrik (FPA nach IFPUG 4.1), Produktivität und Risikoeinschätzung. Bei Wartung betrachten wir die FPs der geänderten Elemente gemäss der von der NESMA definierten erweiterten IFPUG-Skala. Das erfordert natürlich die Kenntnis des Funktionsumfangs des gesamten zu wartenden Pakets. Je nach Komplexität und Umfang ergeben sich so die "Maintenance Function Points".

Bei COSMIC ist die Grundlage etwas anders: Man misst ausschliesslich die funktionalen Prozesse, welche Daten bewegen, und nicht die Daten selber. Im Gegensatz zu FPA brauchen wir jetzt keine Messungen für Änderungen der Daten.



Software-Metrik in der Ausbildung

Hans-Georg Hopf: Softwareprofis müssen messen können

Messen liegt am Anfang der modernen Physik. Modelle verhelfen zu Aussagen über das Ursprungsobjekt. Verglichen werden dabei die quantitativen Aussagen. Dazu muss man die richtigen Fragen an ein Software-System, oder an ein Software-Entwicklungssystem, stellen.

Am Beispiel einer Lehrveranstaltung "Softwarequalität" wird gezeigt, wie man mit der Lernumgebung "VirtuOhm" geeignete Lernräume schafft. Mit einem Zwiebelschalenmodell werden die Lerninhalte gebrauchsgerecht in der nötigen Tiefe angeboten, also z.B. Originalliteratur wenn benötigt.

Das Web-basierte Programm ist so gemacht, dass alle Inhalte so langsam aufgebaut werden, damit der Leser auch alles lesen kann und muss, damit er sich nicht einfach durchklickt.

Im Ergebnis muss festgestellt werden, dass

  • Die Teilnehmer waren überfordert mit der Planung und der richtigen Gewichtung, was wichtig ist
  • Die elektronischen Kommunikationsmedien wurden schlecht genutzt
  • Die Prüfungsergebnisse jedoch waren durchaus gleich gut wie in traditionellen Lehrveranstaltungen
  • In der Software jedoch fehlen uns die empirischen Daten, um wirklich "Naturbeobachtungen" vornehmen zu können.


    Melanie Ruhe: Aufwandschätzung von Web – Anwendungen

    Die Arbeit wurde in Australien durchgeführt. Die Autorin arbeitet nun an der zentralen Forschungsabteilung der Siemens AG, wo man sich Gedanken macht über die Effizienz und Effektivität der vorherrschenden Software-Entwicklungsmethodiken.

    Die Qualität der Web-Anwendungen ist zu einem entscheidenden Wettbewerbsfaktor geworden. Erfahrungsbasierte Aufwandschätzungen sind ungeeignet, weil man den Aufwand häufig unterschätzt. COCOMO II: WebMo bietet hier Abhilfe, die aber viel zuwenig bekannt ist und eher selten angewandt wird. Neu gibt es nun aber auch eine kombinierte Parametrics-Methode, nämlich CoBRA (Cost, Benchmarking und Risk Assessment). Bei "Allette Systems" in Australien wurde die Methode ausprobiert.

    Dazu mussten die Kostenfaktoren geschätzt werden (z.B. die Fehlerkosten oder Schattenkosten) betreffend Kriterien wie Stabilität der Anforderungen, Verfügbarkeit, Kundenmitwirkung, etc.). Gemessen wurden "Web Objects", eine Art Function Points für Web Anwendungen.

    Die Ergebnisse waren signifikant besser als Expertenschätzungen, allerdings nicht besser als Modell-basierte Schätzungen, bloss sind letztere in der Praxis erst viel zu spät einsetzbar, wenn nämlich alle Details bereits bekannt sind.




    (c) 2002-2016 DASMA e.V. Impressum
    aktualisiert am: 21. Dez 2006