Projektablauf beim Erstellen einer neuen Accessdatenbank

[Tanzmaus4]

Hallo alle zusammen,

Ich stehe vor der Aufgabe, eine recht umfangreiche Datenbank zu programmieren und hätte gerne eure Meinung zu meiner geplanten Vorgehensweise gehört.

1. Beschreibung der Anforderungen (Eingabe, Verarbeitung, Ausgabe, Automation, ...)
2. Definition der Berechtigungen (Gruppen, Benutzer, Berechtigungen auf die unterschiedlichen Themenbereiche)
3. grober Entwurf der Optik (Schriftart, grundsätzlicher Aufbau aller Berichte, Formulare, etc.)
4. Tabellen
5. Formulare
6. Berichte
7. Automatisierungen
8. Arbeitsanweisungen für die Anwender
9. Test
10. Schulung
11. Start


eigentlich fehlt noch die Altdatenübernahme, aber die ist in diesem Fall nicht gewünscht.

... und - was haltet ihr davon? Hab ich was vergessen oder in der falschen Reihenfolge?

[Jonny]

Hallo Ute

ich finde den Ablauf grundsätzlich gut.
Würde aber vor den Punkt 8 erst testen.
Es könnte dabei herauskommen, dass sonst die Arbeitsanweisungen
häufig geändert werden müssen.

Gruß
Johann

[oma]

Hallo,

Evt. besser:

1. Beschreibung der Anforderungen (Aufgabenstellung, Festlegungen Arbeitsplatzgestaltung, ....Eingabe, Verarbeitung, Ausgabe,  Automation, ...)
4. Tabellen (Tabellenfestlegung, Felder, Schlüsselfelder, Relationen)
2. Definition der Berechtigungen (Gruppen, Benutzer, Berechtigungen auf die unterschiedlichen Themenbereiche)
3. grober Entwurf der Optik (Schriftart, grundsätzlicher Aufbau aller Berichte, Formulare, etc.)
5. Formulare (Gestaltung der Tabellenkonzeptin mit Formularkonstruktionen!)
6. Berichte
7. Automatisierungen ?
8. Arbeitsanweisungen für die Anwender? Soll Anleitung/Schulung  gemeint sein
9. Test
10. Schulung
11. Start

Zunächst immer viel Zeit bei der  Aufgabenstellung inverstieren, hier sollten keine Missverständnisse bzw. Unklarheiten zugelassen werden. Fragen der Eingabe, Ausgabe u. Automation stehen eigentlich hier kaum an.

Danach ist immer die Ermittlung der Daten und deren Aufteilung auf relationale Tabellen der erste Schritt.
Hier hängt die Effffektivität u. die Lösbarkeit mancher Aufgabe ab. Schaue ins Forum, was manche für Klimmzüge veranstalten da ein verkorkstes Tabellendesign vorhanden

Die Definition der Rechte ist auch meist am Ende zu realisieren, da zunächst alles für alle funktionieren muss/sollte

Die Gestaltung der Optik ist wichtig, da viele Nutzer hiervon ihre Einschätzung abhängig machen.

Ebenso das Formulardesign, hier geht es nicht nur um Optik, sondern auch bestimmte Prinzipzien, Verfahren und Vereinfachungen.
Lese mal im Forum: manche möchten 2 Formulare geöffnet haben, aus einem Formular Werte ins 2. kopieren , irgendwelche  "Synchronisationen"  herstellen usw.

Naja. da kann man immer philosophieren, wichtig ist, dass ganze nicht so statisch zu sehen , sondern in jeder Arbeitsphase immer Rückkopplungen zu beachten! So ganz glatt u. schulbuchmäßig läufst es selten.

Gruß Oma

[database]

Hallo,

Datenorganisation ist ein faszinierendes Betätigungsfeld.
Ich habe vor ein paar Jahren mal ein Skriptum für den Unterricht in Datenbanktechnik geschrieben.
Im Anhang findest du einen kleinen Auszug daraus, der sich auch mit deiner Frage beschäftigt. 

Grüße
Peter

[Anhang gelöscht durch Administrator]

[Tanzmaus4]

Danke für die Tipps, 
ich denke mal, dass ich genug Daten für mein Szenario gesammelt habe, jetzt werde ich mal schauen, ob ich die Entitäten alle finde... 

Ich hätte die Berechtigung vor den Tabellen gemacht, weil man doch einstellen kann, dass alle neuen Tabellen die aktuelle Berechtigung bekommen, oder? Das macht doch viel weniger Arbeit und ist auch weniger fehleranfällig.
Außerdem möchte ich unter allen Umständen vermeiden, dass z.B. Produktionsmitarbeiter solche Daten wie Preise oder Zeiten der Produktionsplanung sehen können.

Mit Automatisierungen meine ich z.B., dass ein erledigter Lieferschein automatisch die Ware aus dem Lager ausbucht.

Arbeitsanweisungen für die Anwender wäre z.B. dass der Lagerist beim "erledigt"-Markieren eines Lieferscheins darauf achtet, ob der Lagerort dann komplett frei geworden ist, oder ob noch weiteres Material auf der Palette war, so dass er den Rest wieder auf den identischen Lagerort stellen MUSS, damit die Datenbank automatisch auslagern kann.

[database]

Das Wichtigste ist ein funktionierendes Datenmodel zu erhalten, zu Anfang ganz ohne Gedanken an Berechtigungen und der Gleichen.
So lange das Datenmodell nicht schlüssig, wideerspruchsfrei und vollständig ist, ist jede andere Entwicklungsarbeit nicht angebracht.

Da es sich bei der neuen Datenbank um eine Access-DB handeln soll wirst du vieles vom FE aus steuern müssen, so wahrscheinlich auch den von dir angesprochenen Automatismus.

Außerdem möchte ich unter allen Umständen vermeiden, dass z.B. Produktionsmitarbeiter solche Daten wie Preise oder Zeiten der Produktionsplanung sehen können.

... auch hier musss das Frontend die Sichtbarkeit von Daten einschränken oder regeln - das wird bei Access auf Tabellenebene nicht laufen.

...den Rest wieder auf den identischen Lagerort stellen MUSS, damit die Datenbank...

Ginge meiner Meinung nach für dich als Entwicklerin der DB zu weit - das sind klare und eindeutige Arbeitsanweisungen, die in die Produktion gehören und nicht in die DB-Entwicklung.
Unter Arbeitsanweisungen fallen m.E die Beschreibungen und Vorgaben zur Bedienung der Applikation (Benutzerhandbuch, etc) - also nicht die Tätigkeiten der Lageristen im Lager.

[Tanzmaus4]

Ginge meiner Meinung nach für dich als Entwicklerin der DB zu weit - das sind klare und eindeutige Arbeitsanweisungen, die in die Produktion gehören und nicht in die DB-Entwicklung.

Da gebe ich dir vollkommen recht, allerdings bin ich nicht "nur" die Entwicklerin dieser Datenbank, sondern auch die Buchhalterin der Firma und "Mädchen für alles". Deshalb muss ich mir auch Gedanken zu Arbeitsanweisungen machen.
Bevor ihr jetzt aber alle mit den Augen rollt  , dass eine Buchhalterin eine Datenbank stricken soll: Ich habe damals mal - vor ewigen Zeiten - Datenverarbeitungskauffrau gelernt und ca. 10 Jahre in SAP und MS Office programmiert. Meine Access-Kentnisse sind nur ein wenig eingerostet, aber das wird schon wieder. 
Dieses Forum bietet schliesslich ein Füllhorn an Tipps und Problemlösungen. Man muss sie nur finden. 

[database]

Aha, ein sogenanntes Rundherumgenie   

Dann sieht die Sache natürlich ein wenig anders aus - wobei aber trotzdem die Empfehlung aufrecht bleibt, dass Produktionsanweisungen die DB-Erstellung NICHT beeinflussen sollen.
Mit den Augen rollt niemand, der ein solches Umfeld kennt.

...Man muss sie nur finden

Na dann ... stell nur deine Fragen, wir werden versuchen das Beste zu geben.