3 Zweck
5 Modell der Software-Entwicklung
6 Gliederung und Inhalt der Dokumente
7 Glossar
KM |
|
PM |
|
QS |
|
SE |
|
IT |
Informationstechnik |
Dieses Dokument soll die Studierenden in die Lage versetzen, die geforderte Dokumentation im Praktikum Software-Technik in der gewünschten Form zu erstellen und die Software-Entwicklung vorgabengemäß durchzuführen.
Ein allgemein anwendbares Modell zur Software-Entwicklung wird vorgestellt. Die Phasen, in die die Bearbeitung zerlegt wird, sowie die Rollen, die von den Bearbeitern eingenommen werden und die zu erstellenden Zwischenergebnisse, die sogenannten Produkte, werden beschrieben.
Dieses Modell wird auf die Software-Entwicklung übertragen und die dabei auftretenden speziellen Phasen, Rollen und Produkte werden beschrieben. Zu den zu erstellenden Dokumenten werden Mustergliederungen vorgegeben.
Im Folgenden wird ein Modell der Software-Entwicklung dargestellt. Es umfasst Rollen, die unterschiedliche Verantwortungsbereiche widerspiegeln, Phasen in die sich der gesamte Prozess unterteilen lässt und Produkte, die während des Entwicklungsprozesses entstehen und im Praktikum abzugeben sind.
Das V-Modell verdankt seinen Namen der grafischen Darstellung in V-Form. Seine Produktiv-Phasen entsprechen denen des Wasserfallmodells. Sie sind im absteigendem Zweig des Vs dargestellt. Ergänzend befinden sich im aufsteigendem Zweig die dazugehörigen Testphasen.
Der Begriff Software steht in diesem Umfeld für ein Programm und alle zugehörigen Dokumente um das Programm herum.
Im Vorgehensmodell /KBSt92/ /VMod97/ des Bundes werden vier Verantwortungsbereiche für verschiedenen Aktivitäten in IT-Vorhaben definiert. Es sind:
Die System-Erstellung umfasst die Erstellung aller Dokumente auf dem Weg zum auslieferungsfähigen Endprodukt einschließlich des Programms. Daher werden die System-Ersteller auch Autoren genannt, insbesondere wenn die Zwischenprodukte Dokumente sind und keine Programme.
Das Projektmanagement plant und überwacht Umfang und Termin des Einsatzes von Personal, Maschinen, Räumen und sonstigen Hilfs- und Betriebsmitteln. Gegenüber dem Management werden regelmäßig Statusberichte zum Projekt gegeben. Sie enthalten insbesondere einen Soll-Ist-Vergleich der Aufwände und Termine. Der Repräsentant des Projektmanagement ist der Projektleiter.
Die Qualitätssicherung überprüft die erstellten Produkte und Zwischenprodukte der Software-Erstellung gemäß den Vorgaben des angewendeten Prozesses. Die Erstellung von Testprogrammen gehört dazu.
Das Konfigurationsmanagement ist dafür verantwortlich, alle Zwischenprodukte und sonstige Dokumente zu speichern. Dabei werden auch unterschiedliche Versionen vorgehalten und der jeweilige Status jedes Dokumentes notiert. Typische Dokumentationszustände sind: geplant, in Bearbeitung, vorgelegt, akzeptiert.
In großen Projekten werden die Aufgaben von mehreren Personen wahrgenommen. Beispielsweise beim Projektmanagement kann aber letztendlich nur einer verantwortlich sein, nämlich der Projektleiter. Im Praktikumsumfeld sind die Aufgaben nicht so groß, dass hier mehrere Personen beteiligt sind. PM, QS und KM sollen deshalb neben den Verantwortungsbereichen gleichzeitig die entsprechende verantwortliche Person bezeichnen. SE steht in dem Sinne auch für System-ErstellerIn oder auch mehrere SystemerstellerInnen.
Teile der folgenden Ausführung sind nicht für sich allein verständlich, sondern setzen die Kenntnis der entsprechenden Kapitel der Vorlesung Software-Technik voraus.
Vor einer Software-Entwicklung werden grundsätzliche Überlegungen darüber angestellt, ob und wie die Anforderungen des Kunden zu erfüllen sind. Die geschieht in der Machbarkeitsanalyse. Es folgt die Analyse, in der festgelegt wird, was das zu erstellende System alles umfassen soll. Im Entwurf wird festgelegt, wie das System aufgebaut ist und wie es die Anforderungen des Auftraggebers erfüllen soll. Darauf folgen noch die Implementierung und der Test.
In allen Phasen werden in Übereinstimmung mit den Zielen des Praktikums die benötigten Bearbeitungszeiten und gefundene Fehler protokolliert. Beobachtungen über das Zusammenwirken mit Kollegen und dem Umfeld werden notiert. Für Phasen, in denen wichtige Produkte entstehen, planen die Projektgruppen gesonderte Überprüfungsphasen ein.
Zu jeder Phase, in der produktiv am System gearbeitet wird, kann eine Qualitätssicherungs-Phase vorgesehen werden. In manchen Beschreibungen taucht diese zugehörige Phase gar nicht mehr auf, da sie grundsätzlich in jede Produktiv-Phase integriert ist. Eine ausdrückliche 1:1-Zuordnung von Produktiv- zu Qualitätssicherungs-Phase wird wegen der besseren Sichtbarkeit der QS im Praktikum empfohlen.
Die Phasen werden im Folgekapitel dargestellt. Die Beschreibung beschränkt sich in den ersten Abschnitten auf die allgemeine Zielsetzung einer Phase. Stehen einem Bearbeiter noch keine speziellen Methodenkenntnisse zur Verfügung, sollte diese Anleitung als grobe Vorgabe für die Strukturierung einer Software-Entwicklung ausreichen. Es folgt dann in den meisten Fällen eine Beschreibung, die sich an der Vorlesung orientiert. In späteren Kapiteln folgen dann noch für jede Phase die Vorbedingungen und Nachbedingungen, die Ablaufbeschreibung und die Gliederungen der zu erzeugenden Produkte.
Für große Software-Projekte werden die Phasen nicht genau einmal durchlaufen, sondern es können Teilsysteme definiert werden, die nach einer gemeinsamen Analyse die restlichen Phasen unabhängig voneinander durchlaufen und zum Schluss zusammengefügt werden.
Die evolutionäre Software-Entwicklung beginnt mit den Teilen, die dem Kunden mit dem geringsten Aufwand den größten Nutzen bringen. Dafür wird ein Kern-System entwickelt. Im Einsatz kann der Kunde seine Anforderungen an das Gesamtsystem problemlos aktualisieren und die weiteren Funktionalitäten werden in Zyklen, die jeweils die unten angegebenen Phasen enthalten realisiert.
Zunächst muss der Auftragnehmer die gestellte Aufgabe grob analysieren, um sicher zu gehen, dass er die Anforderungen vollständig und richtig verstanden hat. Dazu sind Rückfragen zur Beseitigung von Unklarheiten oder die Beschaffung von Hintergrundinformation erforderlich. Es ist zu klären, welche kritischen Qualitätsmerkmale zum Scheitern des Projektes bzw. zur Weigerung des Kunden, das Endergebnis bzw. Produkt zu akzeptieren, führen können. Zu all diesen Punkten sind grundsätzliche Lösungsideen zu skizzieren und zu bewerten sowie das Risiko abzuschätzen, ein Qualitätsmerkmal nicht zu erfüllen. Auf dieser Basis wird die Entscheidung getroffen, ob das Projekt überhaupt machbar ist.
Das Produkt der Machbarkeitsanalyse ist die Machbarkeitsstudie.
Im Gegensatz zur später folgenden Analyse konzentriert sich die Machbarkeitsanalyse auf die Qualitätsmerkmale. Die Funktionalität des zu erstellenden Systems wird nur sehr grob beschrieben. Bezogen auf die Funktionalität kann die Machbarkeitsstudie als Grobanalyse und die spätere Analyse als Feinanalyse betrachtet werden.
Alle funktionalen Anforderungen, Qualitätsmerkmale und Randbedingungen sind anzugeben. Sie erhalten Namen, deren erster Buchstabe auf den Typ der Anforderung hinweist. Qualitätsmerkmale werden mittels PLANGUAGE spezifiziert /Gilb88/, d.h. es werden folgende Rubriken spezifiziert:
Name |
Name des Qualitätsmerkmals |
Erklärung |
kurze Erklärung des Qualitätsmerkmals |
Maßeinheit |
Maßeinheit, in der das Qualitätsmerkmals gemessen wird |
Test |
stichwortartige Beschreibung des Tests der Einhaltung des Qualitätsmerkmals |
Ist |
heutiger Wert des Qualitätsmerkmals |
Soll |
geplanter Wert des Qualitätsmerkmals |
Schlechtestens |
schlechtester akzeptierter Wert des Qualitätsmerkmals
|
Traumwert |
Wert des Qualitätsmerkmals in den kühnsten Träumen |
Quellenhinweise |
woher die angegebenen Zahlen stammen |
Zu jedem Qualitätsmerkmal wird mindestens eine Lösung angegeben. Jede Lösung erhält einen Namen und wird kurz beschrieben.
Die Lösungen werden hinsichtlich der Wechselwirkung auf die anderen Qualitätsmerkmale bewertet. Dazu werden die Qualitätsmerkmale den Lösungen in einer Matrix gegenüber gestellt. Im Kreuzungspunkt wird der Einfluss der Lösung auf die Erfüllung des Qualitätsmerkmals notiert. Eine Notation verwendet die Symbole --, -, o, +, ++, eine andere Prozentzahlen in 5er-Schritten zwischen -100 und +100.
Für jedes Qualitätsmerkmal wird notiert welches Risiko der Erfüllung im Wege stehen könnte und was ggf. dagegen unternommen werden kann.
In einem geeigneten Verfahren ist das Produkt der Phase zu überprüfen. Eine Formale Inspektion wird empfohlen.
| Produkte | Verantwortliche |
Eingangsprodukt | Aufgabenbeschreibung | AuftraggeberIn |
durchzuführende Tätigkeiten |
| Softwareentwicklung (SE) |
Ausgangsprodukt | Machbarkeitsstudie | Projektmanagement (PM) |
Nachbedingungen | Qualitätssicherung der Machbarkeitsstudie mit geeignetem Verfahren. Formale Inspektion empfohlen. Machbarkeitsstudie im Konfigurationsmanagment abgeben. | Qualitätssicherung (QS) Konfigurationsmanagment (KM) |
In der Analyse geht es darum, mit dem Kunden genau abzustimmen welche Aufgaben das System erledigen soll, welche Daten in welchen Formaten und Zusammenhängen auftreten und welche Funktionalitäten erwartet werden. Gegenüber dem späteren Entwurf wird hier die Frage nach dem Was gestellt und die Beantwortung der Frage nach dem Wie bewusst dem Entwurf überlassen. Informationen über Datenvolumina oder zu erwartende Aufrufhäufigkeiten sind für den späteren Entwurf ebenfalls von Bedeutung. Häufig neigen Ingenieure dazu Lösungen zu präsentieren, bevor die Aufgabenstellung wirklich klar ist. Vorsicht!
Die Analyse beschreibt also das bestehende Umfeld bzw. das geplante System bezüglich der
unter Berücksichtigung
Zur Befragung des Kunden werden Interviews durchgeführt und unterschiedliche Befragungstechniken angewendet. Ein wichtiger Aspekt dabei ist immer die Rückkopplung, in der überprüft wird, ob das was der Auftragnehmer verstanden hat und in seiner Darstellung dem Kunden präsentiert, noch dem entspricht was der Kunde gemeint hat. Prototypen, dienen ebenfalls der Klärung der Anforderungen.
Je nach der gewählten Analysemethode stehen verschiedene Aspekte im Vordergrund und unterschiedliche Diagrammarten werden verwendet:
Das Analysemodell der objektorientierten Analyse enthält die folgenden Diagramme und kommentiert sie.
Die Anwendungsfälle werden gruppiert und zu Paketen zusammengefasst. Verschiedene Pakete können durch verschiedene Personen bzw. Gruppen realisiert werden.
Für die häufig gewünschte grafische Oberfläche wird ein Prototyp erstellt, an Hand dessen der Kunde seine Anforderungen präzisieren kann.
In einem Data Dictionary werden die Beschreibungen der Klassen zusammengestellt.
In einem geeigneten Verfahren ist das Produkt der Phase zu überprüfen.
| Produkte | Verantwortliche |
Vorbedingungen | Machbarkeitsstudie vom Konfigurationsmanagement akzeptiert. | Konfigurationsmanagement (KM) |
Eingangsprodukt | Machbarkeitsstudie | Projektmanagement (PM) |
durchzuführende Tätigkeiten | Objektorientierte Analyse
| Softwareentwicklung (SE) |
Ausgangsprodukt | Analysemodell | Projektmanagement (PM) |
Nachbedingungen | Qualitätssicherung des Analysemodells mit geeignetem Verfahren. Analysemodell im Konfigurationsmanagement abgeben. | Qualitätssicherung (QS) Konfigurationsmanagement (KM) |
Die Planung steht hier hinter der Analyse, da die Aufwandsabschätzung ein Mindestmaß an Kenntnis über das zu erstellende System erfordert. Bei viel Erfahrung und in Abstimmung mit dem Detaillierungsgrad der Funktionsbeschreibung der Machbarkeitsstudie kann die Aufwandsschätzung bereits nach der Machbarkeitsanalyse erfolgen. Wir wollen auf Nummer sicher gehen und keine Versprechungen machen, ohne eine Basis zu haben, der wir selber trauen.
In der Planung wird die Bearbeitung der gesamten Aufgabe in die vorgesehenen Phasen zerlegt. Die Zerlegung folgt dem hier vorgegebenen Muster. Es ist festzulegen welche Qualitätssicherungsphasen vorgesehen sind. Für jede Phase werden die zu erstellenden Produkte sowie die Verantwortlichkeiten festgelegt und der Aufwand geschätzt. Für die gesamte Entwicklung wird ein Terminplan erstellt.
Die Planung kann vor Beendigung der Analyse anlaufen, sobald in der Analyse genügend detaillierte Informationen für eine seriöse Planung vorliegen.
Für die oben aufgezählten Aufgaben werden unterstützende Formblätter zur Verfügung gestellt.
In einem geeigneten Verfahren ist das Produkt der Phase zu überprüfen.
| Produkte | Verantwortliche |
Vorbedingungen | Analysemodell vom Konfigurationsmanagement akzeptiert. | Konfigurationsmanagement (KM) |
Eingangsprodukt | Machbarkeitsstudie, Analysemodell | Projektmanagement (PM) |
durchzuführende Tätigkeiten |
| Projektmanagement (PM) |
Ausgangsprodukt | Projektplan | Projetmanagement (PM) |
Nachbedingungen | Qualitätssicherung des Projektplans mit geeignetem Verfahren. Projektplan im Konfigurationsmanagment abgeben. | Qualitätssicherung (QS) Konfigurationsmanagment (KM) |
Im Entwurf geht es nun darum, ein System zu konstruieren, das all die geforderten Funktionalitäten und Qualitätsmerkmale aus der Machbarkeitsstudie und der Analyse erfüllt. Hier kann und soll der Entwerfer seine Kreativität und sein handwerkliches Geschick anwenden um festzulegen, wie das System die Anforderungen erfüllen soll. Endlich kann gestaltet werden.
Zunächst sind einige grundsätzliche Fragen zu beantworten, die die Systemarchitektur grundsätzlich beeinflussen.
Daraus resultiert eine Strukturierung des Systems in Schichten und Partitionen.
Der objektorientierte Entwurf unterteilt sich in den Systementwurf und den Objektentwurf. Beim Systementwurf sind die im Überblick aufgelisteten grundlegenden Entscheidungen zu treffen.
Beim Objektentwurf werden unter Berücksichtigung der Laufzeit- und Speichereffizienz
In einem geeigneten Verfahren ist das Produkt der Phase zu überprüfen. Eine Formale Inspektion wird empfohlen.
| Produkte | Verantwortliche |
Vorbedingungen | Analysemodell vom Konfigurationsmanagement akzeptiert. | Konfigurationsmanagement (KM) |
Eingangsprodukt | Analysemodell | Projektmanagement (PM) |
durchzuführende Tätigkeiten |
| Softwareentwicklung (SE) |
Ausgangsprodukt | Entwurfsdokumentation | Projetmanagement (PM) |
Nachbedingungen | Qualitätssicherung der Entwurfsdokumentation mit geeignetem Verfahren. Formale Inspektion wird empfohlen. Entwurfsdokumentation im Konfigurationsmanagment abgeben. | Qualitätssicherung (QS) Konfigurationsmanagment (KM) |
Der Entwurf des Systems wird in der vorgesehenen Programmiersprache implementiert. Programmierrichtlinien sind dabei zu beachten.
In einem geeigneten Verfahren ist das Produkt der Phase zu überprüfen.
| Produkte | Verantwortliche |
Vorbedingungen | Entwurfsdokumentation vom Konfigurationsmanagement akzeptiert. | Konfigurationsmanagement (KM) |
Eingangsprodukt | Entwurfsdokumentation | Projektmanager (PM) |
durchzuführende Tätigkeiten |
| Softwareentwicklung (SE) |
Ausgangsprodukt | Programm | Projetmanager (PM) |
Nachbedingungen | Qualitätssicherung des Programms mit geeignetem Verfahren. Programm im Konfigurationsmanagment abgeben. | Qualitätssicherung (QS) Konfigurationsmanagment (KM) |
Der Test setzt lauffähige Programmmodule voraus. Ein Modul kann also erst nach seiner Implementierung getestet werden. Es muss jedoch nicht die komplette Umgebung eines Moduls existieren, bevor es getestet wird. Diese Umgebung kann durch Testprogramme ersetzt werden. Es ist möglich, bezogen auf den zu testenden Modul aufrufende als auch aufgerufene Module durch Ersatzmodule zu simulieren.
Erhält der Tester ein Programm zum Test, erhebt sich die Frage, was nun alles zu testen ist. Je nach dem, ob der Tester das Programm einsehen kann oder nur seine Schnittstelle kennt, unterscheidet man Black-Box-Tests und Glas-Box-Tests.
In jeder Produktiv-Phase von der Analyse bis zum detaillierten Entwurf gibt es andere Schwerpunkte der Entwicklung. Es ist nun nahe liegend, bereits im Entwicklungsprozess Testfälle zu bestimmen und zu dokumentieren, die dann später durchgeführt werden können.
Durchgeführte Tests müssen nachvollziehbar und nachweisbar sein. Deshalb sind sie zu dokumentieren.
In den Produktiv-Phasen können bereits Testfälle identifiziert werden, die besonders kritische Fälle darstellen oder sicherstellen sollen, dass die Funktionalität vollständig und korrekt erbracht wird. Jeder geplante Testfall ist mit folgenden Informationen zu dokumentieren
Wichtig ist, die erwartete Testausgabe wirklich vor der Testdurchführung zu dokumentieren, da sonst die Gefahr besteht, dass man zu unkritisch mit den gelieferten Testergebnissen ist.
Die Dokumentation der Eingabedaten kann sich auch in Dateien befinden, die unmittelbar zum Lauf des Tests verwenden werden. Die Nachvollziehbarkeit muss gewährleistet sein.
Die Tests werden wie geplant durchgeführt. Die tatsächlichen Ausgaben und/oder Reaktionen werden dokumentiert und mit den erwarteten Ausgaben verglichen.
| Produkte | Verantwortliche |
Vorbedingungen | Programmmodule vom Konfigurationsmanagement akzeptiert. | Konfigurationsmanagement (KM) |
Eingangsprodukt | Programmmodule | Projektmanager (PM) |
durchzuführende Tätigkeiten |
| Softwareentwickler (SE) |
Nachbedingungen | Testdokumentation im Konfigurationsmanagment abgeben. | Konfigurationsmanagment (KM) |
Ausgangsprodukt | Testdokumentation | Projetmanager (PM) |
Im Projektabschluss werden die Aufwands- und Fehlerzahlen zusammengetragen. Gemeinsam mit den persönlichen Notizen zum Umfeld werden sie analysiert und bewertet und falls erforderlich Maßnahmen zur Verbesserung des Prozesses oder des Umfeldes eingeleitet.
Die Ergebnisse einer Phase werden Produkte genannt. Zu den vorher beschriebenen allgemeinen Phasen gibt es folgende Zwischenergebnisse:
Grundsätzlich sind für die Phasen Machbarkeitsanalyse bis einschließlich Test jeweils folgende Produkte zu erstellen bzw. zu erweitern.
 |
|
Die Produkte aus dem vorherigen Kapitel sind bis auf das Programm selbst, alles Dokumente.
| Anforderungen |
Unterscheidung in funktionale Anforderungen, die vom entwickelten System erfüllt sein müssen, Qualitätsmerkmale, die quantifiziert werden und einen Grad der Erfüllung haben und die Randbedingungen, die vorgegeben sind (Hardware, Software u.a.) |
| Auftraggeber |
Der Kunde / Auftraggeber ist derjenige, der das Softwareprodukt in Auftrag gibt und es später auch bezahlt, sofern er zufrieden ist. Er beschreibt, was er von dem Produkt erwartet (Anforderungen). |
| Auftragnehmer |
Der Auftragnehmer erfüllt die Anforderungen des Auftraggebers. Über die Lösungen beschreibt er, wie er die Anforderungen erfüllen wird. |
| Black-Box-Test |
Im Black Box Test werden die Module getestet, ohne deren Programmtext zu kennen. Sie sind rein funktionsorientiert. Es wird geprüft, ob sich aus den Eingabedaten die erwarteten Ausgabedaten erzeugen lassen. |
| Data Dictionary |
Data Dictionary ist ein Verzeichnis, das Informationen über die Struktur von Daten,
ihre Eigenschaften sowie ihre Verwendung enthält.
|
| Formale Inspektion |
Formale Inspektion ist eine Methode der Qualitätssicherung, nach der in genau definierten Phasen mehrere Inspektoren in verschiedenen Rollen ein vorliegendes Dokument unter Einhaltung der Vorgaben detailliert hinsichtlich Vollständigkeit, Korrektheit und Konsistenz begutachten. |
| Funktionale Anforderungen |
Funktionale Anforderungen beschreiben eine Funktion, die ein Produkt erfüllen muss, kann auch
als Inhaltsanforderung bezeichnet werden und bezieht sich auf den Umfang
des Produktes
|
| Glas-Box-Test |
Im Glas-Box-Test werde die Module mit Kenntnis des Programmtextes getestet. Der Test ist kontroll- und datenflußorientiert. |
| Konfigurationsmanagement |
Das Konfigurationsmanagement ist dafür verantwortlich, alle Zwischenprodukte und sonstige Dokumente zu speichern. Dabei werden auch unterschiedliche Versionen vorgehalten und der jeweilige Status jedes Dokumentes notiert. Typische Dokumentationszustände sind: geplant, in Bearbeitung, vorgelegt, akzeptiert. |
| Kunde |
Der Kunde / Auftraggeber ist derjenige, der das Softwareprodukt in Auftrag gibt und es später auch bezahlt, sofern er zufrieden ist. Er beschreibt, was er von dem Produkt erwartet (Anforderungen). |
| Nachbedingung |
Die Nachbedingung einer Phase umfasst die Liste der in dieser Phase zu erstellenden Produkte, sowie die Kriterien, die diese Produkte erfüllen müssen. z.B. die anzuwendende Art der Qualitätssicherung auf die Produkte. |
| Paket |
Ein Paket ist eine Sammlung von Klassen, die zur Implementierung eines oder mehrere logisch zusammengehöriger Anwendungsfälle verwendet werden. In der Analysephase werden diese zusammengehörigen Anwendungsfälle ebenfalls als Paket bezeichnet. |
| Partition |
Partitionen sind die vertikale Anordnung der Teilsysteme eines Systems. Partitionen teilen ein System in mehrere unabhängige oder lose gekoppelte Teilsysteme, von denen jedes eine Art Dienst bereitstellt. |
| Phase |
Die Softwareentwicklung wird in einzelne Phasen unterteilt.
|
| Produkt |
In jeder Phase entstehen Produkte die zum Teil als Eingabeprodukte für die nächste Phase benötigt werden. |
| Produktiv-Phase |
Als Produktiv-Phase bezeichnet man die Phasen in der Software-Entwicklung ohne die organisatorischen und Qualitätssicherungsphasen. Machbarkeitsanalyse, Analyse, Planung, Entwurf, Implementierung. |
| Projekt |
Ein Projekt ist ein einmaliges Vorhaben begrenzter Dauer, das zur Erreichung eines definierten Zieles mit begrenzten Personal- und Sachmitteln durchgeführt wird. |
| Projekthandbuch |
Ist die Konkretisierung des Prozesshandbuches für ein vorliegendes Projekt. |
| Projektmanagement |
Das Projektmanagement plant und überwacht Umfang und Termin des Einsatzes von Personal, Maschinen, Räumen und sonstigen Hilfs- und Betriebsmitteln. Gegenüber dem Management werden regelmäßig Statusberichte zum Projekt gegeben. Sie enthalten insbesondere einen Soll-Ist-Vergleich der Aufwände und Termine. Der Repräsentant des Projektmanagement ist der Projektleiter. |
| Prototyp |
Prototyp ist ein provisorisches Software-System, das während der Produktdefinition
erstellt wird, um Anforderungsfragen zu klären oder Anforderungen zu
veranschaulichen.
|
| Prozess |
Ein Prozess beschreibt Aktivitäten, Methoden und Verfahren, die zur Entwicklung und Überprüfung von Software benötigt werden. /Balz-SM/ |
| Prozesshandbuch |
Das Prozesshandbuch beschreibt die erforderlichen Phasen zur Softwareentwicklung, inklusive der zu erstellenden Produkte. |
| Pseudo-Code |
Pseudo-Code ist eine textuelle semiformale Darstellung von Kontrollstrukturen in Anlehnung an problemorientierte Programmiersprachen. /Balz-SE/ |
| Qualitätsmerkmal |
Qualitätsmerkmale werden auch Eigenschaftsanforderungen genannt. Sie müssen vor dem ersten Versuch einer Lösungsspezifikation spezifiziert und quantifiziert sein. |
| Qualitätssicherung |
Die Qualitätssicherung überprüft die erstellten Produkte und Zwischenprodukte der Software-Erstellung gemäß den Vorgaben des angewendeten Prozesses. Die Erstellung von Testprogrammen gehört dazu. |
| Randbedingungen |
Randbedingungen charakterisieren die Umgebung, in der das Produkt erstellt wird.
Dazu gehören können:
|
| Rolle |
Eine Rolle beschreibt die notwendigen Erfahrungen, Kenntnisse und Fähigkeiten, über die ein Mitarbeiter verfügen muss, um Aktivitäten durchzuführen. /Balz-SM/ |
| Schicht |
Gliederung einer Softwarearchitektur in hierarchische Schichten. Jede Schicht besteht aus Systemkomponenten, z.B. Benutzeroberfläche, eigentliche Anwendung, Datenhaltung. |
| Software-Entwicklung/System-Erstellung |
Die Software-Entwicklung / System-Erstellung umfasst die Erstellung aller Dokumente auf dem Weg zum auslieferungsfähigen Endprodukt einschließlich des Programms. Daher werden die System-Ersteller auch Autoren genannt, insbesondere wenn die Zwischenprodukte Dokumente sind und keine Programme. |
| Softwareprodukt |
Ein Softwareprodukt ist die Gesamtheit von Softwarekomponenten (Programmen, Dokumentationen usw.), die als Ganzes entwickelt, vertrieben, angewendet und gewartet werden. Es besteht aus:
|
| Vorbedingung |
Die Bedingungen, die vor Aufgabenbeginn erfüllt sein müssen. Eingabeprodukte. |
Gilb88 |
Gilb, T.
|
KBSt92 |
Koordinierungs- und Beratungsstelle der Bundesregierung für
Informationstechnik in der Bundesverwaltung
|
VMod97 |
Entwicklungsstandard für IT-Systeme des Bundes, Vorgehensmodell,
|
Balz96 |
Balzert, Helmut
|
Balz98 |
Balzert, Helmut
|
Dumk93 |
Reiner Dumke
|