Entwicklung und Bewertung von Software im Bereich von Office Automatisierung unter Verwendung von Open Source und Closed Source Technologien

Transkript

1 Entwicklung und Bewertung von Software im Bereich von Office Automatisierung unter Verwendung von Open Source und Closed Source Technologien Development and Evaluation of Software in the Office Automation Field by using Open Source and Closed Source Technologies Reinhard Pintsuk Vienna University of Economics and Business Administration, Reg. No April 3 rd, 2006 Information Business Seminar Course Paper Prof. Dr. Wolfgang Janko and Univ.-Ass. Mag. Dr. Stefan Koch Institute for Information Business Vienna University of Economics and Business Administration Augasse 2-6 A-1090 Wien, AUSTRIA - 1 -

2 Entwicklung und Bewertung von Software im Bereich von Office Automatisierung unter Verwendung von Open Source und Closed Source Technologien Development and Evaluation of Software in the Office Automation Field by using Open Source and Closed Source Technologies Stichworte: Office Automatisierung, Open Source, Closed Source, SW-Bewertung Keywords: Office Automation, Open Source, Closed Source, Software Evaluation Zusammenfassung In der vorliegenden Arbeit werden eine Open Source und eine Closed Source Lösung für ein Problem entwickelt und gegenübergestellt. Ziel für beide Lösungen ist es, sich innerhalb der Grenzen der IT-Strategie zu bewegen und dabei möglichst flexibel zu bleiben. Abstract This paper is about the development and comparison of an open source and a closed source solution for a problem. The goal of both solutions is to stay compliant with the IT strategy on the one hand and stay as flexible as possible on the other hand

3 Inhaltsverzeichnis 1 EINLEITUNG AUSGANGSSITUATION PROBLEMSTELLUNG ZIELSETZUNG AUFBAU DER ARBEIT 6 2 KONZEPT DARSTELLUNG UND BESCHREIBUNG DES KONZEPTS OPEN SOURCE SOFTWARE CLOSED SOURCE SOFTWARE OFFICE AUTOMATISIERUNG Skriptsprachen Gründe für die Verwendung von Skriptsprachen 9 3 TECHNISCHE ANFORDERUNGEN FÜR DIE KONZEPTUMSETZUNG MICROSOFT OFFICE OPENOFFICE.ORG BEAN SCRIPTING FRAMEWORK BSF4REXX OPEN OBJECT REXX Rexx/SQL 12 4 BEWERTUNG VON SOFTWARE EINFÜHRUNG UND ÜBERBLICK QUALITÄTSMODELLE FCM-Modelle Vorgehensmodelle SOFTWARE-METRIKEN Einteilung von Software-Metriken Klassische Software-Maße 19 5 DURCHFÜHRUNG UND ERGEBNISSE DER BEWERTUNG VORGANGSWEISE AUSWAHL EINES QUALITÄTSMODELLS AUSWAHL VON ZU MESSENDEN QUALITÄTSMERKMALEN AUSWAHL GEEIGNETER SOFTWARE-QUALITÄTSMAßE UND ABBILDUNG AUF DAS QUALITÄTSMODELL MESSUNG DER SOFTWARE UND INTERPRETATION DER ERGEBNISSE 23 6 ZUSAMMENFASSUNG, AUSBLICK LITERATUR ANHANG ANHANG A: CODE BEISPIEL, AUTOMATISIERUNG MIT MS-EXCEL

4 8.2 ANHANG B: CODE BEISPIEL, AUTOMATISIERUNG MIT OOO-SCALC ANHANG C: CODE BEISPIEL, AUTOMATISIERUNG MIT MS-ACCESS ANHANG D: CODE BEISPIEL, AUTOMATISIERUNG MIT MYSQL

5 1 Einleitung 1.1 Ausgangssituation Das heutige Unternehmensumfeld ist geprägt durch eine hohe Wettbewerbsdynamik, zunehmende Komplexität des Marktes, anspruchsvollere Kunden und verstärkten Kostendruck. Die verstärkte Globalisierung, der damit steigende Informationsfluss, exponentielles Technologiewachstum und die immer kürzeren Produktlebenszyklen begünstigen diese Entwicklung. Der Wandel von einer Produktions- zu einer Dienstleistungsgesellschaft begünstigt die wachsende Bedeutung der Beziehung zu Kunden und Partnern sowie dem damit verbundenen flüchtigen Schlüsselkapital "Wissen". Die steigenden Anforderungen an ein Unternehmen erfordern schnelle, präzise Entscheidungen und eine effektive strategische Planung. Die erarbeiteten Strategien haben immer kürzere Halbwertzeiten. Falsche oder zu spät getroffene Entscheidungen werden umgehend vom Unternehmensumfeld sanktioniert. Eine schnelle und richtige Umsetzung der Unternehmensstrategie ist dabei der Schlüssel zum Erfolg. 1.2 Problemstellung Die hohe Anzahl an unterschiedlichen IT-Lösungen und die zunehmend notwendige Vernetzung von IT-Lösungen aufgrund von z.b. Unternehmenszusammenschlüssen führen zu steigenden Kosten in Erhaltung, Wartung und Weiterentwicklung von IT-Systemen. Des Weiteren steht die IT einem steigenden Kostendruck seitens der Unternehmensleitung gegenüber. 1.3 Zielsetzung Bei AUDI werden Strategien für Teilbereiche des Unternehmens, z.b. der IT, aus der Unternehmensstrategie abgeleitet. Die im Jahr 2005 implementierte Organisations- und Informationsmanagement-Strategie 2015 (O&IM Strategie 2015) der Markengruppe Audi erfordert eine Neuausrichtung der IT. Unter anderem werden darin Anforderungen an die IT- Architektur- und Technologie-Strategie abgeleitet. Die Ausgangssituation in der IT- Architektur- und Technologie-Strategie ist u.a. geprägt durch eine Vielzahl von individuellen IT-Lösungen sowie den Einsatz von zu vielen Software-Entwicklungswerkzeugen und Programmiersprachen. Audi hat im Rahmen seiner O&IM Strategie 2015 Maßnahmen entwickelt, die geeignet sind, den zukünftigen Anforderungen zu entsprechen. Der Verfasser entwickelt in dieser Arbeit einen Lösungsansatz, der geeignet scheint, die zukünftigen Anforderungen an eine effiziente Unternehmens-IT zu unterstützen. Der Schwerpunkt bei der erarbeiteten Lösung liegt dabei auf Wiederverwendbarkeit und Portabilität

6 Daraus leiten sich die Ziele dieser Arbeit ab: Erstellung einer Office Automatisierungssoftware mit dem Ziel, dass die Portabilität dieser Software zwischen Open Source und Closed Source Plattformen möglichst hoch ist. Bewertung dieser Software 1.4 Aufbau der Arbeit In der Einleitung, Kapitel 1, wurde das Thema dieser Arbeit vorgestellt und eine Themenabgrenzung vorgenommen. Es folgt eine kurze Vorstellung des Unternehmens Audi. Kapitel 2 beschäftigt sich mit dem dieser Arbeit zugrunde liegenden Konzept und beschreibt das Umfeld der Arbeit. In Kapitel 3 werden die notwendigen technischen Anforderungen zur Umsetzung des Konzepts erläutert. Kapitel 4 erläutert zunächst die theoretischen Grundlagen für die Bewertung von Software. Anschließend werden zwei wesentliche Vertreter der Software-Metriken vorgestellt und analysiert. Das folgende Kapitel 5 beschreibt die Durchführung der Bewertung und versucht, die Ergebnisse zu interpretieren. In der Schlussbetrachtung, Kapitel 6, werden die Ergebnisse kurz zusammengefasst und es wird versucht, eine Bewertung für zukünftige IT-Entscheidungen abzugeben

7 2 Konzept 2.1 Darstellung und Beschreibung des Konzepts Bild 1 Closed Source Umgebung Die abgebildete Closed Source Umgebung zeigt Client- und Serverseitig die Verwendung von Closed Source Software. Die zu erstellende Software dient als Vermittler zwischen der Anwendung am Client (z.b. MS-Excel) und der Datenbankanwendung am Server (z.b. MS- Access oder MS-SQL). Software Linux Client, OpenOffice.org Bild 2 Open Source Umgebung Linux Server, MySQL Die abgebildete Open Source Umgebung zeigt Client- und Serverseitig die Verwendung von Open Source Software. Die zu erstellende Software dient als Vermittler zwischen der Anwendung am Client (z.b. Calc, die Tabellenkalkulation im OpenOffice.org) und der Datenbankanwendung am Server (z.b. MySQL). Ziel der Arbeit ist es, die als Vermittler dienende Software derart zu erstellen, dass sie mit möglichst wenig Aufwand von der Closed Source Umgebung in die Open Source Umgebung portiert, also übertragen werden kann. 2.2 Open Source Software Unter Open-Source-Software versteht man Softwareprogramme, deren Quelltext für jedermann einsehbar und frei verfügbar ist. Für Open-Source-Software gibt es eine Reihe verschiedener Lizenzen, die dem Benutzer jeweils unterschiedliche Freiheitsgrade im Umgang mit der Software und bezüglich ihrer Weiterverbreitung gewähren. [vgl. Hans02, 160] - 7 -

8 Folgende Vorteile von Open Source Software können, losgelöst von den spezifischen Unterschieden verschiedener Lizenzen, genannt werden [vgl. Hans02, 160f]: Der Quellcode der Software steht dem Benutzer frei (gemeint ist damit auch kostenfrei) zur Verfügung und er kann die Software prinzipiell beliebig an seine Bedürfnisse anpassen. Die Software wird i.d.r. nicht von einem einzelnen Unternehmen bzw. Organisation vermarktet, die die Verwendungsmöglichkeiten der Software beschränkt. Die Software wird gemeinschaftlich durch eine Anwendergemeinde im Internet gewartet und weiterentwickelt. Die zukünftige Wartung und Weiterentwicklung der Software hängt nicht von einem einzelnen Unternehmen ab und kann prinzipiell von jedem interessierten Entwickler übernommen werden. Fehler werden durch die freie Verfügbarkeit des Quellcodes schneller aufgedeckt und behoben. Weiterhin können eventuell sicherheitskritische Funktionen prinzipiell von jedem persönlich begutachtet und bei Bedarf deaktiviert werden. Als Beispiele für bekannte Open-Source-Softwareprojekte können das Betriebssystem Linux, die Büroanwendung OpenOffice.org, der DatenbankServer MySQL, der WebServer Apache und die Skriptsprache Open Object Rexx genannt werden. Lizenzkosten fallen bei Open Source Software nicht an, wodurch diese Art von Software in den vergangenen Jahren an Attraktivität gewonnen hat. 2.3 Closed Source Software Closed Source Software ist dadurch gekennzeichnet, dass der Quellcode der Software für den Benutzer nicht frei zur Verfügung steht. Bei der Beschaffung dieser kommerziellen Software, wie z.b. Microsoft Windows, Microsoft Windows Server und Microsoft Office, können einem Unternehmen im Unterschied zu Open Source Software - beträchtliche Lizenzkosten entstehen. 2.4 Office Automatisierung Office Automatisierung bedeutet im Kontext der vorliegenden Arbeit die Steuerung von Office-Anwendungen (z.b. Microsoft Office, OpenOffice.org) mit einer Skriptsprache Skriptsprachen Skripts wurden ursprünglich als eine Mitschrift von Befehlen verstanden, die ein Benutzer hintereinander eingegeben hat. Wenn anschließend die gleichen Kommandos ein weiteres mal ausgeführt werden sollten, konnte anstatt einer wiederholten Eingabe das Skript zur Ausführung der Befehle genutzt werden. Hiermit geht der Begriff Skriptsprache historisch auf die Möglichkeit zur Automatisierung von wiederkehrenden Tätigkeiten zurück [vgl. Hans02, 953]. Eine Skriptsprache erlaubt neben dem bloßen Abspeichern der Kommandos die Formulierung von Ablaufsteuerungsprogrammen. Hierdurch kann die (wiederholte) Ausführung dieser Kommandos an Bedingungen geknüpft werden. Kommandos können entweder dem Aufruf von externen Programmen (extern aus der Sicht der Skriptsprache) oder - 8 -

9 von Softwarekomponenten entsprechen, mit denen die Skriptsprache erweitert wurde. Skriptsprachen werden auch als Sprachen der vierten Generation bezeichnet. [vgl. Hans02, 954] Gründe für die Verwendung von Skriptsprachen Skriptsprachen haben im Wesentlichen drei wichtige Eigenschaften [vgl. Hans02, 954]: Erweiterbarkeit: Der Befehlsumfang kann relativ einfach erweitert werden. Zwei Sprachschichten: Die Befehle der Skriptsprache sind meist in einer anderen Programmiersprache, z.b. C, implementiert. Interpretativ, dynamische Typisierung: Skriptsprachen sind in der Regel interpretativ (wird über einen Interpreter ausgeführt) und verlangen keine Deklaration der verwendeten Variablen. Durch die oben genannten Eigenschaften eignen sich Skriptsprachen sehr gut für die komponentenbasierte Softwareentwicklung und damit für schnelle Anwendungsentwicklungen. Die Skriptsprache fungiert hierbei als Vermittler und ermöglicht somit die Interaktion zwischen den verschiedenen Komponenten auf einfachste Weise. Insbesondere gilt dies, wenn wie in der vorliegenden Arbeit ihre gemeinsame Verwendung zum Entwicklungszeitpunkt noch nicht absehbar war. Skriptsprachen können dazu beitragen, einen hohen Grad an Wiederverwendung für Komponenten zu erreichen. Das führt wiederum zu einer hohen Codequalität der Komponenten (ausgiebige Tests durch häufige Verwendung) und andererseits zu einer hohen Produktivität des Entwicklers (Wiederverwendung eines Großteils der Funktionalität) [vgl. Hans02, 954f]. Einer der ersten Skriptsprachen war die Sprache REXX, die von Michael Cowlishaw im Jahr 1979 bei IBM entwickelt wurde. Die vom Verfasser dieser Arbeit entwickelte Software wurde auf Basis dieser Skriptsprache erstellt

10 3 Technische Anforderungen für die Konzeptumsetzung 3.1 Microsoft Office Microsoft Office ist ein umfassendes Office-Paket, das gegen Bezahlung von Lizenzgebühren angeboten wird. Microsoft Office ist ausschließlich auf Windows Betriebssystemen lauffähig. Wichtige Vertreter aus der Microsoft Office Produktfamilie sind [MsO06]: Word Die Textverarbeitung von Microsoft Office. Excel Die Tabellenkalkulation von Microsoft Office. Powerpoint Die Präsentationssoftware von Microsoft Office. Outlook , Kontaktverwaltung, Notizen, Aufgabenverwaltung. Access Die Datenbanksoftware von Microsoft Office. 3.2 OpenOffice.org OpenOffice.org ist ein umfassendes Office-Paket, das ohne Lizenzgebühren, aber mit offenem Programmcode angeboten wird. OpenOffice.org ist auf den wichtigsten Betriebssystemen unter anderem Microsoft Windows, Mac OS X X11, GNU/Linux und Solaris verfügbar und besteht aus folgenden Komponenten [OOo06]: Writer Die Textverarbeitung von OpenOffice.org. Calc Die Tabellenkalkulation von OpenOffice.org. Impress Die Präsentationssoftware von OpenOffice.org. Draw Das Grafikprogramm von OpenOffice.org. Zur Erstellung von einfachen Diagrammen bis zu dynamischen 3-D-Illustrationen mit Spezialeffekten. Base Das Datenbankmodul von OpenOffice.org. Es können eigene Datenbanken integriert oder die integrierte Datenbank verwendet werden. Math Für die Erstellung von mathematischen Gleichungen und Formeln. OpenOffice.org erlaubt den Import und Export von Microsoft Office Dokumenten. 3.3 Bean Scripting Framework Bean Scripting Framework (BSF) is a set of Java classes which provides scripting language support within Java applications, and access to Java objects and methods from scripting languages [ ]. [Ajp05]

11 Das bedeutet, dass Skriptsprachen via das Bean Scripting Framework Zugriff auf Java Objekte und Methoden erhalten. Nachfolgendes Bild zeigt die wesentlichen Komponenten: BSFManager und BSFEngine. Bild 3 BSF-Architektur, Überblick [nach Hane05, 17] Der BSF-Manager steuert alle script execution engines und ist für sie verantwortlich. Des weiteren verwaltet der BSF-Manager die object registry, die den Skriptzugriff auf Java Objekte ermöglicht. 3.4 BSF4Rexx 1 BSF4Rexx bedeutet BSF mit einer Rexx Engine [vgl. Flat06, 25]. Damit wird die Benutzung von Rexx über BSF ermöglicht. Jedes Java-Programm kann Rexx aufrufen und Rexx-Skripte können mit Java Objekten kommunizieren. Des weiteren ermöglicht BSF4Rexx die Benutzung von Java als riesige externe Funktionsbibliothek. Bild 4 BSF4Rexx Architektur [nach Flat06, 28] 1 [BSF4Rexx]

12 3.5 Open Object Rexx 2 Open Object Rexx ist ein Open Source Projekt, das durch die RexxLA 3 verwaltet wird. oorexx ist eine Skriptsprache und wird unter der Common Public License (CPL) v1.08 verteilt [CPL06]. Object Rexx (oorexx) kann wie folgt charakterisiert werden: An English-like statement Fewer Rules Interpreted not compiled Built in functions and methods Typeless variables String handling Decimal Arithmetic Clear error messages and powerful debugging Rexx/SQL 4 Rexx/SQL stellt Rexx-Programmierern ein konsistentes, einfaches und gleichzeitig leistungsfähiges Interface für SQL-Datenbanken zur Verfügung. Es sind mehrere Verbindungen zu verschiedenen Datenbanken von verschiedenen Herstellern in einem Rexx- Skript möglich. 2 [oorexx06] 3 Rexx Language Association 4 [RexxSQL]

13 4 Bewertung von Software 4.1 Einführung und Überblick Der Bewertung von Software liegt die Software-Qualitätssicherung zugrunde. Unsere Gesellschaft ist in vielen Lebensbereichen auf das fehlerfreie Funktionieren von Software-Systemen angewiesen. Flugzeuge, Schiffe, Automobile und auch medizinische Geräte werden durch Software-Systeme gesteuert. Ziel der industriellen Software-Entwicklung muss es daher sein, ein Software-Produkt mit definierter Qualität zu erstellen. Über den Begriff der Qualität gibt es unterschiedliche Auffassungen. Es lassen sich fünf verschiedene Ansätze unterscheiden, die verschiedene betriebliche Sichten auf das Produkt beschreiben [vgl. Balz98, 256]: Der transzendente (= übernatürlich) Ansatz: Qualität ist universell erkennbar, absolut einzigartig und vollkommen und steht für kompromisslos hohe Standards und Ansprüche an die Funktionsweise eines Produkts. Vertreter dieses Ansatzes meinen, dass Qualität nicht exakt definiert oder gemessen werden kann. Qualität lässt sich nur durch Erfahrung bewerten. Dieser Ansatz ist für die Praxis nicht geeignet. Der produktbezogene Ansatz: Qualität ist eine genau spezifizierte Größe, die das Produkt beschreibt, messbar ist und das Aufzeigen von Qualitätsunterschieden ermöglicht. Subjektive Beobachtungen und Wahrnehmungen werden nicht berücksichtigt. Aufgrund der gemessenen Qualität kann eine Rangordnung von verschiedenen Produkten der gleichen Kategorie aufgestellt werden. Dieser Ansatz bezieht sich auf das Endprodukt, nicht auf den Kunden und kann damit zu einer mangelhaften Berücksichtigung der Interessen der Kunden führen. Der benutzerbezogene Ansatz: Qualität wird durch den Produktbenutzer festgelegt und weniger durch das Produkt selbst. Der Benutzer entscheidet anhand seiner Wünsche und Bedürfnisse, ob es sich um ein Qualitätsprodukt handelt oder nicht. Produkte, die diese Bedürfnisse am besten befriedigen, werden als qualitativ hochwertig beurteilt. Da der Benutzer oft nur vage Qualitätsvorstellungen hat, ist es für den Hersteller im Voraus meist schwierig, die Bedürfnisse des Benutzers zu erkennen bzw. zu antizipieren. Das meistverkaufte Produkt ist oft nicht das Produkt, das eine optimale Bedürfnisbefriedigung bietet. Hinzu kommt, dass sich die Bedürfnisse eines Benutzers mit fortschreitender Technologie ändern können. Der prozessbezogene Ansatz: Qualität entsteht durch die korrekte Erstellung eines Produkts. Der Erstellungsprozess wird spezifiziert und überwacht, um Ausschuss- und Nachbearbeitung auf das gewünschte Maß zu reduzieren und ihn kontinuierlich an die sich ändernden Kundenbedürfnisse anzupassen

14 Der Kosten/Nutzen-bezogene Ansatz: Qualität ist abhängig von Kosten und Nutzen. Ein Qualitätsprodukt ist demnach ein Erzeugnis, das einen bestimmten Nutzen zu einem akzeptablen Preis erbringt. Diese Ansätze versuchen den Begriff Qualität durch Umschreibung zu verdeutlichen. Daneben gibt es auch Versuche, den Begriff der Qualität zu definieren. Einen produkt- und prozessbezogenen Ansatz liefert dabei die DIN 55350, Teil 11: Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. Balzert definiert die Produkt-Qualität von Software in Anlehnung an die DIN ISO 9126 wie folgt [vgl. Balz98, 257]: Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software- Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Wallmüller bezieht sich in seinen Ausführungen u.a. auf Boehm, der zur Problematik der Bestimmung der Qualität eines Software-Produktes sinngemäß folgende 3 Fragen stellt [vgl. Wall01, 13]: Problem der Definition von Software-Qualität Ist es überhaupt möglich, Definitionen der Eigenschaften und Merkmale eines Software-Produkts aufzustellen, die messbar sind und sich nicht überschneiden? Problem der Qualitätsprüfung Wie gut kann man die Qualität eines Software-Produkts bzw. die Eigenschaften und Merkmale messen, welche die Qualität des Software-Produktes bestimmen? Problem der Qualitätslenkung Wie kann man Informationen über die Qualität des Produkts zur Verbesserung des Produkts im Lifecycle verwenden? Allgemeine Definitionen der Software-Qualität sind für die praktische Anwendung unzureichend, deshalb beschreibt man die Software-Qualität durch ein Qualitätsmodell. 4.2 Qualitätsmodelle Durch ein Qualitätsmodell wird der allgemeine Begriff der Qualität operationalisiert. Dies geschieht durch das Ableiten von Unterbegriffen [vgl. Balz98, 257; Wall01, 60]. Sie haben den Zweck, die verschiedenen Vorstellungen über Qualität zu vereinheitlichen und damit eine einheitliche Kommunikation zu erreichen. Qualität wird dadurch definierbar und planbar

15 4.2.1 FCM-Modelle Bild 5 Aufbau von FCM-Qualitätsmodellen (factor-criteria-metrics-models) [nach Balz98, 257] Aufbau des FCM-Qualitätsmodells [vgl. Balz98, 258] Die Software-Qualität wird im Allgemeinen, oder bezogen auf einzelne Entwicklungen, durch Qualitätsmerkmale beschrieben, die im englischen Sprachraum auch als factor bezeichnet werden. Qualitätsmerkmale werden in einem nächsten Schritt in Teilmerkmale bzw. Kriterien weiter verfeinert. Letztendlich werden diese Teilmerkmale/Kriterien definiert. Qualitätsmerkmale entsprechen eher einer benutzerorientierten Sichtweise, während Teilmerkmale oft die softwareorientierten Eigenschaften widerspiegeln. Durch Qualitätsindikatoren bzw. Metriken werden die einzelnen Teilmerkmale mess- und bewertbar gemacht. Indikatoren sind ausgewiesene Eigenschaften eines Software-Produkts, die zu den Qualitätsmerkmalen in Beziehung gesetzt werden können. Beispielhaft für Indikatoren nennt Balzert die Pfadlänge, den modularen Aufbau sowie Programmstruktur und Kommentar und bezieht sich dabei auf die DIN ISO 9126, S.2. Quantifizierbare Indikatoren können mit Hilfe von Qualitätsmaßen quantitativ gemessen werden und das Ergebnis, der Messwert, wird auf einer Skala abgebildet. Ein Software-Qualitätsmaß ist eine quantitative Skala und eine Methode, mit welcher der Wert bestimmt werden kann, den ein Indikator für ein bestimmtes Software-Produkt aufweist. Da mehrere Qualitätsmerkmale oft gemeinsame Teilmerkmale besitzen, kann ein FCM- Modell einen Baum oder auch ein Netz bilden. Teilmerkmale können selbst eine Hierarchie bilden, so dass ein FCM-Modell auch mehr als drei Ebenen enthalten kann. FCM-Modelle können für die Prozessqualität und die Produktqualität aufgestellt werden, ein Beispiel dafür sind die nachfolgend beschriebenen Software-Qualitätsmerkmale nach DIN ISO

16 Software-Qualitätsmerkmale nach DIN ISO 9126, S. 3ff [vgl. Balz98, 258] Es werden folgende sechs Qualitätsmerkmale für Software-Produkte definiert, die auf jede Art von Software angewendet werden können und sich lediglich minimal überschneiden. Teilmerkmale bzw. Metriken enthält diese Norm nicht, der Anhang der Norm beinhaltet einen Vorschlag zur Definition von Teilmerkmalen. Die sechs Qualitätsmerkmale sind nach DIN ISO 9126 [vgl. Balz98, 259f]: Funktionalität Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z.b. die benötigte Genauigkeit von berechneten Werten. Angemessenheit: Eignung der Funktionen für spezifizierte Aufgaben, z.b. aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen. Interoperabilität: Fähigkeit, mit vorgegebenen Systemen zusammenzuwirken. Ordnungsmäßigkeit: Erfüllung von anwendungsspezifischen Normen, Vereinbarungen, gesetzlichen Bestimmungen und ähnlichen Vorschriften. Sicherheit: Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten zu verhindern. Zuverlässigkeit Fähigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. Reife: Geringe Versagenshäufigkeit durch Fehlzustände. Fehlertoleranz: Fähigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer spezifizierten Schnittstelle zu bewahren. Wiederherstellbarkeit: Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. Zu berücksichtigen sind die dafür benötigte Zeit und der benötigte Aufwand. Benutzbarkeit Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe. Verständlichkeit: Aufwand für den Benutzer, das Konzept und die Anwendung zu verstehen. Erlernbarkeit: Aufwand für den Benutzer, die Anwendung zu erlernen (z.b. Bedienung, Ein-, Ausgabe) Bedienbarkeit: Aufwand für den Benutzer, die Anwendung zu bedienen. Effizienz Verhältnis zwischen dem Leistungsniveau der Software und dem Umgang der eingesetzten Betriebsmittel unter festgelegten Bedingungen. Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung. Verbrauchsverhalten: Anzahl und Dauer der benötigten Betriebsmittel für die Erfüllung der Funktionen

17 Änderbarkeit Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen, Verbesserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen und der funktionalen Spezifikationen einschließen. Analysierbarkeit: Aufwand, um Mängel oder Ursachen von Versagen zu diagnostizieren oder um änderungsbedürftige Teile zu bestimmen. Modifizierbarkeit: Aufwand zur Ausführung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an Umgebungsänderungen. Stabilität: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Änderungen. Prüfbarkeit: Aufwand, der zur Prüfung der geänderten Software notwendig ist. Übertragbarkeit Eignung der Software, von einer Umgebung in eine andere übertragen zu werden. Umgebung kann organisatorische Umgebung, Hardware- oder Software-Umgebung einschließen. Anpassbarkeit: Möglichkeiten, die Software an verschiedene, festgelegte Umgebungen anzupassen, wenn nur Schritte unternommen oder Mittel eingesetzt werden, die für diesen Zweck für die betrachtete Software vorgesehen sind. Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgesetzten Umgebung notwendig ist. Konformität: Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt. Austauschbarkeit: Möglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu verwenden, sowie der dafür notwendige Aufwand. Weitere Beispiele für FCM-Modelle sind [vgl. Balz98, 261ff]: FURPS, Hewlett Packard, 1985 (Functionality, Usability, Reliability, Performance und Supportability) Software-Qualitätsmodell von McCall, Modell von Boehm Das DGO-Modell Vorgehensmodelle Neben den FCM-Modellen gibt es auch Vorgehensmodelle. Das sind Modelle, durch deren Anwendung man zu einem entwicklungs- oder unternehmensspezifischen Qualitätsmodell gelangt. Als Vertreter dafür sei der Goal-Question-Metric-Ansatz (GQM-Ansatz) von Basili/Rombach genannt, der eine systematische Vorgehensweise zur Erstellung eines entwicklungsspezifischen Qualitätsmodells angibt [vgl. Balz98, 263; Wall01, 35]. Wallmüller geht an dieser Stelle auf weitere Ansätze ein, die jedoch für die vorliegende Arbeit nicht relevant sind [vgl. Wall01, 36-43]. 4.3 Software-Metriken A software metric is any type of measurement that relates to a software system, process or related documentation." [vgl. Somm04, 655]

18 Software-Metriken (bzw. Maße) beziehen sich also auf Attribute von ein oder mehreren Objekten bzw. Komponenten der Software-Entwicklung, -Wartung oder Anwendung [vgl. Dumk03, 169]. Wallmüller verweist in seinen Ausführungen auf die Arbeit von Itzfeld, Schmidt und Timm. Danach müssen Software-Qualitätsmaße bestimmte Gütekriterien erfüllen. Gütekriterien für Software-Qualitätsmaße, nach Itzfeld, Schmidt und Timm [vgl. Wall01, 44]: Objektivität Zuverlässigkeit Validität (Messtauglichkeit) Normierung Vergleichbarkeit Ökonomie Nützlichkeit Die Validität ist dabei am schwierigsten zu messen, stellt aber sicher, dass die Anforderungen der Benutzer erfüllt werden. Maße, für die keine Aussagen über deren Validität vorliegen, sind für objektive Qualitätsbewertungen nicht brauchbar [vgl. Wall01, 44; Somm04, 516]. Nachfolgendes Bild zeigt die Entwicklung der Software-Metriken zwischen 1960 und Bild 6 Meilensteine in der Entwicklung von Software-Metriken [nach Alyo06, 10] Einteilung von Software-Metriken 5 Eine oft verwendete Einteilung von Software-Maßen erfolgt in Prozess- und Produktmetriken. 5 [vgl. Wall01, 47ff; Somm04, ]

19 Bild 7 Klassifikation von Software-Metriken [nach Alyo06, 11] Ein Prozessmaß misst Attribute im Software-Prozess oder der Entwicklungsumgebung (z.b. Anzahl der Jahre an Entwicklungserfahrung), ein Produktmaß misst Attribute direkt am Produkt, z.b. Anzahl der Codezeilen (LOC, Lines of Code), die Strukturkomplexität (Steuerfluss, Verschachtelungstiefe) oder die Datenstrukturkomplexität (Anzahl verwendeter Variablen) Klassische Software-Maße An dieser Stelle wird nun auf die beiden bekanntesten Maße näher eingegangen. Beide Maße betonen den Quellcode als zentrales Messobjekt, vereinfachen aber sehr stark die unterschiedlichen Programmmerkmale [vgl. Wall01, 50] Maß von McCabe (Cyclomatic Complexity) 6 Mc Cabe misst die logische Struktur eines Programms und geht von der Idee aus, ein Programm als einen gerichteten Graphen darzustellen. Dabei sind die Knoten des Graphen die Anweisungen und die Kanten der Kontrollfluss zwischen den Knoten. Mc Cabe meint, dass die Programmkomplexität von der Anzahl der Hauptwege dieses Programmgraphen abhängig ist. Die Formel für die Berechnung lautet: v(f) = e n + 2p, wobei: e Anzahl der Kanten im Programmgraphen n Anzahl der Knoten im Programmgraphen p Anzahl der Zusammenhangskomponenten (unabhängige Teilgraphen, z.b. Module, Prozeduren, immer mindestens 1) Mc Cabe nutzt sein Maß, um die minimale Anzahl der Testfälle zu finden und schlägt einen qualitativ guten Wert mit v(f) 10 vor. Danach sollte sich auch die Modulgröße richten. 6 [vgl. Wall01, 50-54; JaKo04, 13ff]

20 Bild 8 Berechnung der Cyclometic Complexity [nach JaKo06, 15] Der Wert von v(f) ist beiden Fällen v(f) = 4. Das Maß von McCabe ist also nichts anderes, als die Anzahl der Entscheidungen, Ands, Ors und Nots + 1 [vgl. Wall01, 52]. Ein Vorteil ist die einfache Berechenbarkeit. Eine Schwachstelle bei dieser Art der Messung ist, dass nicht der eigentliche Umfang des Programmes beachtet wird, da jeder Knoten des Graphen beliebig viele Anweisungen enthalten kann, solange sich darunter keine Verzweigung befindet Maß von Halstead 7 Die Halstead-Metrik zählt zu den Umgangsmetriken. Dieser Ansatz beruht auf der Prämisse, dass ein Programm nur aus Operanden und Operatoren besteht. Operator bezeichnet dabei Symbole, die den Wert oder die Anordnung eines Operanden beeinflussen. Operanden bezeichnen Variablen, Konstanten oder Sprungmarken. Halstead hat folgende drei Maße entwickelt: Umfang V = (N1+N2)*ld(n1+n2) Schwierigkeit L = (2/n1)*(n2/N2) Testaufwand E = (V/L) n 1 Anzahl verschiedener Operatoren n 2 Anzahl verschiedener Operanden N 1 Gesamtanzahl aller Operatoren N 2 Gesamtanzahl aller Operanden n = n 1 + n 2 Anzahl verschiedener Symbole N = N 1 + N 2 Anzahl Gesamtzahl aller Symbole Deren Klassifikation ist dabei sprachabhängig und wurde von Halstead nicht definiert [vgl. Wall01, 54]. Die Messung beschränkt sich darauf, die unterschiedlichen und insgesamt auftretenden Operatoren und Operanden zu zählen und die Ergebnisse in obige drei Formeln einzusetzen. Ein Vorteil dieses Maßes ist, dass auch komplizierte Ausdrücke berücksichtigt werden und z.b. im Gegensatz zum Maß von Mc Cabe viele verschiedene Variablen einen hohen 7 [vgl. Wall01, 54ff; JaKo04, 16ff]