Borges

Ohne den Vertrag vollständig und im genauen Wortlaut zu kennen, kann gar keine seriöse Aussage getroffen werden. Gilt ein Tarifvertrag? Gibt es einen Verweis auf einen Tarifvertrag? Gab es Änderungskündigungen? Die beste Lösung ist ein Gespräch mit dem Betriebsrat, falls es einen gibt. Falls nicht, z.B. Gewerkschaftsbüro oder ähnliches suchen und nachfragen. Natürlich mit Vertragskopie.

Standardfehler: -Untergliederungen verlangen mindestens zwei Unterpunkte. -Ich hoffe, gleichwertiger Inhalt ist nicht auf verschiedene Gliederungsebenen verteilt (z.B. 2 und 2.1, 3 und 3.1) -Keine nackten Schlagwörter als Überschriften Die Suchmaschine Deiner Wahl findet für Dich viele Hinweise, wie Gliederungen auszusehen haben. Auf fast jedem Uni-Server findet man entsprechende Merkblätter. Gruß, Borges

Ich bin auch manchmal entsetzt von Dokumentationen, die sich stilistisch wie der Aufsatz "Mein schönster Ferientag" lesen. Insofern vollkommener Konsens. Aber trotzdem erkenne ich aus der Zielsetzung der Projektdokumentation nicht, warum die Vergangenheitsform strikt vermieden werden soll. Schauen wir einmal in die Umsetzungshilfen des BMBF (http://www.bmbf.de/pub/it-abschlussbericht.pdf) Eine handlungsorientierte Darstellung (dieser Begriff wird auch von unserer IHK in ihren Handreichungen genutzt) ist keine reine technische Dokumentation, keine Benutzerdokumentation oder ähnliches. Präsens dahin, wo es hingehört. Bei der Beschreibung von Programmfunktionen wie im Ausgangsbeispiel sicher. Bei den kundenbezogenen Dokumenten im Anhang auch. Aber die Projektdokumentation ist viel mehr. Was ist, wenn durch externe Ereignisse Änderungen im Projektablauf notwendig geworden sind. Wenn Tests ergeben haben, dass eine Funktion nicht den Wünschen des Auftraggebers entsprochen hat und daraufhin Änderungen erfolgten? Das muss doch alles dort hinein (handlungsorientiert!). Ein völliger Verzicht auf die Vergangenheitsform ergibt für mich nur dann Sinn, wenn die Dokumentation in Form eines Projekttagebuchs erfolgt. Die Beispieldokumentationen in den Umsetzungshilfen des BMBF scheinen meine Auffassung da zu unterstützen. Und ich habe den Eindruck, dass unsere Prüfungsausschüsse (Duisburg) das auch pragmatisch sehen. Die ärgert eher ein Blödsinn wie "Soll-Analyse". Übrigens gilt ähnliches für die strikte Vermeidung der "Ich"-Form mit analogen Argumenten. Ich habe dazu auch schon die Aussage gehört, dass eine zu neutrale Schreibweise manchmal nicht erkennen lässt, wo die Fremdleistungen in einem Projekt aufhören und die Eigenleistung (oder auch Handlung) anfängt. Gruß, Borges

Die Reflektion war nur ein Beispiel. Ein Anderes: Die strikte Verwendung des Präsens wirkt IMHO lächerlich, wenn im Projektverlauf ein unvorhergesehenes Ereignis eintritt, das dann zu einer Änderung der ursprünglichen Konzeption führt. Das passierte nun einmal in der Vergangenheit. Ich will damit nur sagen, dass pauschale Aussagen blödsinnig sind :-) Gruß, Borges

Wer sagt das? Es geht hier um die Dokumentation eines abgeschlossenen konkreten Projektes, nicht um eine Benutzerdokumentation oder ähnliches. Wie kann man im Präsens eine abgeschlossene Handlung reflektieren? Gruß, Borges

Das Wochenende scheint für mich schon zu nah zu sein...was meinst Du genau? -Zitiert habe ich aus: http://www.bmbf.de/pub/it-abschlussbericht.pdf -Aúch immer wieder nett sind die Handreichungen der IHK z.B. unter http://www.ihk-duisburg.de/downloads/Handreichungen_IT-Berufe.pdf Sollte konkret das Pflichtenheft gemeint sein, kann ich nur auf die DIN VDI/VDE3694 verweisen. Die wollte der Prüfungsausschuss im o.g. Fall ausdrücklich berücksichtigt haben. Schönes Wochenende! Gruß, Borges

.::NotesUser::. schrieb: >Ist das nicht ein wenig viel? >Man soll doch die Doku innerhalb von 10 Std als FIAE fertig stellen... Achtung, Missverständnis! Die Dokumentation ist "eine handlungsorientierte Darstellung des Projektablaufes mit praxisbezogenen, d.h. betriebsüblichen Unterlagen" (siehe Umsetzungshilfen des BMF). Das Pflichtenheft ist ein Arbeitsergebniss, entweder als Teil eines umfangreicheren Projektes oder als eigenständiges Projekt. Daher sollte in der Dokumentation "nur" die Vorgehensweise beschrieben werden und das Pflichtenheft selbst dann in den Anhang (sofern erforderlich). Die Zeit, die dafür erforderlich ist, geht nicht zu Lasten der Dokumentation, sondern gehört in die entsprechende Projektphase. Das sollte schon im Projektantrag berücksichtigt worden sein. Der Quellcode einer Anwendung steht ja auch nicht vollständig im eigentlichen Bericht. Einer meiner FIs hat als Anwendungsentwickler die Erstellung eines Pflichtenheftes als Projektthema gewählt. Dort wurde dann im Projektbericht der Prozeß der Erstellung beschrieben, das eigentliche Pflichtenheft hätte dann einen halben Ordner füllen können. Die Wahl zeigte Mut zum Risiko, da ein solches Projekt im Bereich unserer IHK (Duisburg) wohl noch nicht so oft vorgekommen ist. Das weckt natürlich Aufmerksamkeit bei den Prüfern, im positiven wie negativen Sinne. Aber es hat sich für den (Ex-)Auszubildenden gelohnt ;-) Gruß, Borges

Der o.g. Termin für die IHK-Duisburg taucht auf der Info-Seite zur vorgezogenen Prüfung auf: http://www.ihk-duisburg.de/ihk.asp?his=3.29.1441 Frage aber vorsichtshalber bei den zuständigen Mitarbeiter/innen dort nach (http://www.ihk-duisburg.de/ihk.asp?his=3.29.1438), da gerade auf das Online-Verfahren umgestellt wird. Dadurch standen bis vor kurzem einige Termine noch nicht ganz fest. Aus taktischen Gründen sollte man den Antrag aber möglichst "gestern" abgegeben haben. Bei z. B. den Informatikkaufleuten hatte man dann die Chance, ausserhalb des offiziellen Genehmigungsverfahrens schon einige Hinweise des Prüfungsausschusses zu erhalten, ob der Antrag genehmigungsfähig ist. Gruß, Borges

Bitte als *.pdf oder *.rtf. Hier sind noch alte Office-Versionen im Einsatz (warum auch nicht?). Die Annahme, Word 2k oder xp muss doch jeder haben oder lesen oder konvertieren können, führt bei mir zu einer ...ähem... inneren Abwehrhaltung gegen die Bewerbung. Das zeigt, sich keine Gedanken gemacht zu haben. Gruß, Borges