Glossar

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Agile Softwareentwicklung

Die Agile Softwareentwicklung stellt den Oberbegriff für den Einsatz der Agilität in der Softwareentwicklung dar und hat zum Ziel, die Qualität der Softwareentwicklung zu verbessern. Als Agilität bezeichnet man hierbei die Verwendung agiler

Aus diesen ergeben sich wiederum agile Prozesse, die einen an agilen Werten und Prinzipien ausgerichteter und auf agilen Methoden aufbauenden Arbeitsprozess beschreiben.

Ziel eines solchen agilen Prozesses ist es, den Softwareentwicklungsprozess durch Abbau der Bürokratisierung und durch stärkere Berücksichtigung der menschlichen Aspekte effektiver und für alle Beteiligten vorteilhafter zu gestalten.

Zu den bekanntesten Vertretern der agilen Prozesse zählt zweifelsohne Extreme Programming. Es gibt allerdings weitere Vertreter, wie z.B. Adaptive Software Development, Crystal oder Scrum.

Akzeptanztest

Ein Akzeptanztest prüft in einer Art Blackbox-Test die Nutzbarkeit des Produkttests durch den Endanwender. Es wird lediglich das äußere Verhalten der Software bei spezifizierten Handlungen getestet - der Code der Software wird dabei nicht berücksichtigt.

Anforderungsanalyse

Die Anforderungsanalyse beschreibt eine Aktivität innerhalb der Softwareentwicklung, bei der die Anforderungen, die der Auftraggeber an das zu entwickelnde Software-Produkt hat, zunächst ermittelt und dann in formalisierter Form schriftlich festgehalten werden. Hierbei wird die Anforderungsanalyse zumeist im Dialog zwischen dem Kunden bzw. dem Endanwender und dem Entwickler des Software-Produktes durchgeführt.

Die festgehaltenen Anforderungen sollten folgende Eigenschaften besitzen:

Als Ergebnis der Anforderungsanalyse ist das Pflichtenheft zu sehen, welches alle Anforderungen zusammenfasst und somit das zu entwerfende Software-Produkt im Ganzen beschreibt.

Code Review

Ein Code-Review ist ein Peer-Review auf Code-Ebene. Einer oder mehrere fachlich versierte Programmierer betrachten zusammen mit dem Entwickler des Codes selbigen im Detail. Die Ziele des Code-Review sind vielschichtig. Durch Code Review werden optimalerweise nicht nur Fehler gefunden und Testfälle erweitert. Dadurch, dass sichergestellt ist, dass mehrere Programmierer den Code verstanden haben, wird auch der Grad an Klarheit, Robustheit und Wartbarkeit deutlich erhöht. Ein weiterer Vorteil von Code Reviews ist die Tatsache, dass sich allgemein anerkannte "Best Practices" herausbilden, der Stil der Programmierung im Unternehmen sich vereinheitlicht und Wissen optimal zwischen mehr und weniger erfahrenen Programmierern ausgetauscht wird.

Continuous Integration

Ein Begriff aus dem Extreme Programming, welcher besagt, dass fertig gestellte Aufgaben (d.h. die Quelltextänderungen inklusive der zugehörigen Tests) sofort dem Gesamtsystem hinzugefügt werden. Diese stehen somit allen Teammitgliedern zur Verfügung und gehen mit in die regelmäßig ablaufenden Tests ein. Die Häufigkeit der Integration hängt dabei sehr von den Verhältnissen im Projekt ab, die Integration sollte aber auf jeden Fall erst erfolgen, wenn die jeweilige Aufgabe vollständig abgeschlossen ist.

Design Patterns

Ein Design Pattern (Entwurfsmuster) beschreibt eine in der Praxis bewährte Lösung für ein immer wiederkehrendes Problem. Es stellt eine Art Vorlage dar, mit der das aufgetretene Problem gelöst werden kann.

Function-Point-Methode

Die Function-Point-Methode ist ein Verfahren zu Aufwandsschätzung bei Softwareprojekten. Grundlage dieser Methode ist die Bestimmung von in die Bewertung einfließenden Faktoren. Diese Faktoren werden mathematisch verknüpft, so dass der Gesamtaufwand aus ihnen berechnet werden kann.

Geschäftsprozesse

Ein Geschäftsprozess ist eine Menge von zusammen gehörenden Aktivitäten, die gemeinsam einen Wert (eine Leistung/ein Produkt) für einen Kunden erzeugen und dessen Ergebnis eine strategische Bedeutung für das den Prozess durchführende Unternehmen hat. Die Gesamtheit der Geschäftsprozesse eines Unternehmens lässt sich mit den Abhängigkeiten zwischen den Geschäftsprozessen in einer so genannten Prozesslandkarte darstellen. Sie weisen hierarchische Strukturen auf, ein Geschäftsprozess kann also z.B. in Teilprozesse unterteilt werden.

Integrationstests

Der Begriff Integrationstest bezeichnet in der Softwareentwicklung eine aufeinander abgestimmte Reihe von Einzeltests. Gemeinsam dienen sie dazu, die verschiedenen voneinander abhängigen Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen. Dem Integrationstest gehen für jede Einzelkomponente Unit-Tests voran.

Zur Durchführung der Integrationstests wird für jede Anhängigkeit zwischen zwei Komponenten eines Systems ein Testszenario definiert, welches in der Lage ist nachzuweisen, dass nach der Zusammenführung sowohl beide Komponenten für sich wie auch der Datenaustausch über die gemeinsame(n) Schnittstelle (n) spezifikationsgemäß funktionieren.

Der Umfang von Integrationstests ist nicht auf ein Gesamtsystem festgelegt. Da der zeitliche Aufwand für Integrationstests mit wachsender Komponentenanzahl überproportional ansteigt, ist es üblich, Integrationstests für einzelne, abgegrenzte Subsysteme durchzuführen und diese dann im weiteren Verlauf als eine Komponente zu betrachten ( Bottom-Up-Methode ). Bei dieser Methode enden die Integrationstests erst mit den erfolgreichen Testläufen in einer mit dem späteren Produktivsystem identischen Testumgebung.

In kleineren Softwareprojekten finden Integrationstests häufig während der Codierung durch den oder die Programmierer statt. Unmittelbar im Anschluss an die Programmierung eines Moduls wird das Modul selbst und das Zusammenspiel mit dem bisher erstellten Programmcode getestet. In großen, umfangreichen Software-Projekten, die meist im Rahmen eines Projekts durchgeführt werden, erhöht sich der Aufwand für Tests generell so stark, dass diese zur Steigerung der Effizienz automatisiert durchgeführt werden.

Iterative Entwicklung

Ein Begriff aus dem Extreme Programming. Er besagt, dass man den Entwicklungsprozess in mehrere (kleine) Iterationen aufteilen soll, um so den Entwicklungsprozess agiler zu gestalten.

Am Anfang jeder Iteration findet eine sogenannte Iterationsplanung statt, in der festgelegt wird, welche vom Kunden definierten User Stories als nächstes mit den zur Verfügung stehenden Kapazitäten implementiert werden sollen. Am Ende der jeweiligen Iteration wird das Ergebnis mehreren Tests unterzogen und dem Auftraggeber zur Verfügung gestellt.

Lastenheft

Das Lastenheft (grobes Pflichtenheft) beschreibt die Anforderungen und Wünsche an das zu entwickelnde Produkt in natürlicher Sprache. Hierbei konzentriert es sich auf die wesentlichen Eigenschaften des Produktes, beschreibt also das "was" und nicht das "wie".

Ein Lastenheft sollte folgendem Gliederungsschema folgen:

Da die oben aufgezeigte Gliederung nur eine Empfehlung ist, können sich Lastenhefte je nach Einsatzgebiet und Branche in Aufbau und Inhalt stark unterscheiden. Meist wird auf Basis des Lastenheftes im weiteren Projektverlauf ein Pflichtenheft erstellt.

Lasttests

Unter einem Lasttest oder Performancetest versteht man einen (nicht funktionalen) Softwaretest, mit dem eine gewisse Last auf dem laufenden System erzeugt und das Verhalten desselben beobachtet und untersucht wird. Er stellt somit eine Form der Simulation dar. Ziel dabei ist es, (1) Fehler aufzudecken, die im funktional orientierten Systemtest/Integrationstest nicht gefunden wurden, und (2) nichtfunktionale Anforderungen, wie z.B. geforderte Antwortzeiten sowie Mengenverarbeitungen, für den Wirkbetrieb nachzuweisen. Der Lasttest ist demnach dem funktionalen Test nachgelagert, d.h. das (Teil-)System muss in einem funktional stabilen Zustand sein, um überhaupt auf Performanz testen zu können.

Model Driven Architecture

Die Model Driven Architecture definiert einen Ansatz zur Entwicklung von Softwaresystemen und besagt, dass eine vollständige Spezifikation eines Softwaresystems immer aus einem Plattform-unabhängigen (in UML definierten) Modell und mindestens einem Plattform-abhängigen Modell besteht.

Objektorientierte Analyse

Ziel der objektorientierten Analyse ist es, die Anforderungen an ein Software-Produkt mit Hilfe von objektorientierten Konzepten problemnah zu modellieren. Das so entstehende Modell lässt sich grob in drei Teilmodelle gliedern.

Da das Modell das zu entwickelnde Produkt aus Anwendersicht beschreibt, bedeutet dies:

Die objektorientierte Analyse stellt einen Teil der objektorientierten Modellierung dar, welche sich in den Teil der Domänenmodellierung (Analyse) und den Teil des Systementwurfs (Design) aufgliedert.

Objektorientiertes Design

Das Design berücksichtigt - anders als die Analyse - neben den fachlichen Aspekten des Auftraggebers auch technische Gegebenheiten. Ziel ist es also, das während der objektorientierten Analyse erstellte Modell weiter zu entwickeln und darauf aufbauend zunächst den objektorientierten Systementwurf und aus diesem wiederum den Implementierungsentwurf zu erstellen. Im Systementwurf - auch Architekturentwurf genannt - wird die Architektur der Software festgelegt und umfasst die:

Je nach Art der zu entwickelnden Anwendung können weitere Komponenten hinzukommen.

Ziel des Implementierungsentwurfs ist es, den Systementwurf weiter zu verfeinern und so an die Zielprogrammiersprache anzupassen, dass die verwendete Programmiersprache Einfluss auf den Entwurf haben kann (Stichwort Mehrfachvererbung).

Pair Programming

Eine Praktik aus dem Extreme Programming, bei der Programmierer stets zu zweit am Code arbeiten und während der Entwicklung intensiv über Entwurfsalternativen diskutieren. Konkret bedeutet dies: Ein Programmierer schreibt den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie Probleme, die ihm dabei auffallen, sofort anspricht. Diese können dann sofort gelöst werden. Die beiden Programmierer sollten sich bezüglich dieser beiden Rollen abwechseln. Auch die Zusammensetzung der Paare sollte sich häufig ändern. Das Ergebnis dieser Vorgehensweise ist eine höhere Codequalität, größere Produktivität und bessere Wissensverbreitung.

Peer Review

Unternehmen setzen Peer Reviews zur Qualitätssicherung ein. So führen Unternehmen, die im Bereich Wirtschaftsprüfung oder Beratung tätig sind, so genannte Peer Reviews durch. Dabei wird ein Projekt (Wirtschaftsprüfung oder Beratungsprojekt) eines Unternehmens durch einen Experten oder ein Expertenteam eines anderen Unternehmens der gleichen Branche anhand von Projektunterlagen und Arbeitspapieren überprüft.

In der Softwareentwicklung beizeichnet man Aktivitäten als Peer Review, in denen ein Ersteller eines Dokumentes (Lastenheft, Code, Diagramm, ...) ein solches einem fachlich ähnlich versierten Experten vorstellt und dieses während des Peer Reviews möglicherweise angepasst und optimiert wird.

Pflichtenheft

Das Pflichtenheft (Fachfeinkonzept, fachliche Spezifikation) enthält eine Zusammenfassung aller fachlichen Anforderungen, die das zu entwickelnde Produkt aus Sicht des Auftraggebers erfüllen muss und wird meist als Vertragsgegenstand behandelt. Im Gegensatz zum Lastenheft sind die Inhalte präzise, vollständig und nachvollziehbar formuliert, so dass es nicht zu Missverständnissen zwischen den Vertragsparteien kommen kann.

Ein Pflichtenheft sollte folgendem Gliederungsschema folgen:

Refactoring

Refactoring ist ein Begriff aus der Informatik, spezieller der Softwareentwicklung. Refactoring ist ein wichtiger Bestandteil des Extreme Programming.

Beim Refactoring wird der Quelltext eines Computerprogramms umgestaltet, wobei die tatsächliche Programmfunktion unverändert bleiben soll.

Refactoring dient der Verbesserung der Wartbarkeit des Designs in der Art, dass es für den Programmierer leichter wird, den bestehenden Code funktional zu erweitern oder an anderer Stelle wiederzuverwenden. Dies versucht man zu erreichen, indem man den Code bezüglich folgender Kriterien verbessert:

Refactoring wird nur auf funktionierendem Code ausgeführt (dessen Funktionalität soll ja erhalten bleiben). Dies beinhaltet aber auch das Risiko unerwünschter Änderungen und Fehler. Um dieses Risiko zu vermeiden (oder wenigstens zu minimieren), verwendet man verschiedene Regeln, die den Prozess des Refaktorisierens ungefährlicher machen.

Softwaretechnik

Die Softwaretechnik gilt als Teilgebiet der Informatik und befasst sich mit dem ingenieurmäßigen Entwerfen, Herstellen und Implementieren von Software und den damit verbundenen Prozessen. Da die Entwicklung von Softwaresystemen ein weitreichender und komplexer Vorgang ist, unterteilt sich die Softwaretechnik in mehrere Teildisziplinen aus den Bereichen der Informatik und des Projektmanagements, welche jedoch während des gesamten Entwicklungsprozesses eng miteinander verzahnt sind. Zu diesen Disziplinen gehören die Software-Entwicklung, das Software-Management und die Software-Qualitätssicherung.

Systemtests

Der Systemtest kann definiert werden als:

Er wird in den funktionalen und den nicht funktionalen Systemtest eingeteilt. Zumeist wird er von der entwickelnden Organisation, d.h. nicht vom Anwender selbst, durchgeführt.

Der funktionale Systemtest dient zur Überprüfung eines Systems bezüglich dessen funktionaler Qualitätsmerkmale Korrektheit und Vollständigkeit.

Nicht funktionale Qualitätsmerkmale, wie z.B. die Sicherheit, die Benutzbarkeit, die Interoperabilität, die Prüfung der Dokumentation oder die Zuverlässigkeit eines Systems, werden über den nicht funktionalen Systemtest einer Prüfung unterzogen.

Test Driven Development

Ein Begriff aus dem Extreme Programming welcher besagt, dass die Tests für die zu entwickelnde Komponente vor der eigentlichen Komponente implementiert werden.

Beim "klassischen" Testen werden die Tests zumeist parallel zu oder nach der Implementierung unabhängig zum testenden System entwickelt. Diese Vorgehensweise kann jedoch dazu führen, dass die gewünschte Abdeckung mittels Tests nicht erreicht wird. Gründe hierfür sind:

Ein weiterer sehr wichtiger Nachteil beim "klassischen" Testen ist, dass der Entwickler, der die Tests entwickelt, das zu testende System zu gut kennt und somit ungewollt "um die Fehler herum" testet.

Test Driven Development (auch Test First Development oder Extreme Testing genannt) beschreibt einen Ansatz, den Nachteilen des "klassischen" Testens entgegen zu wirken.

UML

Die UML (Unified Modelling Language) ist eine von der OMG entwickelte und standardisierte Beschreibungssprache, die eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung definiert.

Die UML unterstützt 13 Diagrammtypen, die in Verhaltens- und Strukturdiagramme unterteilt werden. Zu den Verhaltensdiagrammen gehören:

Zu den Strukturdiagrammen gehören:

Unit-Tests

Unit-Tests sind Teil des Vorgehensmodelles Extreme Programming. Sie werden auch als Komponententests bezeichnet. Unit-Tests dienen der Validierung der Korrektheit von Modulen einer Software, z.B. von einzelnen Klassen. Als Voraussetzung für Refactoring kommt ihnen besondere Bedeutung zu. Nach jeder Änderung wird durch Prüfen aller zuvor definierten Testfälle die Fehlerfreiheit sichergestellt. Beim testgetriebenen Programmieren werden die Unit-Tests parallel zum eigentlichen Sourcecode erstellt und gepflegt. Durch automatisierte, reproduzierbare Unit-Tests sind so die Auswirkungen von Änderungen sofort nachzuvollziehen. Der Programmierer entdeckt dadurch leichter änderungsbedingte Nebeneffekte oder Fehler.

User Stories

User Stories werden im Extreme Programming verwendet, um die Anforderungen an die zu entwickelnde Software zu beschreiben. Eine User Story beschreibt ein Stück Funktionalität innerhalb der Software und wird vom Kunden in textueller Form verfasst.

Jede User Story wird zur Abschätzung zunächst in kleine Aufgaben unterteilt. Anschließend wird für jede Aufgabe ermittelt, wieviel Zeit sie in Anspruch nimmt. Aus der Summe der ermittelten Werte ergibt sich so, wie lange es dauert und somit was es kostet, die jeweilige User Story zu implementieren.

Versionsverwaltung

Unter der Versionsverwaltung versteht man ein System, welches in der Regel in zweierlei Hinsicht eingesetzt wird.

Zum einen ermöglicht es die Versionierung bestimmter Ressourcen (wie z.B. Quellcode-Dateien, Dokumente, Bilder). Hierzu werden alle laufenden Änderungen einer Ressource erfasst und protokolliert, so dass jederzeit auf jede protokollierte Version der Ressource zugegriffen werden kann.

Zum anderen bietet es die Möglichkeit, den gemeinsamen Zugriff auf die genutzten Ressourcen zu kontrollieren. Hierbei wird sichergestellt, dass jeder Benutzer mit dem aktuellen Stand arbeitet oder auf Wunsch auf den versionierten Stand zugreifen kann.

Zusammengefasst noch einmal die Hauptaufgaben eines Versionsverwaltungssystems: