Vorbereitung für das Implementieren von Programmen

The Macboy

Neues Mitglied
Hallo liebe Java-Forum-Community,
ich bin neu hier, studiere momentan Informatik 1 als Nebenfach und wollte Euch mal generell fragen,
wie Ihr vor der eigentlichen Java-Programmierung vorgeht.

Macht Ihr ein Konzept auf Papier? - Wenn ja, wie sieht das aus?
Nutzt Ihr Mindmapping - Tools o.Ä.?

Momentan schreibe ich auf Deutsch, unterteilt in Klassen und Methoden, was das Programm ungefähr tun soll und verschandel das ganze noch schön mit Pfeilen...

á la : "durchgehe array bis length-1 und suche nach xy" etc...

Jedoch bin ich mit meiner Vorgehensweise ganz und garnicht zufrieden..😳

Wäre für Tipps, Vorlagen, links etc. sehr dankbar 🙂


P.s. : Falls falsches Forum...sorry & verschieben? bitte 🙂


The Macboy
 
Theorie:

- Auftrag annehmen (Lastenheft)
- Entwürfe für GUI und Pflichtenheft
- Entwurf Klassendiagramm mittels UML
- Absprache mit dem Kunden
- (sollten die Arbeitsschritte des Programms zu komplex werden, muss mit dem Kunden Pseudo-Code geschrieben werden für die Programmlogik)
- Umsetzen der Entwürfe

Praxis:

- Auftrag annehmen
- mündliche Absprachen
- Programmieren
- Dokumentieren

So ist es zumindest bei mir. Da ich nur inhouse-Programmierung betreibe, ist das mit den mündlichen Absprachen völlig ok, aber für die freie Wirtschaft würde ich die Theorie-Variante nehmen, sonst setzt du dich schnell in die Nesseln. Wenn du einen echten Kunden hast, dann mach das Ganze plastisch mit vielen Grafiken und Diagrammen. Die wenigsten Kunden haben Ahnung von der Programmierung (zum Glück) da kannst du mit Anschauungsmaterial mächtig punkten.
 
Praxis:

- Auftrag annehmen
- mündliche Absprachen
- Programmieren
- Dokumentieren

Och ein Optimist 😀
Nach "Programmieren, testen, abgeben" wartet doch schon längst das neue, noch viel dringendere, Projekt.

Designpapiere sind eine nahezu unbezahlbare Dokumentation, die es immer dann braucht, wenn der Kunde mit der Software plötzlich wieder hier steht und etwas geändert haben will.

Was man einsetzen kann:
Ganz zu Beginn (Requirements-Engineering) ist es egal - es ist sowieso eine etrem textlastige Arbeit, wobei einige gute Grafiken, egal womit sie erstellt wurden, oft mehr sagen als 1000 Worte.

Für Analyse und Design habe ich am liebstem UML Diagramme und ein gutes Tool, das man in gewissen Fällen sogar als Codegenerator einsetzen kann und das auch reverse Engineering beherrscht. Leider war das mit dem guten Tool in der Vergangeheit reines Wunschdenken - die Chefs meinen so ein Tool sei zu teuer ???:L
 
Och ein Optimist 😀

muss ich ja, sonst verschrecke ich gleich den Nachwuchs 😳

Aber der liebe Andi_CH hat leider recht. Ich könnte mich ein halbes Jahr einschließen und den ganzen Tag nur dokumentieren, dann wären fast alle Anwendungen mal ordentlich mit einer Dokumentation versehen. Aber in der Realität habsch dafür keine Zeit, nur wenn es wirklich nicht anders geht, dann wird mal Dokumentiert außerhalb des Quelltextes.

"Wir sind wenige, aber viele im Geiste wir sind"
Meister Yoda
 

Zurück
Oben