Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Klasse_ Datenbanken_SQL Projekt_ Projektdokumentation

VIEWS: 13 PAGES: 4

  • pg 1
									Thomas–Eßer–Berufskolleg
Klasse: Datenbanken/SQL

Projekt: Projektdokumentation
IHK-Vorgaben
Stichwort Zielstellung Konkretisierung (Kursiv- und Kleinschrift nur für die schulische Durchführung relevant) Mit der Projektarbeit und deren Dokumentation soll der Prüfungsteilnehmer belegen, dass er Arbeitsabläufe und Teilaufgaben zielorientiert unter Beachtung wirtschaftlicher, technischer, organisatorischer und zeitlicher Vorgaben selbständig planen und kundengerecht umsetzen sowie Dokumentationen kundengerecht anfertigen, zusammenstellen und modifizieren kann. Die Ausführung der Projektarbeit wird mit praxisbezogenen Unterlagen dokumentiert. Der Prüfungsausschuss bewertet also die Projektarbeit anhand der Dokumentation. Dabei wird nicht nur das Ergebnis, z. B. ein lauffähiges Programm oder ein funktionierendes Netzwerk, herangezogen, sondern auch der Arbeitsprozess. Die Dokumentation soll eine handlungs- und kundenorientierte Darstellung des Projektablaufs sein. (aus Handreichung IT-Berufe, IHK Aachen) Die Projektdokumentation muss ein Deckblatt der Projektarbeit besitzen, mit dem Titel "Schriftliche Projektarbeit zur Abschlussprüfung zum/zur Berufsbezeichnung (ggf. Fachrichtung) (ITA hat keine Fachrichtung)“ und Thema. Sowie mit Name, Anschrift (Anschrift nicht erforderlich) des Prüfungsteilnehmers, der Angabe des Durchführungszeitraums, der Anschrift des Ausbildungs- bzw. Prüfbetriebs (hier die Schule) und Namen des betrieblichen Verantwortlichen (der/die zuständige/n Fachlehrer) versehen sein Die Seitenzahl (ohne Anhang) von ca. 10-15 sollte man nicht überschreiten (pro weiterem Teammitglied kann die Seitenzahl um 3-5 Seiten überschritten werden); max. 5MB (pro weiterem Teammitglied kann die MB-Größe um 1-2 MB überschritten werden) im PDF Format (zu Korrekturzwecken ist die Datei im Word-Format abzugeben), sowie in einem Anhang praxisbezogene Dokumente und Unterlagen beinhalten. Die eigentlichen Seiten und Anlagen sind zu nummerieren; Ausnahme: Deckblatt, Gliederung und externe Anlagen Quelltexte (SQL-Statements) der im Projekt erstellten Programme sind für das Berufsbild des Fachinformatikers Anwendungsentwicklung (ITA) in schriftlicher Form im Anhang beizulegen. Dabei sollten sich die Quelltexte auf die selbst geschriebenen Anweisungen und die zum Verständnis dieser Programmteile notwendigen fremd erstellten Sourcen beschränken. Neben der schriftlichen Form können Quelltexte auch in einem mit gängigen Editoren lesbaren Format auf CD beigefügt werden. Saubere und korrekte Gestaltung, Rechtschreibung, Grammatik und Ausdruck, stellen ein durchaus wesentliches Kriterium für die Bewertung dar siehe Erwartungshorizont zum Quellennachweis bei Schriftliche Arbeiten Layout

Deckblatt

Umfang

Quelltexte

Formelle Gestaltung Quelle

Gliederungspunkte Punkte Allgemein

Konkretisierung Die Gliederung der Dokumentation sollte (grob) folgenden Aufbau haben: formellen Haupttitel (bei allen dann gleich) inhaltlichen Untertitel (bei allen dann verschieden)
Beispiel: 4. Durchführung 4.1 Installation der Netzwerkkabel

Im Titel sollte schon die zu leistende Tätigkeit genannt werden:
Statt: Server lieber: Server installieren und konfigurieren oder Installation und Konfiguration des Servers

Gliederung (Vorschlag)

1. Projektüberblick 1.1 Projektthema 1.2 Projektbeschreibung 1.3 Projektumfeld und Rahmenbedingungen 2. Problemanalyse 2.1 Ist-Analyse 2.2 Ableitung des Soll-Zustandes 3. Auswahl des Lösungsweges 3.1 Aufzeigen von Lösungsalternativen 3.2 Bestimmung und Begründung des gewählten Lösungsweges 4. Planung der Durchführung 4.1 Festlegung der Lösungsschritte 4.2 Zeit- und Ressourcenplanung 5. Durchführung 5.1 Dokumentation der Arbeitsschritte 5.2 Darstellung aufgetretener Probleme 5.3 Beschreibung von Planungsabweichungen 6. Evaluation der Projektergebnisse 6.1 Vergleich des Ergebnisses (neuer Ist-Zustand) mit dem Soll-Konzept 6.2 Bewertung entstandener Abweichung
Seite 1 von 4 Seite(n) 72b3ae62-1f47-4c3f-a451-c252b6fcfe53.doc 27.11.2007/26.01.2010

R. Nowaczyk

Klasse: Datenbanken/SQL Projekt: Projektdokumentation 6.3 Resümee 7. Evaluation des Projektverlaufs 8. Ausblick A. Glossar B. Anhang Erläuterung der Gliederungspunkte Gliederungspunkt Konkretisierung (Kursiv- und Kleinschrift nur für die betriebliche Durchführung relevant) Projektthema  Wiederholung des Projekttitels Projektbeschreibung  allgemeine Beschreibung des Projektes Projektumfeld und  Darstellung des Betriebes der Schule Rahmenbedingungen  Geschäftsbereiche, Tätigkeitsfelder  lokales Umfeld  Größe/Mitarbeitergröße  IT–Infrastruktur  Zuordnung des Projektes zur Abteilung, Kollegen, Projektbetreuer  allgemeine Beschreibung des Anlasses für das Projekt  sonstige relevanten, allgemeinen Prunkte bezogen auf den Projektgegenstand Problemanalyse  Beschreibung der derzeitigen Situation (Vorher) bezogen auf das Projektthema Ist–Analyse  Hier können Fehler, Nachteile, Defizite und Unzulänglichkeiten der derzeitigen Lösung genannt werden  Hier sollte der konkrete Handlungsbedarf aufgezeigt werden.  Dem Leser soll klar werden: So kann es nicht bleiben Soll–Analyse  Beschreibung der zukünftigen Situation (Nachher)  hier konkret beschreiben, was das Projekt leisten soll  z.B. bei einer Softwareentwicklung: die Funktionalitäten des Programms  Hier können Vorteile, Nutzen, Verbesserungen, Ersparnisse der zukünftigen Lösung genannt werden  Einbeziehung von Schnittstellen (z.B. es sollen regelmäßige Teamsitzungen zum Projektfortschritt durchgeführt werden)  Kostenkalkulation (wenn tatsächlich Kosten entstehen)  Vorteile usw. begründen  Hier wird das Thema abgegrenzt  das mache ich  das mache ich nicht (mit Begründung)  das mache ich später (mit Begründung) Auswahl des  mögliche alternative Lösungswege beschreiben Lösungsweges  z.B. eine andere Programmiersprache benutzen (statt Visual Basic in C/C++ Aufzeigen von programmieren Lösungsalternativen  ein anderes Betriebssystem aufspielen (statt Windows 2000 Linux als Serverbetriebssystem)  mögliche alternative Vorgehensweisen beschreiben  Vor– und Nachteile darstellen und abwägen Bestimmung und  begründete Entscheidung für den gewählten Lösungsweg Begründung des  Darstellung von Zwängen und Gegebenheiten die den gewählten Lösungsweg untermauern gewählten  Vor– und Nachteile gewichten Lösungsweges Planung der  abgeleitet aus der Soll–Analyse Durchführung  Beschreibung der Tätigkeiten und Arbeitsschritte in ihrer sachlogischen Reihenfolge Festlegung der  Beschreibung des (zeitlichen) Ablaufes des Projektes Lösungsschritte  soll etwas programmiert werden, stehen hier die Anforderungen/Schwierigkeiten wofür es programmiertechnische Routinen/Lösungen geben muss  soll etwas bewertet/eingeschätzt/analysiert werden, kommen hier die Kriterien, der Maßstab, die Indikatoren für die spätere Bewertung  soll etwas getestet oder erprobt werden, kommt hier die Beschreibung der “Testkandidaten”  Beschreibung möglicher Probleme und deren Lösung  Beschreibung möglicher alternativer Vorgehensweisen
R. Nowaczyk Seite 2 von 4 Seiten 72b3ae62-1f47-4c3f-a451-c252b6fcfe53.doc 27.11.2007/26.01.2010

Klasse: Datenbanken/SQL Projekt: Projektdokumentation Zeitund Ressourcenplanung          Vergleich mit der im Antrag abgegebenen Planung, evtl. Abweichung begründen prognostizierte Dauer der Prozessschritte Einsatz der Ressourcen was brauche ich für die Durchführung des Projektes (Menschen, Material, sonstige technischen Voraussetzungen) Beschreibung der (technischen) Anforderungen des Projektes abgeleitet aus der Planung analog zur Darstellung des Soll–Konzeptes und ihrer planerischen Realisierung bei den Lösungsschritten wird hier die Durchführung beschrieben (bitte auf ähnliche Reihenfolge achten) eingebettet in eine zeitlineare Darstellung, funktionale Schwerpunkte setzen und besonders beschreiben (z.B. Gespräche mit Schnittstellen) es geht weniger darum, um die haargenauer Beschreibung der Durchführung sondern zwischen den Zeilen muss folgendes deutlich werden:  Kompetenz des Durchführenden  fachliche Fundiertheit der Durchführung  sachlogische Richtigkeit der Reihenfolge der Schritte  Plausibilität  Authentizität  Vorausschau  Nachhaltigkeit der Projektlösung Beschreibung des Vorgehens und der Tätigkeiten Beschreibung der Umsetzung der (technischen) Anforderungen des Projektes wurde etwas programmiert, stehen hier (exemplarisch) die verwendeten Programmierroutinen wurde etwas bewertet/eingeschätzt/analysiert, kommt hier die Darstellung der Ergebnisse wurde etwas getestet oder erprobt, dann kommt hier die Darstellung der Ergebnisse Beschreibung der Prozessschritte aufgetretene Probleme zusammenfassend beschreiben wo gab es erwartete oder unvorhergesehene Probleme zur Planung wo gab es erwartete oder unvorhergesehene Probleme bei der Durchführung mögliche Gründe darstellen mögliche Konsequenzen ziehen und darstellen (konkrete) Abweichungen von der Planung beschreiben Gründe für die Planabweichung beschreiben inwieweit hat sich der Plan realisiert wo gab es Veränderungen zur Planung Bemerkungen zum Zeitmanagement (Plan und Realität) Zustände vergleichen evtl. Einschränkungen der Projektlösung beschreiben (wenn nicht alles geschafft wurde) Bezug schaffen zur soll/ist Analyse wurde etwas analysiert, dann kommt hier die Bewertung und die Gewichtung der Ergebnisse wurde etwas getestet, dann kommt hier die Bewertung und die Gewichtung der Ergebnisse

Durchführung Dokumentation Arbeitsschritte

der

Darstellung aufgetretener Probleme

Beschreibung von Planungsabweichung en

Evaluation der Projektergebnisse Vergleich des Ergebnisses (neuer Ist-Zustand) mit dem Soll-Konzept Bewertung entstandener Abweichung Resümee Evaluation Projektverlaufs Ausblick des

                    

 fallen die Abweichungen ins Gewicht  sieht nun die Projektlösung anders/verändert aus        welche Fehler/Mängel wurden vorausgesehen, was war nicht voraussehbar wo gab es Mängel in der Planung was habe ich durch das Projekt gelernt Beschreibung des subjektiven Faktors (irgendwas persönliches) evtl. noch einmal Vergleich Planung und tatsächliche Durchführung was ist evtl. offen geblieben, wo wird weiter gemacht gibt es schon praktische Erfahrungen im Umgang mit der Projektlösung

R. Nowaczyk

Seite 3 von 4 Seiten

72b3ae62-1f47-4c3f-a451-c252b6fcfe53.doc

27.11.2007/26.01.2010

Klasse: Datenbanken/SQL Projekt: Projektdokumentation Anhang          Bedienungsanleitung Dokumentation evtl. Screenshots größere Tabellen oder Übersichten Quellen– und Literaturangabe Erläuterung von Fachbegriffen (Glossar) Struktogramme exemplarischer Quellcode Originalmaterial (Formulare, Angebote etc.)

zum Stil der Dokumentation (so sollte man es nicht machen)  kein Tagebuchstil (Dann habe ich das gemacht, danach jenes)  z.B. bei der Installation eines Betriebssystems muss nicht jeder Installationsschritt (z.B. Einstellen des deutschen Tastaturlayouts) dargestellt werden, sondern nur die wichtigsten, wo eine Entscheidungskompetenz abverlangt wird, wo man exemplarisch was deutlich machen kann (z.B. bei der Vergabe des Computernamens ein System bei der Namensvergabe)  den Ich–Erzählstil sehr zurückhaltend und dezent anwenden (da wo vielleicht persönliche Entscheidungen getroffen wurden, da wo mit anderen gesprochen wurde etc.)  Bitte keinen Mitleidserzählstil: Statt “Dann mussten wir die Kabelschächte installieren” lieber “Für die sachgerechte Verlegung der Kabel installierten wir Kabelschächte”  Auch keine Selbstbeweihräucherung: Sätze wie “... musste mit viel Feinarbeit und Geduld gearbeitet werden”  Auch keine Sätze die eigene Fehler episch ausbreiten. Statt “Woran ich jedoch scheiterte, aber eine Prozedur im Internet fand, die genau dies erledigte.” lieber “Bei meiner Recherche im Internet stieß ich auf eine Routine, ... Statt “Hier gab es ein weiteres Problem, da das Programm abwechselnd in Access2000 und Acccess2002 programmiert wurde” lieber Beim Testen des Programms in Access2000 und Acccess2002 stellte sich heraus... Die Lösung war ...  Bitte in der Projektdokumentation nicht “hoffen”: keine Sätze wie “Nach einigen Tests hoffe ich...  Grundsätzlich: keine persönlichen Anreden oder Eigennamen in der Dokumentation, stattdessen Funktionsbezeichnungen oder neutrale Anreden  Keine Probleme treten unerwartet, unvorhergesehen oder plötzlich auf. Sie treten einfach auf und werden sofort gelöst bzw. mit ihnen wird (souverän) umgegangen.  Auch wenn es schwer fällt: Bitte nicht soviel emotionale Nähe zum Projekt sprachlich ausdrücken  Wenn Dinge aus Zeitgründen nicht realisiert werden können, dann nicht im Stil des eigenen Versagens darstellen, wenn Dinge innerhalb der Projektzeit nicht realisiert werden, werden sie halt danach fertig, also verschieben  bitte sich nicht in Details verlieren. zum Stil der Dokumentation (so sollte man es machen)  Man schreibt die Dokumentation quasi als Außenstehender der jemanden bei der Planung, Durchführung und Auswertung des Projektes beobachtet.  nicht (nur) das Produkt sondern den Prozess beschreiben  Schwerpunkt der Darstellung/des Stils ist nicht der Projektdurchführende sondern die Sache/der Prozess (Also weniger ich...)  Schwerpunkt der Darstellung/des Stils ist nicht der zeitliche Ablauf (Dann war das, danach kam das ...) sondern der funktionale bzw. strukturelle Zusammenhang (Darstellung der programmierten Fehlerbehandlungsroutinen, Darstellung der ergriffenen Sicherheitsmaßnahmen) des Projekts  Schwerpunkt der Darstellung/des Stils ist nicht die detailgetreue und genaue Beschreibung des Projektes (bitte sich nicht in Details verlieren) sondern der exemplarische Überblick, der funktionale bzw. strukturelle Zusammenhang  die Darstellung und Begründung wichtiger Entscheidung  der kompetente Umgang mit Schnittstellen (Mitarbeitern, Lieferanten etc.)  die Berücksichtigung und das Abwägen von Alternativen  der lösungsorientierte Umgang mit Problemen  die Nachhaltigkeit  die Vorausschau  zum exemplarischen Überblick noch mal: Wichtig ist, dass man Punkte beschreibt, die beispielhaft für die Kompetenz des Prüflings stehen. Beispiele:  diese Fehlerbehandlungsroutine steht (beispielhaft) für den Umgang mit fehlerhaften Benutzereingaben  die Installation des Kabelschachts steht für die sachgerechte Verlegung  der Durchmesser des Lochs steht für die Nachhaltigkeit (evtl. weitere Verlegungen von Kabeln)  Tabellen kommentieren und einleiten, Schlussfolgerungen benennen, Legende mitliefern  Aufzählungen sollten nie "alleine" stehen, sondern immer erst einem einleitenden Text folgen  Standardmäßig wird in Dokumentationen Blocksatz eingesetzt und nicht linksbündige Absatzformatierung  Bitte weniger Bindestrich-Konstruktionen, vieles schreibt man einfach ganz normal zusammen z.B. Zeitplan  Die Dokumente nicht so formatieren, (z.B. durch Textboxen), dass sie sich in der Normalansicht und Seitenlayoutansicht zu stark unterscheiden.  Überschriften bzw. Tabellen und Bilder immer textlich einleiten d.h. einen Einleitungssatz schreiben (z.B. Hier werden tabellarisch die wesentlichen Daten zum Projekt aufgeführt ...)  Die Titelseite bekommt keine Seitennummerierung, diese setzt erst nach dem Inhaltsverzeichnis ein  Zahlenangaben bis zwölf werden ausgeschrieben, es muss also heißen "drei" und nicht 3  Die Funktionalitäten von Word wie Absatzformatierung, Überschriftennummerierung, automatisches Erstellen des Inhaltsverzeichnisses, Tabulator, Fußnoten etc. nutzen

R. Nowaczyk

Seite 4 von 4 Seiten

72b3ae62-1f47-4c3f-a451-c252b6fcfe53.doc

27.11.2007/26.01.2010


								
To top