Über diese Vorlage

Diese LATEX-Vorlage wurde von Stefan Macke1 als Grundlage für die Projektdokumentationen der
Auszubildenden zum Fachinformatiker mit Fachrichtung Anwendungsentwicklung bei der Alte Ol-
denburger Krankenversicherung entwickelt. Nichtsdestotrotz dürfte sie ebenso für die anderen IT-
Berufe2 geeignet sein, da diese anhand der gleichen Verordnung bewertet werden.

Diese Vorlage enthält bereits eine Vorstrukturierung der möglichen Inhalte einer tatsächlichen Pro-
jektdokumentation, die auf Basis der Erfahrungen im Rahmen der Prüfertätigkeit des Autors erstellt
und unter Zuhilfenahme von ? abgerundet wurden.

Sämtliche verwendeten Abbildungen, Tabellen und Listings stammen von ?.

Download-Link für diese Vorlage: http://fiae.link/LaTeXVorlageFIAE

Auch verfügbar auf GitHub: https://github.com/StefanMacke/latex-vorlage-fiae

Lizenz

Dieses Werk steht unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedin-
gungen 4.0 International Lizenz. 3

Namensnennung Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise
nennen. 4

Weitergabe unter gleichen Bedingungen Wenn Sie das lizenzierte Werk bzw. den lizenzierten In-
halt bearbeiten oder in anderer Weise erkennbar als Grundlage für eigenes Schaffen verwenden,
dürfen Sie die daraufhin neu entstandenen Werke bzw. Inhalte nur unter Verwendung von Li-
zenzbedingungen weitergeben, die mit denen dieses Lizenzvertrages identisch oder vergleichbar
sind.

1
Blog des Autors: http://fachinformatiker-anwendungsentwicklung.net, Twitter: @StefanMacke
2
z. B. IT-Kaufleute, Fachinformatiker mit Fachrichtung Systemintegration usw.
3
http://creativecommons.org/licenses/by-sa/4.0/
4
Die Namensnennung im LATEX-Quelltext mit Link auf http://fiae.link/LaTeXVorlageFIAE reicht hierfür aus.
Inhalt der Projektdokumentation

Grundsätzlich definiert die ?, S. 17465 das Ziel der Projektdokumentation wie folgt:

„Durch die Projektarbeit und deren Dokumentation soll der Prüfling belegen, daß er Ar-
beitsabläufe und Teilaufgaben zielorientiert unter Beachtung wirtschaftlicher, technischer,
organisatorischer und zeitlicher Vorgaben selbständig planen und kundengerecht umset-
zen sowie Dokumentationen kundengerecht anfertigen, zusammenstellen und modifizieren
kann.“

Und das ?, S. 36 ergänzt:

„Die Ausführung der Projektarbeit wird mit praxisbezogenen Unterlagen dokumentiert.

Der Prüfungsausschuss bewertet die Projektarbeit anhand der Dokumentation. Dabei wird
nicht das Ergebnis – z. B. ein lauffähiges Programm – herangezogen, sondern der Ar-
beitsprozess. Die Dokumentation ist keine wissenschaftliche Abhandlung, sondern eine
handlungsorientierte Darstellung des Projektablaufs mit praxisbezogenen, d.h. betriebüb-
lichen Unterlagen. Sie soll einen Umfang von maximal 10 bis 15 DIN A 4-Seiten nicht
überschreiten. Soweit erforderlich können in einem Anhang z. B. den Zusammenhang er-
läuternde Darstellungen beigefügt werden.“

Außerdem werden dort die grundlegenden Inhalte der Projektdokumentation aufgelistet:

• Name und Ausbildungsberuf des Prüfungsteilnehmers

• Angabe des Ausbildungsbetriebes

• Thema der Projektarbeit

• Falls erforderlich, Beschreibung/Konkretisierung des Auftrages

• Umfassende Beschreibung der Prozessschritte und der erzielten Ergebnisse

• Gegebenenfalls Veränderungen zum Projektantrag mit Begründung

• Wenn für das Projekt erforderlich, ein Anhang mit praxisbezogenen Unterlagen und Dokumen-
ten. Dieser Anhang sollte nicht aufgebläht werden. Die angehängten Dokumente und Unterlagen
sind auf das absolute Minimum zu beschränken.

In den folgenden Kapiteln werden diese geforderten Inhalte und sinnvolle Ergänzungen nun meist
stichwortartig und ggfs. mit Beispielen beschrieben. Nicht alle Kapitel müssen in jeder Dokumentation
vorhanden sein. Handelt es sich bspw. um ein in sich geschlossenes Projekt, kann das Kapitel 1.5:
Projektabgrenzung entfallen; arbeitet die Anwendung nur mit XML-Dateien, kann und muss keine
Datenbank beschrieben werden usw.

5
Dieses Dokument sowie alle weiteren hier genannten können unter http://fiae.link/LaTeXVorlageFIAEQuellen her-
untergeladen werden.
Formale Vorgaben

Die formalen Vorgaben zum Umfang und zur Gestaltung der Projektdokumentation können je nach
IHK recht unterschiedlich sein. Normalerweise sollte die zuständige IHK einen Leitfaden bereitstellen,
in dem alle Formalien nachgelesen werden können, wie z. B. bei der ?.

Als Richtwert verwende ich 15 Seiten für den reinen Inhalt. Also in dieser Vorlage alle Seiten, die
arabisch nummeriert sind (ohne das Literaturverzeichnis und die eidesstattliche Erklärung). Große
Abbildungen, Quelltexte, Tabellen usw. gehören in den Anhang, der 25 Seiten nicht überschreiten
sollte.

Typographische Konventionen, Seitenränder usw. können in der Datei Seitenstil.tex beliebig an-
gepasst werden.

Bewertungskriterien

Die Bewertungskriterien für die Benotung der Projektdokumentation sind recht einheitlich und können
leicht in Erfahrung gebracht werden, z. B. bei der ?. Grundsätzlich sollte die Projektdokumentation
nach der Fertigstellung noch einmal im Hinblick auf diese Kriterien durchgeschaut werden.
Prüfungsteil A
Prüfling (private Anschrift): Ausbildungsbetrieb:

Bestätigung über durchgeführte Projektarbeit

diese Bestätigung ist mit der Projektdokumentation einzureichen

Ausbildungsberuf (bitte unbedingt angeben):

Projektbezeichnung:

Projektbeginn:______________Projektfertigstellung:______________Zeitaufwand in Std.:_______________

Bestätigung der Ausbildungsfirma:

Wir bestätigen, dass der/die Auszubildende das oben bezeichnete Projekt einschließlich der Dokumentation im
Zeitraum

vom: bis: selbständig ausgeführt hat.

Projektverantwortliche(r) in der Firma:

_________________________________________________________________________________________
Vorname Name Telefon Unterschrift

Ausbildungsverantwortliche(r) in der Firma:

_________________________________________________________________________________________
Vorname Name Telefon Unterschrift

Eidesstattliche Erklärung:
Ich versichere, dass ich das Projekt und die dazugehörige Dokumentation selbständig erstellt habe.

Ort und Datum: ________________________________ Unterschrift des Prüflings:_______________________

 Abschlussprüfung Sommer 2015

Fachinformatiker für Anwendungsentwicklung

Dokumentation zur betrieblichen Projektarbeit

Entwicklung von NatInfo

Webbasiertes Tool zur Unterstützung der Entwickler

Abgabetermin: Vechta, den 23.04.2015

Prüfungsbewerber:
Stefan Macke
Meine Straße 1
49377 Vechta

Ausbildungsbetrieb:
Alte Oldenburger Krankenversicherung AG
Theodor-Heuss-Str. 96
49377 Vechta

Dieses Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen
Grenzen des Urheberrechtgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar. Das gilt insbeson-
dere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Einspeicherung und Verarbeitung in
elektronischen Systemen.
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Inhaltsverzeichnis

Inhaltsverzeichnis

Abbildungsverzeichnis II

Tabellenverzeichnis III

Listings IV

Abkürzungsverzeichnis V

1 Einleitung 1
1.1 Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Projektziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Projektbegründung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Projektschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.5 Projektabgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Projektplanung 1
2.1 Projektphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Abweichungen vom Projektantrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Ressourcenplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Analysephase 2
3.1 Ist-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 Wirtschaftlichkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.1 „Make or Buy“-Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.2 Projektkosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2.3 Amortisationsdauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Nutzwertanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5 Qualitätsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6 Lastenheft/Fachkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Entwurfsphase 5
4.1 Zielplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Architekturdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Entwurf der Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.5 Geschäftslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.6 Maßnahmen zur Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.7 Pflichtenheft/Datenverarbeitungskonzept . . . . . . . . . . . . . . . . . . . . . . . . . 7

Stefan Macke I
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Inhaltsverzeichnis

5 Implementierungsphase 7
5.1 Implementierung der Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Implementierung der Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3 Implementierung der Geschäftslogik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6 Abnahmephase 8

7 Einführungsphase 8

8 Dokumentation 9

9 Fazit 9
9.1 Soll-/Ist-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Eidesstattliche Erklärung 11

A Anhang i
A.1 Detaillierte Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
A.2 Lastenheft (Auszug) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
A.3 Use Case-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
A.4 Pflichtenheft (Auszug) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
A.5 Datenbankmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
A.6 Oberflächenentwürfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
A.7 Screenshots der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
A.8 Entwicklerdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
A.9 Testfall und sein Aufruf auf der Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . xii
A.10 Klasse: ComparedNaturalModuleInformation . . . . . . . . . . . . . . . . . . . . . . . xiii
A.11 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
A.12 Benutzerdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Stefan Macke II
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Abbildungsverzeichnis

Abbildungsverzeichnis

1 Vereinfachtes ER-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Prozess des Einlesens eines Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Use Case-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
4 Datenbankmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
5 Liste der Module mit Filtermöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . vi
6 Anzeige der Übersichtsseite einzelner Module . . . . . . . . . . . . . . . . . . . . . . . vii
7 Anzeige und Filterung der Module nach Tags . . . . . . . . . . . . . . . . . . . . . . . vii
8 Anzeige und Filterung der Module nach Tags . . . . . . . . . . . . . . . . . . . . . . . viii
9 Liste der Module mit Filtermöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . ix
10 Aufruf des Testfalls auf der Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
11 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Stefan Macke III

Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Tabellenverzeichnis

Tabellenverzeichnis

1 Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Kostenaufstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Entscheidungsmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Soll-/Ist-Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Stefan Macke IV
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Listings

Listings
1 Testfall in PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
2 Klasse: ComparedNaturalModuleInformation . . . . . . . . . . . . . . . . . . . . . . . xiii

Stefan Macke V
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Abkürzungsverzeichnis

Abkürzungsverzeichnis

API Application Programming Interface

CSV Comma Separated Value

EPK Ereignisgesteuerte Prozesskette

ERM Entity-Relationship-Modell

HTML Hypertext Markup Language

MVC Model View Controller

NatInfo Natural Information System

Natural Programmiersprache der Software AG

PHP Hypertext Preprocessor

SQL Structured Query Language

SVN Subversion

UML Unified Modeling Language

XML Extensible Markup Language

Stefan Macke VI
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

1 Einleitung

1 Einleitung

1.1 Projektumfeld

• Kurze Vorstellung des Ausbildungsbetriebs (Geschäftsfeld, Mitarbeiterzahl usw.)

• Wer ist Auftraggeber/Kunde des Projekts?

1.2 Projektziel

• Worum geht es eigentlich?

• Was soll erreicht werden?

1.3 Projektbegründung

• Warum ist das Projekt sinnvoll (z. B. Kosten- oder Zeitersparnis, weniger Fehler)?

• Was ist die Motivation hinter dem Projekt?

1.4 Projektschnittstellen

• Mit welchen anderen Systemen interagiert die Anwendung (technische Schnittstellen)?

• Wer genehmigt das Projekt bzw. stellt Mittel zur Verfügung?

• Wer sind die Benutzer der Anwendung?

• Wem muss das Ergebnis präsentiert werden?

1.5 Projektabgrenzung

• Was ist explizit nicht Teil des Projekts (insb. bei Teilprojekten)?

2 Projektplanung

2.1 Projektphasen

• In welchem Zeitraum und unter welchen Rahmenbedingungen (z. B. Tagesarbeitszeit) findet das
Projekt statt?

• Verfeinerung der Zeitplanung, die bereits im Projektantrag vorgestellt wurde.

Stefan Macke 1
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

3 Analysephase

Beispiel Tabelle 1 zeigt ein Beispiel für eine grobe Zeitplanung.

Projektphase Geplante Zeit

Analysephase 9h
Entwurfsphase 19 h
Implementierungsphase 29 h
Abnahmetest der Fachabteilung 1h
Einführungsphase 1h
Erstellen der Dokumentation 9h
Pufferzeit 2h
Gesamt 70 h

Tabelle 1: Zeitplanung

Eine detailliertere Zeitplanung findet sich im Anhang A.1: Detaillierte Zeitplanung auf Seite i.

2.2 Abweichungen vom Projektantrag

• Sollte es Abweichungen zum Projektantrag geben (z. B. Zeitplanung, Inhalt des Projekts, neue
Anforderungen), müssen diese explizit aufgeführt und begründet werden.

2.3 Ressourcenplanung

• Detaillierte Planung der benötigten Ressourcen (Hard-/Software, Räumlichkeiten usw.).

• Ggfs. sind auch personelle Ressourcen einzuplanen (z. B. unterstützende Mitarbeiter).

• Hinweis: Häufig werden hier Ressourcen vergessen, die als selbstverständlich angesehen werden
(z. B. PC, Büro).

2.4 Entwicklungsprozess

• Welcher Entwicklungsprozess wird bei der Bearbeitung des Projekts verfolgt (z. B. Wasserfall,
agiler Prozess)?

3 Analysephase

3.1 Ist-Analyse

• Wie ist die bisherige Situation (z. B. bestehende Programme, Wünsche der Mitarbeiter)?

• Was gilt es zu erstellen/verbessern?

Stefan Macke 2
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

3 Analysephase

3.2 Wirtschaftlichkeitsanalyse

• Lohnt sich das Projekt für das Unternehmen?

3.2.1 „Make or Buy“-Entscheidung

• Gibt es vielleicht schon ein fertiges Produkt, dass alle Anforderungen des Projekts abdeckt?

• Wenn ja, wieso wird das Projekt trotzdem umgesetzt?

3.2.2 Projektkosten

• Welche Kosten fallen bei der Umsetzung des Projekts im Detail an (z. B. Entwicklung, Einfüh-
rung/Schulung, Wartung)?

Beispielrechnung (verkürzt) Die Kosten für die Durchführung des Projekts setzen sich sowohl aus
Personal-, als auch aus Ressourcenkosten zusammen. Laut Tarifvertrag verdient ein Auszubildender
im dritten Lehrjahr pro Monat 1000 € Brutto.

8 h/Tag · 220 Tage/Jahr = 1760 h/Jahr (1)

1000 €/Monat · 13, 3 Monate/Jahr = 13300 €/Jahr (2)
13300 €/Jahr
≈ 7,56 €/h (3)
1760 h/Jahr

Es ergibt sich also ein Stundenlohn von 7,56 €. Die Durchführungszeit des Projekts beträgt 70 Stun-
den. Für die Nutzung von Ressourcen6 wird ein pauschaler Stundensatz von 15 € angenommen. Für
die anderen Mitarbeiter wird pauschal ein Stundenlohn von 25 € angenommen. Eine Aufstellung der
Kosten befindet sich in Tabelle 2 und sie betragen insgesamt 2739,20 €.

Vorgang Zeit Kosten pro Stunde Kosten

Entwicklungskosten 70 h 7,56 € + 15 € = 22,56 € 1579,20 €
Fachgespräch 3h 25 € + 15 € = 40 € 120 €
Abnahmetest 1h 25 € + 15 € = 40 € 40 €
Anwenderschulung 25 h 25 € + 15 € = 40 € 1000 €
2739,20 €

Tabelle 2: Kostenaufstellung

6
Räumlichkeiten, Arbeitsplatzrechner etc.

Stefan Macke 3
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

3 Analysephase

3.2.3 Amortisationsdauer

• Welche monetären Vorteile bietet das Projekt (z. B. Einsparung von Lizenzkosten, Arbeitszeiter-
sparnis, bessere Usability, Korrektheit)?

• Wann hat sich das Projekt amortisiert?

Beispielrechnung (verkürzt) Bei einer Zeiteinsparung von 10 Minuten am Tag für jeden der 25
Anwender und 220 Arbeitstagen im Jahr ergibt sich eine gesamte Zeiteinsparung von

25 · 220 Tage/Jahr · 10 min/Tag = 55000 min/Jahr ≈ 917 h/Jahr (4)

Dadurch ergibt sich eine jährliche Einsparung von

917h · (25 + 15) €/h = 36680 € (5)

Die Amortisationszeit beträgt also 2739,20 € ≈ 0, 07 Jahre ≈ 4 Wochen.

36680 €/Jahr

3.3 Nutzwertanalyse

• Darstellung des nicht-monetären Nutzens (z. B. Vorher-/Nachher-Vergleich anhand eines Wirt-

schaftlichkeitskoeffizienten).

Beispiel Ein Beispiel für eine Entscheidungsmatrix findet sich in Kapitel 4.2: Architekturdesign.

3.4 Anwendungsfälle

• Welche Anwendungsfälle soll das Projekt abdecken?

• Einer oder mehrere interessante (!) Anwendungsfälle könnten exemplarisch durch ein Aktivitäts-
diagramm oder eine Ereignisgesteuerte Prozesskette (EPK) detailliert beschrieben werden.

Beispiel Ein Beispiel für ein Use Case-Diagramm findet sich im Anhang A.3: Use Case-Diagramm
auf Seite iii.

3.5 Qualitätsanforderungen

• Welche Qualitätsanforderungen werden an die Anwendung gestellt (z. B. hinsichtlich Performan-

ce, Usability, Effizienz etc. (siehe ?))?

Stefan Macke 4
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

4 Entwurfsphase

3.6 Lastenheft/Fachkonzept

• Auszüge aus dem Lastenheft/Fachkonzept, wenn es im Rahmen des Projekts erstellt wurde.

• Mögliche Inhalte: Funktionen des Programms (Muss/Soll/Wunsch), User Stories, Benutzerrollen

Beispiel Ein Beispiel für ein Lastenheft findet sich im Anhang A.2: Lastenheft (Auszug) auf Sei-
te ii.

4 Entwurfsphase

4.1 Zielplattform

• Beschreibung der Kriterien zur Auswahl der Zielplattform (u. a. Programmiersprache, Daten-
bank, Client/Server, Hardware).

4.2 Architekturdesign

• Beschreibung und Begründung der gewählten Anwendungsarchitektur (z. B. MVC).

• Ggfs. Bewertung und Auswahl von verwendeten Frameworks sowie ggfs. eine kurze Einführung
in die Funktionsweise des verwendeten Frameworks.

Beispiel Anhand der Entscheidungsmatrix in Tabelle 3 wurde für die Implementierung der Anwen-
dung das PHP-Framework Symfony7 ausgewählt.

Eigenschaft Gewichtung Akelos CakePHP Symfony Eigenentwicklung

Dokumentation 5 4 3 5 0
Reenginierung 3 4 2 5 3
Generierung 3 5 5 5 2
Testfälle 2 3 2 3 3
Standardaufgaben 4 3 3 3 0
Gesamt: 17 65 52 73 21
Nutzwert: 3,82 3,06 4,29 1,24

Tabelle 3: Entscheidungsmatrix

7
Vgl. ?.

Stefan Macke 5
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

4 Entwurfsphase

4.3 Entwurf der Benutzeroberfläche

• Entscheidung für die gewählte Benutzeroberfläche (z. B. GUI, Webinterface).

• Beschreibung des visuellen Entwurfs der konkreten Oberfläche (z. B. Mockups, Menüführung).

• Ggfs. Erläuterung von angewendeten Richtlinien zur Usability und Verweis auf Corporate Design.

Beispiel Beispielentwürfe finden sich im Anhang A.6: Oberflächenentwürfe auf Seite vi.

4.4 Datenmodell

• Entwurf/Beschreibung der Datenstrukturen (z. B. ERM und/oder Tabellenmodell, XML-Schemas)

mit kurzer Beschreibung der wichtigsten (!) verwendeten Entitäten.

Beispiel In Abbildung 1 wird ein Entity-Relationship-Modell (ERM) dargestellt, welches lediglich

Entitäten, Relationen und die dazugehörigen Kardinalitäten enthält.

Abbildung 1: Vereinfachtes ER-Modell

4.5 Geschäftslogik

• Modellierung und Beschreibung der wichtigsten (!) Bereiche der Geschäftslogik (z. B. mit Kompo-
nenten-, Klassen-, Sequenz-, Datenflussdiagramm, Programmablaufplan, Struktogramm, EPK).

• Wie wird die erstellte Anwendung in den Arbeitsfluss des Unternehmens integriert?

Beispiel Ein Klassendiagramm, welches die Klassen der Anwendung und deren Beziehungen unter-
einander darstellt kann im Anhang A.11: Klassendiagramm auf Seite xvi eingesehen werden.

Abbildung 2 zeigt den grundsätzlichen Programmablauf beim Einlesen eines Moduls als EPK.

Stefan Macke 6
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

5 Implementierungsphase

Abbildung 2: Prozess des Einlesens eines Moduls

4.6 Maßnahmen zur Qualitätssicherung

• Welche Maßnahmen werden ergriffen, um die Qualität des Projektergebnisses (siehe Kapitel 3.5:
Qualitätsanforderungen) zu sichern (z. B. automatische Tests, Anwendertests)?

• Ggfs. Definition von Testfällen und deren Durchführung (durch Programme/Benutzer).

4.7 Pflichtenheft/Datenverarbeitungskonzept

• Auszüge aus dem Pflichtenheft/Datenverarbeitungskonzept, wenn es im Rahmen des Projekts

erstellt wurde.

Beispiel Ein Beispiel für das auf dem Lastenheft (siehe Kapitel 3.6: Lastenheft/Fachkonzept) auf-
bauende Pflichtenheft ist im Anhang A.4: Pflichtenheft (Auszug) auf Seite iii zu finden.

5 Implementierungsphase

5.1 Implementierung der Datenstrukturen

• Beschreibung der angelegten Datenbank (z. B. Generierung von SQL aus Modellierungswerkzeug
oder händisches Anlegen), XML-Schemas usw..

5.2 Implementierung der Benutzeroberfläche

• Beschreibung der Implementierung der Benutzeroberfläche, falls dies separat zur Implementie-
rung der Geschäftslogik erfolgt (z. B. bei HTML-Oberflächen und Stylesheets).

• Ggfs. Beschreibung des Corporate Designs und dessen Umsetzung in der Anwendung.

Stefan Macke 7
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

6 Abnahmephase

• Screenshots der Anwendung

Beispiel Screenshots der Anwendung in der Entwicklungsphase mit Dummy-Daten befinden sich im
Anhang A.7: Screenshots der Anwendung auf Seite viii.

5.3 Implementierung der Geschäftslogik

• Beschreibung des Vorgehens bei der Umsetzung/Programmierung der entworfenen Anwendung.

• Ggfs. interessante Funktionen/Algorithmen im Detail vorstellen, verwendete Entwurfsmuster

zeigen.

• Quelltextbeispiele zeigen.

• Hinweis: Wie in Kapitel 1: Einleitung zitiert, wird nicht ein lauffähiges Programm bewertet,
sondern die Projektdurchführung. Dennoch würde ich immer Quelltextausschnitte zeigen, da
sonst Zweifel an der tatsächlichen Leistung des Prüflings aufkommen können.

Beispiel Die Klasse ComparedNaturalModuleInformation findet sich im Anhang A.10: Klasse: Com-
paredNaturalModuleInformation auf Seite xiii.

6 Abnahmephase

• Welche Tests (z. B. Unit-, Integrations-, Systemtests) wurden durchgeführt und welche Ergeb-
nisse haben sie geliefert (z. B. Logs von Unit Tests, Testprotokolle der Anwender)?

• Wurde die Anwendung offiziell abgenommen?

Beispiel Ein Auszug eines Unit Tests befindet sich im Anhang A.9: Testfall und sein Aufruf auf der
Konsole auf Seite xii. Dort ist auch der Aufruf des Tests auf der Konsole des Webservers zu sehen.

7 Einführungsphase

• Welche Schritte waren zum Deployment der Anwendung nötig und wie wurden sie durchgeführt
(automatisiert/manuell)?

• Wurden ggfs. Altdaten migriert und wenn ja, wie?

• Wurden Benutzerschulungen durchgeführt und wenn ja, Wie wurden sie vorbereitet?

Stefan Macke 8
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

8 Dokumentation

8 Dokumentation

• Wie wurde die Anwendung für die Benutzer/Administratoren/Entwickler dokumentiert (z. B.

Benutzerhandbuch, API-Dokumentation)?

• Hinweis: Je nach Zielgruppe gelten bestimmte Anforderungen für die Dokumentation (z. B. kei-
ne IT-Fachbegriffe in einer Anwenderdokumentation verwenden, aber auf jeden Fall in einer
Dokumentation für den IT-Bereich).

Beispiel Ein Ausschnitt aus der erstellten Benutzerdokumentation befindet sich im Anhang A.12:
Benutzerdokumentation auf Seite xvii. Die Entwicklerdokumentation wurde mittels PHPDoc8 au-
tomatisch generiert. Ein beispielhafter Auszug aus der Dokumentation einer Klasse findet sich im
Anhang A.8: Entwicklerdokumentation auf Seite x.

9 Fazit

9.1 Soll-/Ist-Vergleich

• Wurde das Projektziel erreicht und wenn nein, warum nicht?

• Ist der Auftraggeber mit dem Projektergebnis zufrieden und wenn nein, warum nicht?

• Wurde die Projektplanung (Zeit, Kosten, Personal, Sachmittel) eingehalten oder haben sich
Abweichungen ergeben und wenn ja, warum?

• Hinweis: Die Projektplanung muss nicht strikt eingehalten werden. Vielmehr sind Abweichungen
sogar als normal anzusehen. Sie müssen nur vernünftig begründet werden (z. B. durch Änderun-
gen an den Anforderungen, unter-/überschätzter Aufwand).

Beispiel (verkürzt) Wie in Tabelle 4 zu erkennen ist, konnte die Zeitplanung bis auf wenige Ausnah-
men eingehalten werden.

9.2 Lessons Learned

• Was hat der Prüfling bei der Durchführung des Projekts gelernt (z. B. Zeitplanung, Vorteile der
eingesetzten Frameworks, Änderungen der Anforderungen)?

8
Vgl. ?

Stefan Macke 9
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

9 Fazit

Phase Geplant Tatsächlich Differenz

Entwurfsphase 19 h 19 h
Analysephase 9h 10 h +1 h
Implementierungsphase 29 h 28 h -1 h
Abnahmetest der Fachabteilung 1h 1h
Einführungsphase 1h 1h
Erstellen der Dokumentation 9h 11 h +2 h
Pufferzeit 2h 0h -2 h
Gesamt 70 h 70 h

Tabelle 4: Soll-/Ist-Vergleich

9.3 Ausblick

• Wie wird sich das Projekt in Zukunft weiterentwickeln (z. B. geplante Erweiterungen)?

Stefan Macke 10
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

Eidesstattliche Erklärung

Eidesstattliche Erklärung

Ich, Stefan Macke, versichere hiermit, dass ich meine Dokumentation zur betrieblichen Projekt-
arbeit mit dem Thema

Entwicklung von NatInfo – Webbasiertes Tool zur Unterstützung der Entwickler

selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe,
wobei ich alle wörtlichen und sinngemäßen Zitate als solche gekennzeichnet habe. Die Arbeit wurde
bisher keiner anderen Prüfungsbehörde vorgelegt und auch nicht veröffentlicht.

Vechta, den 23.04.2015

Stefan Macke

Stefan Macke 11
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A Anhang

A.1 Detaillierte Zeitplanung

Analysephase 9h
1. Analyse des Ist-Zustands 3h
1.1. Fachgespräch mit der EDV-Abteilung 1h
1.2. Prozessanalyse 2h
2. „Make or buy“-Entscheidung und Wirtschaftlichkeitsanalyse 1h
3. Erstellen eines „Use-Case“-Diagramms 2h
4. Erstellen des Lastenhefts mit der EDV-Abteilung 3h
Entwurfsphase 19 h
1. Prozessentwurf 2h
2. Datenbankentwurf 3h
2.1. ER-Modell erstellen 2h
2.2. Konkretes Tabellenmodell erstellen 1h
3. Erstellen von Datenverarbeitungskonzepten 4h
3.1. Verarbeitung der CSV-Daten 1h
3.2. Verarbeitung der SVN-Daten 1h
3.3. Verarbeitung der Sourcen der Programme 2h
4. Benutzeroberflächen entwerfen und abstimmen 2h
5. Erstellen eines UML-Komponentendiagramms der Anwendung 4h
6. Erstellen des Pflichtenhefts 4h
Implementierungsphase 29 h
1. Anlegen der Datenbank 1h
2. Umsetzung der HTML-Oberflächen und Stylesheets 4h
3. Programmierung der PHP-Module für die Funktionen 23 h
3.1. Import der Modulinformationen aus CSV-Dateien 2 h
3.2. Parsen der Modulquelltexte 3 h
3.3. Import der SVN-Daten 2 h
3.4. Vergleichen zweier Umgebungen 4 h
3.5. Abrufen der von einem zu wählenden Benutzer geänderten Module 3 h
3.6. Erstellen einer Liste der Module unter unterschiedlichen Aspekten 5 h
3.7. Anzeigen einer Liste mit den Modulen und geparsten Metadaten 3 h
3.8. Erstellen einer Übersichtsseite für ein einzelnes Modul 1 h
4. Nächtlichen Batchjob einrichten 1h
Abnahmetest der Fachabteilung 1h
1. Abnahmetest der Fachabteilung 1h
Einführungsphase 1h
1. Einführung/Benutzerschulung 1h
Erstellen der Dokumentation 9h
1. Erstellen der Benutzerdokumentation 2h
2. Erstellen der Projektdokumentation 6h
3. Programmdokumentation 1h
3.1. Generierung durch PHPdoc 1h
Pufferzeit 2h
1. Puffer 2h
Gesamt 70 h

Stefan Macke i
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.2 Lastenheft (Auszug)

Es folgt ein Auszug aus dem Lastenheft mit Fokus auf die Anforderungen:

Die Anwendung muss folgende Anforderungen erfüllen:

1. Verarbeitung der Moduldaten

1.1. Die Anwendung muss die von Subversion und einem externen Programm bereitgestellten
Informationen (z.B. Source-Benutzer, -Datum, Hash) verarbeiten.
1.2. Auslesen der Beschreibung und der Stichwörter aus dem Sourcecode.
2. Darstellung der Daten
2.1. Die Anwendung muss eine Liste aller Module erzeugen inkl. Source-Benutzer und -Datum,
letztem Commit-Benutzer und -Datum für alle drei Umgebungen.
2.2. Verknüpfen der Module mit externen Tools wie z.B. Wiki-Einträgen zu den Modulen oder
dem Sourcecode in Subversion.
2.3. Die Sourcen der Umgebungen müssen verglichen und eine schnelle Übersicht zur Einhaltung
des allgemeinen Entwicklungsprozesses gegeben werden.
2.4. Dieser Vergleich muss auf die von einem bestimmten Benutzer bearbeiteten Module einge-
schränkt werden können.
2.5. Die Anwendung muss in dieser Liste auch Module anzeigen, die nach einer Bearbeitung
durch den gesuchten Benutzer durch jemand anderen bearbeitet wurden.
2.6. Abweichungen sollen kenntlich gemacht werden.
2.7. Anzeigen einer Übersichtsseite für ein Modul mit allen relevanten Informationen zu diesem.
3. Sonstige Anforderungen
3.1. Die Anwendung muss ohne das Installieren einer zusätzlichen Software über einen Web-
browser im Intranet erreichbar sein.
3.2. Die Daten der Anwendung müssen jede Nacht bzw. nach jedem SVN-Commit automatisch
aktualisiert werden.
3.3. Es muss ermittelt werden, ob Änderungen auf der Produktionsumgebung vorgenommen
wurden, die nicht von einer anderen Umgebung kopiert wurden. Diese Modulliste soll als
Mahnung per E-Mail an alle Entwickler geschickt werden (Peer Pressure).
3.4. Die Anwendung soll jederzeit erreichbar sein.
3.5. Da sich die Entwickler auf die Anwendung verlassen, muss diese korrekte Daten liefern und
darf keinen Interpretationsspielraum lassen.
3.6. Die Anwendung muss so flexibel sein, dass sie bei Änderungen im Entwicklungsprozess
einfach angepasst werden kann.

Stefan Macke ii
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.3 Use Case-Diagramm

Use Case-Diagramme und weitere UML-Diagramme kann man auch direkt mit LATEX zeichnen, siehe
z. B. http://metauml.sourceforge.net/old/usecase-diagram.html.

Abbildung 3: Use Case-Diagramm

A.4 Pflichtenheft (Auszug)

Zielbestimmung

1. Musskriterien
1.1. Modul-Liste: Zeigt eine filterbare Liste der Module mit den dazugehörigen Kerninformatio-
nen sowie Symbolen zur Einhaltung des Entwicklungsprozesses an
• In der Liste wird der Name, die Bibliothek und Daten zum Source und Kompilat eines
Moduls angezeigt.
• Ebenfalls wird der Status des Moduls hinsichtlich Source und Kompilat angezeigt.
Dazu gibt es unterschiedliche Status-Zeichen, welche symbolisieren in wie weit der
Entwicklungsprozess eingehalten wurde bzw. welche Schritte als nächstes getan werden
müssen. So gibt es z. B. Zeichen für das Einhalten oder Verletzen des Prozesses oder
den Hinweis auf den nächsten zu tätigenden Schritt.
• Weiterhin werden die Benutzer und Zeitpunkte der aktuellen Version der Sourcen und
Kompilate angezeigt. Dazu kann vorher ausgewählt werden, von welcher Umgebung
diese Daten gelesen werden sollen.

Stefan Macke iii

Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

• Es kann eine Filterung nach allen angezeigten Daten vorgenommen werden. Die Daten
zu den Sourcen sind historisiert. Durch die Filterung ist es möglich, auch Module zu
finden, die in der Zwischenzeit schon von einem anderen Benutzer editiert wurden.
1.2. Tag-Liste: Bietet die Möglichkeit die Module anhand von Tags zu filtern.
• Es sollen die Tags angezeigt werden, nach denen bereits gefiltert wird und die, die noch
der Filterung hinzugefügt werden könnten, ohne dass die Ergebnisliste leer wird.
• Zusätzlich sollen die Module angezeigt werden, die den Filterkriterien entsprechen.
Sollten die Filterkriterien leer sein, werden nur die Module angezeigt, welche mit einem
Tag versehen sind.
1.3. Import der Moduldaten aus einer bereitgestellten CSV-Datei
• Es wird täglich eine Datei mit den Daten der aktuellen Module erstellt. Diese Datei
wird (durch einen Cronjob) automatisch nachts importiert.
• Dabei wird für jedes importierte Modul ein Zeitstempel aktualisiert, damit festgestellt
werden kann, wenn ein Modul gelöscht wurde.
• Die Datei enthält die Namen der Umgebung, der Bibliothek und des Moduls, den
Programmtyp, den Benutzer und Zeitpunkt des Sourcecodes sowie des Kompilats und
den Hash des Sourcecodes.
• Sollte sich ein Modul verändert haben, werden die entsprechenden Daten in der Da-
tenbank aktualisiert. Die Veränderungen am Source werden dabei aber nicht ersetzt,
sondern historisiert.
1.4. Import der Informationen aus Subversion (SVN). Durch einen „post-commit-hook“ wird
nach jedem Einchecken eines Moduls ein PHP-Script auf der Konsole aufgerufen, welches die
Informationen, die vom SVN-Kommandozeilentool geliefert werden, an NatInfo übergibt.
1.5. Parsen der Sourcen
• Die Sourcen der Entwicklungsumgebung werden nach Tags, Links zu Artikeln im Wiki
und Programmbeschreibungen durchsucht.
• Diese Daten werden dann entsprechend angelegt, aktualisiert oder nicht mehr gesetzte
Tags/Wikiartikel entfernt.
1.6. Sonstiges
• Das Programm läuft als Webanwendung im Intranet.
• Die Anwendung soll möglichst leicht erweiterbar sein und auch von anderen Entwick-
lungsprozessen ausgehen können.
• Eine Konfiguration soll möglichst in zentralen Konfigurationsdateien erfolgen.

Produkteinsatz

1. Anwendungsbereiche
Die Webanwendung dient als Anlaufstelle für die Entwicklung. Dort sind alle Informationen

Stefan Macke iv
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

für die Module an einer Stelle gesammelt. Vorher getrennte Anwendungen werden ersetzt bzw.
verlinkt.
2. Zielgruppen
NatInfo wird lediglich von den Natural-Entwicklern in der EDV-Abteilung genutzt.
3. Betriebsbedingungen
Die nötigen Betriebsbedingungen, also der Webserver, die Datenbank, die Versionsverwaltung,
das Wiki und der nächtliche Export sind bereits vorhanden und konfiguriert. Durch einen täg-
lichen Cronjob werden entsprechende Daten aktualisiert, die Webanwendung ist jederzeit aus
dem Intranet heraus erreichbar.

A.5 Datenbankmodell

ER-Modelle kann man auch direkt mit LATEX zeichnen, siehe z. B. http://www.texample.net/tikz/
examples/entity-relationship-diagram/.
1DWXUDO/LEUDU\ > @
1DWXUDO0RGXOH 1DWXUDO(UURUFRGH
LG,17(*(5 > @
LG,17(*(5 LG,17(*(5
QDPH9$5&+$5
HQYLURQPHQWBLG,17(*(5). QDPH9$5&+$5

OLEUDU\BLG,17(*(5). GHVFULSWLRQ9$5&+$5
1DWXUDO(QYLURQPHQW
>@
LG,17(*(5 PRGXOHQDPHBLG,17(*(5).
> @ >@ PRGXOHW\SHBLG,17(*(5).
QDPH9$5&+$5
1DWXUDO0RGXOHW\SH
VRXUFHBSDWK9$5&+$5 HUURUFRGHBLG,17(*(5). > @
LG,17(*(5
VYQBSDWK9$5&+$5 FDWDORJBXVHUBLG,17(*(5).
ILOHW\SH9$5&+$5
VHUYHU9$5&+$5 FDWDORJBVL]H,17(*(5
>@ GHVFULSWLRQ9$5&+$5
FDWDORJBGRQHBDW7,0(67$03
1DWXUDO0RGXOHQDPH > @ FDWDORJBSUHYLRXVO\BGRQHBDW7,0(67$03
1DWXUDO+LVWRU\
LG,17(*(5 >@ FUHDWHGBDW7,0(67$03
LG,17(*(5
QDPH9$5&+$5 > @ XSGDWHGBDW7,0(67$03
VRXUFHBXVHUBLG,17(*(5).
LVBLJQRUHG%22/ 0RGXOH&DWDORJ8VHU
> @ PRGXOHBLG,17(*(5).
GHVFULSWLRQ7(;7 FDWDORJBXVHUBLG
>@ KDVK9$5&+$5
0RGXOH(QYLURQPHQW
> @ VDYHGBDW7,0(67$03
HQYLURQPHQWBLG
+LVWRU\0RGXOH
0RGXOH0RGXOHW\SH
>@ PRGXOHBLG
PRGXOHW\SHBLG
+LVWRU\6RXUFH8VHU
0RGXOH/LEUDU\ >@
>@ VRXUFHBXVHUBLG
>@ OLEUDU\BLG
0RGXOH(UURUFRGH >@
1DWXUDO0RGXOHQDPH+DV7DJ 1DWXUDO0RGXOHQDPH+DV:LNL
HUURUFRGHBLG
PRGXOHQDPHBLG,17(*(5). PRGXOHQDPHBLG,17(*(5).
0RGXOH0RGXOHQDPH > @
WDJBLG,17(*(5). ZLNLBLG,17(*(5).
PRGXOHQDPHBLG
7DJ0RGXOHQDPH :LNL0RGXOHQDPH 1DWXUDO8VHU
> @
PRGXOHQDPHBLG PRGXOHQDPHBLG >@ LG,17(*(5

0RGXOHQDPH7DJ 0RGXOHQDPH:LNL QDPH9$5&+$5

> @
WDJBLG ZLNLBLG IXOOQDPH9$5&+$5
>@ LVBVKRZQ%22/
>@ >@
LVBQRWLILHG%22/
1DWXUDO6YQ
PRGXOHBLG,17(*(5).
> @ > @
VYQBXVHUBLG,17(*(5).
VYQBUHYLVLRQ,17(*(5
1DWXUDO7DJ 1DWXUDO:LNL
VYQBPHVVDJH9$5&+$5 >@
LG,17(*(5 LG,17(*(5
VYQBFRPPLWHGBDW7,0(67$03
QDPH9$5&+$5 DUWLFOH9$5&+$5
VYQBKDVK9$5&+$5
VOXJ9$5&+$5
6YQ8VHU
7DJ6OXJ
VYQBXVHUBLG
VOXJ
6YQ0RGXOH
PRGXOHBLG

Abbildung 4: Datenbankmodell

Stefan Macke v
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.6 Oberflächenentwürfe

Browser
http://natinfo.intranet/module/

Filter:
Source- and Catalog-Information Source: Catalog:
from Environment: Date: Date:
Select Select Select
Library: Username: Username:
Select Select Select

Filter

Module Library Sourcen Catalog Source-User Source-Date Catalog-User Catalog-Date

DGTEST UTILITY Grashorn 01.04.2010 Grashorn 02.04.2010

EINTEST SYSTEM Mustermann 01.04.2010 Grashorn 02.04.2010
NOCHEINS UTILITY Grashorn 05.04.2010 Grashorn 05.04.2010
MANUEL SYSTEM Grashorn 01.03.2010 Grashorn 01.03.2010
RESET CON Mustermann 02.03.2010 Mustermann 02.03.2010
TESTER SYSTEM Grashorn 01.02.2010 Grashorn 01.02.2010
... ... ... ... ... ... ... ...

Abbildung 5: Liste der Module mit Filtermöglichkeiten

Stefan Macke vi
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

Browser
http://natinfo.intranet/module/DGTEST

DGTEST

Tag, Source

Sourcen: ENTW>SVN=QS>PROD

Source-Dates: Hash: Catalog:

ENTW: 05.04.2010 2345678901
SVN: 02.04.2010 1098765432
QS: 03.04.2010 1098765432
PROD: 01.01.2010 8765432109

Abbildung 6: Anzeige der Übersichtsseite einzelner Module

Browser
http://natinfo.intranet/tag/

Tags:
Erweiterung, Framework, Test

Module Description Tags Wiki

DGTEST Testet Test DGTEST (EP)

EINTEST Testerweiterung Test, Erweiterung EINTEST (EP)
NOCHEINS Ein Framework Framework

Abbildung 7: Anzeige und Filterung der Module nach Tags

Stefan Macke vii

Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.7 Screenshots der Anwendung

Häufig benötigte Seiten

Ein-Klick-Menü
Direktaufruf

Inhaltssuche

/ Tags / HGP Tags, Modules

Tags
Project, Test

Modulename Description Tags Wiki

DGTEST Macht einen ganz tollen Tab. HGP SMTAB_(EP), b

MALWAS HGP, Test

HDRGE HGP, Project

WURAM HGP, Test

PAMIU HGP

Abbildung 8: Anzeige und Filterung der Module nach Tags

Stefan Macke viii

Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

Häufig benötigte Seiten

Ein-Klick-Menü
Direktaufruf

Inhaltssuche

/ Modules / ENTW Tags, Modules

Modules

Environment

Library

Catalog user

Catalog date

Source user

Source date

Reset

Name Library Source Catalog Source-User Source-Date Catalog-User Catalog-Date

SMTAB UTILITY MACKE 01.04.2010 13:00 MACKE 01.04.2010 13:00

DGTAB CON GRASHORN 01.04.2010 13:00 GRASHORN 01.04.2010 13:00

DGTEST SUP GRASHORN 05.04.2010 13:00 GRASHORN 05.04.2010 13:00

OHNETAG CON GRASHORN 05.04.2010 13:00 GRASHORN 01.04.2010 15:12

OHNEWIKI CON GRASHORN 05.04.2010 13:00 MACKE 01.04.2010 15:12

Abbildung 9: Liste der Module mit Filtermöglichkeiten

Stefan Macke ix
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.8 Entwicklerdokumentation

lib-model
[ class tree: lib-model ] [ index: lib-model ] [ all elements ]
Packages:
lib-model Class: Naturalmodulename
Files: Source Location: /Naturalmodulename.php
Naturalmodulename.php
Class Overview Methods
Classes:
Naturalmodulename BaseNaturalmodulename __construct
| getNaturalTags
--Naturalmodulename getNaturalWikis
loadNaturalModuleInformation
__toString
Subclass for representing a row from the
'NaturalModulename' table.

Class Details

[line 10]
Subclass for representing a row from the 'NaturalModulename' table.

Adds some business logic to the base.

[ Top ]

Class Methods

constructor __construct [line 56]

Naturalmodulename __construct( )

Initializes internal state of Naturalmodulename object.

Tags:

see: parent::__construct()
access: public

[ Top ]

method getNaturalTags [line 68]

array getNaturalTags( )

Returns an Array of NaturalTags connected with this Modulename.

Stefan Macke x
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

Tags:

return: Array of NaturalTags

access: public

[ Top ]

method getNaturalWikis [line 83]

array getNaturalWikis( )

Returns an Array of NaturalWikis connected with this Modulename.

Tags:

return: Array of NaturalWikis

access: public

[ Top ]

method loadNaturalModuleInformation [line 17]

ComparedNaturalModuleInformation
loadNaturalModuleInformation( )

Gets the ComparedNaturalModuleInformation for this NaturalModulename.

Tags:

access: public

[ Top ]

method __toString [line 47]

string __toString( )

Returns the name of this NaturalModulename.

Tags:

access: public

[ Top ]

Documentation generated on Thu, 22 Apr 2010 08:14:01 +0200 by phpDocumentor 1.4.2

Stefan Macke xi
 Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.9 Testfall und sein Aufruf auf der Konsole

1 <?php
2 include(dirname(__FILE__).’/../bootstrap/Propel.php’);
3

4 $t = new lime_test(13);
5

6 $t−>comment(’Empty Information’);
7 $emptyComparedInformation = new ComparedNaturalModuleInformation(array());
8 $t−>is($emptyComparedInformation−>getCatalogSign(), ComparedNaturalModuleInformation::EMPTY_SIGN, ’
Has no catalog sign’);
9 $t−>is($emptyComparedInformation−>getSourceSign(), ComparedNaturalModuleInformation::SIGN_CREATE, ’
Source has to be created’);
10

11 $t−>comment(’Perfect Module’);
12 $criteria = new Criteria();
13 $criteria−>add(NaturalmodulenamePeer::NAME, ’SMTAB’);
14 $moduleName = NaturalmodulenamePeer::doSelectOne($criteria);
15 $t−>is($moduleName−>getName(), ’SMTAB’, ’Right modulename selected’);
16 $comparedInformation = $moduleName−>loadNaturalModuleInformation();
17 $t−>is($comparedInformation−>getSourceSign(), ComparedNaturalModuleInformation::SIGN_OK, ’Source sign
shines global’);
18 $t−>is($comparedInformation−>getCatalogSign(), ComparedNaturalModuleInformation::SIGN_OK, ’Catalog sign
shines global’);
19 $infos = $comparedInformation−>getNaturalModuleInformations();
20 foreach( $infos as $info)
21 {
22 $env = $info−>getEnvironmentName();
23 $t−>is($info−>getSourceSign(), ComparedNaturalModuleInformation::SIGN_OK, ’Source sign shines at ’ . $env);
24 if ($env != ’SVNENTW’)
25 {
26 $t−>is($info−>getCatalogSign(), ComparedNaturalModuleInformation::SIGN_OK, ’Catalog sign shines at ’ .
$info−>getEnvironmentName());
27 }
28 else
29 {
30 $t−>is($info−>getCatalogSign(), ComparedNaturalModuleInformation::EMPTY_SIGN, ’Catalog sign is empty
at ’ . $info−>getEnvironmentName());
31 }
32 }
33 ?>

Listing 1: Testfall in PHP

Stefan Macke xii

 Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

Abbildung 10: Aufruf des Testfalls auf der Konsole

A.10 Klasse: ComparedNaturalModuleInformation

Kommentare und simple Getter/Setter werden nicht angezeigt.

1 <?php
2 class ComparedNaturalModuleInformation
3 {
4 const EMPTY_SIGN = 0;
5 const SIGN_OK = 1;
6 const SIGN_NEXT_STEP = 2;
7 const SIGN_CREATE = 3;
8 const SIGN_CREATE_AND_NEXT_STEP = 4;
9 const SIGN_ERROR = 5;
10

11 private $naturalModuleInformations = array();

12

13 public static function environments()

14 {
15 return array("ENTW", "SVNENTW", "QS", "PROD");
16 }
17

18 public static function signOrder()

19 {
20 return array( self :: SIGN_ERROR, self::SIGN_NEXT_STEP, self::SIGN_CREATE_AND_NEXT_STEP, self::
SIGN_CREATE, self::SIGN_OK);
21 }
22

23 public function __construct(array $naturalInformations)

24 {
25 $this−>allocateModulesToEnvironments($naturalInformations);

Stefan Macke xiii

 Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

26 $this−>allocateEmptyModulesToMissingEnvironments();
27 $this−>determineSourceSignsForAllEnvironments();
28 }
29

30 private function allocateModulesToEnvironments(array $naturalInformations)

31 {
32 foreach ($naturalInformations as $naturalInformation)
33 {
34 $env = $naturalInformation−>getEnvironmentName();
35 if (in_array($env, self :: environments()))
36 {
37 $this−>naturalModuleInformations[array_search($env, self::environments())] = $naturalInformation;
38 }
39 }
40 }
41

42 private function allocateEmptyModulesToMissingEnvironments()

43 {
44 if (array_key_exists(0, $this−>naturalModuleInformations))
45 {
46 $this−>naturalModuleInformations[0]−>setSourceSign(self::SIGN_OK);
47 }
48

49 for ($i = 0;$i < count(self :: environments());$i++)

50 {
51 if (! array_key_exists($i, $this−>naturalModuleInformations))
52 {
53 $environments = self::environments();
54 $this−>naturalModuleInformations[$i] = new EmptyNaturalModuleInformation($environments[$i]);
55 $this−>naturalModuleInformations[$i]−>setSourceSign(self::SIGN_CREATE);
56 }
57 }
58 }
59

60 public function determineSourceSignsForAllEnvironments()

61 {
62 for ($i = 1; $i < count(self :: environments()); $i++)
63 {
64 $currentInformation = $this−>naturalModuleInformations[$i];
65 $previousInformation = $this−>naturalModuleInformations[$i − 1];
66 if ($currentInformation−>getSourceSign() <> self::SIGN_CREATE)
67 {
68 if ($previousInformation−>getSourceSign() <> self::SIGN_CREATE)
69 {
70 if ($currentInformation−>getHash() <> $previousInformation−>getHash())
71 {
72 if ($currentInformation−>getSourceDate(’YmdHis’) > $previousInformation−>getSourceDate(’YmdHis’))
73 {
74 $currentInformation−>setSourceSign(self::SIGN_ERROR);
75 }

Stefan Macke xiv

 Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

76 else
77 {
78 $currentInformation−>setSourceSign(self::SIGN_NEXT_STEP);
79 }
80 }
81 else
82 {
83 $currentInformation−>setSourceSign(self::SIGN_OK);
84 }
85 }
86 else
87 {
88 $currentInformation−>setSourceSign(self::SIGN_ERROR);
89 }
90 }
91 elseif ($previousInformation−>getSourceSign() <> self::SIGN_CREATE && $previousInformation−>
getSourceSign() <> self::SIGN_CREATE_AND_NEXT_STEP)
92 {
93 $currentInformation−>setSourceSign(self::SIGN_CREATE_AND_NEXT_STEP);
94 }
95 }
96 }
97

98 private function containsSourceSign($sign)

99 {
100 foreach($this−>naturalModuleInformations as $information)
101 {
102 if ($information−>getSourceSign() == $sign)
103 {
104 return true;
105 }
106 }
107 return false ;
108 }
109

110 private function containsCatalogSign($sign)

111 {
112 foreach($this−>naturalModuleInformations as $information)
113 {
114 if ($information−>getCatalogSign() == $sign)
115 {
116 return true;
117 }
118 }
119 return false ;
120 }
121 }
122 ?>

Listing 2: Klasse: ComparedNaturalModuleInformation

Stefan Macke xv
Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler

A Anhang

A.11 Klassendiagramm

Klassendiagramme und weitere UML-Diagramme kann man auch direkt mit LATEX zeichnen, siehe
z. B. http://metauml.sourceforge.net/old/class-diagram.html.

Abbildung 11: Klassendiagramm

Stefan Macke xvi

Entwicklung von NatInfo
Webbasiertes Tool zur Unterstützung der Entwickler
A Anhang
A.12 Benutzerdokumentation
Ausschnitt aus der Benutzerdokumentation:
Symbol Bedeutung global
Alle Module weisen den gleichen Stand auf.
Es existieren keine Module (fachlich nicht
möglich).
Ein Modul muss durch das Übertragen von
der vorherigen Umgebung erstellt werden.
Auf einer vorherigen Umgebung gibt es ein
Modul, welches übertragen werden kann,
um das nächste zu aktualisieren.
Ein Modul auf einer Umgebung wurde ent-
gegen des Entwicklungsprozesses gespei-
chert.
Stefan Macke
Bedeutung einzeln
Das Modul ist auf dem gleichen Stand wie
das Modul auf der vorherigen Umgebung.
Weder auf der aktuellen noch auf der vor-
herigen Umgebung sind Module angelegt.
Es kann also auch nichts übertragen wer-
den.
Das Modul der vorherigen Umgebung kann
übertragen werden, auf dieser Umgebung
ist noch kein Modul vorhanden.
Das Modul der vorherigen Umgebung kann
übertragen werden um dieses zu aktualisie-
ren.
Das aktuelle Modul ist neuer als das Mo-
dul auf der vorherigen Umgebung oder die
vorherige Umgebung wurde übersprungen.
xvii