Software zur Verwaltung der Münzsammlung?

Wenn mich recht entsinne, war in der letzten "Welt des Sammelns" (dieses Blättchen, das immer der MünzenRevue beiliegt) auch irgendeine Münzensammlungsverwaltungdatenbanklösung. :) Leider hab' ich diese Beilage nicht mehr; aber offenbar hat der Gietl Verlag da etwas auf den Markt gebracht.

Tschüs,
Christian
 
Durch Zufall bin ich auf einen Programmierer (war mir bei meiner DB behilflich) gestoßen, der ein Münzenverwaltungsprogramm entwickelt hat. Er bat mich sein Programm unter die Lupe zu nehmen und ich habe es mit Freude getan, man lernt ja nie aus.

Erster Blick und schon hing ich an der Tastatur, Frage per Mail: "Bist du ein Sammler?" Die Antwort kannte ich schon, er ist keiner!

Was nützt es, wenn er ein Fachmann auf seinem Gebiet ist, aber die Probleme und Wünsche der Sammler nicht kennt. Diese sind (meine Meinung) so unterschiedlich und vielfältig, dass ein perfektes System nie entstehen wird.
 
Raphael schrieb:
[...]Was nützt es, wenn er ein Fachmann auf seinem Gebiet ist, aber die Probleme und Wünsche der Sammler nicht kennt.[...]
Das bedeutet eigentlich nur, das er wenig Ahnung von der Planung eines Projektes hat. Das Programmierung maximal 10% der Arbeit ausmacht, wollen die meisten nicht glauben.

Aber wie dein Beispiel zeigt, fliessen genau aus diesem Grund ungefaehr 50-60% der Arbeitszeit VOR der Programmierung in die Analyse von Beduerfnissen der "Kunden", Befragung von spaeteren Nutzern, etc. etc. ... ;)

Was man hier vergisst oder falsch macht, muss man um so teurerer mit Arbeitszeit bezahlen, um so spaeter man den Fehler entdeckt.
 
@janek,

Da bist du etwas auf dem Holzweg.

Ich bin über 15 Jahre im Geschäft. Wenn die Implementierung tatsächlich
nur 10% der Projektzeit ausmachen würde, wären viele Projekte, auch in
grossen Firmen, unbezahlbar.

Natürlich gibt es solche Projekte - das ist aber eher die Ausnahme,
nicht die Regel. Nicht von ungefähr gibt seit einiger Zeit bei der
Entwicklung eine Tendenz in Richtung "Extreme-Programming", um
ausufernde Planungszeiten einzusparen. Denn die kosten viel Geld.

Mit "Extreme Programming" stösst man aber bei Unis oder FHs
natürlich eher noch auf taube Ohren. Das ist etwas, das aufgrund
von wirtschaftlichen Zwängen im Praxisumfeld geboren wurde.
Im universitären Umfeld, wo jeder Student eher Einzelkämpfer ist,
ist das eher schwer vermittelbar.

Gruss,
jeggy
 
mifrjoar schrieb:
Wie gibst Du den dort eine Jahreszahl AH1405 ein ? Das Jahresfeld ist rein numerisch und als AD fest vorgegeben. Mich stört, wenn ich immer erst umrechnen muss.

Coinbook war übrigens die Software, die auf meine konstruktive Kritik einfach nicht geantwortet haben. Eigentlich Schade, weil mir das Programm vom Ansatz her recht gut gefallen hatte.

@mifrjoar

Da ich bisher nicht in die Verlegenheit gekommen bin, eine Jahreszahl ausgehend von der Hedscha (schreibt man das so?) zu verwenden, hatte ich diesbezüglich noch keine Probleme mit Coinbook Open. Bis jetzt hat die Julianisch-Gregorianische Zählung gereicht. Weltmünzensammler oder Sammler mit Fokus auf den arabischen Raum kriegen da natürlich ein Problem.

Für meine Zwecke hat es aber bisher gereicht. Ich kann eine Liste für die Versicherung generieren und eine Bilddatei hinterlegen. Eine eigene Datenbank mit ACCESS oder EXCEL aufzubauen, fehlt mir die Zeit und Coinbook Open ist deshalb für mich eine preisgünstige und annehmbar komfortable Lösung.

Natürlich würde ich mir auch eine eierlegende Wollmilchsau mit Mangogeschmack wünschen, schade darum, daß sich Coinbook nach Deiner Anfrage so zugeknöpft zeigt.
 
jeggy schrieb:
... Wenn die Implementierung tatsächlich
nur 10% der Projektzeit ausmachen würde, wären viele Projekte, auch in
grossen Firmen, unbezahlbar.

Natürlich gibt es solche Projekte - das ist aber eher die Ausnahme,
nicht die Regel. Nicht von ungefähr gibt seit einiger Zeit bei der
Entwicklung eine Tendenz in Richtung "Extreme-Programming", um
ausufernde Planungszeiten einzusparen. Denn die kosten viel Geld.

Mit "Extreme Programming" stösst man aber bei Unis oder FHs
natürlich eher noch auf taube Ohren. Das ist etwas, das aufgrund
von wirtschaftlichen Zwängen im Praxisumfeld geboren wurde.
Im universitären Umfeld, wo jeder Student eher Einzelkämpfer ist,
ist das eher schwer vermittelbar.

Gruss,
jeggy

Ja ja, wenn die Implementierung nur 10 Prozent ausmacht und die Projektentwicklung 80 Prozent, dann ist das für den Entwickler teuer. Also verkauft man lieber ein unausgereiftes Produkt als ausgereift für billig, und bei den ersten auftretenden Fehlern schiebt man das Ganze auf die ungenaue/unscharfe Ausschreibung oder grobe Fehler in der Pflichten- oder Lastenheftphase. Die Vergabekriterien der meisten Untenehmen ("billig, koste es, was es wolle") unterstützen dies noch. Nachbesserungen läßt man sich dann fürstlich bezahlen, manche Softwarefirmen leben nur von sowas. Das kostet letztendlich viel mehr Geld, aber nicht jenes der Entwickler.
 
JensiS schrieb:
Ja ja, wenn die Implementierung nur 10 Prozent ausmacht und die Projektentwicklung 80 Prozent, dann ist das für den Entwickler teuer. Also verkauft man lieber ein unausgereiftes Produkt als ausgereift für billig, und bei den ersten auftretenden Fehlern schiebt man das Ganze auf die ungenaue/unscharfe Ausschreibung oder grobe Fehler in der Pflichten- oder Lastenheftphase. Die Vergabekriterien der meisten Untenehmen ("billig, koste es, was es wolle") unterstützen dies noch. Nachbesserungen läßt man sich dann fürstlich bezahlen, manche Softwarefirmen leben nur von sowas. Das kostet letztendlich viel mehr Geld, aber nicht jenes der Entwickler.

Du hast schon recht, ist das Budget zu klein, leidet meist die Qualität bis
hin zum Crash des Projekts oder Unbrauchbarkeit der Projektergebnisses.

Wenn bei XP-geführten Projekten am Schluss des Projekt etwas Generelles
schief gegangen, ist der Fehler jedoch ganz klar beim Auftragnehmer
(den Entwicklern) zu suchen. Da gibt es dann keine Ausreden. ;)

Beim klassischen Ansatz ist das jedoch oft ein Problem. Nicht selten
wird ein Projekt genau vorgabenmässig umgesetzt, und am Ende ist
der Kunde nicht zufrieden, weil er sich was anderes vorgestellt hatte.
Ich habe so etwas leider schon x-fach erlebt.

Budget: Meist ist es für den Kunden zu teuer und jemand anderes bekommt
den Auftrag. Passiert so etwas, hat man aber einen schlechten Vertrieb.

Bei Extreme-Programming-Ansätzen kann man es tatsächlich
hinterher nicht auf die Ausschreibung oder das Lastenheft schieben.
Denn das wird ja üblicherweise sowieso vom Kunden während der
Projektphase selbst stark verändert. Vor allem bein XP-Ansatz. Der ist gut
sowohl für den Kunden (falls er bereit ist, auch selbst die notwendige
Zeit zu investieren - er wird nämlich ins Projekt viel mehr mit eingebunden
- das muss ihm von Anfang an klar gemacht werden.) als auch für den
Auftragnehmer.

Die Implementierungszeit ist bei XP-Ansätzen höher, weil viel mehr iterativ
vorgegangen wird und das Projekt mit dem Kunden zusammen auch mitten
im Projekt mal die Richtung ändern kann.

Gruss,
jeggy
 
So, damit ist dieser Thread nun auch wieder thematisch zerlegt. :D

Es ging doch um Münzsoftware...da ist mir leider noch keine gute
untergekommen, ich habe den Eindruck, dass das daran liegt, dass
da jeder seine eigene Vorstellung von Ordnung hat. Eine "eierlegende
Wollmilchsau", die jeden Wünschen und Ansprüchen gerecht werden kann,
wäre zu schwierig einzurichten und zu komplex.

Der richtige Ansatz wäre hier, einen vorlagenbetriebenen Kern zu bauen,
der extrem flexibel ist. Mittels vielen mitgelieferten Vorlagen, welche
gesammelten Sammler-Vorstellungen entspringen (man auch die dann als
Fortgeschrittener auch verändern oder selbst erstellen)
kann man dann das Programm auf vielfältige Weise vor-einrichten, so dass
jeder eine passende Variante des Programms betreiben kann, die seinen
Ansprüchen genügt.

Durch den gemeinsamen Kern wäre dann auch der so wichtige Datenaustausch
möglich.

So eine Art Lotus Notes fürs Münzensammeln ;)
 
Jeggy, zwei kurze Sachen zu dem obigen:
1. XP wird bei uns primaer gelehrt, weil fuer das "richtige" Entwickeln (mit V-Modell oder was auch immer) im Rahmen eines Projektes im Semesters gar keine Zeit bleibt.

2. Sind Projekte bei generell in Gruppen von mind. 4, was bei ganz anderen Stellen zu Probleme fuehrt. Ich sag nur: "Der hat meinen 'schoenen' Code veraendert ... *heul* *flenn*"

---

Aber zurueck zum Thema:
jeggy schrieb:
[...]So eine Art Lotus Notes fürs Münzensammeln ;)
muhahaha ... wo man 3 Admins braucht um eine Email Adresse einzurichten? ... Spass beiseite...

Ich verstehe schon, was du meinst. Im Endeffekt braucht man eine Oberflaeche fuer den Eurosammler, eine fuer den Jahrgangssammler, einer fuer den Typensammler, eine fuer den Motivsammler, eine fuer den Weltmuenzensammler, ... (Reihenfolge rein willkuerlich!)

Die Datenbank im Hintergrund muss aber quasi die Obermenge all dessen bilden, also den maximalen Informationsgehalt.

- Wenn man z.B. nicht verschiedene Zeitrechnungen beachtet, sind die Weltmuenzensammler sauer.

- Der eine will Einkaufspreis erfassen, der andere nicht. Wenn man ihn aber ganz aus der DB rauslaesst, ist erstere sauer.

- Der naechste will 20 verschiedene Felder pro Muenze, ein anderer ist Minimalist und braucht nur 5 (jetzt rein fikitiv, hab ich nicht nachgezaehlt :))

und so weiter und so weiter.

Das Problem besteht nicht unbedingt in den einzelnen Sichten auf das System, sondern in dem Finden dieser Obermenge. Vergisst man hier irgend eine Kleinigkeit, wird irgendwer irgendwann schreinen das die Software nicht an seine Beduerfnisse angepasst werden kann. Wo hier ein realistischer Schnitt anzusetzen ist, ist wohl schwer zu ermitteln.
Aber ich glaub zu diesem Thema gab es schonmal einen ausfuerhlichen Thread, wo sowas diskutiert wurde. ... Blaube bei dem Schoen<->KM Konverter, wo es darum ging, welche Felder man denn nun eigentlich fuer eine Muenze erfassen sollte. Schon damals gingen die Meinung stark auseinander.

Ich bereite mal bis Ende der Woche eine kleine Umfrage vor. Wir koennen ja mal versuchen das Stimmungsbild hier im Forum zu erfassen. Ich glaub dann werden wir sehen, warum bisher keine allgemein anerkannte Loesung existiert. ;)

Wie stellst du dir solche Templates vor? Bei der reinen Anzeige von Daten kann ich mir das noch vorstellen. Das Problem sehe ich bei der Erfassung!
Woher soll die Software wissen wie die Felder zusammenhaengen bzw. die Software muesste verhindern, dass der Benutzer Templates mit nicht zusammen gehoerenden Feldern erstellt....
Das halte ich fuer sehr schwierig / komplex.
 
Zurück
Oben
Sie nutzen einen Adblocker

Sicherlich gibt es Seiten im Internet, die es mit Werbung übertreiben. Dieses Seite gehört nicht dazu!

Aus diesem Grunde bitte ich Sie, Ihren Adblocker zu deaktivieren. Danke!

Ich habe den Adblocker für diese Seite ausgeschaltet