CSharp

Hallo, ich lebe in Köln, arbeite in Köln und zuständig war für mich auch IHK Köln, hatte ich aber glaube ich auch schon mal geschrieben ) aber hast völlig Recht. Wenn das stimmt was der Kollege da sagt sollte er IHK und Wohnort nennen, dann kann jemand mal recherchieren. Denn eigentlich sollte ja gleiches Recht für alle gelten und nicht die einen schreiben können was sie wollen während die anderen auf 20 Seiten beschränkt sind. gruß cSharp

Supi! Das ist genau das, was die anwesenden Prüflinge hier hören wollen. Und wenn in deiner von 200 Seiten auf 30 Seiten gekürzten Doku einige wesentliche Punkte fehlen? Nimmst Du das dann auf deine Kappe? Woher weißt Du bei deinem In-die-Hand-Nehmen-und-wiegen dass die Doku nicht so qualitativ wesentlich hochwertiger war als die restringierte 30 Seiten Doku? Ich glaube einfach nicht dass ein Anwendungsentwickler mit 30 Seiten Dokumentation auskommt, wenn man so etwas wie 1,5 Zeiligen Text und 4 cm Rand zzgl. Fußnoten voraussetzt. Es geht der IHK aber nach meinen Informationen nicht nur um ein Kundenprojekt, sondern vor allem darum, den kompletten Entwicklungsvorgang vom Auftrag bis zur Projektübergabe und Wartung nachvollziehen zu können. Wenn jemand eine 200 Seiten Doku vernünftig aufzieht, dann könnt ihr Prüfer euch heraussuchen was ihr lesen wollt. Wenn euch die technische Doku nicht interessiert, dann lasst sie eben liegen. Wenn euch Lastenheft und Pflichtenheft nur grob interessieren, dann schaut halt nur mal kurz drüber. Ich gehe bei meinen Ausführungen nur davon aus, dass der Azubi sehr wohl darüber nachgedacht hat, was er wie in die Doku reinpakt und nicht einfach alles zusammengeschmissen hat was noch irgendwie von Bedeutung sein könnte, noch dazu ohne jegliches Konzept. Aber ich habe meine Doku so aufgezogen dass man im Anhang selbst nochmal den Entwicklungsprozess nachvollziehen konnte, einige Verweise darauf im Prozessbericht taten ihr übriges. Die 10 Seiten prozessorientierter Projektbericht sind das Kernstück. Und wenn ich darin schreibe "Als Konzept lege ich dem Auftraggeber das Lastenheft vor" oder "Mit dem abgeschlossenem Projekt erhält der Auftraggeber die Benutzer - Dokumentation" ist es doch nur gut wenn ich diese dann auch in den Anhang packe. Sowas als "Müll" zu bezeichnen denke ich ist bezeichnend für die Motivation, sorry... gruß cSharp

Hallo, mir wurde aber explizit gesagt, ich solle die Originaldokumente hinzupacken. Und die Originaldokumente waren mit Screenshoots. Wohlgemerkt, im Anhang! Ich glaube nicht, dass sich die Prüfer sämtlichen Anhang durchgelesen haben und diesen Inhalt noch zur Prüfung hinzunommen haben. Es geht doch mehr darum, dass es ein realistisches Projekt ist. Und die Doku ist nunmal das wichtigste, sodass ich durchaus verstehen kann, dass die Prüfer alles haben wollen. Denn erzählen kann ich als Prüfling viel, wenn ich die geschriebene Doku vorlegen kann, dann kann mir keiner sagen, dass ich kein realistisches Projekt durchgeführt habe. Denn der IHK liegt alles vor: Das eigentliche Projekt und sämtliche Schriftstücke dazu, mit denen die Prüfer alles nachvollziehen können. Hierzu muss ich dann nur noch sämtliche Fragen beantworten können, dann kann bei der Prüfung eigentlich nichts mehr schiefgehen, es sei denn, man schreibt im Projektbericht absoluten Murks. gruß cSharp

Hallo timmibonn, klar ist für ein Listing etc. Courier oder ähnliches die erste Wahl, aber trotzdem habe ich noch keinen in meinem Jahrgang und auch bei den vorhergehenden Jahrgängen gesehen, die einen kompletten Bericht in Courier gesetzt haben. Wenn man vorher ein halbwegs vernünftiges Konzept hatte wie das Projekt durchzuführen ist, dann gehört man ganz schnell zu der Kategorie dass man nicht weiß, wie man mit 10 Seiten Projektbericht auskommen sollen. 80 Seiten Anhang? Und was machst Du dann mit 200 Seiten Anhang? Ich habe seinerzeit die IHK Köln kontaktiert und gefragt, was sie in der Doku alles bräuchten. Als Antwort kam dann pauschal: "Alles, was im Rahmen des Projektes erstellt wurde". Auch sämtlichen Sourcecode, und das wurde sogar nochmal betont. Also: Projektbericht: 10 Seiten Lastenheft: 4 Seiten Pflichtenheft: 8 Seiten Testprotokolle: 5 Seiten technische Doku: 8 Seiten Anwenderdoku: 15 Seiten (Screenshoots nehmen viel Platz ein) sonstige Schriftstücke: 5 Seiten (Testplanung, Abnahmeprotokoll etc.) dann sind wir schon bei 40 Seiten im Anhang + 10 Seiten Projektbericht, und ich habe noch keinen Sourcecode hinzugefügt. Das waren bei mir unmengen, denn die ASP Seiten und das Backend wurden noch um das Frontend erweitert, und hier kommen schnell mal >100 Seiten Sourcecode zusammen, aber das sollte laut IHK Köln alles hinein. Natürlich schön sortiert mit Deckblättern etc. Ich habe von den 70 Stunden Softwareentwicklung sicherlich 30 Stunden durchgetippert, und da die meisten Anwendungsentwickler recht schnell tippen können (nach einem guten Konzept ist die Implementierung nur noch Formsache), kommen da eben recht viele Seiten zu stande. Wie gesagt: Was machst du damit? gruß cSharp

Hallo, ich glaube dass die meisten eher Probleme mit zuwenig Platz haben, nicht mit zuviel Platz. D.h. die meisten werden versuchen durch eine andere Schriftart noch mehr in den Bericht unterzubringen, denn die 10 Seiten sind verflucht wenig. Aber dafür gibt´s ja einige Tricks ) gruß cSharp

Hallo, ich habe bei meinem Projekt eine Ist Analyse mit Hilfe eines Lastenheftes gemacht und ein Sollkonzept erstellt, das Ergebnis dieser Konzeptphase war das Pflichtenheft, welches der Auftraggeber anschließend erhalten hat. Dieses Pflichtenheft und das zu Grunde liegende Lastenheft habe ich in die Dokumentation gepackt und sollte an Konzeptdoku ausreichen. Hinzu kamen noch Protokolle, Anwenderdoku, technische Doku, Plandoku (wirtschaftlich, zeitlich => Milestoneplan) und natürlich prozessorientierter Projektbericht. Ach ja, und ein "Projekttagebuch" habe ich auch noch hinzugefügt, das habe ich nicht in meinen Projektbericht eingearbeitet. Damit ist die Doku vollständig... ) gruß cSharp

Hallo, nein, der wird in den Berufsschulen - zumindest in meiner ehemaligen - höchstens mal kurz angeschnitten, und ich war bis auf ingesamt 3 Fehltage in meinen kompletten 3 Jahren immer da. Das Ganze kommt viel zu kurz, zumindestens in der theoretischen Ausbildung. Im Betrieb ist das was anderes... gruß cSharp

Hallo, also: du musst einen Kundenauftrag bearbeiten. Dazu gehört sowohl die Konzeptphase, die Realisierungsphase, die Testphase und die Projektübergabe. Also musst du ein Pflichtenheft und anschließend ein Softwareprodukt mit Dokumentation erstellen. Vergiß die Wirtschaftlichen Aspekte deines Projektes nicht zu planen und abschließend zu bewerten. Mit deiner Abschlussprüfung sollst du beweisen, dass du einen Auftrag mit allen Facetten selbstständig bearbeiten kannst. Fremdleistungen sind in der Doku entsprechend zu kennzeichnen. Wenn du noch weitere Fragen hast, sach einfach Bescheid... gruß cSharp PS: Lass dich von den 70 Stunden nicht abschrecken, das geht ohne Probleme auch wenn man sich wirklich daran hält )

Hallo, mach blos nicht den Fehler dass du darauf baust dass die Prüfer keine Ahnung hätten. Es gibt wohl auch Prüfer die sich extra für eine Prüfung mit neuen Themen befassen um dir einige grundliegende und auch tiefer gehende Fragn zu stellen. Und bei der Doku finden die Prüfer auch den kleinsten Schnitzer, deswegen bereite dich sehr gut auf dein Fachgespräch vor. Du musst als Experte für dein Projekt auftreten und alle Fragen rund um dein Projekt beantworten können. Vor allem: Warum hast du das Projekt so gemacht und nicht anders? Welche Alternativen gab es und warum hast du dich für diese entschieden (wirtschaftlich argumentieren!)? gruß cSharp

Hallo, in welchem Ausbildungsjahr bist du? gruß cSharp

Hallo, Lastenheft: WAS WOFÜR? => ein erstes Zusammenschreiben des Auftrags, was das Projekt bewirken soll, Motivation für das Projekt (hier NICHT "IT Abschlussprüfung reinschreiben!!!"), Pflichtkriterien, Wunschkriterien, Abgrenzungskriterien usw. sprich einfach heruntergeschrieben was der "kunde" haben will. Meistens wird das Lastenheft auch vom Kunden selbst geschrieben. Pflichtenheft: WIE? WOMIT? => eine Verfeinerung des Pflichtenheftes, enthält auch schon eine Art Konzept, auf jeden Fall eine Verfeinerung der ersten Anforderungen aus dem Lastenheft und die Lösungsstrategie. Zusätzlich noch eine verfeinerte Aufwandsplanung und die Ergebnisse der Ist-Analyse System-/Programmdokumentation: Dokumentation in dem das Produkt von seiner technischen Seite her erklärt wird => Kernfunktionen erläutern, wichtigste Struktogramme und Ablaufpläne, Sourcecode, ER Diagramme, Datenbankzugriffe, Datenflussdiagramme usw. Benutzerdokumentation: Hier mit Hilfe von Screenshoots dem Benutzer das Programm erklären. "Um einen Ping auszuführen klicken sie bitte HIER!" )

Hallo, ich kenne jemanden der in Köln im FISI Prüfungsausschuss sitzt, und da wurde uns gesagt dass der Prüfungsausschuss von mal zu mal verstärkter darauf achtet, dass die Prüflinge etwas aus ihrem Berufsbild machen und nur geringe Teile einer berufsverwandten Tätigkeit machen. Geht lieber auf Nummer sicher, ansonsten habt ihr nachher das Problem... gruß cSharp

Hallo, such etwas nützliches für deine Arbeitsumgebung. Etwas was die Arbeit der anderen Programmierer oder der anderen Kollegen erleichtert. Und wenn es das Verwalltungsprogramm einer Backuplösung ist, die den Zustand, den Aufbewahrungsort und die Rahmendaten der Backups der Firmenserver in einem Webfrontend oder in einem VS Frontend anzeigt und bei Bedarf den jeweiligen User darüber informiert, dass noch ein Backup gemacht werden muss bzw. das Bänder gewechselt werden müssen, so in die Richtung, allerdings sollte man ein so einfaches Projekt ein wenig ausarbeiten. Viel wichtiger als das Projekt ist der Entwicklungsprozess und die Dokumentation. 4 Dokumente solltest du auf jeden Fall unaufgefordert erstellen: 1. Lastenheft 2. Pflichtenheft 3. Programm-/Systemdokumentation 4. Benutzerdokumentation Ansonsten sollte das Projekt so gewählt sein dass man die Vorzüge des Produktes hervorheben kann, vor allem die Wirtschaftlichkeit. Gruß cSharp

Hallo, du bist FISI und machst die Aufgaben eines FIAE, das kannst du vergessen! nur ein ganz kleiner Teil darf von einem Artverwandten Beruf sein, der Rest sollte aus der Kernqualifikation sein. Also: Du als FISI darfst nicht ein Projekt machen was eindeutig von einem FIAE gemacht werden sollte, das wird die IHK sicherlich ablehnen und wenn nicht kommst du spätestens beim Fachgespräch in Argumentationsnotstände. Client/Server aufsetzen, IT Lösungen planen, IT Strukturen optimieren => das sind aufgaben die du als FISI machen solltest und nicht eine Webseite mit einer Datenbank dahinter. gruß cSharp

Hallo, die IHK Köln hat diesmal, weil die Präsentationen in einer Berufsschule gehalten wurden, Beamer zur Verfügung gestellt, jedoch wusste das kaum einer der Prüflinge vorher. Ich habe meinen Beamer jedenfalls mitgebracht, obwohl ich es vorher wusste, und das war auch gut so: Nach Anschluss des zur Verfügung gestellten Beamers im Präsentationsraum schaltete sich das Gerät aus irgendwelchen Gründen jede Minute einmal für etwa 5 Sekunden aus. Natürlich habe ich dann meinen eigenen - funktionstüchtigen - Beamer benutzt und die Präsentation war kein Problem aus technischer Sicht. Ebenfalls wird auch bewertet, wie gut man sich auf den Ausfall der Präsentationsmedien vorbereitet hat. Ich habe meine Powerpointpräsentation auf Folien gezogen, diese sichtbar auf den Tisch gelegt. Und in der Nähe der Prüfer auch noch die Präsentation in ausgedruckter Form, sodass ich selbst bei einem Stromausfall hätte präsentieren können. Und sowas wird bewertet... Ganz klar sollte für den Prüfling sein, dass SEINE Prüfung und SEINEN händen liegt, und nicht in den Händen der Prüfer. Zumal es euch doch selbst zu doof sein muss, vor einem Prüfungsausschuss mit Diskutieren anzufangen weil der zur Verfügung gestellte Beamer nicht funktionierte und nach eingelegtem Protest vor demselben Prüfungsausschuss noch einmal präsentieren zu müssen. Ohne es zu merken bekommt man wegen dieser Antipartie schon weniger Punkte. gruß cSharp

Hallo, ob ich meine visuelle Präsentation mit einer Schlussfolie abrunde hängt sehr von meinem persönlichen Stil ab. Wenn ich sehr karg mit Folien umgehe ist so eine Folie unangebracht. Wenn ich aber mit Folien meine Präsentation an jeder Stelle untermale, dann würde ich beim Schlusssatz eine Schlussfolie auflegen, das gehört dann einfach dahin. Wichtig ist das Gesamtbild und die Art wie ihr euch verkauft. Über Details nachzudenken ist sicherlich gut, aber wichtiger sind die Kernpunkte eurer Präsentation. Die Doku-Prüfer müssen euer Projekt wiedererkennen. Neue Aspekte sind immer willkommen, wenn sie schlüssig zu eurem Projekt passen. Wichtig ist auch dass ihr hinter eurem Projekt steht und nicht denkt: "Die Lösung ist aber nicht so gut, ich hät´s auch besser hinbekommen können." gruß cSharp

Hallo, die ICH - Form kann natürlich hervorheben, dass man alles selbst gemacht hat. Nichts desto trotz ist es kein Problem, wenn man eine allgemeine Form wählt. Ich habe meine Abschlussarbeit auch in einer allgemeinen Form geschrieben "Nach der Projektinitialisierung wurde eine Ist - Analyse durchgeführt. Hierbei fiel zuerst einmal auf, dass...". Es kommt sicherlich mehr auf den Inhalt an. Für Anwendungsentwickler kann mich Jestertales nur anschließen: Balzert Grundlagen der Softwareentwicklung lesen und die Kapitel studieren, in denen es um Projektmanagement geht und zusätzlich die, die zu dem jeweiligen Projekt passen. Sehr wichtig sind: Entwicklungsstrategien (Top Down / Bottom Up Verfahren) Aufwandsschätzmethoden (Function Point Methode lernen!), Projektmanagement (V-Modell bevorzugen, ist schwieriger, aber macht Eindruck), Testverfahren (extrem wichtig! Umfangreich Strategie beschreiben...), Qualitätssicherung (anhand Qualitätsmerkmalen entlanghangeln), Aktivitäten (Meetings, GoLive - Aktivitäten usw.) das sind die Kernpunkte. Auch für gewisse Stellen des Projektes sollte man Alternativen abschätzen und bewerten und begründen können, warum man sich für seine Lösung entschieden hat. gruß cSharp

In der Prüfung wird dich vermutlich niemand fragen: "Warum haben Sie hier eine globale Variable benutzt statt 6x eine lokale?". Deswegen würde ich mir hierüber kaum Gedanken machen. Die Technik "Variablen so lokal wie möglich" beruht darauf dass du damit am wenigsten Speicher verbrauchst, was meistens auch mit einer Performancesteigerung zusammenhängt. Dies war solange interessant wie Speicher und Prozessorperformance nicht im Überfluss vorhanden waren. Heute macht die ein oder andere globale Variable nichts mehr aus. Allerdings würde ich größere Arrays auch wirklich nur so lokal wie möglich benutzen, denn hier verschwendet man ansonsten wirklich zu viel Speicher... gruß cSharp

35 Stunden für Systemintegratoren inklusive Pufferzeiten und Zeit für die Dokumentation. gruß cSharp

Hallo, es kommt nicht so sehr darauf an was du machst. Dein Projekt steht nicht im Mittelpunkt, du sollst nur zeigen dass du einen Auftrag völlig erfassen, dein Projekt planen, realisieren, testen und das Produkt übergeben (an den Kunden) kannst. Setz lieber nicht auf die tollste Programmierung. Wichtiger ist, dass du dein Vorgehen begründen kannst, dich mit dem was du gemacht hast auskennst und dich mit den Ergebnissen auseinandersetzen kannst. Ich habe bei meinem Projekt auch nur die Minimalziele erreicht, das Projekt war nichts tolles aber ich konnte mein Vorgehen erklären und begründen und das Ergebnis aus allen Sichtweisen betrachten, und darauf kommt es an. Zu deiner eigentlichen Frage: eigentlich ist jede gängige Programmiersprache erlaubt, so auch PHP. gruß cSharp

Hallo, es kommt nicht so sehr auf das Projekt an. Hier einige Hilfen: [*] Mach etwas was du von der Basis her gut kannst [*] Mach etwas wo du eventuell dich noch mit etwas neuem befassen musst (sollte aber nicht mehr als ein paar Stunden dauern!) [*] Such dir ein Projekt aus wo du die wirtschaftlichen Ziele und den letztendlichen Nutzen klar herausstellen kannst [*] Es muss am Besten auch immer Alternativen zu deiner Lösung geben. Du musst begründen können, warum du es so und nicht anders gemacht hast (ein "der Chef wollte es so" darf höchstens an einigen Stellen fallen, aber nicht über dem Projekt schweben). [*] Achte auf das Projektmanagement. Wenn du hier nicht fit bist besorge dir das Buch aus dem Stamm-Verlag für deinen Beruf und mach damit einen Crashkurs. [*] Mach auf keinen Fall etwas ®evolutionäres wenn du es nicht völlig beherrschst. [*] Achte darauf dass deine Zeitplanung gut überdacht ist. Pufferzeit nicht vergessen. Genügend Zeit für Konzept und Planung berücksichtigen [*] Wichtig ist auch, dass deine Wahl zu deinem Berufsbild passt, also als FISI solltest du nicht ausschließlich einen Router installieren und Kabel ziehen. Oder nur eine Webpräsenz aufbauen. [*] Keine Projekte "klauen", spätestens beim Fachgespräch landest du auf der Nase. [*] Mindmaps für Fachgespräch erstellen [/list=1] mehr fällt mir nicht ein... gruß cSharp

Beispiele: "Was ist der Unterschied zwischen MS SQL Datenbanken und MS Access Datenbanken?" "Um welchen Datenbanktyp handelt es sich bei MS-Access?" "Was sind die Kennzeichen dieses Typs?" "Wie haben Sie die Datenbank aufgebaut?" "Erklären Sie bitte die 3. Normalform und auch bitte, warum die 3. Normalform erstrebenswert ist!" (Vorsicht, eine DB ist nur in 3 NF wenn sie auch in 1 und 2 NF ist, deswegen hier umfangreich antworten!) "Was sind Anormalien?" "Welche Datenbanktypen kennen Sie noch und wo liegen die Unterschiede?" "Wie kann man auf die Datenbanken zugreifen?" uswusf. Gut drauf vorbereiten, vor allem auf die Erstellung deiner eigenen Lösung. Kernfrage: Warum hast du die Datenbank genau so gemacht und nicht anders? Hope this will help u... gruß cSharp

Hallo, Leider bin ich nicht in der Materie drin, deswegen weiß ich nicht ob dies essentiell ist, die Vorgaben von SAP zu kennen. Wenn dem so ist, geb ich dir natürlich Recht. Doch, war sie leider schon. Im übrigen brauchen wir das nicht an einem Ausbildungsbetrieb festzuhalten. Alle Leute die bei der IHK Köln durchgefallen sind die ich kennen gelernt habe hatten das gleiche Problem: Projektmanagement wurde weder in der Schule ausreichend behandelt noch im Betrieb in der Lehrbuchform angewandt. kann ich nachvollziehen. nichts desto trotz kenne ich genug leutz aus dem selben Ausbildungsberuf die über gleiche Defizite klagen, die Ihnen bei der Prüfung zum Verhängnis wurden. Hmm, veräppeln will ich eigentlich niemanden. Es gibt nur einen himmelweiten Unterschied zwischen dem was die Ausbildungsrichtlinien betreffen und was tatsächlich in einigen Fällen ausgebildet wird. Nochmal, ich arbeite nur und ausschließlich für "interne Kunden", d.h. ich hab noch nie eine Zeile Sourcecode geschrieben die jemand anderes benutzt hat als die Leute die ich kenne. Mitlerweile habe ich das auch aufgearbeitet. Aber beigebracht hat mir das hier keiner und darauf hingewiesen dass es darauf ankommt hat mich auch keiner. Klar war ich ein wenig zu passiv und habe nur das gelernt was ich musste, anstatt mir den Ausbildungsrahmenplan zu schnappen und abzuhaken, was ich gelernt habe und was nicht. Den Namen mag ich hier nicht nennen, der Betrieb ist (unter anderem) in Köln und mein "Team" besteht z.T. aus gerade mal 2 Leuten, die mit Arbeit zugeschüttet werden, die vor der IT Krise ab etwa Anfang 2000 von sehr viel mehr Entwickler gemacht wurde. Deswegen - vermutlich - auch die "schlampige" Arbeit. Sourcecode wird Inline - Dokumentiert, "das hat bisher immer ausgereicht" (ich zitiere nur meine Leutz hier). Gruß cSharp

Hallo, woran macht man denn fest, dass ein Azubi keine Ahnung hat? Die Prüfungen werden von Leuten durchgeführt, die keinen blassen Schimmer davon haben, wie die Softwareentwicklung in meiner Firma abläuft. Bei "uns" werden Anforderungen verteilt von den Managern an die Entwickler, von den Entwicklern wird eine Aufwandschätzung gemacht, dann kommt das GO von den Managern und nach der Implementierung bekommen die Anforderer/Manager dann einen Prototyp, der dann nach Wünschen des Anforderers angepasst wird. Es fehlen laut IHK: - Ist Analyse - Soll Konzept - Feinkonzept - Design - Teststrategie (die ersten 4 Punkte werden bei uns in einem Schritt ohne Trennung abgehandelt!) dann fehlen solche Formalien wie: - Lastenheft - Pflichtenheft - Testprotokoll - Abnahmeprotokoll - Benutzerdokumentation - Programmdokumentation Wie soll ich bitte einem Manager klarmachen, dass er seine Anforderungen in einem Lastenheft zusammenzufassen hat? Soll ich es ihm schreiben? Und dass er mit der Aufwandschätzung auch noch sowas wie ein Pflichtenheft bekommt? "What´s this?" wurde ich nur gefragt. Und dass die Tester beim Integrationstest ein Protokoll auszufüllen haben anstatt die Ergebnisse und Fehler einfach auf einen Zettel zu kritzeln. Es gehörte für mich als Prüfling mehr dazu, die Arbeit hier in ein Standard - Schema zu zwängen als das eigentliche Problem zu lösen. Als ich die Aufgabe bekommen habe wusste ich sofort, wie die Lösung auszusehen hat. Wieso muss ich mir dann noch Gedanken machen über Alternativen? Ich weiß doch nach 3 Jahren was meine Geldgeber von mir haben wollen und was sie grundsätzlich ablehnen. Nur zur Info: Ich entwickle Software nur für interne Kunden. Und was mich am meisten ärgert, ist diese strenge 70 Stunden Richtlinie, wenn ich in diesen 70 Stunden Konzept - Design - Implementierung - Test - Schulung - Dokumentation - Abnahme usw. unterbringen soll bleiben für die Implementierung nicht mehr als etwa 20-30% der Zeit. Was soll bei diesem Zeitrahmen denn herumkommen? "Normale" große Projekte die so etwas wie Anforderungsmanagement und alle möglichen Protokolle und Dokumente brauchen gehen über einen Zeitraum von mehreren Monaten, vielleicht sogar Jahren. Und sogenannte "Teilprojekte" sind noch schwieriger darzustellen als diese Miniprojekte, denn hier brauche ich zig Schnittstellen, muss viel zu viel abgrenzen zwischen eigener Leistung und Fremdleistung. gruß cSharp

... ist es relativ einfach ein Projekt zu bestehen. Anstatt 2 Jahre lang zu arbeiten kann man auch einfach ein von der IHK empfohlenes Buch (s. Beiträge von Jestertales) auswendig lernen und dann einfach ein Abschlussprojekt - Inhalt völlig egal - nach diesem Schema abgeben. Ob man dabei was gelernt hat ist völlig wurscht... gruß cSharp