Dokumentation und Kontrollen während eines Projektes

[blackdevile]

Hallo zusammen,

ich suche schon ne ganze weile kann aber im Internet keine 100%ige (90%ig würde auch noch reichen) genaue aussage finden über die Dokumentationspflicht in einem Programmier-Projekt.

Genauer gesagt habe ich folgende "noch" ungeklärten Fragen.

1) Wie muss Quellcode Dokumentiert werden (Im Programm und/oder für den Kunden)

1a) Wie weit muss der Quellcode dabei erklärt werden?

1b) Wie muss die beschreibung von Funktionen (intern/extern) erklärt und Definiert werden

1c) Wie soll die beschreibung von Funktionen erklärt werden (nur wenn von 1b abweichend)

1d) Dokumentationtne über vorhandene Funktionen allgemein, was für Funktionen gibt es (wie "beweise" ich dem Kunden das kein z.B. Trojaner einprogrammiert wurde?)

2) Was für Versionskontrollen der Software muss ich erstellen?

3) Was für Kontrollpunkte gibt es während der Programmierung? (Also im ablauf der Programmierung wann muss/ wann soll ich den Kunden ein Zwischenergebniss Präsentieren damit ich am Ende nicht mit einem Programm dastehe was gänzlich anders ist als der Kunde sich das vorgestellt hat?

Ich werde mich weiter im Internte schlau machen und die Ergebnisse hier Posten. Habe bei google und mit der SUFU nix gefunden was mir ausreichend passende Aussage geben würde.

Danke für eure Gedult+Hilfe schonmal im vorraus

greetz

chris

[robotto7831a]

Hallo!

Zu 1: Soweit mir bekannt ist, gibt es dafür keine ISO oder DIN Norm. Jedes Unternehmen dokumentiert mehr oder weniger im Quellcode.

Zu 2: Versteh ich nicht. Ich kenne ein CVS. Meinst Du das?

Zu 3: Dafür gibt es das Pflichtenheft. Du machst das was darin vereinbart ist und mehr nicht.

Frank

[blackdevile]

@robotto7831a danke für die Flinke antwort

und fürs verschieben -.- wusste nicht wohin damit.

zu 2) damit meine ich z.b.

Vers. 1.0 Bilder können angezeigt werden

Vers. 1.1 Bilder können gedreht werden

damit der Kunde eine übersicht hat wann was passiert ist, bzw. MUSS sowas sein, oder ist das nur nett weil ich den Kunden toll finde, oder kann ich sowas ganz lassen?

Mit CVS trifft es das schon ganz gut, nur ist halt die Frage was Muss/soll ich machen.

Zu 3) d.h. wenn drinne steht "Kontrolle wenn so und soviel erledigt ist" mach ich das, wenn nicht kann ich auch sagen, hier fertiges Produkt gib mir das Geld und fertig?

Weil ich meine es wird zwar im Lastenheft schreibt der Kunde zwar was er will, aber bekanntlich hat selbst eine Münze schon zwei Seiten, so kann ich auch Problem gänzlich anders lösen als der Kunde sich das ursprünglich vielleicht Gedacht hat.

Deswegen die frage zu den Kontrollpunkten, nicht das ich eine Lösung entwickle die der Kunde so nicht wollte.

Muss der Kunde das Produkt dann abnehmen wenn es seine Spezifikationen erfüllt hat, selbst wenn es das ganze anders löst als gedacht?

greetz

chris

[robotto7831a]

Das Pflichtenheft ist die Konkretisierung des Lastenheftes. Der Kunde schreibt das Lastenheft und Kunde und Auftragnehmer entwickeln daraus das Pflichtenheft und das wird Vertragsbestandteil. Und wenn im Pflichtenheft nicht steht, dass das Produkt einen Salto vollbringen kann, dann hat er auch später keinen Anspruch darauf. Dann ist es eine Weiterentwicklung und ein neues Teilprojekt.

Wenn im Vertrag nicht vereinbart ist, dass es diese und jene Meilensteine gibt und sich dann alle treffen und auf das Produkt schauen dann entwickelst Du die Software halt laut Pflichtenheft und gibst dem Kunden dann das fertige Produkt.

Frank

[Karl Nickel]

1) Wie muss Quellcode Dokumentiert werden (Im Programm und/oder für den Kunden)

Wie robotto7831a bereits schrieb gibt es keine Vorgaben. Ein guter Entwickler dokumentiert seinen Code aber immer. Damit tut er sich selbst den größten Gefallen.

1a) Wie weit muss der Quellcode dabei erklärt werden?

Quellcode ist idealerweise selbsterklärend und nachvollziehbar. Manchmal geht das nicht immer, dann schreibt man zu einzelnen Code-Blöcken ein kurzes Inline-Kommentar, was man gerade treibt.

1b) Wie muss die beschreibung von Funktionen (intern/extern) erklärt und Definiert werden

Auch hier gibt es keine Vorgaben. Meistens werden Funktionen/Methoden ausführlich dokumentiert. Quellcode selbst wird an komplizierteren Stellen mit Inline-Kommentaren versehen

1c) Wie soll die beschreibung von Funktionen erklärt werden (nur wenn von 1b abweichend)

Javadoc bietet sich dafür zum Beispiel an. Es gibt zig Portierungen für andere Programmiersprachen.

1d) Dokumentationtne über vorhandene Funktionen allgemein, was für Funktionen gibt es (wie "beweise" ich dem Kunden das kein z.B. Trojaner einprogrammiert wurde?)

Naja, idealerweise werden Schnittstellen und Funktionsweise der Software vertraglich geregelt. Je nachdem, wie sicherheitskritisch die Software ist, kann es auch Haftungsklauseln für den Entwickler geben. Manche Kunden sichten auch den Quellcode. Das hängt ganz vom Projekt/Kunden ab und kann man pauschal nur schlecht beantworten. Im Streitfall geht's eh zum Anwalt...

2) Was für Versionskontrollen der Software muss ich erstellen?

Guckst du HIER. Solche Systeme haben vor allem den Vorteil, dass du Änderungen auch wieder problemlos rückgängig machen kannst. Ist sehr praktisch, wenn man wirklich mal etwas verzockt hat. So gibt's meistens keinen großen Ärger

3) Was für Kontrollpunkte gibt es während der Programmierung? (Also im ablauf der Programmierung wann muss/ wann soll ich den Kunden ein Zwischenergebniss Präsentieren damit ich am Ende nicht mit einem Programm dastehe was gänzlich anders ist als der Kunde sich das vorgestellt hat?

Das hängt auch wieder vom Kunden/Projekt ab. Das ganze steht unter dem Oberbegriff agile Softwareentwicklung. Dort gibt es verschiedene Ansätze, wie man Softwareentwicklung "besser" macht. Mein persönlicher Favorit ist Scrum. Wir treffen unseren Kunden nach jedem Sprint und präsentieren ihm die erzielten Ergebnisse bzw. vorher besprochenen Features. Ein Sprint dauert meist 2-4 Wochen. BTW kann man froh sein, wenn man die Möglichkeit hat, solche agile Methoden benutzen zu dürfen. Meistens sieht's ja eher so aus: Kunde ruft an, Programmierer setzt sofort um. Auf lange Zeit ist da der Burnout sicher...

Weil ich meine es wird zwar im Lastenheft schreibt der Kunde zwar was er will, aber bekanntlich hat selbst eine Münze schon zwei Seiten, so kann ich auch Problem gänzlich anders lösen als der Kunde sich das ursprünglich vielleicht Gedacht hat.

Deswegen die frage zu den Kontrollpunkten, nicht das ich eine Lösung entwickle die der Kunde so nicht wollte.

Sollten es Probleme sein, die ein ganzes Projekt stoppen können, müssen Lösungen eventuell überdacht werden. Ansonsten gilt: Der Kunde hat immer recht und bekommt das, für was er bezahlt hat. Mach dir also nicht mehr Arbeit, als nötig ist. Notiere eventuelle Probleme und besprich sie mit dem Kunden. Auftretende Probleme (=Änderungswünsche) sind das Geld von morgen

Muss der Kunde das Produkt dann abnehmen wenn es seine Spezifikationen erfüllt hat, selbst wenn es das ganze anders löst als gedacht?

Ja, vor allem dann, wenn's vertraglich so festgelegt wurde. Daher ist es sehr sehr wichtig, immer ein Pflichten- und Lastenheft zu haben sowie das Projekt ausführlich zu dokumentieren...

[IJK]

Einiges über "allgemein gültige" Dokumentation und sogar Normen findest du im Wiki unter "Technische Dokumentation".

Grundlegend gilt: man dokumentiert so viel wie nötig und so wenig wie möglich

Zu einem Programm gehört möglicherdings

- Inlinedoku

- Schnittstellendoku

- Installationshinweise / -anweisungen

- Systemdoku mit Aufrufbeispielen

- Betriebshandbuch mit Fehlermeldungen

- Anwenderhandbuch mit von allem etwas

Ansonsten: einfach mal beim Kollegen spicken...