[Artemis]

Da ich bei einem Projekt meistens einfach anfange loszuprogrammieren, ist es fast immer so, dass ich nach kurzer Zeit die Lust verliere, weil mir das ganze irgendwie sinnlos vorkommt.

Deshalb wollte ich einfach mal fragen, wie ich am besten an ein Projekt (in dem Fall Website) herangehe.

• Brauche ich ein "Aufgabenheft", oder reicht es, wenn ich das im Kopf habe?
• Womit soll ich bei der Durchführung anfangen? Front-End, also HTML-Ausgabe, oder Design der Seite oder doch als erstes mit dem Back-End, also dem Admin-Kontrollzentrum.
• Wie viele Gedanken muss ich mir vorher machen? Soll ich einfach nur das Konzept im Kopf haben, oder ist es besser wenn ich alles durchgeplant und aufgeschrieben habe. (Welche MySQL-Tabellen, mit welchen Feldern, welche Klassen wofür benutzen)

Ich hoffe ihr könnt mir aus dem Tal der Verzweiflung heraushelfen.

[Ben]

Hilft dir das?
[Grundlagen] Entwicklung eines Projektkonzeptes

[Chr!s]

Du könntest dir das durchaus gelungene Tutorial von WarrenFaith mal ansehn:
http://forum.developers-guide.net/showthread.php?t=623

// edit
Hm oh da war wohl etwas zu langsam.. =)

[Artemis]

Hey, danke für den Link.

[Basti]

Hi.

Zitat von Artemis

Da ich bei einem Projekt meistens einfach anfange loszuprogrammieren, ist es fast immer so, dass ich nach kurzer Zeit die Lust verliere, weil mir das ganze irgendwie sinnlos vorkommt.

Woran liegts? Überschätzt? Verzettelt? Kein Ziel definiert? Kein Durchhaltevermögen? Neue, interessantere Ziele gefunden?

• Brauche ich ein "Aufgabenheft", oder reicht es, wenn ich das im Kopf habe?

Nein, scheibs auf! Sehr ausführlich. Anders bekommst du keinen detailierten Überblick über den Umfang und hast damit ja auch keine Entscheidungsgrundlage, ob du das Projekt angehen kannst/willst oder nicht. Wichtig vor allem auch: Damit hast du klar, wann das Projekt beendet ist. Ein Projekt ist u.A. definiert durch einen begrenzten zeitlichen Rahmen.

Wenn du dir den nicht setzt ... dann wirst du nie fertig und das kann frustrieren. Das heißt nicht, dass deine Website danach nicht weiterentwickelt wird etc., aber das Projekt ist fertig, geschafft und das ist ... ziemlich wichtig. *g

Außerdem ist ein Lastenheft/Pflichtenheft eine gute Grundlage für alles weitere. Egal, obs danach losgeht, zu recherchieren, welche Anwendungen den Anforderungen nahe kommen (dann kannst du die Anforderungen einfach ablesen und mit den gebotenen Features vergleichen) oder obs an den Entwurf geht (die Objekte leiten sich z.B. aus den zu speichernden Daten ab etc.), oder ob du z.B. ein Framework benutzt (dann kannst du das Lastenheft im Optimalfall einfach in das Framework kopieren und hast damit schonmal das Grundgerüst).

Schreib aber nicht nur die zu speichernden Daten und die Funkionen auf, sondern auch Qualitätskriterien (Tests etc.), Leistung (Performance, Skaliebarkeit), etc. Und auch deine Ziele würde ich schriftlich fixieren.

Wenn noch nicht klar ist, wohin es gehen soll, dann mach erstmal eine grobe Vision - so klar wie möglich - und definiere dann erstmal ein kleines Projekt, das eben nur einen kleinen Teil umsetzt. Für den Entwurf musst du in etwa wissen, wo es hingeht, aber am ende dieses Runs hast du ein lauffähiges System, was halt erstmal kaum was bietet. Dann setzt du dich hin und definierst neue Ziele - anhand der Erfahrungen, die du bis dahin gemacht hast und ggf. geänderter Anforderungen.

• Womit soll ich bei der Durchführung anfangen? Front-End, also HTML-Ausgabe, oder Design der Seite oder doch als erstes mit dem Back-End, also dem Admin-Kontrollzentrum.

Entwurf! Hier später was zu ändern wird teuer - dennoch wird es immer wieder nötig sein. Aber macht schon Sinn, hier ein wenig zu investieren. Material zum Thema Architektur von Webanwendungen (auch mit PHP) gibt es sehr, sehr viel im Netz. Klassisch hier Patterns, wie FrontController, dann z.B. MVC oder PageController.

Wenn das steht, kannst du letztlich von verschiedenen Seiten rangehen. Die Daten sind im Lastenheft definiert, ebenso die Funktionen. Gegebenenfalls auch schon die Views incl. Pageflow.

Was ich sinnig finde, ist, von den Usecases ranzugehen ud dort die wichtigsten zuerst zu bearbeiten (falls möglich). Wenn du also ein CMS schreibst, dann ist vielleicht das erstmal Wichtigste das, dass du neue Seiten anlegen willst. Wie also soll dieser Prozess aussehen?

- Backend-Link,
- Login-Formular ausfüllen,
- Über Link in Hauptmenü du den Artikeln,
- Link "neu",
- Artiel schreiben,
- Hauptmenü -> Seiten,
- Link "neu",
- Titel schreiben,
- Artikel auswählen,
- Speichern,
- In Seitenliste auf "Freigeben" klicken

Das ist kein Witz! Viele CMS "funktieren" in etwa so!

Meine Variante:
- Login-Link klicken,
- Anmelde-Formular ausfüllen (innerhalb der Site) -> man landet wieder au der Seite, diese hat nun oben eine Toolbar,
- In der Toolbar auf "Neue Unterseite" klicken (macht natürlich nur Sinn, wenn alle Seiten in einem Baum liegen),
- Seitentyp wählen, der eingefügt werden soll (wird ggf. übesprungen, da nicht überall ale Seiten erlaubt sind),
- Formular mit allen Daten ausfüllen, abschicken (hier könnte auch ein Button stehen "als Entwurf speichern")

Macht also Sinn, sich hier einfach mal hinzusetzen und zu schauen: Wie würde ich das gerne machen wollen; was denke ich, wie würden es die späteren Benutzer gerne machen; wie würden sie es denn tatsächlich gerne machen;

Und dann natürlich: Wie passt das mit der Komplexität des Systems zusammen? Welche Kompromisse bin ich bereit einzugehen?

• Wie viele Gedanken muss ich mir vorher machen? Soll ich einfach nur das Konzept im Kopf haben, oder ist es besser wenn ich alles durchgeplant und aufgeschrieben habe. (Welche MySQL-Tabellen, mit welchen Feldern, welche Klassen wofür benutzen)

Das Problem ist eben, dass du immer dann, wenn du Neuland betrittst nicht wirklich gut planen kannst. Um so wichtiger ist es aber, gut zu planen! Und deinen Plan in relativ kurzen Abständen zu evaluieren.

Und dann suchst du dir am besten Tools, mir denen du dir doppelte Arbeit ersparst. Das heißt, du nimmst z.B. den DBDesigner oder seinen Nachfolger (ist der schon draußen, das Dingens von MySQL AB?), mit dem du aus deinem ERM gleich die Datenbank erstellen lassen kannst. Bei deinem UML-Programm das gleiche Spiel. Umbrello hat z.B. Codegeneration für PHP5.

Noch wichtiger davor wäre allrdings der Gedanke, ob du mit vorhandene Lösungen nicht einfacher (günstiger) zum Ziel kommst. Das kann ein fertiges CMS sin, aber auch ein Applicetion Framework oder aber auch nur eine Hand voll fertiger Komponenten, wie Smarty + PEAR:B oder so.

Ich hoffe ihr könnt mir aus dem Tal der Verzweiflung heraushelfen.

Huch? Vielleicht doch ersmal was kleineres suchen, wenn du jetzt schon verzweifelt bist. *g

Viel Spaß.
Basti

[Ben]

Liest sich wieder mal gut Basti. *daumen hoch*

[Neq']

Zitat von Ben

Liest sich wieder mal gut Basti. *daumen hoch*

Kann ich nur befürworten und mitspammen.

Ich wäre ja dafür den Thread Sticky zu machen und eventuell etwas umzubenennen, da es bestimmt noch öfters solche Fragen gibt. Dazu kommt noch das dass Tutorial von Warren (?) auch hier verlinkt ist.

[WarrenFaith]

Da ich gerade mal wieder das konzept für ein doch ziemlich großes Projekt mache, werde ich nebenbei mal etwas niederschreiben und mein tutorial erweitern und durch basti verbessern.
Da ich allerdings prioritäten setzen muss, wird das nicht schon morgen passieren.
Ich schreib das nur, damit man mich beizeiten darauf mal wieder "stoßen" kann.

[WarrenFaith]

Ich hoffe ich verstoße gegen keine Regeln, wenn ich den Thread hier einfach mal als eine Art kleines Notizbuch nutze, aber so könnte man 2 Dinge erreichen:
1. Am Ende des Konzepts kann ich durch zusammenkopieren aller interessanter Beiträge mein Tutorial gut ergänzt oder erweitert werden
2. Andere können, so sie denn wollen, der Konzeptentstehung indirekt beiwohnen und können kritisch hinterfragen oder Vorschläge unterbreiten.
Wenn nicht, einfach löschen @Ben
----------------------

Am Anfang des Konzepts hab ich mir jetzt anhand verschiedener Themengebiete verschiedene Überschriften generiert.
Die erste Überschrift betrifft das allgemeine Backend, sprich eine Art CMS, welches aber selbstgemacht wird. Zu diesem gehören nun natürlich Module, die unbedingt hineinmüssen.
Nun ist die Frage, wie weit soll ich in dem Konzept gehen? Soll ich unterteilen unter "Konzeptidee", Pflichtenheft und "technisches Datenblatt"?
Meine erste Intention war so. Sprich im Konzept steht nur im Text, was die einzelnen Module bezwecken sollen. Es wird praktisch mündlich beschrieben und soll mehr eine Einführung in die Projektidee verschaffen. Ganz vereinfacht gesagt: ein Marketingdokument.
Im Pflichtenheft würden dann die Funktionalitäten direkt geklärt werden. Sprich das Modul (nehmen wir Blog) muss können: Hinzufügen, Bearbeiten, Löschen, Moderieren etc.
Im technischen Datenblatt würde ich dann schon so speziell werden, dass es nur für Programmierer interessant wird. Sprich was für Datenbanktabellen dahinter stehen. Welche Datentypen zu beachten sind. Wie lang wird die Titelzeile bei einem Blogeintrag maximal werden etc.

Diese Lösung ist natürlich recht aufwendig, da 3 Dokumente vonnöten und strikte Trennung erfolgen muss. Großer Vorteil ist aber, dass man jemanden sein Konzept vorstellen kann, ohne ihn mit technischen Details zu überfordern bzw den Programmierer nicht mit Erklärungen, was ein Blog ist, nervt.

Was würdet bzw habt ihr gemacht?

[Basti]

Also, das was du hier Pflichtenheft nennst scheint mir das klassische Lastenheft zu sein und das, was du technisches Datenblatt nennst (in sofern es nicht schin in den Entwurf hineingeht) wäre das eigentliche Pflichtenheft.

Ausformulierte Passagen finde ich aber auch wichtig. Ich pack das ins Lastenheft und das Pflichtenheft ist ja nur eine Verfeinerung davon.

Was das "Marketingdokument" angeht: Ich hab neulich mit drei Partnern ein CMS verkauft und aus meinem Lastenheft hat der Kommunikationsdesigner in der Runde ein albsolut abgefahrenes "Marketingdokument" gezimmert, das absolut "untechnisch" war und die 10 Seiten Pflichtenheft oder so auf ein Schaubild und ein Blatt Text mit wenigen kurzen Absätzen komprimiert.

Das kann in meinen Augen also nochmal ein ganz anderer Stiefel sein, als ein ausformuliertes Lastenheft.

Basti

[WarrenFaith]

Ich kenne ein Pflichtenheft eher nur in der Spezifizierung von Features sowie Abgrenzungs-, Muss- und Wunschkriterien.
Um das Beispiel Blog zu nehmen, würde dort (vereinfacht) stehen:
Muss:
Erstellen, Löschen, Bearbeiten von Einträgen
Wunsch:
Moderation möglich

Also eigentlich nur beschrieben, was es können soll, damit man den Umfang der Features erkennt.

Laut Wiki habe ich dann wohl was falsches in der Berufsausbildung gelernt oder falsch in Erinnerung behalten, dort heisst es:

Zitat von Lastenheft

Ein Lastenheft (oder Anforderungsspezifikation) beschreibt die unmittelbaren Anforderungen, Erwartungen und Wünsche an ein geplantes Produkt, formuliert in natürlicher Sprache.

Quelle: Wikipedia.org - Lastenheft

Zitat von Pflichtenheft

Das Pflichtenheft (auch Sollkonzept, Fachfeinkonzept oder fachliche Spezifikation) ist die vertraglich bindende, detaillierte Beschreibung einer zu erfüllenden Leistung, zum Beispiel dem Aufbau einer technischen Anlage, der Konstruktion eines Werkzeugs oder auch der Erstellung eines Computerprogramms. Im Gegensatz zum Lastenheft sind die Inhalte präzise, vollständig und nachvollziehbar sowie mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.

Quelle: Wikipedia.org - Pflichtenheft

Das ändert natürlich die Begrifflichkeiten.

Danke Basti!

Btw: also für "interne" Leute, würde ein Lasten- und Pflichtenheft ausreichen, da ich vielleicht das Projekt verwerten möchte, wäre ein Marketingdokument dann im Nachhinein erst zu empfehlen richtig? Macht ja auch Sinn, warum und wieso etwas Anwerben, was noch gar nicht detailiert existiert geschweige denn geplant ist.

[Basti]

Also von wegen natürlicher Sprache im Lastenheft steht bei Balzert 1996 (Band 1) z.B. was anderes. Aber ich finde das quasi als Einleitung auch nicht schlecht, einen Überblick über die Zusammenhänge, wie Benutzergruppen/Rolen etc. zu geben, die eben aus den Listen der zu speichernden Daten und bereitzustellenden Funktionen nicht direkt hervorgeht.

Laut Balzert gehört das Lastenheft in die Planungsphase, an deren Ende die Grundlage für eine Entscheidung über des Projektes steht und das Pflichtenheft in die Definitionsphase. Er schreibt aber auch, dass es von der Planungsphase ganz unterschiedliche Auffassungen gibt. Ein wichtiger Unterschied sei z.B., ob Standard-Software entwickelt wird oder, ob Individual-Software entwickelt wird.

Und, von agiler Softwareentwickung ist in dem ganzen Schinken noch nichts zu lesen. Das Buch ist eben erst 1996 erschienen und er hat nach eigenen Angaben 5 Jahre dran gesessen, Kent Becks XP-Buch z.B. erst 1999.

Fände ich persönlich in jedem Fall interessant, auch mal dorthin zu schauen, denn ich hab damit bisher wenig Erfahrung. So haben wir oben genanntes CMS-Projekt auch mit vielen Lücken definiert und mit vielen Variablen kalkuliert, um dieses in kurzen Zyklen entwickeln und nach jedem Zyklus die Anforderungen neu definieren können - obwohl die Grundfunktionen natürlich klar sind. Aber gerade der Zugang zu den Daten (Kategoriesierung, Verknüpfung untereinander etc.) das steht alles noch nicht fest.

Ich glaube, in irgendeinem Java-Magazin stang mal ein interessanter Artikel über Vertragsgestaltung in agilen Projekten. Find den aber grad nicht...

Basti

[WarrenFaith]

Also ich fasse mal zusammen:
Lastenheft - Grundlageninfos zum Projektumfang
Pflichtenheft - technische Spezifikationen

Die agile Planung klingt auch sehr interessant. Da ich noch kein Projekt erlebt habe, in dem die Planung zu 100% hingehauen hat, ist natürlich der "Korrekturaufwand" geringer, wenn man etwas anders realisieren muss und daher gezwungen ist gewisse Planungen über den Haufen zu werfen.
Sehr interessant.

[Basti]

Wichtig vielleicht noch zu eränzen, dass Lasten- und Pflichtenhefte lediglich die fachlichen Anforderungen enthalten.

Basti

[WarrenFaith]

Design(studien), Usability sowie SEO werden extra behandelt, dass ist klar. Fehlt sonst noch was?

[Basti]

Zitat von WarrenFaith

Design(studien), Usability sowie SEO werden extra behandelt, dass ist klar. Fehlt sonst noch was?

Kommt drauf an. Zum Teil sind das ja Qualitätsanforderungen, da hier in jedem Fall festgehalten werden sollten.

Basti

[Basti]

Zitat von Basti

Ich glaube, in irgendeinem Java-Magazin stang mal ein interessanter Artikel über Vertragsgestaltung in agilen Projekten. Find den aber grad nicht...

-> OBJECTspektrum 1/2006

Basti