wie fange ich das Projekt richtig an?
-
Hallo,
Excel bietet die Möglichkeit, CSV (Comma separated values) zu erstellen. Das ist einfacher (am Anfang), als das über SQL zu machen. Ich kenne deinen Kenntnisstand nicht, aber das klingt einfacher, als sich über ODBC oder sowas da einzuklinken.
-
ich würde zuerst UML-Diagramme erstellen.
wenn du alleine bist in deinem Projekt, musst du selber Analyse und Implementation vornehmen.
Als erstes eine Use-Case Study, woraus hervorgeht (aus sicht des Kunden) welche Funktionalitäten erwünscht sind.
Dann folgt die Analyse: Umsetzung der Funktionalität. Es empfehlen sich Klassen- und Synchronisationsdiagramme (allenfall Komponentendiagramme, um modularisierung zu erreichen)
Dann coden.
-
ok, zu meinem Kenntnisstand: Anfänger
Mir fehlen hier jetzt halt die Ansätze...
-
cof schrieb:
ich würde zuerst UML-Diagramme erstellen.
wenn du alleine bist in deinem Projekt, musst du selber Analyse und Implementation vornehmen.
Als erstes eine Use-Case Study, woraus hervorgeht (aus sicht des Kunden) welche Funktionalitäten erwünscht sind.
Dann folgt die Analyse: Umsetzung der Funktionalität. Es empfehlen sich Klassen- und Synchronisationsdiagramme (allenfall Komponentendiagramme, um modularisierung zu erreichen)
Dann coden.UNFUG! NICHTS ALS UNFUG!
mach auf keinen fall ein uml-diagramm und mach auf keinen fall ein struktogramm. sowas kriegt man nur in der schule gelernt, weil es sich in klausuren leicht abprüfen läßt. und die ihk-leute können halt nicht programmieren, in der fachinformatikerausbildung läuft vieles aus dem ruder.
-
weiss ja nicht wo du arbeitest
-
cof schrieb:
weiss ja nicht wo du arbeitest
trauriges thema. auch ich zeige den schülern struktogramme und ein wenig uml, damit sie die ihk-prüfungen mit ner möglichst guten note bestehen.
-
Kann da Volkard nur zustimmen.
Wird viel Wind gemacht mit UML & Co. In der Praxis wirst du damit später kaum konfrontiert. Hauptsache du kannst sowas lesen.
Struktogramme bzw PAPs sind manchmal aber echt für einen Anfänger hilfreich bei der Umsetzung.
In der Schule hat mein Lehrer auch immer darauf gepredigt Diagramme hier und da.
Alles Blödsinn.
In der Praxis ist das zeitlich bei größeren Projekten absolut nicht machbar.
Mit sowas musst du dich als Projektplaner bzw Projektleiter auseinandersetzen.Als Anfänger würde ich dir auch von Zugriff auf Excel,SQL abraten.
Für solche Übungsprojekte reicht es vollkommen wenn du dir die Daten aus nem ASCII File holst.
-
UML & Co, Struktogramme bringen echt nicht viel, außer man will vielleicht einen fremden quellcode verstehen, da kann es ganz hilfreichsein sowas zu erstellen.
Aber normal ist es zu zeitaufwendig und ein (misslungener/halbechter(?)) Erstenwurf hilft viel weiter als ein Struktogramme und macht einem alles viel besser klar ein blödes diagramm
-
wenn man an einem grossen Projekt arbeitet, mit analyse team und entwicklungsteam ist UML sinnvoll. die analytiker erstellen die Diagramme und das andere team coded danach
-
cof schrieb:
wenn man an einem grossen Projekt arbeitet, mit analyse team und entwicklungsteam ist UML sinnvoll. die analytiker erstellen die Diagramme und das andere team coded danach
so sagt es wenigsten die theorie.
aber trifft hier eh nicht zu:Der USER soll über eine Eingabemaske ein paar Kriterien eingeben und das Programm soll ihm dann ein paar mögliche Varianten ausgeben.
-
analyse team und entwicklungsteam
Da du beides in einer Person bist und dein Projekt überschaubar ist solltest du das UML,Diagramme,Struktogramme zeichnen erst mal vergessen, und dich auf die Umsetzung konzentrieren.
-
Ok, also was ich machen soll weiß ich ja.
Ich hab ja das Anforderungsprofil.Aber wie fang ich da jetzt an...
Mach ich zuerst die Oberfläche?
-
tribblexer schrieb:
Ok, also was ich machen soll weiß ich ja.
Ich hab ja das Anforderungsprofil.Aber wie fang ich da jetzt an...
Mach ich zuerst die Oberfläche?Nein, du machst dir erst einmal ein paar Gedanken darueber, welche Schnittstellen
du benoetigst. Frag dich folgendes:Wie will ich die Daten einlesen? (Schnittstelle zum einlesen der Daten)
Wie will ich die Kriterien einlesen? (Schnittstelle zum definieren von Kriterien
evtl. mit Filterfunktionalitaeten innerhalb der Schnittstelle zum einlesen der
Daten?)
Wie will ich die Daten verarbeiten? (Schnittstelle zum verarbeiten der Daten)
Wie sollen die Daten repraesentiert werden?) (Schnittstelle zum ausgeben der
Daten - in Datei, auf dem Bildschirm, wie auch immer)Mach dir erstmal Gedanken ueber die "Hintergrundarbeit" die gemacht werden soll,
srpich die Datenverarbeitung. Ueber die grafische Gestaltung kannst du dir
spaeter immernoch gedanken machen.Am besten du designest das Ganze so, dass du es in einem Konsolenprogramm testen
kannst. Dann schaust du ob deine Implementierung korrekt arbeitet und dann
haust du die grafische Oberflaeche drauf.Denke der Ansatz sollte nicht falsch sein. Fall irgendwer das anders machen
wuerde, oder Verbesserungsvorschlaege hat, nur her damit
mfg
v R
-
"schnittstellen" ist ein schönes wort.
schnittstellen zum ausgeben definieren? ich denke, man kann die daten auch einfach ausgeben!
dito zum einlesen!
filterschnittstellen? hab keine in den anforderungen gesehen.
und verarbeitungsschnittstellen gibts nicht.
ansonsten volle zustimmung.
-
und nach dem alles läuft fängst du an das ganze in uml-bildchen zu malen, damit auch dein vorgesetzter versteht was du fabriziert hast.
viel erfolg.
-
volkard schrieb:
"schnittstellen" ist ein schönes wort.
schnittstellen zum ausgeben definieren? ich denke, man kann die daten auch einfach ausgeben!
dito zum einlesen!
filterschnittstellen? hab keine in den anforderungen gesehen.
und verarbeitungsschnittstellen gibts nicht.
ansonsten volle zustimmung.Naja, mit Schnittstellen meinte ich ich sowas wie Klassen + deren Memberfunktionen
die ich Implementieren muss.Ist vielleicht etwas ungluecklich ausgedrueckt :).
Mit Filter meinte ich, dass die auszugebenen Daten erst einmal anhand von
Kriterien ausgewaehlt werden. Dachte mir, da die Excel-Datei (oder CSV-Datei)
wahrscheinlich eh komplett eingelesen wird, muss man sie ja erstmal mit
hilfe der Kriterien "filtern" um an sein Ergebnis zu kommen. Weiss ja nicht,
wie genau er es haben will/muss.mfg
v R
-
Ich persönlich mach das immer so das ich das Programm so progge das es in einer Konsole zu 100% läuft und Bugfrei ist.
Danach wird eine Gui gebastelt. Finde ich besser weil die GUi eh nur max 5% des Aufwandes ausmachen soll und wenn du dich um beides gleichzeitig kümmert fällt dir immer auf "hmm da is ja noch ein bug, oh hier könnte noch ein button hin" und das lenkt mich persönlich ab.
-
Ich will da jetzt nicht den Experten markieren, aber ich denke, dass das ganze mit SQL doch recht einfach geht. Wenn man mal die Anbindung an die Db (in diesem Fall Excel) hat, kann man sich mit Hilfe der 'Kriterien' doch eine SQL-Abfrage basteln, damit ein Recordset füllen und das anzeigen.
Hört sich doch ganz leicht an, oder?
-
ok, hier mal die relevanten Sachen aus dem Anforderungsprofil:
Also, wenn ich das jetzt mal als Konsolenanwendung schreibe, wie würdet ihr die Klassen definieren?
Oder reicht eine Klasse?
Sorry, aber ich hab wirklich noch nicht soviel Ahnung...
-
Jover schrieb:
aber ich denke, dass das ganze mit SQL doch recht einfach geht.
wie? per ODBC oder per COM über Excel oder Access?
das erfordert entweder, daß der user das ms-office drauf hat, oder daß für odbc zeugs ruminstalliert wird mit setup.exe und so.
schlicht als kommaseparierte *.txt exportiert und neben die eigene *.exe gelegt und gut ists, würd ich sagen. nicht, weil es einfacher zu proggen ist, sondern weil es später für den user einfacher ist.
