Literatur fuer Projektplanung
- Ersteller SneezR
- Erstellt am
Tumbleweed
Captain
- Registriert
- März 2008
- Beiträge
- 3.600
Geht es dir um das Projektmanagement? Da geht es vom klassischen Wasserfall bis zur moderneren agile Entwicklung und dann gibt es noch viele Mischformen und einige andere Ansätze dazwischen. Das biegt sich jeder so zurecht, wie es am besten zum eigenen Team und Projekt passt.
Wenn es dir mehr um die technische Konzeption geht, dann interessieren dich vielleicht dieses und jenes Werk.
Vielleicht meinst du aber auch was ganz anderes. Mal sehen.
Wenn es dir mehr um die technische Konzeption geht, dann interessieren dich vielleicht dieses und jenes Werk.
Vielleicht meinst du aber auch was ganz anderes. Mal sehen.
Ich weis das kann man so direkt nicht sagen, da dass ja jeder anders sieht, aber welches Modell ist sagen wir mal recht "Einsteiger freundlich"? ^^
Hast du dazu Erfahrungen?
Dazu stellt sich für mich auch noch die Frage von "Beta"-Tests. Sind diese von sehr großem Vorteil und beanspruchen dann nicht auf einmal mehr Zeit als die eigentliche Programmierung und ab wann lohnt es sich einen Beta-Test, sagen wir mal an Freunde und Bekannte, weiterzugeben?
Zu den Büchern, dort würde ich eher zu dem OO-Buch tendieren. Werde mich die Tage mal näher darüber informieren und nach alternativen suchen, da mir der Schreibstil von O Reilly nicht so zusagt.
Hast du dazu Erfahrungen?
- Im Prinzip habe ich von meinem ersten Projekt das grobe Konzept und würde m.E. dieses verfeinern und die möglichen Probleme erst einmal nur festhalten.
- Wenn ich damit fertig bin würde ich die möglichen Probleme genauer recherchieren.
- Speziell die Thematik der Sicherheit steht hier für mich bei diesem Projekt im Vordergrund.
- Anschließend die DB-Struktur so genau wie möglich festlegen, um spätere Änderungen zu minimieren.
- Folgend die Objektmodellierung.
- Sobald die Objekte erstellt sind, werden Funktionen zum Programm-Ablauf geschrieben.
- Und am Schluss alles mit GUI schön verpackt. :-)
Dazu stellt sich für mich auch noch die Frage von "Beta"-Tests. Sind diese von sehr großem Vorteil und beanspruchen dann nicht auf einmal mehr Zeit als die eigentliche Programmierung und ab wann lohnt es sich einen Beta-Test, sagen wir mal an Freunde und Bekannte, weiterzugeben?
Zu den Büchern, dort würde ich eher zu dem OO-Buch tendieren. Werde mich die Tage mal näher darüber informieren und nach alternativen suchen, da mir der Schreibstil von O Reilly nicht so zusagt.
Tumbleweed
Captain
- Registriert
- März 2008
- Beiträge
- 3.600
Deine Punkte klingen mehr nach Wasserfall. Alles bis ins kleinste Detail vorher auskaspern und dann wird es genau so durchgezogen, wie es die Dokumente verlangen. Du läufst bei sowas immer ein Stück weit Gefahr, dass du auf Probleme stößt, die du nicht vorhergesehen hast (z.B. auf Grund mangelnder Erfahrung). Da du ja allein an dem Projekt arbeitest oder zumindest der einzige stakeholder bist, kannst du zumindest ausschließen, dass sich ständig die Anforderungen ändern.
Die Alternative zu diesem Weg wäre eher Top-Down vorzugehen, also erst einmal Meter machen, einen Durchstich zu einem Prototypen, den man dann in mehreren Iterationen verfeinert. Dieser Ansatz erzwingt aber quasi TDD, um sicheres Refactoring zu erlauben und nicht ständig neue Bugs einzubauen. Im Zuge dessen, schau dir unbedingt Versionskontrolle (SVN oder Git) und Continuous Integration (z.B. Jenkins) an.
Zum Testing - klar könntest du Prototypen rausgeben, so nach diesem Schema. Am wichtigsten finde ich aber die eigene automatische Testabdeckung, auch wenn du nicht test-first (siehe TDD) entwickelst. Solche Tests sind durchaus Mehraufwand, ja. Es rechnet sich aber, weil du dadurch direkt viele viele Fehler ausschließt.
Die Tests durch Menschen solltest du eher unter anderen Aspekten betrachten. Kommen die User mit deiner Software zurecht, d.h. hast du das GUI intuitiv genug gestaltet? Fehlen wichtige Features, die die User veranlassen würden, deine Software nicht mehr zu benutzen?
Das sollten so die wichtigsten Stichpunkte sein, damit du dich weiter umsehen kannst. Ich beschäftige mich selbst gerade mehr mit dem agilen Weg und TDD. Letzteres erfordert aber viel Disziplin beim Design deiner Software. Du merkst dabei sehr schnell, welcher Code schlecht testbar ist.
Die Alternative zu diesem Weg wäre eher Top-Down vorzugehen, also erst einmal Meter machen, einen Durchstich zu einem Prototypen, den man dann in mehreren Iterationen verfeinert. Dieser Ansatz erzwingt aber quasi TDD, um sicheres Refactoring zu erlauben und nicht ständig neue Bugs einzubauen. Im Zuge dessen, schau dir unbedingt Versionskontrolle (SVN oder Git) und Continuous Integration (z.B. Jenkins) an.
Zum Testing - klar könntest du Prototypen rausgeben, so nach diesem Schema. Am wichtigsten finde ich aber die eigene automatische Testabdeckung, auch wenn du nicht test-first (siehe TDD) entwickelst. Solche Tests sind durchaus Mehraufwand, ja. Es rechnet sich aber, weil du dadurch direkt viele viele Fehler ausschließt.
Die Tests durch Menschen solltest du eher unter anderen Aspekten betrachten. Kommen die User mit deiner Software zurecht, d.h. hast du das GUI intuitiv genug gestaltet? Fehlen wichtige Features, die die User veranlassen würden, deine Software nicht mehr zu benutzen?
Das sollten so die wichtigsten Stichpunkte sein, damit du dich weiter umsehen kannst. Ich beschäftige mich selbst gerade mehr mit dem agilen Weg und TDD. Letzteres erfordert aber viel Disziplin beim Design deiner Software. Du merkst dabei sehr schnell, welcher Code schlecht testbar ist.
Also zum Verständnis von Top-Down..
Ich hätte ja jetzt geplant
1. DB Struktur (Tabellen mit Spalten)
2. Objekte (auslesen, speicher, etc)
Nach Top-Down würde das dann ja bedeuten
1. DB Struktur (nur Tabellen)
2. Objekte
3. DB Spalten
4. Objekte auslesen
5. Objekte speichern
6. Objekte etc.
7. Grobes UI
8. Objekt Funktionen
9. zB User-Einstellungen
10. Ansichten verfeinern
etc. pp.
Richtig?
TDD habe ich auch in der Berufsschule kennengelernt und es wahrlich ein wahnsinns Aufwand, welcher sich aber in späteren Arbeitsschritten schnell wieder rentiert und das Leben um einiges einfacher macht.
Ich hätte ja jetzt geplant
1. DB Struktur (Tabellen mit Spalten)
2. Objekte (auslesen, speicher, etc)
Nach Top-Down würde das dann ja bedeuten
1. DB Struktur (nur Tabellen)
2. Objekte
3. DB Spalten
4. Objekte auslesen
5. Objekte speichern
6. Objekte etc.
7. Grobes UI
8. Objekt Funktionen
9. zB User-Einstellungen
10. Ansichten verfeinern
etc. pp.
Richtig?
TDD habe ich auch in der Berufsschule kennengelernt und es wahrlich ein wahnsinns Aufwand, welcher sich aber in späteren Arbeitsschritten schnell wieder rentiert und das Leben um einiges einfacher macht.
Tumbleweed
Captain
- Registriert
- März 2008
- Beiträge
- 3.600
Ich denke, der Kern ist YAGNI. Du kannst natürlich schon Tabellen anlegen, aber eben nur die, die du für die Funktionalität der ersten Iteration brauchst (natürlich auch nur die nötigen Spalten).
Genauso mit sämtlichen anderen Dingen. Objekte werden nicht direkt mit allen möglichen Methoden und Feldern angereichert, die du denkst später mal zu brauchen, sondern du hältst es minimal und implementierst nur was nötig ist, um das Ziel zu erreichen. Solche Ziele werden im agilen Prozess in der Regel in User Stories festgehalten. Das Gegenstück im klassischen Prozess wären die Use-Case-Diagramme, die auch recht aufwändig sind, aber schon logische Fehler im Ablauf vermeiden.
Genauso mit sämtlichen anderen Dingen. Objekte werden nicht direkt mit allen möglichen Methoden und Feldern angereichert, die du denkst später mal zu brauchen, sondern du hältst es minimal und implementierst nur was nötig ist, um das Ziel zu erreichen. Solche Ziele werden im agilen Prozess in der Regel in User Stories festgehalten. Das Gegenstück im klassischen Prozess wären die Use-Case-Diagramme, die auch recht aufwändig sind, aber schon logische Fehler im Ablauf vermeiden.
Die Projektplanung ist eines der Kernthemen des Software Engineerings.
Wikipedia gibt dazu schon eine gute Übersicht darüber, was da so auf einen alles zukommt.
Beim Vorgehensmodell wird heutzutage am meisten RUP verwendet, aber auch das Wasserfallmodell ist recht häufig. Zunehmen setzt man auch gerne auf agile Methoden wie zB Extreme Programming.
Diese Bücher zählen zu den Standardwerken in diesem Bereich:
Lehrbuch Der Objektmodellierung: Analyse und Entwurf mit der U.M.L. 2
Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software der Gang of Four
Mit denen hat man fast alles abgedeckt. Dazu empfiehlt sich vielleicht noch ein Buch über Softwarearchitektur, dass dir bei der Entwicklung der Programmstruktur hilft:
Software Architecture in Practice
Wenn du diese drei Bücher durch hast, bist du ganz vorne dabei, wenn es um das Thema Software Engineering inkl. Projektmanagement und Softwarearchitektur geht. Da macht dir dann so schnell keiner was vor.
Wikipedia gibt dazu schon eine gute Übersicht darüber, was da so auf einen alles zukommt.
Beim Vorgehensmodell wird heutzutage am meisten RUP verwendet, aber auch das Wasserfallmodell ist recht häufig. Zunehmen setzt man auch gerne auf agile Methoden wie zB Extreme Programming.
Diese Bücher zählen zu den Standardwerken in diesem Bereich:
Lehrbuch Der Objektmodellierung: Analyse und Entwurf mit der U.M.L. 2
Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software der Gang of Four
Mit denen hat man fast alles abgedeckt. Dazu empfiehlt sich vielleicht noch ein Buch über Softwarearchitektur, dass dir bei der Entwicklung der Programmstruktur hilft:
Software Architecture in Practice
Wenn du diese drei Bücher durch hast, bist du ganz vorne dabei, wenn es um das Thema Software Engineering inkl. Projektmanagement und Softwarearchitektur geht. Da macht dir dann so schnell keiner was vor.
Ähnliche Themen
- MicroStream
- Programmieren
