Projektplanung / Softwareentwicklung

[WC-Stein]

Hallo liebe Community,

Ich bin seit längerem dabei ein für meine Verhältnisse größere Software Projekt zu planen, merke aber schon seit geraumer Zeit, dass ich dazu wohl die "Soft Skills" oder Kompetenzen nicht besitze.
Ich würde daher gerne mal fragen, ob ihr gute Tutorials oder Open Books zum Thema Planung und Entwicklung von Software kennt.

Ich danke schon mal für gute Antworten
lG Martin

[maRKus23]

Was verstehst du denn unter "Softskills"?

[WC-Stein]

Wie Plane ich größere Projekte. Wie Konzipiere ich. usw.
Man schreibt ja den Quellcode nicht einfach so aus dem nichts los. Es gibt ja ne Phase in der man alles erstmal Plant.

[nurf]

Das ist kompliziert, aber nichts geht über Erfahrung auf dem Gebiet (Arbeitsstunden schätzen).

Ansonsten kannst du dir ja mal "SCRUM" anschauen alias agile Software-Entwicklung.

Risk-Management kommt meistens zu kurz.

Das kann ich in Kürze sagen.

[Korbinian]

Infach mal hinsetzen und alles aufschreiben was du brauchst? Dann mal hinmalen was mit was zusammenhaengt, UML diagramme malen, ... Ist doch nicht so schwer?

[PRIEST]

Man kann es mit der vorplanung nämlich auch übertreiben ^^
Allerdings ist ne dokumentation wärent des programmierens für spätere änderungen ganz hilfreich

[berniebutt]

Triviale Projekte können ohne jede Planung geschrieben werden. Aber was ist schon trivial? Du musst die Aufgaben des Projektes sauber analysieren und überschaubare Teilaufgaben bilden. Diese Teilaufgaben sind dann zweckmässig unabhängig voneinander zu realisren und zu testen. Wenn sie funktionieren sind sie im Zusammenhang zusammenzufügen. Ist und bleibt keine leichte Angelegenheit. Erfahrung und Übung macht es! Bei grösseren Projekten ist immer auf unvorhergesehene Ereignisse zu achten. Alte Programmiereregel: "Man muss immer mit der 'Dummheit des Anwenders rechen!".

[DocJunioR]

Korbinian schrieb:

Infach mal hinsetzen und alles aufschreiben was du brauchst? Dann mal hinmalen was mit was zusammenhaengt, UML diagramme malen, ... Ist doch nicht so schwer?

naaajaa... das ist bei kleinen Projekten ausreichend.
Aaber eigentlich gehört da ne ganze Menge mehr dazu..

Es existieren sehr unterschiedliche Projektierungsmodelle. Einige sind

[]Das Wasserfallmodell (sehr linear und garnicht iterativ)- Der "Erfinder" des Modells hatte eigentlich aussagen wollen, "ein Wasserfallmodell ist nicht sehr sinnhaft"- man hörte aber nur "ein Wasserfallmodell"...
[]V-Modell XT (etwas "agiler" als das V-Modell 97)
[]Rational Unified Process (RUP)
[]Scrum (sehr agil, für kleine bis mittlere Projekte)

Die regeln alles bis ins kleinste Detail.

Grundsätzlich kann man so vorgehen:

Zuallererst ein Brainstorming: Welche Funktionen soll das Produkt haben?
Hierbei können verschiedene Techniken helfen:
[] Grundsätzlich sind Mindmaps sehr schön für Brainstormings
[] Diese können dann auch gleich in ein Use-Case-Diagramm überführt werden
[*] LowTec-IT ist immer gut (Ich nehm immer so Zellulosehaltige flache Rechtecke und ein in Holz verpacktes Kohlenstoffstäbchen, dazu ein Stück vulkanisiertes Kautschuckendprodukt)

Anschließend nimmt man sich die Use-Cases einzeln vor und überlegt sich einen groben Programmablauf (das wäre dann ein Aktivitätendiagramm)
Ein Stück weit kann man hier auch schon Design machen und Klassen definieren, da man ja in den Aktivitäten- oder auch in Sequenzdiagrammen zumindest die Klassennahmen, aber auch schon einige Nachrichten(Methoden) und Attribute braucht.
Es muss am Ende beschrieben sein, was ein Anwendungsfall tut, welche Daten er benötigt und was am Ende an Daten raus geht.

Wenn man zu mehrt ist, sollte man hier schonmal wer anfangen, Testfälle zu erstellen. Dies spart immens Zeit gegenüber der Testfallerstellung anhand des fertigen Produkts.

Das war jetzt die Phase der Anforderungs- und Softwareanalyse- es folgt das Design.

Hier wird dann das vertieft, was man an Klassendiagrammen schon hat. Es werden also Konstruktoren und Hilfsvariablen, sowie -methoden definiert und die Klassenrahmen generiert (schlimmstzenfalls von hand eingetippt).

Anhand der Klassenbeschreibungen können nun Komponenten- bzw. Unit-Tests erstellt werden. Auch wenn es reizvoll ist, zuerst den Code zu entwickeln, ist es durchaus sinnvoll, schon einmal eine Testsuite zu haben, die das erwartete Ergebnis kennt. Man kann dann sein Programm- auch in Teilschritten- schonmal während der Entwicklung nachvollziehbar prüfen.

Anschließend wird das Ganze implementiert und abschließend mit den bereits erstellten Tests auf Herz und Nieren getestet.

Testen ist übrigens ein sehr komplexes Thema. Allein für ein Datumsfeld könnte man 21 Testfälle finden. Bei zwei Datumsfeldern wäre eine vollständige Prüfung mit lediglich 21*21 Testfällen erledigt, für Schleifen ist es noch viel schlimmer- Da gibts aber eigene Techniken für..
Einige Stichworte für google: ISTQB, Testabdeckung, Zweigabdeckung, Dynamische Tests, Grenzwertanalyse, Äquivalenzklasse

Jeder Test ist im Übrigen zu protokollieren.
Das ganze "Papier" das bisher angefallen ist, ist die Projektdokumentation. Fehlt eigentlich nur noch Eine Bedienungsanleitung und fertig ist das Projekt.

Vollkommen außer Acht gelassen ist hier der Zeit- und Geldfaktor.

Für Projekte mit mehreren Leuten gibts auch groupware, z.B. phprojekt.

[WC-Stein]

Danke für die Ausführungen.

Ich habe mittlerweile etwas mehr gelesen. Ich hatte bereits in der Uni Grundlagen der Projektplanung kennen gelernt.

Es ist aber schwer etwas zu finden, was sich mit Projekten, die man vlt. alleine oder zu zweit durchziehen möchte. Viele Bücher beschäftigen sich in sehr großem Rahmen mit der Mitarbeitermotivation etc. Das ist zwar alles sehr wichtig für Projekte bei denen mehr als zwei bis drei Personen mitarbeiten, trifft für mich aber nicht zu.
Weiterhin ist auch die Geld und Zeitkomponente immer sehr wichtig. Was ist denn mit Hobbyprojekten und kostenfreier OpenSource Entwicklung.

Ich mache das jetzt erstmal so, dass ich mir einen Zeitrahmen gesetzt habe, was mir alles zu meinem Projekt einfällt. Das schreibe ich mir auf und wenn die Zeit vorbei ist, gibts erstmal n Feature Freeze.
Im Anschluss überlege ich mir, welche Ideen sinnvoll sind, welche vlt. erst später umgesetzt werden können, für die erste Version aber erstmal zu weit gehen.
Ich habe dann also eine Art Anforderungskatalog für Version 0.1 oder so etwas.
Diesen werde ich dann durchgehen und alle Punkte weiter ausarbeiten.
Bis an diesen Punkt habe ich jetzt erstmal gedacht.

Ich finde es zudem schwer Leute zu finden, die evtl. mitarbeiten wollen. Zwar währe es nicht schlecht, wenn man einiges Arbeit aufteilen kann, aber ist halt schwer potentielle Mitarbeiter zu finden. Ich bin bisher auf unterschiedlichste Stereotypen getroffen:

Der planlosen Ideenhaber
Er hat eine 'tolle' Idee, weiß aber nicht wie er sie umsetzen soll.
Meist gibt es diese Idee schon seit mindestens 1000 Jahren. Zudem macht er sich überhaupt keine Gedanke n über die Umsetzung. Es ist in den meisten Fällen auch schon sein 1000stes Projekt, was er großspurig in einem Forum ankündigt.

Der posenden Trottel
Der posende Trottel, will unbedingt mitmachen, und möchte sich mit seinen extrem guten Quilifikationen auszeichnen, natürlich gibt er damit die ganze Zeit an. Hat man ihn einmal in sein Projekt eingebunden, fängt er an zu nerven. Alles kann er angeblich besser und weiß auch wie alles was man sich ein mühsamer Kleinstarbeit ausgedacht hat besser funktioniert, was es dann nicht macht, weil es so wie er das sich gedacht hat kaum umsetzbar ist. Lässt man ihn dann mal ein paar Ideen haben, stellt sich schnell heraus, dass er in Wirklichkeit keine Ahnung hat und überhaupt nicht weiß, auf was man mit dem Projekt hinaus will.

Der Skeptiker
Der Skeptiker schreibt einfach nur ins Forum, dass das sowieso nichts wird, denn das Projekt hat es schon vor Jahren gegeben und ist auch gescheitert.
Man könnte ihn manchmal auch als Realisten bezeichnen

Der Größenwahnsinnige OS-Neuerfinder
Der ist wirklich am niedlichsten. Hatte in der Schule Informatik, sonst nix. Er kommt dann mit Sätzen daher wie: "Ich möchte gerne mein eigenes Betriebssystem entwickeln. Es soll aber besser sein, als Windoof. Weiß jemand, wo ich da anfangen kann?" Für ihn gibt es in der Welt nix böses und in seinem Kopf kein Wissen.

Der Ideenausnutzer
Der Ideenausnutzer möchte gerne an deinem Projekt mitarbeiten. Es stellt sich aber heraus, dass er sich das in etwa so vorstellt, dass du die Arbeit machst und er einfach rumkommandieren kann. Nach einiger Zeit scheint er dann auch davon überzeugt zu sein, dass die Idee ursprünglich von ihm stammt. Er ist eng verwandt mit dem posenden Trottel.

Ich habe daraus einiges gelernt. Es ist echt schwer Leute zu finden, wenn man sich nicht wenigstens mit einem Overview und den ersten Gedanken über das Projekt vorbereitet hat. Man sollte sich auch nicht lange mit irgendwelchen Leuten herum schlagen die einem immer in das Konzept reden.
Eigtl. ist es so oder so ein wenig zu optimistisch einfach seine Ideen in dieses Forum zu posten und zu hoffen, dass die Leute aufspringen.

Wie macht ihr das eigtl. wenn ihr merkt ihr benötigt einige Mithilfe, vlt. auch Fachkompetenzen zu Themen die ihr selber mit euren Wissen nicht abdeckt?

lG Martin

[pumuckl]

WC-Stein schrieb:

Es ist aber schwer etwas zu finden, was sich mit Projekten, die man vlt. alleine oder zu zweit durchziehen möchte.

Abgesehn vom etwas unglücklichen Satzbau kann ich dem nur voll zustimmen, mir gehts ähnlich. Auf der einen Seite habe ich nicht umwerfend viel Zeit für ein eigenes Projekt, zumal ich im Job schon die ganze Woche vor der Kiste sitze und entwickle. Mein Freizeitpensum das ich investieren möchte liegt also bei so ca. 5-10 Stunden am WE, wenn nicht grade irgendwas anderes ansteht. In ein 3-Mann-Projekt wo die beiden anderen auf meine Mitarbeit zählen kann ich auf die Weise schlecht gehen, also wirds auf ein 1-Mann-Projekt hinauslaufen. Hin und wieder kommt mir da zwar eine Idee, die aber meist recht schnell in Richtung "größenwahnsinniger OS-Neuerfinder" ausartet - okay, es ist kein OS, aber ne neue Sprache mit eigenem Compiler oder ähnliche Hirngespinste. Andererseits hab ich aber auch wenig Lust, den (n+1)ten Taschenrechner, Kalender Adressbuch etc. zu implementieren.
Aktuell trage ich mich mit dem Gedanken, mir ein open-source Projekt zu suchen wo ich dann und wann irgendein kleineres Feature oder einen Bug mit minor severity beisteuere.