Hallo,

danke für eure Antworten. Es ist interssant auf welche art und weise ihr eure projekte plant.
Die Methode(n) von sweetkira und mA1k finde ich für mich am sinnvollsten, vor allem weil ich schon meine erfahrungen mit mind mapping gemacht habe

Danke an alle Schreiber.

mfg

marten

Mister Ad

Malfunction

es kommt natürlich immer auf die größe des projektes an. solange es was privates oder ein ein-mann projekt ist, kann man sich sein vorgehensmodell selbst stricken und vor allen dingen nach bedürfnis anpassen.

ich sach mal so aus'm bauch heraus, wie ich das machen würde:

1. Bedarfsanalyse / Anforderungsanalyse

dabei wird festgestellt, was das zu entwickelnde system leisten soll, und ob diese leistungen auch benötigt werden. hat man einen kunden, so ist in dieser phase der dialog mit dem kunden enorm wichtig. erstellt der kunde ein lastenheft, so hat man oft schon die halbe miete, da dort grob (möglicherweise auch laienhaft) die anforderungen gestellt sind.

2. Analysephase

aus den anforderungen werden use-case (use-case : anwendungsfall) diagramme modelliert (wurde hier schon erwähnt). dabei werden alle äußeren anwendungsfälle modelliert. also alle funktionen die der benutzer des systems direkt anstossen kann.
diese stellen dann im grunde die systemleistung dar. alle anderen funktionen sind intern und für den kunden eher uninteressant.
diese use-case diagramme gehören auch ins pflichtenheft.

danach mache ich ein klassendiagramm, welches die geschäftslogik abbildet. wenn ich z.b. eine userverwaltung realisieren muß, so findet sich dafür ein klassendiagramm, in dem klassen wie user, adresse etc. mit ihren methoden, attributen und relationen abgebildet sind.
diese klassendiagramme kommen ebenfalls ins pflichtenheft.

die gliederung des pflichtenheftes könnte z.b. so aussehen:

1 Zielbestimmung
1.1 Muß-Kriterien
1.2 Soll-Kriterien
1.3 Kann-Kriterien
1.4 Abgrenzungskriterien
2 Einsatz
2.1 Anwendungsbereiche
2.2 Zielgruppen
2.3 Betriebsbedingungen
3 Umgebung
3.1 Orgware
3.2 Hardware
3.3 Software
3.4 Produktschnittstellen
4 Funktionalität (Hauptteil)
5 Mengengerüst (Daten)
6 Leistungen
7 Benutzungsoberfläche
7.1 Benutzermodell
7.2 Kommunikationsstrategie
7.3 Kommunikationsaufbau
7.4 Benutzerdokumentation
8 Qualitätsziele
9. Entwicklungs-Konfiguration (Software, Hardware, Orgware)
10. Einführungsstrategie
11. Anhänge
11.1 Abkürzungen
11.2 Glossar
11.3 Literatur

Wichtig ist in der Analysephase auch festzustellen, welche Komponenten man wiederverwenden kann, und welche externen Komponenten man verwenden kann. Besonders bei nem webprojekt gilt, dass man das rad nicht neu erfinden muß. z.b. kann man evtl. gästebuch, forum, etc. vom markt nehmen statt selbst zu entwickeln.

Auch ist es ratsam, vor der abgabe das pflichtenheftes dem kunden einen wegwerfprototypen zu zeigen, und diesen absegnen zu lassen. kann hinterher viel ärger ersparen - "wie.... so habe ich mir das aber nicht vorgestellt".

3. Entwurf

hier werden dann die einzelnen komponenten im detail entworfen, also klassendiagramme erzeugt.
je nach plattform ist hier auf einsatz von entwurfsmustern zu achten, auch wenn man alleine entwickelt. nichts ist peinlicher und ärgerlicher, als seinen eigenen code garnicht mehr zu verstehen.

4. Implementierung

da muß ich ja nix mehr zu sagen - protoypen mache ich aber grundsätzlich nicht erst hier. sondern schon vorher ( für layout, menüführung, dialoge, etc.)

dann kommt noch ausgabe, pflege, etc.

das wäre so mein vorgehensschema, welches sich natürlich je nach komplexität des projektes variiert werden kann.

wasserfallmodell, spiralmodell, v-modell97 naja, kann man drüber reden. sicher kann man sich was abgucken, aber wenn es ein standard sein soll, ist meine persönliche empfehlung das v-modell xt. ist einfach sehr flexibel, und in unserem land quasi industriestandard.

Ich mach mir eine Liste Wo ich alle Seiten und deren Features drauf hab die ich dann nach und nach abhake

@ Malfunction

Danke für die sehr ausführliche anleitung

Die Hinweise von euch zur Projektplanung sollten jetzt ausreichend sein
Jetzt muss ich das ganze nur noch anwenden


@Du-weisst-schon-wer

kurz und schmerzlos so hatte ich es auch mal versucht aber irgendwie hat es nicht den erfolg gebracht, vor allem habe ich immer wieder beim implementieren eines neuen Features festgestellt, das die einzelene Tabellen erweitert werden müssen.
Außerdem habe ich auch nachdem etwas fertig war, festgestellt, das es überflüssig ist

Kort

Hab mir mal das Vorgehen von Malfunction durchgelesen, aber noch Definitionsfragen:

Was sind Angrenzungskriterien?
Was ist denn Orgware?
Und was ist das genau mit den Modellen? v-modell xt?

__________________
"Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it." - Linus Torvalds, 1996

Malfunction

abgrenzungskriterien sind z.b. funktionalitäten, die dein system nicht leisten wird.
kann sehr wichtig sein, wenn ein kunde hinterher stress macht, dass etwas fehlt. dann kann man auf's pflichtenheft verweisen, wo steht, dass diese funktionalität nicht integriert ist.

orgware, da verweise ich mal faulerweise auf die definition von http://www.computerlexikon.com/begriff.php?id=2117 :

Zu Vorgehensmodellen solltest du dich im netz schlau machen. im grunde hat der to ja genau wissen wollen, wie man ein projekt planvoll durchführt. bei ner firma mit vielen duzent projektbeteiligten ist diese problematik noch viel wichtiger.
das hat viel mit projektorganisation zu tun.
die modelle haben sehr unterschiedliche ansätze.
z.b. kann man starr nach meilensteinen entwickeln. was dazu führen kann, dass zum termin nicht alles fertig ist (lineares phasenmodell). deshalb kann man auch immer wieder schleifen ziehen (spiralmodell) wo man auf das bisher entwickelte schaut, und u.u. das weitere vorgehen abändert.

gerade bei softwareentwicklung ist vieles nicht so genau vorhersehbar. schon alleine, weil bei langer projektdauer evtl. neue techniken auf den markt kommen.

interessant ist hier noch eine etwas neuere vorgehensweise die xtreme programming genannt wird. dabei wird wird nahe beim kunden, oder sogar on site entwickelt. immer kleine pakete, und wenn eines fertig ist stellt man den kunden vor die wahl, was er als nächstes entwickelt haben möchte. so hat man sehr schnell ein laufendes system, dessen funktionalität erweitert wird. so kann man missverständnisse schnell klären und fehlentwicklungen vermeiden.

in der vergangenheit war es oft so, dass man sich nach der absegnung des pflichtenheftes bis zur abnahme nicht mehr (oder kaum) mit dem kunden abgesprochen hat. das ausgelieferte system entsprach dann u.u. überhaupt nicht dem, was der kunde wollte.

auf jeden fall sollte man sich mit uml auseinander setzen, wenn man oo entwickelt.
paket- und klassendiagramme versteht jeder, der sich halbwegs mit oop auskennt.
use-case diagramme erfordern eigentlich nur common sense.
danach kann man sich in sequenzdiagramme etc. einarbeiten, um z.b. komplexe operationen abzubilden.

tekknotrip

Ich zeichne mir immer die Abläufe auf.

das was die Software können soll weis ich schon vorher.
Nur die Logik ist am WICHTIGSTEN und die sollte vorher überlegt sein...
Also sämtlich mögliche if Bedingungen AUFZEICHNEN und TRUE und FALSE Wege verfolgen.

Das spart Zeit und jede Menge Code (wenn man sich einmal verrennt ist es schwer wieder rauszukommen). Ich such jetzt nur noch ne Software, damit ich nicht mehr malen muss

Ich hatte mal eine Projektsoftware im Studium (Elektro) wo man einfache Verküpfungen miteinander verbinden konnte und Bedingungen aufstellen konnte. Leider weis ich nicht mehr wie die hieß.

Vielleicht kann hier jemand was empfehlen?

Gruss, Micha

imported_Ben

@malfunction:
Deine Asführungen sind interessant zu lesen.

Danke.

__________________
Webentwickler-Blog - Buchbesprechung PHP Design Patterns - SQL-Antipatterns