erstes echt großes Projekt

[Thomas]

Hey Leute!

ich hab viel Erfahrung mit PHP, AJAX und Webprogrammierung im Allgemeinen.
Meine Projekte beschränkten sich bis jetzt jedoch auf kleinere Projekte (Standard-Websites (dynamisch&statisch), kleine Onlineshops, etc.)

Ich beginn diesesmal jedoch mit nem echt großen Projekt (geschätzte Arbeitszeit ca. 300 Stunden. Deshalb die Frage, wie geh ich das am besten an???
Meine derzeitiger Projektplan sieht so aus, was würdet ihr noch ändern/hinzufügen um die (wichtige)Qualitätssicherung & Erweiterbarkeit zu gewährleisten?

Planungsphase:
 - Anforderungsanalyse (abgeschlossen)
 - Funktionen, FrontEnd- & Backend-GUi rudimentär planen (abgeschlossen)
 - serverseitiges Model planen (PHP, MySQL, Cronjobs, ...)(abgeschlossen)
 - AJAX-Model planen (abgeschlossen)

Umsetzungsphase:
 - Grundsystem programmieren
 - Module programmieren
 - GUI programmieren

Pre-Release-Tests:
 - Standardisierung (Code besser lesbar machen, HTML, JS validieren)
 - Hacking- & Hijacking-Tests
 - privatet Kurz-Dokumentation schreiben
 - Hilfedateien & Tutorials erstellen
 - Rechtskonformität und Lizenzen prüfen

Alpha-Tests starten:
 - 1-3 Leute testen
 - optimieren

Beta-Tests starten:
 - 5-10 Leute testen
 - Bug fixing

Releasen

Was würdet ihr ändern/hinzufügen?

danke
Thomas

[dedlfix]

echo $begrüßung;

Ich beginn diesesmal jedoch mit nem echt großen Projekt (geschätzte Arbeitszeit ca. 300 Stunden. Deshalb die Frage, wie geh ich das am besten an???

Ein Projekt benötigt immer mehr Zeit als veranschlagt. Ist dies bereits berücksichtigt, gilt der erste Satz trotzdem. Oder anders. 90% der Arbeit benötigt 90% der Zeit. Die Rest benötigt die anderen 90% der Zeit.

Pre-Release-Tests:

• Standardisierung (Code besser lesbar machen, HTML, JS validieren)

Das sollte von Anfang an geschehen. Hinterher ist keine Zeit oder Lust vorhanden, grundlegende Fehler auszubessern.

• Hacking- & Hijacking-Tests

Auch das muss von Anfang an berücksichtigt werden, um keine grundlegenden, schwer auszubessernde Lücken einzubauen.

• privatet Kurz-Dokumentation schreiben

Wenn das Projekt umfangreich ist, benötigt man die Dokumentation selbst, wenn man an einem lange nicht angefassten Teil Änderungen vornehmen möchte. Es sei denn, man hat ein so gutes Gedächtnis, dass man sich an alle Details erinnert, die zur jeweiligen Lösung geführt haben. Dann aber hat man am Ende vielleicht keine Zeit mehr, zu dokumentieren. Also am besten gleich die Dokumentation mitschreiben (phpdoc-Stil).

Möglich ist auch, zuerst die öffentlichen Schnittstellen (Funktions/Methodenköpfe) mit Beschreibung zu erstellen und dann erst die Inhalte (samt Programmkommentaren) hinzufügen.

• Hilfedateien & Tutorials erstellen

Lässt sich teilweise automatisch aus einer guten phpdoc-Dokumentation erstellen.

• Rechtskonformität und Lizenzen prüfen

Das sollte in der Planungsphase angesiedelt sein.

Alpha-Tests starten:
Beta-Tests starten:

Ist es ein Auftrag eines Kunden? Dann ist es vorteilhaft, ihn frühzeitig in den Fortschritt einzubinden. Nicht dass er andere Aufgabenstellung formuliert hat als er eigentlich haben will, oder du dich anderweitig mit dem Ergebnis von seinen Vorstellungen entfernst. Andererseits hilft im Zweifelsfall eine detaillierte Aufstellung dessen, was zu erbringen ist (Stichwort: Lasten- und Pflichtenheft).

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

Ich beginn diesesmal jedoch mit nem echt großen Projekt (geschätzte Arbeitszeit ca. 300 Stunden. Deshalb die Frage, wie geh ich das am besten an???

Ein Projekt benötigt immer mehr Zeit als veranschlagt. Ist dies bereits berücksichtigt, gilt der erste Satz trotzdem. Oder anders. 90% der Arbeit benötigt 90% der Zeit. Die Rest benötigt die anderen 90% der Zeit.

Diesen Erfahrungswert kann man gar nicht genug betonen.

Es gibt in der Softwareentwicklung Ansätze, die Zeitdauer eines Projekts greifbarer als nur "dauert länger als geplant" zu machen. Ein Ansatz dazu ist, die einzelnen Programmieraufgaben in so kleine Teile zu zerteilen, dass sie der ausführende Programmierer als nicht aufwendiger als zwei Tage einschätzt, und dann für alle Einzelaufgaben vom ausführenden Programmierer eine Zeitschätzung vorzunehmen. Der tatsächliche Zeitaufwand für die Erledigung der Aufgabe wird ebenfalls erfasst. Aufgrund von Erfahrungswerten aus vorherigen Projekten, oder mindestens aus den erledigten Aufgaben des laufenden Projekts ist ermittelbar, wie gut der Programmierer schätzen kann - und daraus kann man dann errechnen, wie wahrscheinlich es ist, dass das Projekt in X, Y oder Z Tagen fertig wird.

Pre-Release-Tests:

• Standardisierung (Code besser lesbar machen, HTML, JS validieren)

Das sollte von Anfang an geschehen. Hinterher ist keine Zeit oder Lust vorhanden, grundlegende Fehler auszubessern.

• Hacking- & Hijacking-Tests

Auch das muss von Anfang an berücksichtigt werden, um keine grundlegenden, schwer auszubessernde Lücken einzubauen.

Tests gehören nach meiner Ansicht ganz an den Anfang des Programmierens. Tests sind die zwingende Grundlage für gut funktionierende und einfach debugbare Software. Die Methode heißt "TDD" - Test-driven Design oder meinetwegen auch Test-driven Development.

Die Idee dahinter ist, dass man sich als allererstes einen Test schreibt, und dann erst den Programmcode, der diesen Test positiv erfüllt.

Man schreibt sich also einen Test, der eine neue Klasse instanziiert, und führt den Test aus. Der scheitert natürlich, weil man das Codefile mit der Klasse noch nicht geschrieben hat. Also schreibt man jetzt das Codefile mit der noch leeren Klasse, und erwartet, dass der Test jetzt funktioniert. Wenn ja, hat man alles richtig gemacht, wenn nein, lauert irgendwo schon ein dummer Fehler, den man korrigieren muss.

Dann schreibt man sich einen Test für den Aufruf der ersten Klassenmethode. Der scheitert natürlich auch, weil die Methode noch nicht existiert. Also: Methode in die Klasse reinschreiben, damit überhaupt was aufrufbar ist, und Test erneut ablaufen lassen. Klappt erwartungsgemäß alles, kann es weitergehen, ansonsten: Den Fehler suchen.

Die Methode hat natürlich nicht nur zu existieren, sondern soll aus Eingabedaten irgendwelche Ausgabedaten machen. Das kann man wieder in einer Testfunktion formulieren: Man ruft die Methode mit definierten Eingabedaten auf und formuliert auch, welche Ausgabedaten zurückkommen sollen, und lässt das Testframework vergleichen, ob das auch passiert. Den Test wieder durchlaufen lassen (er muss scheitern, weil die Methode noch nichts tut), dann den Methodencode schreiben, so dass der Test erfolgreich durchläuft, und das wieder verifizieren.

Wenn man diese Methode konsequent für alles anwendet, was man programmiert, erreicht man eine sehr hohe Programmqualität bzw. sehr wenige Bugs, außerdem dokumentieren die geschriebenen Tests automatisch, was der eigentliche Code tun soll, und man erhält bei späteren Veränderungen am Code auch sofort Feedback, wenn man irgendeine Funktionalität unabsichtlich zerstört hat, während man doch eigentlich nur etwas erweitern wollte. Ebenso kann man den Programmcode natürlich auch abgesichert durch die Tests beliebig umschreiben und verbessern und trotzdem sicher sein, dass sich am Ergebnis nichts ändert (aber natürlich nur, sofern man gute Tests geschrieben hat, die so wenig wie möglich Definitionslücken lassen für bislang undefiniertes Verhalten - und wenn man in so eine Lücke tappt, die dann einen Fehler verursacht, schreibt man dafür natürlich wieder einen Test, damit dieses Problem in Zukunft nie mehr auftritt).

• privatet Kurz-Dokumentation schreiben

Wenn das Projekt umfangreich ist, benötigt man die Dokumentation selbst, wenn man an einem lange nicht angefassten Teil Änderungen vornehmen möchte. Es sei denn, man hat ein so gutes Gedächtnis, dass man sich an alle Details erinnert, die zur jeweiligen Lösung geführt haben. Dann aber hat man am Ende vielleicht keine Zeit mehr, zu dokumentieren. Also am besten gleich die Dokumentation mitschreiben (phpdoc-Stil).

Möglich ist auch, zuerst die öffentlichen Schnittstellen (Funktions/Methodenköpfe) mit Beschreibung zu erstellen und dann erst die Inhalte (samt Programmkommentaren) hinzufügen.

Das TDD-Framework SimpleTest bietet z.B. als Funktionalität an, mit Mock-Objekten zu arbeiten, bei denen man im Prinzip nur den Methodennamen und die Parameter des Aufrufs spezifiziert und dann nur "künstlich" beschreibt, welcher Rückgabewert bei welchem Input auszuliefern ist. Die Mock-Objekte können dabei genau prüfen, ob sie mit den richtigen Parametern aufgerufen werden. Insgesamt ist das sehr hilfreich beim Testen komplexer Verzahnungen von Objekten.

• Rechtskonformität und Lizenzen prüfen

Das sollte in der Planungsphase angesiedelt sein.

Auf jeden Fall.

Alpha-Tests starten:
Beta-Tests starten:

Ist es ein Auftrag eines Kunden? Dann ist es vorteilhaft, ihn frühzeitig in den Fortschritt einzubinden. Nicht dass er andere Aufgabenstellung formuliert hat als er eigentlich haben will, oder du dich anderweitig mit dem Ergebnis von seinen Vorstellungen entfernst. Andererseits hilft im Zweifelsfall eine detaillierte Aufstellung dessen, was zu erbringen ist (Stichwort: Lasten- und Pflichtenheft).

Standard-Erfahrungswert: Das, was der Kunde bestellt, ist nicht das, was er tatsächlich haben will. Selbst wenn man es bis ins kleinste Detail in einem Lasten- und Pflichtenheft festlegt, von ihm unterschreiben lässt, und auch exakt so realisiert.

Die frühzeitige Mitwirkung des Kunden und die Flexibilität des Entwicklungsprozesses, auf geänderte Kundenwünsche und vor allem geänderte Kundenprioritäten reagieren zu können, ist eigentlich unerlässlich.

- Sven Rautenberg

[Thomas]

Pre-Release-Tests:

• Standardisierung (Code besser lesbar machen, HTML, JS validieren)
  Das sollte von Anfang an geschehen. Hinterher ist keine Zeit oder Lust vorhanden, grundlegende Fehler auszubessern.

Klar, aber am Schluss macht eine zweite Überprüfung doch Sinn ;)

• Hacking- & Hijacking-Tests
  Auch das muss von Anfang an berücksichtigt werden, um keine grundlegenden, schwer auszubessernde Lücken einzubauen.

Nö, am Anfang werden die Risiken berücksichtigt und in die Plannung einbezogen! Das gehört meiner Ansicht nach schon in die Modellbildung.
Aber Tests, ob durch tippfehler oder was auch immer noch Sicherheitslücken sind können doch auch nicht schaden?

• privatet Kurz-Dokumentation schreiben
  Wenn das Projekt umfangreich ist, benötigt man die Dokumentation selbst, wenn man an einem lange nicht angefassten Teil Änderungen vornehmen möchte. Es sei denn, man hat ein so gutes Gedächtnis, dass man sich an alle Details erinnert, die zur jeweiligen Lösung geführt haben. Dann aber hat man am Ende vielleicht keine Zeit mehr, zu dokumentieren. Also am besten gleich die Dokumentation mitschreiben (phpdoc-Stil).

Also ne Doc hab ich noch nie beim programmiern gebraucht, Kommantare mit Zusicherungen aber sehr wohl!

• Hilfedateien & Tutorials erstellen
  Lässt sich teilweise automatisch aus einer guten phpdoc-Dokumentation erstellen.

Hilfedateien sind für den Endnutzer, vornehmlich DAUs, da bringt keine phpdoc was^^

• Rechtskonformität und Lizenzen prüfen
  Das sollte in der Planungsphase angesiedelt sein.

Stimmt, da war ich zu Dumm für copy&paste^^

lg
Thomas

[dedlfix]

echo $begrüßung;

Pre-Release-Tests:

• Standardisierung (Code besser lesbar machen, HTML, JS validieren)
  Das sollte von Anfang an geschehen. Hinterher ist keine Zeit oder Lust vorhanden, grundlegende Fehler auszubessern.
  Klar, aber am Schluss macht eine zweite Überprüfung doch Sinn ;)

Das kann man so pauschal nicht beantworten. Sicher ist eine Qualitätskontrolle der Anwendung aus Anwendersicht und auch des Codes sinnvoll. Validität ist ein erstrebenswertes Ziel. Doch ist es auch nicht dramatisch, wenn "kleine Invaliditäten" keinen Einfluss auf das Ergebnis haben.

• Hacking- & Hijacking-Tests
  Auch das muss von Anfang an berücksichtigt werden, um keine grundlegenden, schwer auszubessernde Lücken einzubauen.
  Nö, am Anfang werden die Risiken berücksichtigt und in die Plannung einbezogen! Das gehört meiner Ansicht nach schon in die Modellbildung.
  Aber Tests, ob durch tippfehler oder was auch immer noch Sicherheitslücken sind können doch auch nicht schaden?

Die Frage ist, ob der Aufwand lohnt, einen nicht am Projekt beteiligten und daher unvoreingenommenen, guten und damit sicher nicht billigen Code-Qualitätskontrolleur drübersehen zu lassen. Oder ob man, wenn man sicherheitslückentechnisch auf aktuellem Wissensstand ist, für alle Möglichkeiten Testfälle erstellt und diese gegen den Code laufen lässt. Mit anderen Worten: eine Abwägung von Aufwand, Nutzen und Restrisiko.

Also ne Doc hab ich noch nie beim programmiern gebraucht, Kommantare mit Zusicherungen aber sehr wohl!

Mein Gedächtnis ist nicht so gut, dass ich mir alle vorhandenen Funktionen und Methoden sowie deren Parameter nebst möglichen Werten merken kann. Selbst dann nicht, wenn ich sie (irgendwann mal) selbst geschrieben habe. Da lobe ich mir phpdoc-Syntax-Dokumentation, die von der IDE geparst und mir beim Tippen als Hilfe eingeblendet werden kann.

• Hilfedateien & Tutorials erstellen
  Lässt sich teilweise automatisch aus einer guten phpdoc-Dokumentation erstellen.
  Hilfedateien sind für den Endnutzer, vornehmlich DAUs, da bringt keine phpdoc was^^

Ok, akzeptiert. Siehe dazu auch https://forum.selfhtml.org/?t=180384&m=1191777

echo "$verabschiedung $name";

[Daniel Thoma]

Hallo Thomas,

Ich beginn diesesmal jedoch mit nem echt großen Projekt (geschätzte Arbeitszeit ca. 300 Stunden. Deshalb die Frage, wie geh ich das am besten an???

Also so zwei Monate Arbeit alleine? Das ist eigentlich noch ziemlich überschaubar, wenn Du alleine bist, hast Du zudem keine internen Kommunikationsprobleme, was schon ziemlich vieles vereinfacht. Wenn man mit einem Team arbeitet, besteht viel stärker die Gefahr, dass jeder einen Teil zusammenwurstelt und man am Schluss feststellt, dass nichts zusammenpasst.
Aber auch wenn Du alleine arbeitest, ist vermutlich die größte Gefahr, dass Du alles sauber nach Deinem Plan abarbeitest und am Schluss merkst, dass irgendetwas wegen eines grundlegenden Konzeptionsfehlers ganz am Anfang nicht tun kann, und Du keine Zeit mehr hast, das noch zu retten.
Dein Plan sieht ja ein Grundsystem vor. Ich würde zunächst dieses Grundsystem (natürlich unter Berücksichtigung auch der anderen Anforderungen) sauber planen, implementieren und zu testen. Wenn das alles klappt, weißt Du schonmal, dass Du ein funktionierendes System hast, auch wenn es Dir vielleicht nicht gelingt, alle Anforderungen zu realisieren.
Dann würde ich erst anfangen, schrittweise die GUI und weiter Module hinzuzufügen. Dabei kannst Du laufend testen, dass das System soweit auch funktioniert. Wenn ein gewisser Funktionsumfang realisiert ist, hast Du so auch schonmal die Möglichkeit, die Anwendung dem Kunden zu zeigen. Irgend etwas hat er sich dann wahrscheinlich anders vorgestellt und Du hast noch Zeit, umzusteuern.

Dedlfix hat gemeint, man könne die Dokumentation aus der Quelltextdokumentation generieren. Für die Bedienungsanleitung (und die scheinst Du zu meinen) gilt das aber natürlich nicht. Quelltextdokumentationen werden für Entwickler geschrieben und sind zudem gemäß dem internen Aufbau der Anwendung organisiert.

Grüße

Daniel

[Thomas]

Die 200 Stunden beziehen sich nur auf System mit Modulen (ohne GUI, das macht wer anderer).

Nö, ich hab schon Dokumentation gemeint!
(Soll etwas ausführlicher als nur eine Zusammenfassung der Klassenbeschreibungen sein)
V.a. da vermutlich alle zwei Monate neue Module hinzukommen werden...

lg
Roland

[dedlfix]

echo $begrüßung;

Nö, ich hab schon Dokumentation gemeint!
(Soll etwas ausführlicher als nur eine Zusammenfassung der Klassenbeschreibungen sein)
V.a. da vermutlich alle zwei Monate neue Module hinzukommen werden...

Eine vollständige funktionsbeschreibende Dokumentation für Programmierer fände ich mit phpdoc-Syntax im Code notiert (und gegebenenfalls mit Tools daraus extrahiert) am sinnvollsten. Man hat damit alle Quellen an einem Fleck und die Gefahr, die Dokumentation anzupassen zu vergessen ist geringer, weil einem beim Ändern der Code-Datei die Dokumentationskommentare ins Auge fallen.

Eine (zusätzliche) Anleitung im Tutorial-Stil hingegen ist sicher in einem Extra-Dokument besser aufgehoben. Man muss da ja vielleicht nicht jedes Detail des Codes und jeden Parameter einer Funktion beschreiben und man hat auch andere Möglichkeiten, die Ausgabe zu formatieren.

Ebenso finde ich es sinnvoll, eine Bedienungsanleitung für den Anwender in einem eigenständigen Dokument unterzubringen.

echo "$verabschiedung $name";

[Multi]

Mahlzeit,

Nö, ich hab schon Dokumentation gemeint!
(Soll etwas ausführlicher als nur eine Zusammenfassung der Klassenbeschreibungen sein)

Bei grossen Projekten (und da rede ich nicht von Projekten mit 200 Stundne, das fällt noch unter klein) wird erst ein Fachkonzept entwickelt, anschliessend ein Fachfeinkonzept, was die P>unkte im Fachkonzept weiter auffächert.
Aufgrund dieses Fachkonzeptes wird ein DV-Konzept erstellt, was im Endeffekt die komplette Software im Klartext ist. Du musst dieses dann nur noch in Programmcode "übersetzen".

V.a. da vermutlich alle zwei Monate neue Module hinzukommen werden...

In dem Fall ist vorallem die Schnittstellendokumentation wichtig. Die muss so exakt sein, dass jeder Programmierer ohne jegliche Vorkenntnisse in kürzester Zeit damit umgehen kann.

Dinge wie PHPDoc sind dabei maximal eine Ergänzung aber kein Ersatz für eine Vorabdokumentation.

Also je nachdem, wie die komplette Grösse des Projektes sein wird, fällt die Doku aus. Umso langfristiger das Projekt, umso ausführlicher muss die Doku sein. Plane zwischen 10 und 20% deiner Projektdauer für die Dokumentation ein, dieser Wert ich bei grossen Projekten üblich, da in den meisten Fällen mehrere Personen mit Dokumentation und deren Absegnung beschäftigt sind.