Crow T. Robot

Hat deine zuständige IHK keine Vorlagen zum Download auf ihrer Webseite? Schau mal nach, bei einigen IHKs gibt es das.

Ein fertiges DV-Konzept früherer Projekte kann ich dir leider nicht anbieten, die Zeit habe ich einfach nicht. Schau dir mal Beispielprojekte aus dem Forum an (die Suchfunktion ist dabei dein Freund). Ganz allgemein: Das Fachkonzept, d.h. die fachlichen Funktionen und Anforderungen des Produkts, hast du ja bereits im Pflichtenheft dokumentiert. Es ist nun Aufgabe des DV-Konzeptes diese Aspekte aufzugreifen und aus dv-technischer Sicht zu konkretisieren. Du analysierst also nach und nach die Inhalte des Fachkonzepts (Pflichtenheft) und entwickelst hieraus das Produkt "auf dem Papier" (also ohne Programmierung). Die genannten Darstellungsmethoden (ERD, PAP, UML, ET etc.) dienen zur Visualisierung der Ergebnisse. - Aus den Muß- und Kannkriterien und den Produktfunktionen ergibt sich, was das Programm für den Anwender leisten soll. Beispiel: "Nur Mitarbeiter der Abteilung XYZ dürfen die Stammdaten verändern" -> Zugangskontrolle für die Bearbeitungsfunktion. Hieraus lassen sich also die konkreten Programmfuntionen entwickeln, d.h. Aufbau und Ablauf lassen sich entwickeln. Je nach Ansatz erhältst du Module samt Modulfunktionen (PAP, Struktogramm) oder ein Klassenmodell (UML). - Aus dem Produkteinsatz ergeben sich Anforderungen an die Bedienerführung und Produktumgebung. Hinsichtlich der Bedienerführung sind die fachlichen und (insbesondere) technischen Kenntnisse der Zielgruppe zu beachten. - Die Produktumgebung entscheidet u.a. darüber, welche technischen Schnittstellen einzusetzen sind (Zugriff auf Datenbank, APIs, Dateien, Ein- und Ausgabegeräte etc.). - Die Produktdaten fließen in den Entwurf des Daten[bank]modells ein. Aus den zu verarbeitenden Informationen werden also das Relationen- (ERD) oder Objektmodell (UML) abgeleitet. - Aus den Anforderungen an die Benutzeroberfläche wird ein Entwurf der Benutzerschnittstelle (GUI, Kommandos bei textorientierten Systemen). - Die übrigen Abschnitte des Pflichtenhefts haben Einfluß auf so ziemlich alle bisher erwähnten DV-Teile.

Im DV-Konzept wird beschrieben, wie die einzelnen fachlichen Funktionen und Anforderungen des Fachkonzeptes in die DV umgesetzt werden. Dazu gehören u.a.: - Analyse der Produktumgebung - Wahl der Programmiersprache und des Datenbanksystems (relational?) - Entwicklung des Daten[bank]modells (ERD, Datenflußplan) - Entwurf der Benutzerschnittstellen (GUI, Kommandos) - Modul- oder Klassenentwurf (PAP/Struktogramm, UML, ET) Wichtig ist nur, daß in dieser Phase noch nichts programmiert oder sonstwie implementiert wird. Es geht lediglich darum, eine dv-technische Lösung für die funktionalen Anforderungen (Fachkonzept) zu entwickeln.

Zu eine Access-Anwendung gehören ja bekanntermaßen Tabellen, Abfragen, Formulare, Berichte und ggfs. Module. Ich denke mal bei der Erarbeitung des Feinkonzepts wirst du diese Punkte - soweit sie für dein Projekt relevant sind - ebenfalls ansprechen. Daher könntest du die Realisierung ebenso einteilen: 3. Realisierung 3.1 Einrichten der Datentabellen 3.2 Erstellen der Abfragen 3.3 Entwerfen der Berichte 3.4 Entwerfen der Formulare 3.5 Kodieren der Module 3.6 Testfälle Darauf lassen sich die 40 Stunden sehr detailliert verteilen, wobei 3.1-3.4, 3.5 und 3.6 vermutlich in etwa jeweils 1/3 dieser Zeit einnehmen.

Dafür gibt es die Funktion sprintf(): { char string[10]; int number = 123; sprintf (string, "%d", number); }

Du musst eine sogenannte Projektdokumentation erstellen, in der du die Vorgehensweise der Projektdurchführung dokumentierst. Lies dir die anderen Beiträge in diesem Forum durch, das hilft ungemein weiter. Eine einfache Gliederung kann so aussehen (müsste noch weiter ausgeführt werden): - Thema - Projektschnittstellen - Ablauf- und Ressourcenplanung - Ist-Analyse - Soll-Konzept - Implementierung - Test - Dokumentation - Abnahme - Schlußbetrachtung Die zeitliche Einteilung ist meist schon auf dem Projektantrag anzugeben, außerdem gehört sie in die Ablaufplanung. Das Benutzerhandbuch ist nicht identisch mit der Projektdoku, sondern eine Beschreibung des Produkts für den Endanwender (Manual) und wird meist als zusätzliche Dokumentation gefordert, genauso wie eine Entwicklerdoku (das ist normalerweise der kommentierte Quelltext). Form, Gestaltung und Umfang ergeben sich normalerweise aus den Anforderungen deiner zuständigen IHK. Meistens darf man 10 Seiten nicht überschreiten, wobei Deckblatt, Inhaltsverzeichnis, Anhang und Anlagen hier nicht mit eingerechnet werden.

Hallo IJK! Auch dir erstmal Danke für deinen Beitrag. "Da gibt es Muster".... Ich wollte jetzt schon fragen welche und wofür, bis ich im letzten Moment deine Überschrift "Ereignisdiagramm" gelesen habe... Im IT-Handbuch kann ich das Stichwort aber leider nicht finden, nur die übliche EPK. Und die ist ja für die Darstellung des Geschäftsprozesses. Hilft mir beim DV-Entwurf also nicht weiter... Auf PAP/Struktogramm verzichte ich natürlich nicht ganz, aber ich kann auch nicht jede noch so kleine Routine darstellen, das geht vom Zeit- und Platzaufwand her schon gar nicht. Ich beschränke mich dabei auf einige wenige Funktionen, deren Komplexität das auch rechtfertigt...

Hallo oversize! Erstmal Danke für deine Antwort. Eine Liste aller Module und der zugehörigen Funktionen gibt es natürlich. Allein schon, weil die Schnittstellen ja definiert und dokumentiert werden müssen. Aber daraus alleine ergibt sich natürlich noch kein Programmablauf. Und da der gegenseitige Aufruf der öffentlichen Funktionen quasi "kreuzundquer" verlaufen kann, bräuchte ich eine Tapete, um dort alle Funktionen unterzubringen. Stichwort Kapselung: Da es sich um eine VB-Anwendung handelt, ist natürlich eine vollständige Modularisierung gegeben. Die meisten Funktionen gehören als Ereignisroutinen zu den jeweiligen Formularen, die Hilfsfunktionen sind themenorientiert auf drei "echte" Module verteilt.

Natürlich darfst du fremde Grafiken einsetzen, und das solltest du sogar unbedingt tun, wenn es der Verständlichkeit dient. Du solltest aber auf jeden Fall darauf hinweisen, daß du die Grafiken nicht selbst erstellt hast (wie bei anderen "Fremdleistungen" auch) und woher du diese hast (Quellenangabe, evtl. auch im Quellenverzeichnis).

@ KillingJoke Ob du dir Sorgen machen möchtest überlasse ich mal dir. Aber ich habe von meiner IHK auch erst drei (!) Tage nach Beginn des offiziellen Durchführungszeitraums Bescheid bekommen. Insgesamt hat die IHK knapp sechs Wochen zur Genehmigung gebraucht. Allerdings habe ich rechtzeitig angerufen gehabt, um mir zumindest mündlich das OK zur Durchführung zu holen. Also: Ruf an, die beissen nicht!

Das stammt natürlich von mir und das Testkonzept ist im Pflichtenheft als eigenes Kapitel definiert. Dort ist beschrieben, was wann wie und wo zu testen ist. Die einzelnen Kriterien beziehen sich jeweils auf unterschiedliche Phasen des Projekts (Modultest bei der Kodierung, Funktionstest bei der Integration, sowie begleitende und nachgelagerte Maßnahmen zur Qualitätssicherung. Also danke für deine Mühe und deine hilfreichen Tipps!

Schade dass ausser mir auch niemand eine Idee hat. Vielleicht habe ich mich auch unverständlich ausgedrückt... Es geht darum dass ich nicht alle Programmfunktionen (das sind ein paar Dutzend) in der Konzeptphase dokumentieren kann (PAP oder Struktogramm), der Aufwand wäre viel zu gross. Daher suche ich nach einer Möglichkeit, zumindest den allgemeinen Programmablauf grafisch darzustellen, so dass bestenfalls auch der gegenseitige Aufruf der Modulfunktionen deutlich wird. Hat dazu jemand eine Idee?

So hatte ich das auch nicht gemeint. Gedacht ist, daß mit der Integration und Einweisung ein Teil des Testkonzeptes (Integrations- und Funktionstest) abgearbeitet wird. Wenn bei der Einweisung Fehler auftreten oder von den Anwendern Wünsche bzw. Fragen geäußert werden, wird das Produkt ggfs. überarbeitet. Erst danach erfolgt die endgültige Abnahme. Ist das in dieser Form problematisch? Schliesslich lag die Durchführung immer noch allein bei mir.

Hallo Timmi! Danke für deine Antwort! Die Reihenfolge finde ich einleuchtend und entspricht so ziemlich meinen Vorstellungen, war aber noch unsicher... "Ganz an den Schluss" heisst also, dass das alles nicht mehr zur Durchführung gehört? Oder sollte/könnte ich das als eigenes Kapitel zwischen Durchführung und Projektergebnisse packen? Das sollte besser nicht ausgelagert werden, denn die Einweisung ist tatsächlich auch als Pilotphase gedacht, bei der erste Problemfälle aufgegriffen werden sollen. Gut dass du nochmal drauf hinweist, aber das habe ich von dir schon so oft gelesen, dass ich das niemals mehr vergessen werde.

Möchte sich eventuell noch jemand erbarmen mir ein paar Tipps zu geben. Vor allem interessiert mich wo und in welcher Reihenfolge die noch fehlenden Punkte (Integration, Test, Übergabe, Einweisung der Benutzer, Erstellung der Doku) am besten untergebracht werden.

Hallo zusammen! Wie kann man am besten die Konzipierung es zu erstellenden Programms dokumentieren? Es handelt sich bei mir um eine VB6-Anwendung und viele Funktionen kümmern sich nur um die Ereignissteuerung die der Benutzer mit der GUI auslöst. Der Aufwand für PAP/Struktogramm zu jedem Teil scheint mir viel zu hoch. Doch irgendwie muss man in der Doku ja einen Gesamtüberblick über den Aufbau und die Funktionsweise des Programms bekommen. Hat da jemand eine Idee? Gibt es eine sinnvolle Form, wie man z. B. den gegenseitigen Aufruf der Module und Funktionen darstellen kann? Einen Plan ähnlich wie für den Datenfluß kann man auch schlecht auf einem A4-Blatt unterbringen, da es insgesamt etliche Dutzend (aber zum Großteil sehr kleine) Funktionen sind.

Hallo zusammen! Irgendwie komme ich bei der Dokumentation des Feinkonzeptes durcheinander. Welche Dinge gehören hier genau zum System- und welche zum Programmentwurf? Insgesamt betrifft das ja den Entwurf des Datenbankmodells, der GUI, den Modulen (oder Klassen bei OOP) und Funktionen. Wo gehört hier ein eventuell zu erstellender Prototyp hinein? Kann hier jemand Licht ins Dunkel bringen? :confused:

Hallo zusammen! Ich habe - wie so viele andere zur Zeit auch - einige Fragen zum Aufbau der Dokumentation. Zur Zeit verwende ich eine Gliederung wie unten gezeigt. Wo und in welcher Reihenfolge gehören dort die noch fehlenden Punkte Funktionstest, Integration, Endabnahme, Einweisung und Dokumentation hinein? Gehören die alle noch zur eigentlichen Durchführung oder einiges bereits zu den Ergebnissen (z.B. die Doku-Erstellung)? Ist das ansonsten vollständig, habe ich was übersehen oder gar schon zu stark untergliedert? Bin für alle Hinweise dankbar. 1 Projektbeschreibung 1.1 Einführung 1.2 Einbindung in den Geschäftsprozeß 1.3 Ausgangslage 1.4 Projektziel 1.5 Änderungen gegenüber dem Projektantrag 2 Ablauf- und Ressourcenplanung 2.1 Ablaufplanung 2.2 Sachmittel- und Raumplanung 2.3 Personal- und Kostenplanung 3 Durchführung 3.1 Grobkonzept I / Ist-Zustand 3.2 Grobkonzept II / Soll-Konzept 3.3 Technische Schnittstellen / Technisches Umfeld 3.4 Feinkonzept I / Systementwurf 3.5 Feinkonzept II / Programmentwurf 3.6 Implementierung 4 Projektergebnisse 4.1 Soll-Ist-Vergleich 4.2 Schlußbetrachtung 5 Anhang 5.1 Glossar 5.2 Quellenverzeichnis 5.3 Anlagenverzeichnis

Hallo Krizzpee! Also ich kann mir da relativ gar nichts drunter vorstellen. Und wenn dir das ebenso geht, ist es vielleicht das beste, wenn du direkt mit deinem verantwortlichen Ansprechpartner bei deiner zuständigen IHK in Kontakt trittst. Derjenige, der das geschrieben hat, sollte wohl am besten wissen was gemeint ist.

Besser noch geht's so: SELECT * FROM nutzer WHERE alter BETWEEN 19 AND 38 Schliesst alle Datensätze ein, bei denen der Wert für "alter" zwischen 19 und 38 (jeweils inklusive!) liegt.

Moin zusammen! Hat denn wirklich niemand eine Idee oder Meinung dazu? Über Antworten würde ich mich sehr freuen.

Hallo zusammen! Kurze Frage: Im Projektantrag muss man ja auch die geplanten Präsentationsmittel angeben. Die Vorgaben im Formular (bei uns Flipchart, Tageslichtprojektor) möchte ich aber nur als Notlösung nutzen, falls Laptop/Beamer ausfallen. Soll ich das entsprechende trotzdem ankreuzen, auch wenn ich es planmäßig gar nicht nutzen möchte? Danke schonmal für eure Meinungen...

Hallo zusammen! Unten habe ich die geplanten Projektphasen für meinen Projektantrag aufgeführt. Bei dem Projekt handelt es sich um eine VB-Applikation mit Datenbankzugriff. Es wäre nett wenn ihr mal einen Blick auf diese Aufstellung werfen und diese kommentieren könntet bezüglich Umfang, Genauigkeit, Verständlichkeit und Zeitplanung (ist diese realistisch?). Danke schonmal! 1. Aufnahme des Ist-Zustandes (2 Std.) 2. Erstellung des Soll-Konzepts (2 Std.) 3. Erstellung des Pflichtenhefts (4 Std.) 4. Entwurf des Datenbankmodells (2 Std.) 5. Entwurf der Benutzeroberfläche (5 Std.) 6. Erstellung der Datenbank (2 Std.) 7. Implementierung des Programms (28 Std.) 8. Programmtest und Fehlerkorrektur (5 Std.) 9. Projektabnahme (2 Std.) 10. Installation und Einweisung (2 Std.) 11. Erstellen der Dokumentation (10 Std.) 12. Pufferzeit (6 Std.) 13. Gesamtdauer (inkl. Pufferzeit 70 Std., ohne 64 Std.) Was mich selber etwas stört ist der Punkt 7, könnte man den noch sinnvoll untergliedern? Sollte bei der Gesamtdauer die Pufferzeit eingerechnet werden oder nicht?

Richtig, hatte ich zu spät gelesen... [ich glaube auch, RvP hatte das uns gegenüber mal erwähnt ]

Moment, da muss ich mal nachhaken: AFAIK wird die Ausgestaltung der Dokumentation nicht mit eingerechnet, sondern ausschliesslich die Erstellung des reinen Textes (samt Gliederung), d.h. Gestaltung und "Schmuckwerk" sind sozusagen Privatvergnügen.