Ivo_

Das mag sein, das war aber mein subjektives Gefühl. Und außerdem bestehen 90% diese Prüfung, man muss sich schon anstrengen um es nicht zu schaffen. Und natürlich wollen die feststellen ob man sein Beruf ausüben kann, das ist ja der Grund für diese Prüfung. Das eine unabhängige Instanz sagt, A kann es. Aber wenn man gleichgestellt ist, ist das unabhängig von der Situation.

Ist einfach ein Gespräch zwischen Informatiker, du kannst dich nicht vorbereiten. Wenn du das was du können solltest kannst, wirst du keine Probleme haben.

Dann ist es sinn frei. Du willst als Entwickler unabhängig von OPs sein, deswegen benutzt du Docker :). Und glaube nicht das was installieren als Projektarbeit zählt.

Wieso ist die Durchfallquote bei der IHK so niedrig, was denkt ihr? Wir hatten so bei manchen Mathe Klausuren Durchfallquote von 80%.

Möchtest du als AE oder IS was mit docker machen?

Also bei mir in der Einladung stand max 18min ist nd das gleiche haben mir die Prüfer gesagt :). Also schceibt wirklich unterschiedlich zu sein.

Ich meine, der Sinn der Prüfung ist Kenntnisse zu demonstrieren, das muß in gewissen Rahmen passieren, aber natürlich gibt es auch toleranzen. Und wenn man 2 Minuten weniger braucht, ist es halt so. Man sollte nicht alles zu ernst und zu genau nehmen.

Also die 15 min sind ja nur ein Richtwert. Wenn das Gesamtkonzept passt und den roten Faden konsequent befolgt wird, dann +/- 3min ist sicherlilch ok (die maximale Zeit ist ja 18min).

Vielen dank an Stefan Macke. Deine Vorlage hat mir viel Zeit gespart und mir erlaubt mich an den tatsächlichen Inhalt zu konzentrieren. Habe am ende 82 Punkte für die Projektdoku bekommen und bin selber zufrieden. Der Aufwand entspricht die Belohnung.

Ist ein gutes Argument. Habe abgerufen, kommt ende Aug.

Rienne, es wäre dann vielleicht sinnvoll wenn du schreibst wie lange nach der mündlichen Prüfung du es bekommen hast. Wenn es manch andere so schreiben, dann habe ich schon alles was ich brauche.

Wie lange braucht den so die IHK durchschnittlich um das Zeugnis zuzuschicken?

OK guter Hinweis, ist bei mein Projekt konkret nicht der Fall, aber ich werde der Zeitraum vergrössern.

Hallo, es wird mich sehr freuen feedback über den Antrag zu bekommen :). Vielen Dank im Voraus Projektantrag: Programmierung einer Projektliste Author: IM # Thema (300 chars): - Programmierung einer elektronischen Projektliste zur Unterstützung einer Bauingenieurfirma. # # Termin (Ihr möglicher Bearbeitungszeitraum: 02.03.2017 - 10.05.2017): - 15.3 - 1.4 # # Projektbeschreibung (8000 chars): - Bei der Ingenieurbüro für Baustatik und Bauphysik gibt es pro Jahr über 500 Projekte. Die Projekten werden insgesamt von 7 Bauingenieuren, 7 Bauzeichner und zwei Asistenten bearbeitet. Ausgangssituation: Die Projektliste besteht aus Papier und wird manuell von einer der Assistenten vervollständigt, wenn ein neues Projekt kommt. Dann Trägt sich einen Ingenieur oder Bauzeichner als bearbeiter ein. Weil es die Liste nur einmal am Schreibtisch vom Assistenten gibt, entstehen keine Doppelt Bearbeitungen. Was aber passieren kann dass ein Projekt unbemerkt eingetragen wird und es keiner bearbeitet, bis rückfragen kommen. Es ist auch schon passiert dass die Liste aus der Papiertonne geholt werden musste, weil sie aus versehen entsorgt wurde. Auf Druck von meiner Seite wurde dann die Liste in eine Excel Tabelle umgewandelt. Jetzt war es möglich einen Backup zu haben und direkt vom Arbeitsplatz die Liste anzusehen. Das hat die Anzahl von unbemerkte Projekte reduziert, weil es jeden direkt Auffällt wenn eine leere Zelle in einer Zeile gibt. Zielsetzung: Um noch besser den Überblick über die Projekte zu behalten soll jetzt eine Anwendung geschrieben werden, die die Verwaltung übernimmt. Die Anwendung soll folgende Aufgaben übernehmen: 1: Alle Mitarbeiter sollen sich registrieren und anmelden können. Es gibt keine Berechtigungen, alle können immer genau das gleiche. 2: Erstaufnahme von neuen Projekten so dass diese für alle Mitarbeiter sichtbar sind. Bei der Erstaufnahme soll ein Erinnerungsdatum eingetragen werden, wenn der Projekt bis dahin nicht in Bearbeitung ist, wird eine Erinnerung an alle Mitarbeiter geschickt. 3: Ein Mitarbeiter kann einen Projekt wählen und Stunden drauf verbuchen, damit wird ein Projekt in Bearbeitung gesetzt. Diese Buchungen sind immer für alle sichtbar und dienen der Zeiterfassung. 4: Ein Mitarbeiter kann einen Projekt abschließen. Ich übernehme alleine die Projektausführung. Das bedeutet ich übersetze alle Anforderungen in einem Softwaresystem die sie alle ausfüllt. Strukturplan: Der Projekt wird agil entwickelt werden. Weil die Zeit für die Bearbeitung fest ist wird für die Durchführung Scrum benutzt. Ich erstelle in der Planungsphase alle User Stories und pflege die in den Backlog ein. Die Stories bilden den Software ab und werden mit dem Stakeholder (der Ingenieurfirma) abgesprochen. Wenn keine offene Fragen mehr sind wird mit der Abarbeitung des Projekts angefangen. Die Sprintlänge soll so gewählt werden dass es ein paar potenzial Lieferbare Stücke gibt die dann immer verbessert werden bis. Bei sieben volle Arbeitstage stehen insgesamt 56 Stunden zur Verfügung. Deswegen denke ich dass eine Sinnvolle Sprintlänge zwei Tage wäre, dann hätte man drei volle Sprints und einen Tag um Abschlussarbeiten zu erledigen und den Projekt abzugeben. Ein weiterer Vorteil vom Agilen vorgehen ist dass man die Arbeit tatsächlich nach Use Cases trennt und nach Sprintende ein funktionsfähigen Software Stück hat, was tatsächlich den gewünschten Mehrwert bietet. # # Projektumfeld (3000 chars): Das Projekt wird zur interne Nutzung in der Firma Entwickelt. Die Entwicklung wird unter stendiger Kommunikation mit den Stakeholdern entwickelt. # # Projektphasen (3000 chars): - Analyse und Planung: 10h Kundenanforderungen aufnehmen (Epic): 2h Prüfung der unterschiedlichen Varianten und Entscheidungsfindung: 1h Wirtschaftlichkeitsanalyse: 1h Epic in User Stories aufteilen: 3h Mockups für die Einzelne User Stories deffinieren: 2h Stories und Mockups Vorstellung und Freigabe abholen: 1h - Implementierung: 52h Aus Use Stories Interne APIs deffinieren: 1h Aus Use Stories Public API deffinieren: 1h Interne API Configuration Managment: 1h Unit Tests Configuration Managment: 1h Interne API Datenbank: 2h Unit Tests Datenbank: 1h Interne API Logik: 25h Unit Tests Logik: 5h GUI: 10h Integration Tests: 5h - Dokumentation: 6h Projektdoumentation: 5h Kundendokumentation: 1h - Präsentation und Übergabe: 1h Inbetriebnahme: 1h Gesamtsumme: 70 h # # Dokumentation (3000 chars): - Backlog - Bearbeitungsübersicht - Mockups - Screenshots der Anwendung - Testergebnisse - Benutzerdokumentation # # Anlagen (PDF 200MB): keine # # Präsentationsmittel (250 chars): keine zusätzliche. #