Softwareprojekt

IT-Projekt

Projektprozess In der folgenden Grafik ist der organisatorische Ablauf des Softwareprojektes dargestellt. Außerdem bestimmen die Studierenden in dieser Stufe, nach welchem Verfahrensmodell das Softwareprojekt durchgeführt werden soll. Je nachdem sind auch die in den verschiedenen Etappen einzureichenden Resultate und Unterlagen unterschiedlich. Ungeachtet des Prozessmodells wird das Topic von den Arbeitsgruppen in jeder Software-Projektphase erarbeitet und am Ende werden eine Darstellung und diverse Review-Dokumente erstellt. Im Anschluss daran wird das Topic aufbereitet.

In der Review werden die Resultate der laufenden Projektphase in Gestalt einer Darstellung (PowerPoint o.ä.) von einem oder höchstens zwei Studierenden im Software-Projektseminar präsentiert. Im Anschluss an ein Gruppentreffen evaluiert der Supervisor alle Resultate der laufenden Stufe und evaluiert sie mit den Studierenden. Mit dem Abschlussevent schließt das Softwareprojekt, bei dem die Arbeitsgruppen einerseits die Resultate der vergangenen Etappe und andererseits die ausführbare und geprüfte Technologie in Gestalt einer Warenpräsentation während des Softwareprojekt-Seminars präsentieren.

Dabei wird das Produkt in Relation zu den in den Spezifikationen festgelegten Zielen bewerte. Neben dem letzen Review-Dokument bilden darüber hinaus folgende Aspekte die Basis für die Projektabnahme: Aus den Einzelbewertungen der Einzelphasen, dem Gesamtergebnis und den Vorträgen wird eine Gesamtnote ermittelt. Innerhalb des Softwareprojekts kann die Unternehmensgruppe ein Prozessmodell auswählen.

Das erwartete Ergebnis pro Stufe variiert je nach Vorgehensmodell leicht und wird in den jeweiligen Kapiteln ausführlicher aufbereitet. Zur Sicherstellung der Ergebnisvergleichbarkeit sind die meisten Forderungen für alle Verfahren gleich. Folgende Prozessmodelle sind verfügbar: Beim Waterfall-Modell ist die Softwareentwicklung streng in einzelne Schritte gegliedert, die hintereinander ablaufen.

Rückkopplungen von Einzelphasen zu früheren Perioden sind im Gewässermodell nur bedingt möglich. Um das Modell des Wasserfalls zu einem gelungenen Ergebnis zu führen, ist viel Know-how für die Konzeption und Gestaltung der Simulationssoftware erforderlich. Bereits in der Projektierungsphase werden die Spezifikationen auf der Grundlage eines Pflichtenheftes aufgesetzt. In der Designphase wird das Gesamtkonzept für das zu erstellenden Produkt ausformuliert.

Dazu gehören das Design der SW-Architektur und des Beteiligungsmodells, die Spezifikation von Bauteilen und Interfaces, die Bestimmung des Bedienkonzepts und der Benutzeroberfläche. In der Umsetzungsphase werden alle in den Spezifikationen spezifizierten Vorgaben gemäß dem Konzept vollumfänglich erfüllt. Die Validierung der Simulationssoftware erfolgt mit einem Testskript, das in dieser Zeit erstellt werden soll.

Das Resultat ist eine Dokumentation zur Validierung, die die Basis für die Überprüfung und die letzte Vorführung ist. Zusätzlich sollen in dieser Darstellung die Funktionalitäten der Anwendung in Gestalt einer Produktdarstellung dargestellt werden. Allerdings wurden auch besondere Prozessmodelle erarbeitet, um verschiedene Problemstellungen von bestehenden Prozessmodellen zu lösen, die Wiederverwendbarkeit von bestehenden Lösungsansätzen zu verbessern und die Wichtigkeit der SW-Architektur zu vergrößern.

Aus der Erkenntnis, dass die Aktivitäten der SW-Entwicklung (Anforderungsanalyse, Design, Umsetzung und Test) nicht streng getrennt werden können, resultierte die Aufteilung des Software-Entwicklungsprozesses in mehrere Iterationsstufen. In diesen Etappen werden die Aktivitäten der SW-Entwicklung mit unterschiedlichen Aufwendungen parallelisiert. Jacobson, Bock und Rumbaugh, "Die drei Amigos", die "Väter der UML", beschrieben 1999 den Einheitlichen Softwareentwicklungsprozess[JBR99], seine wohlbekannten Repräsentanten den Rationalen Einheitlichen Prozess (RUP von IBM), den Open Unified Prozess (Eclipse Foundation) und den Elite-Engineering-Prozess (OOSE).

Basierend auf dem Einheitlichen Prozess wird für das Softwareprojekt die folgende Vorgehensweise empfohlen. Mit unterschiedlichem Arbeitsaufwand verlaufen die Einzelaktivitäten in den unterschiedlichen Stadien des Softwareprojekts zeitgleich. In der Planungsphase ist die Vorgehensweise zunächst für alle Verfahren gleich. Mit diesem Verfahren können jedoch bereits erste Probeimplementierungen zur Aufwandschätzung vorgenommen werden.

Die Grobkonzeption wird in der Designphase erarbeitet. Darüber hinaus soll ein Testskript angelegt werden, indem die Testbeispiele der Einzelmerkmale festgelegt werden, gegen die die später zu testende Anwendung auswählt. Bereits in der Umsetzungsphase werden die individuellen Bedürfnisse durchlaufen. Mit der zunehmenden Zunahme von Prozessmodellen, die als zu kompliziert, zu rigide und zu unbürokratisch galten, insbesondere bei kleineren Projekten wie dem V-Modell oder dem Einheitlichen Prozess, kam es zu einer Gegensteuerung, die zur Ausgestaltung der so genannten Agile Prozessmodelle beitrug.

Mit diesen Verfahren soll die Bürokratie abgebaut werden, indem nur wenige Vorschriften oder Verhaltensweisen festgelegt werden. Die sehr flexiblen Verfahren sind sehr anwendungsorientiert mit sehr kurzen Iterationen. Von großer Wichtigkeit sind auch die gesellschaftlichen Gesichtspunkte während des Entwicklungsprozesses der Software. Mit einer speziellen Ausgestaltung vieler Prozessmodelle, wie beispielsweise des Einheitlichen Prozesses, können diese agiler gemacht werden (z.B.: Agiler Einheitlicher Prozess (Agile Unified Process, AUP)).

In dem Softwareprojekt hat der agilere Ansatz folgende Merkmale: Anders als beim Einheitlichen Prozess durchläuft dieses Verfahren pro Software-Projektphase komplett eine Softwareentwicklungsiteration. Die Aktivitäten der Software-Entwicklung laufen innerhalb einer iterativen Phase ab. Mit dem agilem Ansatz können und sollten jedoch die ersten Testumsetzungen zur Schätzung des Aufwands vorgenommen werden.

Schon in der ersten Wiederholung wird ein schnelles Prototyping durchgeführt. Dazu werden die Voraussetzungen analysiert, die grobe Architektur des Gesamtsystems geschaffen, das Basis-Framework umgesetzt und erprobt. In Summe wird der Prototype zweimal um weitere Zusatzfunktionen ergänzt. Nach jeder Wiederholung entsteht eine ausführbare Programmversion, die um weitere Funktionalität bitet.

Je nach Verfahrenswahl sind die Aufgabenstellung und/oder die zu erwartenden Resultate, der Inhalt und die Zahl der Überprüfungsdokumente sowie der Inhalt der Vorträge festgelegt. Für eine vergleichbare Beurteilung setzen sich die Aufgabenstellungen und der vorgeschlagene Inhalt der Unterlagen und Darstellungen aus einem allgemeinen, vom Verfahren unabhängigen Teil und einem verfahrensspezifischen Teil zusammen.

Die folgende Übersicht beschreibt diese für die unterschiedlichen Verfahren im Detail. Am Ende des Softwareprojekts wird ein abschließendes Überprüfungsdokument aus allen Projektergebnissen erzeugt. Im Vortrag sollen die wesentlichen Resultate der Einzelphasen in 15 min präsentiert werden. In der letzten Darstellung wird der Schluss des Softwareprojekts wiedergegeben.

Die Ergebnisse des Softwareprojekts werden in Gestalt einer Warenpräsentation präsentiert. Die Demonstration des laufenden Programms und seiner Funktion sollte so nah wie möglich am Geschehen sein. Die notwendigen Konstruktionsänderungen sind in den nachfolgenden Schritten zu dokumentieren und zu begründen. Im Endstadium werden in der Regel keine Funktionalität umgesetzt, sondern nur das Produkt mit einem Testskript geprüft und eine Dokumentation angelegt.

Nachfolgend sind alle Voraussetzungen aufgeführt: Die Auswahl des Verfahrensmodells ist zu treffen und zu begründen, die Spezifikationen sind zu erstellen, die eingesetzten Techniken sind zu definieren und die organisatorische Struktur der Unternehmensgruppe ist zu definieren. Das zentrale Resultat der Planungs- und Konstruktionsphase ist das Lastenheft und die Vorbereitung des Grobentwurfs oder, je nach Verfahren, auch die Resultate der Detailplanung.

Das Überprüfungsdokument sollte den nachfolgenden inhaltlichen Rahmen haben: Ein zweites unabhängiges Projekt ist die Erstellung einer Developer-Dokumentation.

Der Fokus dieser Darstellung liegt auf der Umsetzung. Es sollen 3 Belege als Überprüfungsbelege angelegt werden: Sie können die Unterlagen nach Belieben kombinieren. Der folgende Inhalt sollte in das Dokument zur endgültigen Überprüfung aufgenommen werden: Zusätzlich ist ein Handbuch zu erstellen, das die Funktion und die Bedienoberfläche der Anwendung beschreibt. Abschließend soll eine Einbauanleitung für das fertiggestellte Entwicklungssystem erarbeitet werden.

Die Zielsetzung dieser Darstellung ist es, die Resultate des Softwareprojekts, d.h. die laufende Simulationssoftware, zu präsentieren. Entscheiden Sie sich für einen Demo-Typ, der für Ihr persönliches Softwareprojekt vorteilhaft/geeignet ist. Der vorgeschlagene Inhalt ist für alle Verfahren gleich. Das Aufgabengebiet des Einheitlichen Prozesses umfasst Aufgabenstellungen aus allen Software-Projektphasen. Deshalb sollten neben den allgemeinen Aufgabenstellungen auch Resultate aus allen Bereichen des Entwicklungsprozesses präsentiert werden.

Nachfolgend sind alle Voraussetzungen aufgeführt: Die Auswahl des Verfahrensmodells ist zu treffen und zu begründen, die Spezifikationen sind zu erstellen, die eingesetzten Techniken sind zu definieren und die organisatorische Struktur der Unternehmensgruppe ist zu definieren. Das zentrale Resultat der Planungs- und Konstruktionsphase ist das Lastenheft und die Vorbereitung des Grobentwurfs oder, je nach Verfahren, auch die Resultate der Detailplanung.

Sie können die Überprüfungsdokumente als unabhängige Belege oder als allgemeines Belege anlegen. Die Bestandteile des Überprüfungsdokuments sollten den nachstehend aufgeführten Umfang haben: Nachfolgend werden einige der möglichen Darstellungsinhalte für die Planung vorgestellt: Pro Anforderung: Es sollen zwei Belege als Überprüfungsbelege angelegt werden: Das Überprüfungsdokument sollte den nachfolgenden inhaltlichen Rahmen haben: Ein zweites unabhängiges Projekt ist die Erstellung einer Developer-Dokumentation.

Der Fokus dieser Darstellung liegt auf der Umsetzung. Es sollen 3 Belege als Überprüfungsbelege angelegt werden: Sie können die Unterlagen nach Belieben kombinieren. Der folgende Inhalt sollte in das Dokument zur endgültigen Überprüfung aufgenommen werden: Zusätzlich ist ein Handbuch zu erstellen, das die Funktion und die Bedienoberfläche der Anwendung beschreibt. Abschließend soll eine Einbauanleitung für das fertiggestellte Entwicklungssystem erarbeitet werden.

Die Zielsetzung dieser Darstellung ist es, die Ergebnisse des Softwareprojekts, d.h. die laufende Simulationssoftware, zu präsentieren. Entscheiden Sie sich für einen Demo-Typ, der für Ihr persönliches Softwareprojekt vorteilhaft/geeignet ist. Der vorgeschlagene Inhalt ist für alle Verfahren gleich. Bei jeder Wiederholung sollten die nachfolgenden Arbeiten mit zunehmender Feinfühligkeit ausgeführt werden: Ebenso sollten bei dem Agile Verfahren in den Einzelbewertungen vergleichbare Sachverhalte dargestellt werden wie bei den anderen Verfahren.

Nachfolgend werden diese und andere Phasenspezifika dargestellt: Die Auswahl des Verfahrensmodells ist zu treffen und zu begründen, die Spezifikationen sind zu erstellen, die eingesetzten Techniken sind zu definieren und die organisatorische Struktur der Unternehmensgruppe ist zu definieren. Das zentrale Resultat der Planungs- und Konstruktionsphase ist das Lastenheft und die Vorbereitung des Grobentwurfs oder, je nach Verfahren, auch die Resultate der Detailplanung.

Sie können die Überprüfungsdokumente als unabhängige Belege oder als allgemeines Belege anlegen. Die Bestandteile des Überprüfungsdokuments sollten den nachstehend aufgeführten Umfang haben: Nachfolgend werden einige der möglichen Darstellungsinhalte für die Planung vorgestellt: Es sollen zwei Belege als Überprüfungsbelege angelegt werden: Das Überprüfungsdokument sollte den nachfolgenden inhaltlichen Rahmen haben: Ein zweites unabhängiges Projekt ist die Erstellung einer Developer-Dokumentation.

Der Fokus dieser Darstellung liegt auf der Umsetzung. Es sollen 3 Belege als Überprüfungsbelege angelegt werden: Sie können die Unterlagen nach Belieben kombinieren. Der folgende Inhalt sollte in das Dokument zur endgültigen Überprüfung aufgenommen werden: Zusätzlich ist ein Handbuch zu erstellen, das die Funktion und die Bedienoberfläche der Anwendung beschreibt. Abschließend soll eine Einbauanleitung für das fertiggestellte Entwicklungssystem erarbeitet werden.

Die Zielsetzung dieser Darstellung ist es, die Resultate des Softwareprojekts, d.h. die laufende Simulationssoftware, zu präsentieren. Entscheiden Sie sich für einen Demo-Typ, der für Ihr persönliches Softwareprojekt vorteilhaft/geeignet ist. Der vorgeschlagene Inhalt ist für alle Verfahren gleich. Hier sind einige Beispiele aus früheren Softwareprojekten zusammengestellt. Im Laufe der Arbeiten wurden die traditionellen Etappen der Entwicklung von Programmen durchgelaufen.

Auch interessant

Mehr zum Thema