Pflichtenheft als Abschlussprojekt

Pflichtenheft als Abschlussprojekt

Laut Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik §15, Abs. 2 ist es möglich, als Abschlussprojekt zum Fachinformatiker Anwendungsentwicklung anstatt eines „Programmierprojekts“ auch ein reines Pflichtenheft – quasi als Vorlage für die konkrete Programmierung – zu erstellen:

Hierfür kommt insbesondere eine der nachfolgenden Aufgaben in Betracht:
1. in der Fachrichtung Anwendungsentwicklung in insgesamt höchstens 70 Stunden für die Projektarbeit einschließlich Dokumentation:
a) Erstellen oder Anpassen eines Softwareproduktes, einschließlich Planung, Kalkulation, Realisation und Testen,
b) Entwickeln eines Pflichtenheftes, einschließlich Analyse kundenspezifischer Anforderungen, Schnittstellenbetrachtung und Planung der Einführung;

Aber ist das auch sinnvoll?

Softwareentwickler und Programmierer

Der Ausbildungsberuf heißt Anwendungsentwickler und nicht Programmierer. Aus gutem Grund. Die Azubis sollen nicht nur lernen zu programmieren, sondern auch komplexe Anwendungen zu planen und methodisch zu entwickeln. Wir bilden keine „Codeaffen“ aus, sondern Softwareentwickler/-innen, die Anforderungen aufnehmen und bewerten, Architekturen entwerfen, Programmiersprachen auswählen, Wirtschaftlichkeitsprüfungen durchführen und letztlich natürlich auch ein wenig programmieren können.

Die Erstellung eines komplexen Pflichtenhefts für eine umfangreiche Software passt also sehr gut zum Berufsbild und ist in keinster Weise „minderwertig“ im Vergleich zur Programmierung einer Anwendung als Abschlussprojekt.

In der Praxis

Ich bin nicht repräsentativ für alle Prüfer in Deutschland, aber ich habe in meinen Jahren als Prüfer bislang kein einziges reines „Theorieprojekt“ gesehen. Ich würde also einfach mal vermuten, dass diese Projekte nicht allzu oft vorkommen. Das heißt nicht, dass die Pflichtenheft-Projekte schlechter sind. Vermutlich möchten die meisten angehenden Anwendungsentwickler halt lieber programmieren als Anforderungen zu dokumentieren und Diagramme zu zeichnen. Und das ist auch völlig ok. Wenn sich für dein Projekt aber eine Implementierung nicht anbietet oder du lieber die Anforderungen definierst, anstatt sie selbst umzusetzen, dann ist ein Pflichtenheft eine gute Wahl für dich. Du solltest allerdings auf ein paar Punkte achten.

Worauf du achten solltest

Zur Themenfindung für das Abschlussprojekt habe ich schon eine ganze Podcast-Episode aufgenommen. Ein Punkt von vielen ist, dass das Projekt sich gut für eine methodische Entwicklung eignen sollte. Du solltest also die üblichen Verfahren und Techniken zur Softwareentwicklung anwenden und vor allem auch dokumentieren können. Denn darauf basiert deine Note für die Projektdokumentation.

Das ist bei einem reinen Theorieprojekt meiner Meinung nach noch viel wichtiger. Da zentrale Artefakte deiner Projektdokumentation „fehlen“ werden, müssen die anderen umso aussagekräftiger und „besser“ sein. Hier ist eine kleine Liste einiger Inhalte, die bei einem Pflichtenheft nicht in der Dokumentation enthalten sein werden, da es halt kein fertiges Produkt gibt:

  • Quelltext
  • Screenshots der Oberflächen
  • Benutzerdokumentation
  • Entwicklerdokumentation
  • Testprotokolle
  • Abnahmeprotokolle

Diese „fehlenden“ Inhalte gilt es nun zu kompensieren, um die verfügbare Seitenzahl auszunutzen und das volle Spektrum deiner Fähigkeiten zu zeigen. Es wird also eine intensive Analyse- und Entwurfsphase geben, die du mit allen geeigneten Mitteln der Softwareentwicklung dokumentieren musst. Insbesondere fallen mir dazu folgende Artefakte ein:

  • Use-Cases
  • Prozessabläufe (Ist und Soll), z.B. mit EPK, Aktivitätsdiagramm
  • geplante Algorithmen, z.B. mit Sequenzdiagramm, Pseudocode oder PAP
  • Oberflächenentwürfe (Mockups)
  • Qualitätskriterien
  • Testfallkatalog
  • Anforderungen, z.B. als User Stories
  • Lasten- und natürlich das Pflichtenheft selbst
  • Architekturentwurf, z.B. als Komponenten- oder Klassendiagramm
  • Feinentwurf, z.B. als Klassen- oder Zustandsdiagramm
  • Datenmodellierung mit ERM und/oder Tabellenmodell
  • Planung des Deployments, z.B. mit Verteilungsdiagramm
  • Planung der Benutzerschulung und der Dokumentation
  • Wirtschaftlichkeitsbetrachtung mit Amortisationsrechnung

Mehr theoretische Tiefe

Vielen „normalen“ Projektdokumentationen merkt man den wenigen verfügbaren Platz an. Artefakte wie Lasten- und Pflichtenheft werden nur in Auszügen angehängt oder ganz weggelassen, weil insgesamt so viel zu zeigen ist. Allein Screenshots nehmen z.B. mindestens eine ganze Seite ein (wenn man sie lesbar darstellen will). Bei der Erstellung eines Pflichtenhefts fallen einige dieser zeitintensiven Aufgaben weg. Die meisten Projektarbeiten, die ich gesehen habe, bestehen z.B. zu über 50% aus der Implementierungsphase. Diese Phase „produziert“ aber letztlich nur wenige dokumentierbare Artefakte im Vergleich zu den restlichen Projektphasen, z.B. Quelltextauszüge und Screenshots der Anwendung.

Durch den Fokus auf den Entwurf der Anwendung bei einem Nicht-Programmierprojekt kann den einzelnen Artefakten viel mehr Aufmerksamkeit gewidmet werden und sie erhalten einen höheren Stellenwert in der Projektdokumentation. Bei Programmierprojekten wird häufig „noch schnell“ ein Diagramm gemalt, weil das ja wichtig ist. Ich vermute aber, dass viele Projekte einfach runterprogrammiert und nicht methodisch entwickelt werden. Dementsprechend passen nachher die Diagramme auch nicht zur Implementierung oder sie wirken einfach fehl am Platze. Das kann bei einem Pflichtenheft-Projekt nicht passieren. Hier liegt der Fokus des gesamten Projekts genau auf der Erstellung dieser Artefakte.

Dieses Umstands solltest du dir bei der Wahl für ein „Theorieprojekt“ bewusst sein. Du wirst intensiver und einfach auch länger mit der Modellierung verbringen und Wert auf korrekte und passende Artefakte legen müssen.

Fazit

Ein gutes Pflichtenheft schreibt sich nicht von selbst und erfordert viele zentrale Kenntnisse eines Anwendungsentwicklers, die auch bei einem „richtigen“ Projekt mit lauffähiger Software benötigt werden. Durch die deutlich längere Entwurfsphase kannst du dich aber viel intensiver mit ihnen auseinandersetzen. Ein Pflichtenheft als Abschlussprojekt ist also absolut sinnvoll und mehr als nur ausreichend. Einige wenige Artefakte wie Quellcode und Screenshots können logischerweise nicht in der Projektdokumentation enthalten sein, aber viele andere Inhalte sind genauso gut – oder aufgrund der längeren Entwurfsphase sogar noch besser – unterzubringen.


Hast du als Abschlussprojekt ein „richtiges“ Projekt gemacht oder „nur“ ein Pflichtenheft erstellt? Kennst du Projektarbeiten, die ausschließlich die Theorie behandeln? Was ist deine Meinung dazu?

Weitere Infos zur Projektdokumentation

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.

Checkliste für die Projektdokumentation

2 thoughts on “Pflichtenheft als Abschlussprojekt

  1. Hallo,

    ich hätte zu diesem Thema noch eine Frage. Wenn ich ein Pflichtenheft als Abschlussprojekt abgeben möchte, muss ich dann im Projektantrag auch die Zeit nur für die Erstellung des Pflichtenheftes extra angeben? Bei „normalen“ Projekten ist es ja so, dass die Zeit für die Erstellung der Projektdokumentation extra im Projektantrag angeben werden muss (ca. 10% der Projektgesamtdauer). Da die Erstellung eines Pflichtenheftes hier ja quasi das Projekt an sich ist, bin ich mir da nicht ganz sicher, ob die Zeit noch zusätzlich angeben werden muss? Vielen Dank für die Antwort.

    Patrick

  2. Ob die Zeit für die Projektdoku zur Projektzeit zählt, ist keineswegs klar geregelt! Siehe Ist die Projektdokumentation Teil der Bearbeitungszeit des IHK-Abschlussprojekts?

    Aber davon abgesehen: Du musst natürlich die Ergebnisse deiner Analyse- und Entwurfsphase in das physische Pflichtenheft gießen, da du ja nichts programmierst. Also musst du auch entsprechend (viel) Zeit dafür vorsehen. Anstatt 3h für ein „Standard-Pflichtenheft“ kannst du also z.B. 20h einplanen, da du ja ein umfangreicheres Dokument erstellst.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax