Otto-von-Guericke-Universität Magdeburg. Functional Size emeasurement

Transkript

1 Otto-von-Guericke-Universität Magdeburg Functional Size emeasurement Konzeption und prototypische Realisierung einer elearning-umgebung für die funktionale Größenmessung Diplomarbeit Fakultät für Informatik Institut für Verteilte Systeme Arbeitsgruppe Softwaretechnik Themensteller: Betreuer: Prof. Dr. Reiner R. Dumke Dipl.-Inform. Mathias Lother vorgelegt von: Martin Kunz Matrikelnummer: Straße der Einheit Burg Abgabetermin: 30. September 2004 I

2 Otto-von-Guericke-Universität Magdeburg Otto-von-Guericke-Universität Magdeburg Kunz, Martin Konzeption und prototypische Realisierung einer elearning-umgebung für die funktionale Größenmessung Diplomarbeit, Otto-von-Guericke-Universität Magdeburg, II

3 Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis...III Abkürzungsverzeichnis...V Abbildungsverzeichnis... VII Tabellenverzeichnis... IX Verzeichnis der Kode-Fragmente... IX 1 Einleitung Motivation Zielstellung Aufbau der Diplomarbeit Software-Management und Software-Messung Aspekte des Software-Managements Projektmanagement Softwarequalitätsmanagement Aspekte der Software-Messung Software-Metriken und Software-Maße Auswahl der Messziele Bestimmung des Umfangs von Software Physikalische Größe von Software Functional Size Measurement als funktionale Größenmessung Web-Merkmale des Functional Size Measurement FSeMP - Portal zur funktionalen Größenmessung Beschreibung der existierenden Portallösung Ansätze zur Verbesserung Überblick moderner elearning-technologien Begriffsbestimmung Lernformen Lehrformen Architekturformen Learning Management Systems / Learning Content Management Systems...31 III

4 Inhaltsverzeichnis 4.3 Elektronische Zusammenarbeit in einer elearning-umgebung Beispiele existierender elearning-anwendungen Beschreibung der FSeMP elearning-umgebung Nutzeranalyse des Systems Experten-Community als Peer-to-Peer Wissensdistribution Charakterisierung der Experten-Community Komponenten zur Realisierung der Experten-Community FSeMP Metric Selection Guide FSeMP Link Finder FSeMP Video Conferencing FSeMP Bulletin Board FSeMP Case Studies Entwicklungspotential Ausgewählte Aspekte der Realisierung Grundlagen des Functional Size emesurement Portal Prototypische Entwicklung der FSeMP elearning-komponenten Entwicklung des FSeMP Metric Selection Guide Entwicklung des FSeMP Link Finder Entwicklung des FSeMP Bulletin Board Entwicklung der FSeMP Video-Conferencing -Komponente Entwicklung der FSeMP Case Study -Komponente Einbindung der Komponenten als Portlets Evaluierung der realisierten Komponenten Zusammenfassung...73 Literaturverzeichnis...75 Anhang...79 Impressum...90 Selbstständigkeitserklärung...91 IV

5 Abkürzungsverzeichnis Abkürzungsverzeichnis CAME CBT CD-ROM CMM CoCoMo COSMIC DIN DSI DVD ÉTS FAQ FP FFP FPA FSM FSeMP FUR GQM HTML HTTP IBM IFPUG ISBSG ISO IT JDBC JSP Computer Assisted Software Measurement and Evaluation Computer Based Training Compact Disc - Read Only Memory Capability Maturity Model Costructive Cost Model The Common Software Measurement International Consortium Deutsches Institut für Normung e.v. Delivered Source Instructions Digital Versatile Disc École de Technologie Supérieure Frequently Asked Questions Function Point(s) Full Function Point(s) Function Point Analysis Functional Size Measurement Functional Size emeasurement Portal Functional User Requirement Goal-Question-Metric HyperText Markup-Language HyperText Transfer Protocol International Business Machines The International Function Point Users Group The International Software Benchmarking Standards Group International Organization for Standardization Informationstechnologie Java-Database-Connectivity Java Server Pages V

6 Abkürzungsverzeichnis SEMRL SLIM SMLab LCMS LMS LOC MIS ODBC PDF PHP PSP RDBMS SPI SQL UML VAF WBT WWW XML Software Engineering Management Research Laboratory Software Lifecycle Management Software Measurement Laboratory Learning Content Management System Learning Management System Lines of Code Management Information System Open Database Connectivity (vgl. JDBC) Portable Document Format Personal Hypertext Pre-processor Personal Software Process Relationales Datenbankmanagementsystem Software Process Improvement Structured Query Language Unified Modelling Language Value Adjustment Factor Web Based Training World Wide Web extensible Markup Language VI

7 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Bestandteile des Software-Managements [Dumke 2000]...4 Abbildung 2: Teufelsquadrat von Sneed [Sneed 1987]...6 Abbildung 3: Produktqualität im Software-Lebenszyklus [ISO/IEC 2001]...7 Abbildung 4: Qualitätsmerkmale der quality in use attributes [ISO/IEC 2001]...8 Abbildung 5: Ursache-Wirkungsdiagramm nach DIN [Dumke 2002]...8 Abbildung 6: Messprozess nach ISO [ISO/IEC 2002]...11 Abbildung 7: Schema zur Skalen-Anwendung [Dumke 2000]...12 Abbildung 8: Metrikenauswahl nach der GQM-Methode [Dumke 2002]...13 Abbildung 9: Übersicht zu ausgewählten FSM-Methoden...15 Abbildung 10: Generelles Vorgehen beim FSM [Abran 2001]...16 Abbildung 11: Elemente der IFPUG FPA [Lother 2001]...17 Abbildung 12: Elemente der Mark II FPA [Lother 2002a]...18 Abbildung 13: COSMIC FFP Schichtenmodell [COSMIC 2003]...19 Abbildung 14: Elemente der COSMIC FFP [COSMIC 2003]...19 Abbildung 15: Palm-basiertes Werkzeug für das Zählen von Function Points...20 Abbildung 16: Java-basiertes Tool zur Auswertung von Function Points...20 Abbildung 17: Projektverwaltung und -eingabe...22 Abbildung 18: Automatisch erzeugter Projekt-Benchmark-Report...22 Abbildung 19: Visualisierung von Projektdaten...23 Abbildung 20: Aufwandsschätzung mit Hilfe des Estimation 2004-Tools...24 Abbildung 21: Kernfunktionalitäten des FSeMP...24 Abbildung 22: Architektur des offenen Telelernens [Dumke 2003]...30 Abbildung 23: Architektur des betreuten Telelernens [Dumke 2003]...31 Abbildung 24: Architektur beim Teleteaching [Dumke 2003]...31 Abbildung 25: Technische Bausteine einer elearning-umgebung...32 Abbildung 26: Lernprogramm zur Aufzugstechnik...34 Abbildung 27: detaillierte Darstellung zur Aufzugstechnik...35 Abbildung 28: Videobasiertes elearning-system der Deutschen Bahn AG...36 Abbildung 29: Gesamtfunktionalität des FSeMP...40 Abbildung 30: Der FSM Selection Process [ISO/IEC 2003]...41 Abbildung 31: Ergebnis einer Projektbewertung...42 Abbildung 32: Details einer Projektbewertung...43 VII

8 Abbildungsverzeichnis Abbildung 33: Formular zur Projektcharakterisierung...44 Abbildung 34: Auswertung des Metric Selction Guide"...46 Abbildung 35: Startseite des Link-Finder"...47 Abbildung 36: Dokumente im Link-Finder"...47 Abbildung 37: Architektur des Link-Finder"...48 Abbildung 38: Beispiel einer Videokonferenz...49 Abbildung 39: Architektur der Video Conferencing"-Komponente...49 Abbildung 40: FSeMP Bulletin Board...50 Abbildung 41: Architektur des "Bulletin Board"...51 Abbildung 42: FSeMP Case Studies...51 Abbildung 43: Architektur der FSeMP Case Studies"...52 Abbildung 44: Komponenten der Portallösung [Braungarten 2004]...55 Abbildung 45: 3-tier" Architektur der Portallösung [Braungarten 2004]...55 Abbildung 46: Kernaktivitäten der FSeMP elearning-umgebung...56 Abbildung 47: Aktivitätsdiagramm des Metric Selection Guide"...56 Abbildung 48: Aktivitäten im zweiten Entwurf des Metric Selection Guide...57 Abbildung 49: Use-Case-Diagramm für den Link Finder...61 Abbildung 50: Aktivitätsdiagramm für den Link Finder...62 Abbildung 51: Sequenzdiagramm eines PHP-Aufrufs...63 Abbildung 52: Use-Case-Diagramm für das Bulletin Board...64 Abbildung 53: Aktivitätsdiagramm für das Bulletin Board...65 Abbildung 54: 3-tier"-Architektur einer Datenbankanbindung mit PHP...66 Abbildung 55: Sequenzdiagramm einer Datenbankabfrage mit PHP...66 Abbildung 56: Aktivitätsdiagramm für das Video-Conferencing -Tool...67 Abbildung 57: Sequenzdiagramm einer Videokonferenz...68 Abbildung 58: Use-Case-Diagramm für den Abruf von Case-Studies...69 Abbildung 59: Aktivitätsdiagramm für die FSeMP elearning-umgebung...79 Abbildung 60: zweiter Entwurf des Metric Selection Guide...80 VIII

9 Tabellenverzeichnis Tabellenverzeichnis Tabelle 1: Interne und externe Qualitätsmerkmale (vgl. [ISO/IEC 2001])...7 Tabelle 2: Die Stufen des Capability Maturity Model [Dumke 2000]...9 Tabelle 3: Eigenschaften verschiedener Skalentypen (nach [Fenton 1997])...12 Tabelle 4: Unterschiedliche Lernformen...27 Tabelle 5: Anforderungen an elearning-systeme [Riser 2002]...29 Tabelle 6: Gegenüberstellung von LMS und LCMS [Hettrich 2003]...33 Tabelle 7: Bewertungsstufen des Selection Guide...42 Tabelle 8: Übersicht von functional domains" (vgl. [Lother 2001])...44 Verzeichnis der Kode-Fragmente Kode-Fragment 1: Aufbau der grafischen Benutzeroberfläche...58 Kode-Fragment 2: Implementierung eines Action-Listener"...58 Kode-Fragment 3: Berechnung der Methodenbewertung...59 Kode-Fragment 4: Formularaufbau und Variablen-Übergabe...60 Kode-Fragment 5: Funktion zum Herstellen einer Datenbankverbindung...66 Kode-Fragment 6: Funktion zur Datenbankabfrage...67 Kode-Fragment 7: Registrierung einer Instanz des IFramePortlet...70 IX

10 1 Einleitung 1 Einleitung 1.1 Motivation Mit wachsendem, technischem Fortschritt erlangten Rechnersysteme und die auf ihnen ausgeführten Anwendungen eine zunehmende Bedeutung für alle Gebiete des täglichen Lebens. So basiert beispielsweise der globale Daten- beziehungsweise Informationsaustausch auf komplexer, computergestützter Satellitenkommunikation, wobei mit Hilfe hochmoderner Rechentechnik eine multimediale Vielfalt geschaffen werden kann, ohne die unsere schnelllebige Informationsgesellschaft schon lange nicht mehr vorstellbar wäre. Zudem existieren speziell auch in Industrie, Wissenschaft und Gesellschaft Bereiche, in denen der Einsatz fortschrittlicher Informationstechnologie unverzichtbar scheint. Zum Beispiel werden in der Wirtschaft komplizierte Steuerungs- und Planungsaufgaben durch komplexe elektronische Systeme realisiert oder in der Finanzwirtschaft Transaktionen und Wertpapiergeschäfte nahezu ausschließlich über vernetzte Informationssysteme abgewickelt. Vor allem jedoch in der Forschung und Entwicklung begünstigt der Einsatz von Rechnersystemen die Gewinnung einer Vielzahl von Erkenntnissen wie der Entdeckung der 100 größten, derzeit bekannten Primzahlen. Im Zuge dieser Entwicklung ist der IT-Branche und insbesondere der Software produzierenden Industrie als einem der weltweit wichtigsten Wirtschaftsfaktoren ein enormes, ökonomisches Gewicht zugekommen, zumal sie in praktisch allen anderen Wirtschaftszweigen als Zulieferer fungiert und somit von zentraler Bedeutung ist. Getrübt wird diese Attraktivität bezüglich der Wertschöpfungsmöglichkeiten allerdings dadurch, dass anhaltend viele Wettbewerber in einen nicht mehr so stark expandierenden Markt drängen. Um dem Rechnung zu tragen und dem in dieser Branche stark um sich greifenden Konkurrenzdruck standhalten zu können, muss die Produktion von Software unter marktwirtschaftlichen Gesichtspunkten mit dem Ziel der Effizienzoptimierung stattfinden. Aus diesem Grunde ist es für das Management eines Unternehmens der Software-Branche unverzichtbar, bei anstehenden Entscheidungen im Vorfeld auf Prognosen ökonomischer Eckdaten und Kostenfaktoren zurückzugreifen, auf dieser Basis etwaige Risiken zu bewerten und damit vorbeugende Qualitätssicherungsmaßnahmen einzuleiten. Hierfür erweisen sich die ingenieurwissenschaftlichen Herangehensweisen des Software-Engineering als äußerst hilfreich. Insbesondere durch die auf das Messziel der funktionalen Größe ausgerichtete Softwaremessung und die darauf aufbauende Aufwandsschätzung unter Zuhilfenahme algorithmischer Modelle, statistischer Methoden oder Expertenbefragungen, lassen sich 1

11 1 Einleitung aussagekräftige Vorhersagen zum Beispiel bezüglich des aufzubringenden Personalaufwands treffen. 1.2 Zielstellung Durch die in allen Bereichen der Wirtschaft anhaltende Globalisierung kommt es zu einer verstärkten geographischen Arbeitsteilung, um die unterschiedlichen Kostenstrukturen in verschiedenen Wirtschaftsräumen auszunutzen und somit die Kosten zu minimieren. So werden im konkreten Software-Entwicklungs-Prozess nur noch die Angebotserstellung und die frühen Phasen der Softwareentwicklung, wie Problemdefinition, Anforderungsanalyse, Spezifikation und Entwurf, in den klassischen Industriestaaten wie den USA, Europa oder Asien ausgeführt. Die späten Phasen der Software-Entwicklung, wie Implementierung, Test und Auslieferung, werden hingegen häufig in Schwellenländer mit niedrigerem Lohnniveau wie zum Beispiel Indien oder China verlagert [Kindler 1995]. Diese geographische Verteilung bleibt für den Entwicklungsprozess natürlich nicht ohne Folgen, weshalb sich das Management und die Kontrolle der einzelnen Entwicklungsstadien über verschiedene Kontinente und Zeitzonen hinweg als äußerst schwierig darstellen. Dabei können allerdings die Ausprägungen moderner Informationstechnik, wie zum Beispiel das Internet hilfreich sein, um die Zusammenarbeit der den Entwicklungs-Prozess überwachenden Experten zu unterstützen. Eine dieser Zusammenarbeit abträgliche geographische Verteilung der Experten als solche ist aber nach wie vor festzustellen. Mit der Zielstellung, dem angesprochenen Personenkreis eine Orts-unabhängige und personalisierbare Möglichkeit zur Kooperation zu geben, wurde in einem vorangegangenen Projekt ein Portal für die funktionale Größenmessung konzipiert und prototypisch implementiert. Daher besteht das Ziel dieser Diplomarbeit darin, mit Hilfe einer in das Portal zur funktionalen Größenmessung zu integrierenden elearning-umgebung, erfahrenen Softwareentwicklern das Thema der funktionalen Größenmessung näher zu bringen, um eine breite Basis von Softwaremess-Experten in einer virtuellen Gemeinschaft ( Community ) zu vereinen und diese weltweit zugänglich zu machen. Die Bündelung dieses Expertenwissens soll dazu führen, dass zum einen das Portal an sich weiterentwickelt werden kann und das zum anderen bei speziellen Problemstellungen auf sehr schnelle Art und Weise Ansprechpartner gefunden und so Lösungswege aufgezeigt werden können. Für den Erfolg des Portals für die funktionale Größenmessung im Allgemeinen und für die Experten-Community im Speziellen ist natürlich eine breite Basis an sich beteiligenden Softwaremess-Experten von enormer Bedeutung. 2

12 1 Einleitung 1.3 Aufbau der Diplomarbeit Die vorliegende Diplomarbeit befasst sich mit dem Entwurf und der prototypischen Implementierung einer elearning-umgebung für ein existierendes Portal zur funktionalen Größenmessung, welches bereits als Functional Size emeasurement Portal prototypisch implementiert wurde [Braungarten 2004]. Hierfür werden im zweiten Kapitel die Themengebiete Softwarequalitätsmanagement und Softwaremessung kurz umrissen und im dritten Kapitel das Portal in seiner existierenden Form vorgestellt. Darauf folgend werden im vierten Kapitel die theoretischen Grundlagen für das im Mittelpunkt der Betrachtung stehenden Themengebiet elearning gelegt. Daran anschließend erfolgt im fünften Kapitel die Analyse der verschiedenen potenziellen Benutzer einer solchen Umgebung, um mit dem entstandenen Nutzerprofil die für dieses Projekt prädestinierte elearning-umgebung zu identifizieren. Des Weiteren werden die zur Realisierung benötigten Komponenten in ihrer Funktionalität beschrieben und entsprechende Entwicklungs- und Erweiterungsmöglichkeiten aufgezeigt. Im sechsten Kapitel werden dann ausgewählte Aspekte der Realisierung des Systems dargelegt. Neben den technischen Besonderheiten und Merkmalen werden in diesem Kapitel auch die selbst entwickelten Tools in ihrer Implementierung beschrieben. Abschließend wird im siebten Kapitel die Diplomarbeit zusammengefasst, es wird ein Ausblick gegeben und erläutert, inwieweit andere Projekte und wissenschaftliche Arbeiten auf diese Diplomarbeit aufbauen können. 3

13 2 Software-Management und Software-Messung 2 Software-Management und Software-Messung 2.1 Aspekte des Software-Managements Der Prozess der Entwicklung eines Software-Produktes wird im Allgemeinen als Software-Entwicklungsprojekt bezeichnet. Ein Projekt wird deshalb wie folgt definiert: Ein Projekt (project) ist der konkrete Prozess zur Entwicklung eines konkreten Software-Produktes mit den dafür notwendigen Ressourcen. [Dumke 2000, S.8] Ein derartiges Projekt ist durch Prozessmerkmale gekennzeichnet, welche die Anwendung spezieller Methoden, Techniken und Tools im Rahmen der Software- Entwicklung, -Wartung und -Anwendung betreffen, wobei der Einsatz von administrativen und organisatorischen Methoden als Management bezeichnet wird. Daraus ergibt sich folgende Definition: Das Software-Management (software management) ist die Planung, Überwachung und Steuerung des Prozesses und der dabei einzusetzenden Ressourcen zur Entwicklung, Wartung und Anwendung von Software-Systemen. [Dumke 2000, S.183] Das Software-Management ist im Wesentlichen in drei Teile gegliedert, deren Zusammenhang und die sich daraus ergebenden Arbeitsschritte in Abbildung 1 dargestellt sind. Abbildung 1: Bestandteile des Software-Managements [Dumke 2000] 4

14 2 Software-Management und Software-Messung Die für diese Diplomarbeit maßgeblich relevanten Aspekte sind die im Entwicklungsmanagement angesiedelten Gesichtspunkte des Projekt- und Qualitätsmanagements Projektmanagement Das Managen von Software-Projekten ist eine der größten Herausforderungen in der heutigen Software-Entwicklung. Die Qualitätssicherung, die Projektsteuerung ( controlling ) und der zielführende Einsatz der zur Verfügung stehenden Ressourcen sind die Kernaufgaben eines Projekt-Managers. Häufig werden für diese Aufgaben erfahrene Mitarbeiter aus anderen Bereichen des Software-Entwicklungs-Prozess akquiriert, obwohl eigentlich eine spezialisierte Ausbildung für diese Aufgaben erforderlich wäre [Mandl-S. 2001]. Um der Relevanz des Themas Rechnung zu tragen, soll das Projekt-Management Gegenstand der folgenden Betrachtungen sein. Die vorliegende Fachliteratur [Dumke 2000, S.192] definiert das Projektmanagement als die Gesamtheit der planenden, kontrollierenden und steuernden Aktivitäten für die termingerechte Bereitstellung der Ressourcen und der kostengerechten Realisierung eines Software-Produktes. Dieses Projektmanagement kann man dabei unterscheiden in operatives und strategisches Projektmanagement [nach Bundschuh 2000], wobei das operative Management die Projektebene betrifft und das strategische Management sich auf die Managementebene bezieht. Kernbestandteile des Projektmanagements sind neben der Projektsteuerung und der Risikobewertung vor allem auch die Kostenschätzung. Die Projektsteuerung kann dabei dem operativen Projektmanagement zugeordnet werden, wohingegen die Risikobewertung und die Kosten- beziehungsweise Aufwandsschätzung zum strategischen Management gehören. Zu den primären Zielvorgaben des Projektmanagements zählt die Optimierung der Qualität, Quantität, Projektdauer und der Projektkosten. Diese Zielvorgaben stehen miteinander in Konkurrenz um die verfügbaren Ressourcen innerhalb eines IT- Projektes. [Bundschuh 2000] Die Abhängigkeit der Zielvorgaben wird im Teufelsquadrat von Sneed [Sneed 1987] ersichtlich (siehe Abbildung 2). Durch das innere (in der Abbildung blau dargestellte) Viereck wird die Begrenztheit der verfügbaren Ressourcen dargestellt. Eine Verschiebung der Ressourcen beziehungsweise ein Mehrverbrauch einer Zielvorgabe, in Abbildung 2 durch das zweite, innere Viereck gekennzeichnet, hat automatisch eine Verknappung der Ressourcen einer anderen Zielvorgabe zur Folge. 5

15 2 Software-Management und Software-Messung Abbildung 2: Teufelsquadrat von Sneed [Sneed 1987] Softwarequalitätsmanagement Als Softwarequalitätsmanagement betrachtet man die Sicherung von Qualitätsmerkmalen für das Software-Produkt auf der Grundlage der Prozess- und Ressourcenqualität durch organisatorische Methoden und Maßnahmen unter Anwendung spezieller Techniken und Technologien. [Dumke 2002] Hierbei wird die Qualität von Software definiert als die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht. [Dumke 2002] Vor der grundlegenden Betrachtung des Qualitätsmanagements sollen zuerst Aspekte der Software-Qualität im Fokus der Analyse stehen, welche sich in die drei Bereiche Produkt-, Prozess- und Ressourcenqualität gliedert. Produktqualität: Für die Bewertung der Software-Produktqualität spielt der Blickwinkel des Betrachters eine nicht unerhebliche Rolle. Für Benutzer eines Software-Produktes sind in erster Linie die funktionalen Eigenschaften relevant; man spricht hier von externer Qualität eines Software Produktes. Für den Software-Entwickler hingegen spiegelt sich Qualität in den software-technischen Gesichtspunkten wieder, welche man zum Beispiel aus dem Quellkode oder dem Entwurfskonzept herleiten kann. Diese Sichtweise wird als interne Qualität eines Software-Produktes bezeichnet. Zusätzlich kann mit Hilfe der quality in use attributes untersucht werden, ob ein Produkt, in der jeweiligen Benutzungsumgebung, die geforderten Eigenschaften erfüllt und den benötigten Effekt erzielt [ISO/IEC 2001]. 6

16 2 Software-Management und Software-Messung Derartige, unterschiedliche Sichten, geordnet nach internal, external und quality in use, finden sich auch im internationalen Standard für Produktqualität ISO 9126 [ISO/IEC 2001] wieder (siehe Abbildung 3). Abbildung 3: Produktqualität im Software-Lebenszyklus [ISO/IEC 2001] Die für die Bewertung der Qualität entscheidenden Qualitätsmerkmale werden im ISO 9126 Standard nach der Funktionalität, Effizienz, Zuverlässigkeit, Änderbarkeit, Benutzbarkeit und Übertragbarkeit unterteilt. Damit liefert der Standard eine einheitliche Beschreibung der Software-Produktqualität. ISO Software Product Evaluation External and Internal quality Functionality Efficiency o Suitability o Time behaviour o Accuracy o Resource utilisation o Interoperability o Efficiency compliance o Compliance Maintainability o Security o Analysability o Functionality compliance o Changeability Reliability o Stability o Maturity o Testability o Fault tolerance o Maintainability o Reliability compliance compliance Usability Portability o Understandability o Adaptability o Learnability o Installability o Operability o Conformance o Usability compliance o Replaceability o Portability compliance Tabelle 1: Interne und externe Qualitätsmerkmale (vgl. [ISO/IEC 2001]) Die Aufteilung der Qualitätsmerkmale der quality in use attributes ist in der folgenden Abbildung 4 ersichtlich. 7

17 2 Software-Management und Software-Messung Abbildung 4: Qualitätsmerkmale der quality in use attributes [ISO/IEC 2001] Die deutsche Fassung des Standards liefert nach einem Entwurf zur DIN folgendes Ursache-Wirkungsdiagramm: Abbildung 5: Ursache-Wirkungsdiagramm nach DIN [Dumke 2002] Prozessqualität In der Realität zeigt sich deutlich, dass Software-Produktqualität erst in den späten Entwicklungsphasen konstatiert werden kann. Aber gerade die frühen Phasen des Software-Entwicklungsprozess tragen wesentlich zur Gewährleistung der Produktqualität bei [Dumke 2002]. Aus diesem Grund gelangt man zur Problemstellung der Prozessqualität, welche wie folgt definiert wird: Die Software-Prozessqualität ist die Anwendung von Methoden und Techniken des Managements und der Steuerung zur ständigen Verbesserung des Prozesses (als Software Process Improvement (SPI)) mit dem grundlegenden Ziel der Sicherung der Software-Produktqualität [Dumke 2002]. Eine Möglichkeit, den Software-Entwicklungsprozess zu klassifizieren, bietet das Capability Maturity Model (CMM), dessen fünf Niveaustufen in der anschließend aufgeführten Tabelle kurz erläutert werden sollen. 8

18 2 Software-Management und Software-Messung CMM-Stufe 1 (Initial) 2 (Repeatable) 3 (Defined) 4 (Managed) 5 (Optimizing) Charakteristika Abhängig von einzelnen Personen und deren Fähigkeiten Software-Projektmanagement, Software-Qualitätsmanagement, Konfigurationsmanagement, Kosten-/Aufwandsschätzungen Prozessdefinition auf der Grundlage einer Prozessanalyse, integriertes Software-Management, CASE-Tool-Anwendung, Schulungsprogramm, Peer-to-Peer-Reviews Quantitatives Prozessmanagement auf der Grundlage von Metriken, Software-Qualitätsmanagement Prozessänderungsbeherrschung, gezielte Fehlervermeidung, Technologieänderungsbeherrschung Tabelle 2: Die Stufen des Capability Maturity Model [Dumke 2000] Ressourcenqualität Die für den Software-Entwicklungsprozess benötigten Ressourcen gliedern sich nach Dumke in die zur Verfügung stehenden personellen Grundlagen auf der einen Seite, und in die für Entwicklung und Betrieb vorgesehenen Software- und Hardware-Grundlagen auf der anderen Seite [Dumke 2002]. Da man aber gerade Soft- und Hardware-Ressourcen sehr häufig in großem Umfang akquiriert, hat man auf die endgültige Qualität dieser vorgefertigten Ressourcen keinen direkten Einfluss [Dumke 2002]. Hierbei kann eine Qualitätssicherung nur bei der Auswahl entsprechender Ressourcen erfolgen; später auftretende Qualitätsmängel sind in diesem Fall nur schwer zu beheben. Daher legt man den Fokus auf die stetige Verbesserung der Fähigkeiten des Software- Entwicklungspersonals. Hierfür wurde Ende der neunziger Jahre der so genannte Personal Software Process (PSP) entwickelt [Humphrey 1997], mit dessen Hilfe auf der Basis einer verbesserten Planung, fundiertem Training und einer qualifizierten Überwachung eine höhere Produktivität erzielt werden kann. Wie in Abbildung 1 bereits dargestellt, bilden Software-Messungen die Grundlage eines erfolgreichen Software-Managements. Da Methoden zur Sicherung der Software- Qualität vielfach direkt auf Software-Messungen aufbauen, sollen im folgenden Kapitel Aspekte der Software-Messung dargelegt werden. 9

19 2 Software-Management und Software-Messung 2.2 Aspekte der Software-Messung Software-Messung (software measurement) ist der Prozess der Quantifizierung von Attributen der Objekte bzw. Komponenten des Software Engineering mit der Ausrichtung auf spezielle Messziele (measurement goals) und ggf. der Einbeziehung von Messwerkzeugen (measurement tools). [Dumke 2000, S.151] Im Bereich der Software-Messung gibt es vielfältige Messziele, welche sich auf alle Gesichtspunkte (Prozesse, Produkte, Ressourcen) innerhalb des Software-Lebenszyklus beziehen können. Gemäß der Messtheorie wird dabei unterschieden zwischen physikalischen Merkmalen wie Größe und Zeit sowie empirisch messbaren Merkmalen wie Benutzerfreundlichkeit, Zuverlässigkeit und Korrektheit, welche auf dem Erfahrungs- beziehungsweise Wissenshintergrund der Software-Entwicklung beruhen. [Dumke 2000] Die gegebenenfalls einzubeziehenden Messwerkzeuge werden wie folgt definiert: Ein Softwaremeßtool sei ein Softwarewerkzeug, welches Komponenten eines Software- Produktes oder der Softwareentwicklung in ihrer Quellform oder transformierten Form (z.b. als spezielles Modell) einliest und nach vorgegebenen Verarbeitungsvorschriften numerisch oder symbolisch auswertet." [Dumke 2000] Solche der Definition entsprechenden Werkzeuge für die Softwaremessung werden unter dem Begriff CAME-Tools (Computer Assisted Software Measurement and Evaluation) zusammengefasst. Zur Anwendung entsprechender Messtools in einem Softwaremessprozess mit dem Ziel der Erlangung spezifischer Messziele entwickelte die International Organization for Standardization (ISO) einen Messstandard (ISO 15939), der die Intention hat, die Grundlagen von Messung und Bewertung auf der Basis von Erfahrungsdaten zu vereinen [Dumke 2002]. Die folgende Abbildung beschreibt die allgemeinen Komponenten des Modells und deren Interaktionen. 10

20 2 Software-Management und Software-Messung Abbildung 6: Messprozess nach ISO [ISO/IEC 2002] Software-Metriken und Software-Maße In der Fachliteratur [Dumke 2000] wird eine Software-Metrik gemäß der Maßtheorie definiert als eine Abstandsfunktion, welche Attributen von Software-Komponenten Zahlen beziehungsweise Zahlenbereiche zuordnet. Um neben der damit gegebenen Möglichkeit quantitativer Vergleiche auch empirische Aussagen treffen zu können, bedarf es der Definition eines Software-Maßes. Ein solches Software-Maß ist gemäß der Messtheorie eine mit einer Maßeinheit versehene Skala, die in dieser Form ein Software-Attribut bewertet beziehungsweise messbar macht. Demnach wird bei einem Softwaremaß die empirische Bedeutung hauptsächlich durch die Maßeinheit ausgedrückt. 11

21 2 Software-Management und Software-Messung Abbildung 7: Schema zur Skalen-Anwendung [Dumke 2000] Darüber hinaus bestimmt die so genannte Skala die homomorphe Abbildung des numerischen Relativs (Quantifizierung) auf das empirische Relativ (empirische Bedeutung). Hierbei kann die Art der Abbildung variieren (siehe Tabelle 3). Tabelle 3: Eigenschaften verschiedener Skalentypen (nach [Fenton 1997]) Auswahl der Messziele Um aus der Vielzahl existierender Messansätze und Metriken, den für das Projekt beziehungsweise für die Zielstellung praktikabelsten Messansatz herauszufiltern, erweist sich der Einsatz der Goal-Question-Metric - Methode (GQM) als hilfreich (vgl. [ Solingen 1999]). Dazu bedarf es zu Beginn der Definition eines Messziels ( Goal ), darauf folgend werden hypothetische Fragen ( Question ) aufgestellt, welche den Problembereich allumfassend beleuchten sollen und somit einen Ansatz liefern, das 12

22 2 Software-Management und Software-Messung Ziel in geeigneter Weise zu erreichen. Werden diese Hypothesen bestätigt, kann man aus den entsprechenden Fragen dann die zu verwendenden Metriken ( Metric ) auswählen. [Dumke 2002] Abbildung 8: Metrikenauswahl nach der GQM-Methode [Dumke 2002] Bestimmung des Umfangs von Software Für die weitere Betrachtung der Thematik der Softwaremessung soll der Ermittlung des Messzieles der Größe beziehungsweise des Umfangs von Software eine herausgestellte Bedeutung zukommen. Für die Bestimmung der Größe von Software existieren im Wesentlichen drei verschiedene Ansätze [Fenton 1997]: die erste Möglichkeit besteht in der Bestimmung der physischen oder logischen Größe anhand des Quelltextes, ähnlich einem physikalischen Längenmaß. Die zweite Möglichkeit besteht in der Bestimmung der Komplexität als Maß für die Software-Größe. Und die dritte Möglichkeit besteht letztendlich darin, nicht den Quelltextumfang als Basis für die Ermittlung heranzuziehen sondern stattdessen die dem Benutzer entgegengebrachte Funktionalität zu bestimmen und diese schließlich mit Hilfe von verschiedenen Faktoren zu quantifizieren. Da die Komplexität aber in erster Linie Zeit und Speicherplatzverbrauch quantifiziert [Fenton 1997] und nicht im eigentlichen Sinne den Umfang einer Software bestimmt, sollen sich die folgenden Ausführungen auf die physikalische und funktionale Größe konzentrieren. 13

23 2 Software-Management und Software-Messung Physikalische Größe von Software Die Bestimmung der Größe von Software auf Basis abzählbarer Elemente war lange Zeit die einzig anwendbare Möglichkeit zur Bestimmung des Software-Umfangs [Cote 1988]. Dabei kann die Ermittlung auf unterschiedliche Art und Weise an Hand der Anzahl der logischen Anweisungen ( delivered source instructions, DSI) oder der Anzahl der reell vorhandenen Programmzeilen ( lines of code, LOC) durchgeführt werden. Allerdings ist es möglich, dass der Umfang je nach Zählweise variiert, wenn beispielsweise nicht eindeutig definiert wird, ob Leer- oder Kommentarzeilen mit in die Berechnung eingehen. Nach Bundschuh bedingt dies außerdem eine sehr schlechte Vergleichbarkeit der erzielten Werte, zumal bei unterschiedlichen Messungen sehr häufig eine abweichende Interpretation der Zählregeln vorgenommen wird. [Bundschuh 2000] Die Bestimmung der Software-Größe mit Hilfe der physikalischen Größe besticht also in erster Linie aufgrund der Unkompliziertheit des Messverfahrens. Diese Unkompliziertheit und die weite Verbreitung sind einer hohen Automatisierbarkeit zuträglich und versprechen ein hohes Nutzungspotential. Deshalb findet zum Beispiel das LOC-Maß Anwendung in verschiedenen Schätzmodellen wie zum Beispiel dem Constructive Cost Model (CoCoMo) [Boehm 2000] oder dem Software Lifecycle Management (SLIM). [Lother 2002a] Diesen Vorteilen stehen leider auch einige Nachteile gegenüber, die insbesondere bei der Merkmals- und Aufwandsschätzung ins Gewicht fallen. So ist ein wesentlicher Makel sicherlich die Untersuchung des Quelltextes, der aber erst sehr spät im Software- Entwicklungszyklus zur Verfügung steht. Zu kritisieren ist ebenfalls eine starke Abhängigkeit von der Programmiersprache und dem Programmierstil (vgl. [Lother 2001]) Functional Size Measurement als funktionale Größenmessung Aus den obigen Ausführungen wird ersichtlich, dass die Bestimmung des Umfangs von Software anhand ihrer physikalischen Größe gewissen Unzulänglichkeiten unterliegt, weshalb die Methode der funktionalen Größenmessung ( Functional Size Measurement, FSM) entwickelt [Abran 2001] und als ISO/IEC standardisiert wurde [ISO/IEC 1998]. So ist die FSM-Methode schon in den frühen Phasen der Software-Entwicklung (Anforderungsanalyse oder Spezifikation) einsetzbar und gänzlich unabhängig von der verwendeten Programmiersprache oder der technischen Realisierung [Lother 2001]. 14

24 2 Software-Management und Software-Messung Diese Unabhängigkeit von der Realisierung führt dazu, dass die funktionale Größe auch für Benutzer interpretierbar ist, denen zum Beispiel die abstrakte LOC-Anzahl keinen Informationswert bietet. Dadurch liefert die funktionale Größenmessung auch für Kunden und Manager ein nutzbares Ergebnis. Zudem haben sich für verschiedene Einsatzbereiche unterschiedlich ausgerichtete Methoden der funktionalen Größenmessung etabliert. [Bundschuh 2000] Jedoch führt Bundschuh ebenso aus, dass einige Nachteile der funktionalen Größenmessung nicht aus den Augen verloren werden dürfen. Die Möglichkeit, diese Messmethode schon in den sehr frühen Phasen der Software-Entwicklung anwenden zu können, erfordert auf der anderen Seite ein ständiges Nachjustieren, da das Fachkonzept im Laufe der Entwicklung zumeist Änderungen erfährt. Ein weiterer Nachteil ist der Schwierigkeitsgrad bei der Bestimmung der funktionalen Größe. Deshalb bedarf es eines reichhaltigen Erfahrungsschatzes für die korrekte Anwendung der FSM-Methode. [Bundschuh 2000] Ihre Wurzeln hat die funktionale Größenmessung in der im Jahre 1979 von A. Albrecht vorgestellten Forschungsarbeit Function Point Analysis [Albrecht 1979]; diese Veröffentlichung wurde in den darauf folgenden Jahren von verschiedenen Fachverbänden und Interessengruppen adaptiert und modifiziert (siehe Abbildung 9). Abbildung 9: Übersicht zu ausgewählten FSM-Methoden (angepasst nach [Symons 2001]) Die generelle Vorgehensweise zur Bestimmung der funktionalen Größe gliedert sich in die beiden Teile Mapping und Evaluation. In der Mapping - Phase wird versucht, 15

25 2 Software-Management und Software-Messung die Definitionen und Konzepte der funktionalen Größenmessung auf die zu untersuchende Software abzubilden. Die eigentliche Quantifizierung der Elemente findet dann in der Evaluationsphase statt. Abbildung 10: Generelles Vorgehen beim FSM [Abran 2001] Dieses generelle Prinzip zur Bestimmung der funktionalen Größe findet sehr viele, für verschiedene Anwendungsfälle entwickelte Ausprägungen (siehe Abbildung 9). Das elearning-system und das zu Grunde liegende Portal zur funktionalen Größenmessung unterstützen die drei am weitesten verbreiteten Methoden. Deshalb konzentrieren sich die anschließenden Ausführungen auf die drei Methoden Function Point Analysis (IFPUG FPA), MarkII Function Points und Full Function Points (COSMIC-FFP). Function Point Analysis: Die IFPUG FPA stellt eine durch den Fachverband The International Function Point Users Group (IFPUG) nach Albrecht standardisierte und stetig weiterentwickelte Methode zur funktionalen Größenmessung dar. Diese Methode genießt vor allem auf Grund ihrer internationalen Geltung und Verbreitung eine hohe Bedeutung. Entwickelt wurde diese Methode in erster Linie im Hinblick auf Management Information Systems (MIS). Die Bedeutung dieser Methode wurde dann auch durch die Standardisierung nach ISO 20926:2003 Software Engineering anerkannt. [Lother 2002a]. Der eigentliche Messvorgang wird hierbei realisiert durch die Ermittlung der externen Ein- und Ausgaben, der internen und externen logischen Dateien sowie der externen Abfragen (siehe Abbildung 11). Zusätzlich kann eine projektspezifische Anpassung anhand von Gewichtungsfaktoren ( value adjustment factor, VAF) erfolgen, welche sich aus insgesamt 14 Systemmerkmalen ergeben. Da dies aber kein gesichertes Vorgehen darstellt und dementsprechend nicht unumstritten ist, sind diese Gewichtungsfaktoren nicht im ISO Standard enthalten. 16

26 2 Software-Management und Software-Messung Abbildung 11: Elemente der IFPUG FPA [Lother 2001] Mark II FPA: Die Methode Mark II FPA wurde 1988 von Charles Symons in einer seiner zahlreichen Publikationen Function Point Analyses: Difficulties and Improvements. [Symons 1988] vorgestellt und im Jahr 2002 als ISO 20968: 2002 Software Engineering standardisiert. Auch bei der Mark II Function Point Analysis wird die Grundlage durch die FPA von Albrecht gebildet. Die Weiterentwicklung erfolgte mit der Zielstellung, den subjektiven Spielraum bei der Messung zu reduzieren und das Augenmerk auf den Aufwand zu richten, der bei der Realisierung der gewünschten Funktionalität erforderlich ist, und nicht auf die Quantifizierung der dem Benutzer zur Verfügung gestellten Funktionalität [Lother 2002a]. Folgerichtig ergibt sich der Messwert aus den logischen Transaktionstypen der Eingabe, der Berechnung und der Ausgabe (siehe Abbildung 12). Analog zur IFPUG FPA ist eine Gewichtung anhand der 14 bekannten und fünf zusätzlichen Gewichtungsfaktoren möglich, welche aber ebenso nicht im ISO-Standard aufgeführt werden. 17

27 2 Software-Management und Software-Messung Abbildung 12: Elemente der Mark II FPA [Lother 2002a] Full Function Points: Um die Konzentration auf Management Information Systems bei den beiden voran gegangenen Methoden zu durchbrechen, wurde 1997 von St-Pierre Full Functions Points Version 1.0 als Erweiterung der IFPUG Function Points veröffentlicht [St- Pierre 1997]. Mit dieser Erweiterung sollte die Konzentration auf MIS durchbrochen werden und eine Bemessung auch von Echtzeit-Anwendungen und Systemsteurungs- Software ermöglicht werden [Lother 2001]. Der 1998 gegründete Fachverband The Common Software Measurement International Consortium (COSMIC) forcierte die Entwicklung zu einem eigenen Standard, welcher mit der Veröffentlichung der neuartigen Version 2.2 der Full Function Points geschaffen wurde. [Winkler 2003] Ein wichtiger und neuartiger Ansatz der Methode ist die Integration eines Schichten- Modells, in der die unterschiedlichen Sichten auf die Software in verschiedene Ebenen unterteilt sind (siehe Abbildung 13). Die Datenbewegungen zwischen den Schichten werden unterteilt in read, write, entry und exit (siehe Abbildung 14). Die Software-Größe definiert sich dann als Summe jeder einzelnen Ausprägung einer dieser Datenbewegungen. 18

28 2 Software-Management und Software-Messung Abbildung 13: COSMIC FFP Schichtenmodell [COSMIC 2003] Abbildung 14: Elemente der COSMIC FFP [COSMIC 2003] 19

29 2 Software-Management und Software-Messung Web-Merkmale des Functional Size Measurement Das Internet bietet vielfältige Ansätze um Forschung, Entwicklung und Anwendung in unterschiedlichsten wirtschaftlichen und wissenschaftlichen Themengebieten zu unterstützen. Insofern ist es von Interesse welche Möglichkeiten sich für den Bereich der funktionalen Größenmessung erschließen. Hierbei ist festzustellen, dass keine integrierte webbasierte Lösung für die funktionale Größenmessung existiert. Vielmehr existieren monolithische Teillösungen für ein breites Einsatzspektrum im Functional Size Measurement [Lother 2002b]. Dazu zählen beispielsweise Tools zum Zählen von Function Points [Reitz 2001] oder Kalkulationstabellen zur Unterstützung bei der Aufwandsschätzung [SMLab 2004]. Abbildung 15: Palm-basiertes Werkzeug für das Zählen von Function Points Daraus folgt, dass es keine einheitliche Architektur oder Vorgehensweise für die webbasierte funktionale Größenmessung gibt, stattdessen differiert dies in den unterschiedlichen Teillösungen. Abbildung 16: Java-basiertes Tool zur Auswertung von Function Points Ähnlich stellt sich die Situation bei Standard-Dokumenten, Anleitungen oder anderen Fachveröffentlichungen dar. Diese Dokumente werden zwar durchweg von den entsprechenden Organisationen und Autoren online zur Verfügung gestellt, jedoch ist es dem geneigten Leser nicht möglich in diesen Dokumenten mit Hilfe einer einheitlichen Sicht beziehungsweise Darstellung zu recherchieren, vielmehr ist er gezwungen die weit verteilt vorliegenden Dokumente einer aufwendigen Literaturstudie zu unterziehen. 20

30 3 FSeMP - Portal zur funktionalen Größenmessung 3 FSeMP - Portal zur funktionalen Größenmessung Aus der intensiven Zusammenarbeit des Software Measurement Laboratory (SMLab) von Professor Dumke an der Otto-von-Guericke-Universität Magdeburg/Deutschland mit dem von Professor Abran geleiteten Software Engineering Management Research Laboratory (SEMRL) an der Université du Québec à Montréal in Montréal/Kanada entwickelte sich der wissenschaftlich motivierte Anreiz zur Schaffung einer integrierten Portallösung zur funktionalen Größenmessung. 3.1 Beschreibung der existierenden Portallösung Der jetzige Stand der Entwicklung geht im Wesentlichen auf die Arbeit des Diplom- Informatikers und Doktoranden Mathias Lother zurück, der das Projekt initiierte und die Arbeit an dem Projekt organisiert. Eine Machbarkeitsstudie und ein erstmaliger Entwurf wurde im Rahmen einer Diplomarbeit von Dennis Winkler realisiert [Winkler 2003], die Konzeption und die prototypische Realisierung wurde im Rahmen einer Diplomarbeit von René Braungarten durchgeführt [Braungarten 2004]. Das Functional Size emeasurement Portal bieten im Wesentlichen vier Kernfunktionalitäten [Braungarten 2004]: - Speicherung von Projektdaten in einer integrierten Datenbank - Vergleich mit anderen bereits in der Datenbank abgelegten Projekten - Visualisierung von Projektdaten mit Hilfe eines im Portal integrierten Project Visualizer - Aufwandsschätzung mit Hilfe des Estimation Tools Ausgangspunkt der im Portal realisierten Funktionalitäten ist die Eingabe und Verwaltung entsprechender Projektdaten (siehe Abbildung 17). Neben der Speicherung in einer internen Datenbank besteht die Möglichkeit, eine externe kommerzielle Datenbank zu nutzen, dies wird mit Hilfe einer Anbindung an die ISBSG Datenbank realisiert. Diese gebührenpflichtige Datenbank bietet die Möglichkeit, die eigenen Daten mit anderen Projekten zu vergleichen, um sie so gegenüber ausgewählten Industrieprojekten zu benchmarken [Braungarten 2004]. Um eine möglichst genaue Abbildung des Projektes zu erreichen, erfolgt nach der Eingabe der verwendeten Messmethode (IFPUG FFP, COSMIC FFP oder Mark II FPA) eine Charakterisierung anhand umfangreicher, von der ISBSG adaptierter Fragenkataloge. 21

31 3 FSeMP - Portal zur funktionalen Größenmessung Abbildung 17: Projektverwaltung und -eingabe Nach der vollständigen Erfassung aller anhand der Messmethode der funktionalen Größe zugeordneten Fragebögen, besteht die Möglichkeit, sich einen so genanten Benchmark Report generieren zu lassen. [Braungarten 2004] Abbildung 18: Automatisch erzeugter Projekt-Benchmark-Report 22

32 3 FSeMP - Portal zur funktionalen Größenmessung Dieser Bericht vergleicht das eingegebene Projekt mit in der ISBSG-Datenbank vorhandenen Daten entsprechender Vergleichsprojekte und deren Eckdaten. Eine weitere Möglichkeit zur Darstellung der Projektdaten bietet der Project Visualizer. Dieses Tool generiert, aus den eingegebenen eigenen Daten verschiedene Diagramme, welche einen unternehmensinternen Projektvergleich zulassen. Abbildung 19: Visualisierung von Projektdaten Eine weitere Funktionalität, welche das Portal dem Nutzer bietet, stellt das Estimation Tool dar. Damit ist es möglich, auf der Basis der umfassenden Projekt- und Produktivitätsdaten der ISBSG-Datenbank Release 8, eine Aufwandsschätzung mit Hilfe statistischer Methoden durchzuführen [Braungarten 2004]. 23

33 3 FSeMP - Portal zur funktionalen Größenmessung Abbildung 20: Aufwandsschätzung mit Hilfe des Estimation 2004-Tools Aus diesen Kernfunktionalitäten des Functional Size emasurement Portal ergeben sich verschiedene Anwendungsfälle, die in der folgenden Abbildung 21 zusammenfassend dargestellt sind. Abbildung 21: Kernfunktionalitäten des FSeMP 3.2 Ansätze zur Verbesserung Das Portal zur funktionalen Größenmessung bietet einen ersten, integrativen Ansatz zur Unterstützung einer Vielzahl von Formen des Projektmanagements durch Funktionalitäten sowohl zur operativen und strategischen Aufwandschätzung als auch 24

34 3 FSeMP - Portal zur funktionalen Größenmessung zum Benchmarking. Allerdings ist der einzelne Benutzer in seiner Arbeitsweise isoliert: Die Unterstützung in Hinblick auf eine kooperative Zusammenarbeit fällt nicht sehr ausgeprägt aus. Zur Überwindung dieser Unzulänglichkeiten (so genannte shortcomings") sind also im Wesentlichen folgende Ansatzpunkte zu verzeichnen: es sollte die Möglichkeit bestehen, sich grundlegend in das Thema der funktionalen Größenmessung einzuarbeiten es soll ein Erfahrungsaustausch mit anderen Nutzern ermöglicht werden es sollen Problemstellungen zur Diskussion gestellt werden können es sollte eine Plattform für Feedback geschaffen werden es sollte die Möglichkeiten der Kommunikation zwischen den Benutzern des Portals verbessert werden Darum ist es das Ziel der Diplomarbeit ein System zu entwerfen und prototypisch zu implementieren, welches dem Benutzer eine Hilfestellung zur Lösung spezieller Probleme im Bereich Functional Size emeasurement gibt und ihn durch die Einführung kollaborativer Elemente aus der Isolation bei der Arbeit mit dem Portal befreit. Eine weitere Zielstellung ist es, interessierten Einsteigern auf dem Gebiet der funktionalen Größenmessung Informationen und Kontaktmöglichkeiten zu bieten, um damit den potentiellen Nutzerkreis des Portals zu erweitern. 25

35 4 Überblick moderner elearning-technologien Ich erwarte eine Informations- und Wissensgesellschaft. Das ist die Vision einer Gesellschaft, die jedem die Chance einräumt, an der Wissensrevolution unserer Zeit teilzuhaben. Das heißt: bereit zum lebenslangen Lernen zu sein, den Willen zu haben, im weltweiten Wettbewerb um Wissen in der ersten Liga mitzuspielen. [Herzog 1997] 4 Überblick moderner elearning-technologien Dieses Zitat vom Altbundespräsidenten Roman Herzog macht deutlich, welchen Stellenwert die Wissensvermittlung und Wissensaneignung in der heutigen Gesellschaft haben sollte. In diesem Zusammenhang erschließt sich auch die Wichtigkeit des Themas elearning beziehungsweise rechnerunterstützter Lehr- und Lernsysteme im Allgemeinen, denn durch solche Systeme wird erst eine völlig neue Art der Wissensvermittlung ermöglicht. Vor allem auch im wirtschaftlichen Umfeld ermöglichen elearning-systeme neue Ansätze im Bereich der betrieblichen Weiterbildung, da durch immer kürzere Innovationszyklen die Halbwertszeit von Wissen stark sinkt und sich daraus die Notwendigkeit zum lebenslangen Lernen entwickelt. Im betrieblichen Umfeld kann mit steigendem Wettbewerbsdruck auch die Frage nach den Kosten von Aus- und Weiterbildung von zentraler Bedeutung sein. Ein Großteil der Kosten für die betriebliche Fortbildung beläuft sich auf Reise-, Unterbringungs- und Personalkosten für Seminarleiter. Durch den Einsatz von elearning können diese Kosten zu einem erheblichen Teil gesenkt werden. Des Weiteren verringern sich bei steigender Teilnehmerzahl die Produktionskosten pro Kopf für elearning-inhalte ( content ). Im Folgenden sollen deshalb grundlegende Begriffe des Themas elearning erläutert, unterschiedliche technische Architekturen zur Realisierung von Lehr- und Lernsystemen dargelegt und der Stand der Entwicklung an Hand von Beispielen existierender Systeme anschaulich beschrieben werden. 4.1 Begriffsbestimmung elearning ist eine besondere Variante des computergestützten Lernens. Merkmale dieser virtuellen Lernwelten sind, dass die genutzten Lernsysteme und Lernmaterialien: - in digitalisierter Form angeboten werden, - sich durch Multi- und/oder Hypermedialität (Informationsvernetzung) auszeichnen, 26

36 4 Überblick moderner elearning-technologien - Interaktivität zwischen dem Lernenden, dem System, dem Betreuer und den Mitlernenden - vor Ort oder im Netz unterstützen und - online für den Nutzer direkt verfügbar sind." [Anuba 2003] Lernformen Um die verschiedenen technologischen Anforderungen von Lernumgebungen zu bestimmen, sollen hier zunächst die verschiedenen Lernformen gegenübergestellt werden (siehe [Jarz 1997] und [Belanger 2000]). Behaviorismus Wissen ist objektiv Hirn ist ein passiver Behälter Wissen wird abgelagert Lernen durch kleine Schritte Trial & Error/ extern vorgegebenes Feedback kognitiver Behaviorismus Wissen ist objektiv Hirn ist ein passiver Behälter Wissen wird eingearbeitet Lernen durch kleine Schritte und Reflexion extern vorgegebenes Feedback traditioneller Kognitivismus Wissen ist objektiv Hirn ist ein Informationen verarbeitendes Gerät Wissen wird verarbeitet selbständiges, bewusstes Lernen durch Fragestellungen extern modelliertes Feedback Tabelle 4: Unterschiedliche Lernformen Konstruktivismus Wissen ist subjektiv Hirn ist ein Informationen verarbeitendes Gerät Wissen wird konstruiert selbständiges Lernen bei komplexen, unstrukturierten Problemen als aktiver Prozess intern modelliertes Feedback Diese differenzierten Lernformen erfordern unterschiedliche technologische Anforderungen: ist beim Behaviorismus noch eine umfangreiche Fakten- und Wissensbasis vorgegeben mit dem Ziel des Erlernens von Fakten, so erfolgt beim Konstruktivismus nur die Vorgabe von Regeln, Strategien und einer Problemstellung mit dem Ziel der Erwerbung von Wissensstrukturen Lehrformen Betrachtet man die Entwicklung des elearning und die vielfältigen Ausprägungen der elektronischen Aus- und Weiterbildung, so sind im Wesentlichen drei verschiedene 27