Pflichtenheft Ja oder Nein?

[l0rDi]

Hallo!

Ich habe Winterprüfung und frage mich bei meinem Projekt zur Zeit, ob es Sinn macht ein Pflichtenheft zu erstellen.

Mein Projekt ist eine Machbarkeitsstudie inkl. prototypischer Umsetzung der Migration einer Schnittstelle von Forté nach Java.

Ich verstehe ein Pflichtenheft als "gemeinsammen Nenner" zwischen Auftraggeber und dem, der es Umsetzt indem haarklein beschrieben wird, was wie wo gemacht wird, damit es zu keinen Unstimmigkeiten mehr kommen kann.

Da ich jedoch nur Prüfen soll, ob und wie eine Migration dieser Schnittstelle nach Java überhaupt möglich ist, inkl. einer prototypischen Umsetzung in einem kleinem Programm zu Demonstrationszwecken, entfällt der Diskussionsbedarf und somit meines Erachtens auch der Sinn und Zweck des Pflichtenhefts.

Mir ist schon zu Anfang bekannt was genau die migrierte Software leisten muss. Das Aussehen der Prototypanwendung ist irrelevant und ihre abzubildenden Funktionen sind durch die Schnittstellenparameter auch abgesteckt.

Der Großteil des Projekts dreht sich darum Lösungen für das Problem zu finden, diese Lösungen zu bewerten und eine dieser Lösungen im Prototyp zu verwenden.

Nun bin ich aber unsicher ob ich nicht doch ein "kleines" Pflichtenheft erstellen soll, indem ich Haarklein festhalte, wie ich welche Klasse der neuen Schnittstelle umgesetzt habe.

Gehören in solch ein Pflichtenheft eigentlich auch Aktivitätsdiagramme und Geschäftsprozessabbildungen rein oder das weiterhin als Anhang zur Projektdokumentation belassen?

Ich bin übrigens FIAE und bei der IHK Karlsruhe ^^

Danke im Voraus!

[developer]

Hallo,

vieleicht wäre es dann angebrachter, dies unter das Sollkonzept zusammen zu fassen. Mit einer Ist-Analyse und einem Soll-Konzept kannst du eigentlich nichts verkehrt machen. Dort fasst du dann, ähnlich dem Pflichtenheft, zusammen, wie dein Projekt/Anwendung aussehen soll, wenn's fertig ist. Kurz gesagt, das erwartete Ergebnis. Dies brauchst du dann nicht haarklein darzustellen.

Größere Diagramme u.ä. gehören mit einem Verweis an der entsprechenden Stelle in die Anlage.

[CyberDemon]

Eigentlich gehört zu jedem Projekt auch ein Pflichtenheft.

Ich habe es so gemacht, wie Developer es geschrieben hat. Eine ausführliche IST - Analyse und ein ebenso ausführliches SOLL - Konzept. Dazu noch den Hinweis, dass in Absprache mit dem betr. Projektbetreuer auf ein Pflichtenheft verzichtet wird.

Die Prüfer haben nicht danach gefragt und es wurden auch keine Punkte abgezogen.

[l0rDi]

Mein Ist- und Soll-Konzept deckt das eigentlich alles schon vollkommen ab, werde dann auf ein PH verzichten, da es von der Firma auch nicht benötigt wird.

[timmi-bonn]

Ich habe Winterprüfung und frage mich bei meinem Projekt zur Zeit, ob es Sinn macht ein Pflichtenheft zu erstellen.

Ob Du es nun Pflichtenheft, Lastenheft oder Fachkonzept nennst, das ist egal; fast in jedem PMS werden diese Begriffe anders benutzt.

Aber inhaltlich wirst Du darum wohl kaum herum kommen.

Mal ganz abgesehen davon, dass Du beim Erstellen eines sauberen Test-Konzeptes im Prinzip ohne DV-Konzept gar nicht auskommen kannst. Falls Du es zu diesem Zeitpunkt noch nicht hattest, dann erstellst Du es hier (evtl. implizit) sowieso. Und zum Erstellen des DV-Konzeptes ist das Fachkonzept die Grundlage. ...Und das wird - nach der reinen Lehre - halt aus dem Pflichtenheft (oder dem Lastenheft) erstellt.

gruss, timmi

[l0rDi]

Hi und danke für die Hinweise!

Ich schreib mal meine bisherigen Projektinhalte grob als Übersicht hier rein, mich würde interessieren, was ihr für noch wichtig erachtet.

Projektdoku:

Einleitung

--> Problemstellung (Was ist das Problem, wieso gibt es dieses Projekt?)

--> Einbindung in die Entwicklung (Was ist der Projektauftrag, was soll gemacht werden?)

--> Projektumfeld (In welchem Rahmen wird das Projekt durchgeführt? Ist es Teil eines Gesamtkonzepts?)

Projektaufgliederung

--> Projektphasen

(Unterteilung des Projekts in 4 Phasen: Anforderungs- und Ist-Analyse; Design und Konzeption; Prototyp; Dokumentation)

--> Zeitlicher Ablauf inkl. Aufwandtsschätzung und Phasenbeschreibung

Ausgangssituation

--> Anforderungsanalyse (Welche Anforderungen werden gestellt?)

--> Ist-Analyse (Wie sind diese Anforderungen zur Zeit umgesetzt?)

--> Soll-Analysie (Wie sollen die Anfoderungen in Zukunft umgesetzt sein?)

Konzeption und Umsetzung

--> Aktivitäten identifizieren (identifizieren der Anwendungsfälle, festhalten in einem fachlichen Anwendungsfalldiagramm und pro Anwendungsfall ein UML-Aktivitätsdiagramm) --> Diagramme als Anhang im Analysedokument

--> Entscheidungsfindung (Welche zur Auswahl stehende Lösungsmöglichkeit ist nach unseren definierten Kriterien die beste (Produktvergleich inkl. Entscheidungsmatrix)) --> im DV-Konzept

Prototypische Umsetzung

--> Zusammenfassung der an die Umsetzung gestellten Anforderungen, kurze Beschreibung wie es Umgesetzt wurde

--> Verweis auf DV-Konzept (im DV-Konzept stehen die verwendeten Methoden inkl. Quellcodeausschnitte und Beschreibung der Klassenfunktionalitäten)

Fazit

--> Tatsächlich benötigte Arbeitszeit

--> Projektresumee (Erklärung, dass die Projektziele erreicht werden konnten, und eine Empfehlung zur weiteren Verwendung der vorgestellten Lösung)

Glossar

--> Fach- und Fremdworterklärung

Referenzen

--> andersweitig verwendete Dokumentationen, nicht selbst erstellt.

Meint ihr das Reicht?

Also die Projektdoku (Auflistung der Prozessschritte und Beschreibung sowie deren Ergebnis, Zeitplanung, Fazit und Glossar) nimmt im Moment 12 Seiten ein.

Die Entscheidungstreffung und DV-Konzept 11 Seiten und das Dokument mit den UML-Diagrammen 21 Seiten.

Danke für Eure Zeit!