Ein paar Informationen zur IPA im Kanton Zürich aus der Sicht eines Valid- und Prüfungsexperten
Liste ist nicht/nie vollständig - übliche Fragen beantworten ist das Ziel.
Nur weil es machbar tönt muss es nicht machbar sein - 6 Tage sind kurz! (4 Tage sind geplant für Dokumentation) Und es sollen 8 Stunden sein, keine Wochenenden und Nachtschichten.
Es lohnt sich sehr früh zu verhandeln - wenn es signiert ist, dann ist es eher zu spät.
Natürlich muss es den Minimalanforderungen einer IPA entsprechen - da schauen auch die Valid Experten drüber.
Hier ist eine kleine Checkliste fürs signieren.
Das wird leider zu selten gemacht obwohl es in der Dokumentation gefordert ist.
Und zumeist bei Erweiterungen sollte bereits ein solches Diagram vorhanden sein und mit den neuen Elementen erweitert werden
Sinn:
Systemgrenzen Aufzeigen
Abhängigkeiten aufzeigen
Einschränkungen und Freiheiten sichtbar machen
Orientierung verschaffen
Eine kurze Beschreibung ist hier ( Danke an M. Künzler von visuell klar )
Braucht Zeit, Aufwand, Vorbereitung und echtes Training -> Fokus
Welche Mittel eingesetzt werden hängt von dir ab – aber sicher nicht nur PowerPoint.
Verkaufe dich als Fachperson – was hast du super gemacht – da gibt es einen Schwerpunkt in der Präsentation und in der Demo
Ein Kunde sollte bereit sein CHF 10’000 dafür zu bezahlen. ( 10 Tage à 1 kCHF )
Demo muss gut vorbereitet sein
Man kann sich auch auf mögliche Fragen vorbereiten.
Man kann auch Fragen provozieren – es wird interessanter und lebendiger.
Roter Faden heisst: Ziel und der Weg dazu sind geübt.
Kann aus allen Bereichen der Aufgabe Fragen enthalten
Hauptexperte nimmt sicher Bezug aufs Dokument – was ist nicht klar im Dokument? Wo ist der Code etwas holperig? Welche Graphiken haben zu wenig Text.
Es gibt viele implizite Entscheidungen durch
Vorgaben, Richtlinien, Prozesse -> Relevante Dinge können als Vorarbeit dokumentiert werden
Explizite Entscheidungen
Was sind die Kriterien, warum wurden diese gewählt
Welchen Bezug haben die Kriterien zu den Vorgaben der Aufgabe, den Zielen der Firma
Warum haben die Kriterien welches Gewicht
Wie wurden die Varianten bestimmt – gibt es noch weiter Varianten und warum sind die nicht im Vergleich aufgeführt
Begründung und Darstellung der Entscheidung:
Mindestens einen Satz schreiben mit SWOT
Evtl. eine Graphik
Tipp für ein Format: https://foerster-kreuz.com/one-pager-kommen-sie-zum-punkt-wie-ronald-reagan/
Name klar und deutlich aussprechen – gut wenn der Name irgendwo lesbar steht
Etwas aus den Fragen unten – max. 20 Sekunden sprechen:
Was haben sie spezielles in ihrer Lehre gemacht
Was hat ihnen in ihrer Lehre besonders gefallen
Wie sind sie zur Lehrstelle gekommen
Warum haben sie Informatiker als Beruf gewählt
Was wollen sie nach der Lehre machen
Was machen sie in ihrer Freizeit und wie verbindet sich das mit ihrer jetzigen Tätigkeit
Wie wurde das IPA Thema bestimmt
Habe ich Informationen geliefert, die zu Fragen der Zuhörer führen könnten?
Kann ich das in einer offenen Körperhaltung und Augenkontakt erzählen? Üben !
eine kleine erheiternde Geschichte: https://www.youtube.com/watch?v=zz0FDOBspAk
Ausführungstage und Schultage kontrollieren
Aufgabe passt zur Fachrichtung
Aufgabe passt zu den Arbeiten der letzten 6 Monaten
Ausgangslage ist verständlich für eine aussenstehende Person
Detailbeschrieb:
Deckt die Tätigkeiten eines Informatikers der gewählten Fachrichtung ab
Entspricht den Anforderungen an einen Informatiker ( nicht zu komplex - nicht zu einfach)
Es ist klar was geliefert werden soll - der Weg dazu aber nicht schon in allen Details vorgegeben
Beurteilungskriterien:
Kriterien sollten nach Möglichkeit zu Teilaufgaben zuordenbar sein
Eine Teilaufgabe sollte nicht mit zu viel Kriterien bewertet werden ( Aufwand und Komplexität sind zu beachten)
Kriterien ohne Lieferobjekt sollte es nicht geben - mindestens in der Dokumentation sollte eine Spur zu finden sein
Lieferobjekte ohne Bewertungskriterien darf/sollte es nicht geben
Selber eine Aufwandschätzung erstellen gemäss den Teilaufgaben und den erforderlichen Verfeinerungen und dazu gleich die Kriterien hinzufügen ( Sie erleichtern sich bereits jetzt schon die Bewertung - spätestens dann brauchen sie diese Zuordnung)
Aufgabe in aktiver Form schreiben
Substantivierungen eliminieren
Risiken der Aufgabe genau anschauen - 10 Tage sind der Rahmen - es soll gezeigt werden was sie können.
Neue Lerninhalte hinterfragen - muss es wirklich sein - oder ist es so einfach, dass man es nicht erwähnen müsste?
Kriterien zu Code Konformität, Style etc. : Es muss ein Dokument bereitgestellt sein, dass die abschliessenden Kriterien auflistet
Sollte das Project "Agile" Style gemacht werden? Es braucht deswegen nicht daily Stand-ups - es ist und bleibt eine Einzelarbeit.
Gleiches/ähnliches Thema durch einen anderen Kandidat oder aus dem Vorjahr: Das Risiko besteht, dass wir es merken. Bitte deklarieren und aufzeigen wie die fairness gegenüber anderen Kandidaten gewährt werden soll
Erweiterung einer Aufgabe eines Kandidaten der schon das Ding fertiggestellt hat: Wie stellen sie sicher, dass keine Folgefehler den Kandidaten behindern?
Man muss auf PKORG Dokumente hochladen können - der VF kann das testen in dem er ein Dokument in den Dokumentenpool lädt
Sie verwenden eine existierende Infrastruktur ? Stellen sie sicher, dass die Zugriffe funktionieren, die Passworte/Zertifikate nicht gleich ablaufen, die Administratoren wissen, dass Sie mit Anfragen kommen könnten.
Allgemeiner Teil der Aufgabe
auf der Web Page von PK19 sind jeweils unter den Fachrichtungen die aktuell gültigen Dokumente aufgeführt.
https://pk19.ch/applikationsentwicklung/
Das Dokument Leitfaden QV yyyy beschreibt was allgemein gefordert sind und die Rahmenbedingen. Da sind alle Anforderungen für die Kriterien A1 - bis A11 aufgeführt.
Warum Dokumentieren?
Bei der IPA ist es offensichtlich auch wegen der Möglichkeit in einem Rekursfall etwas in den Händen zu haben.
Der Grund warum Informatiker Dokumentieren müssen/sollten ist viel tiefgreifender:
Ungenaue Anforderungen führen zu unzufriedenen Kunden und verspäteten Projekten
Das Problem, das zur Anforderung führte ist oft nicht bekannt.
Nicht existierende Systemlandkarten oder keine Abgrenzungen sind teure technische Schulden, die nie ein Projektbudget sehen werden
Fehlende Abnahmekriterien verzögern die Einführung
Fehlenden Annahmen und Begründungen von Entscheidungen lassen den Code unverständlich wirken und die Wartbarkeit geht gegen Null
Menschen haben die Tendenz nicht sagen zu zu können was sie meinen und meinen, was sie sagen. Schreiben ist eine Form von Reflektieren und ermöglicht Diskussionen im Team, kann unerkannte Vorannahmen aufdecken, die zu Fehlern führen könnten, kann die Anforderungen oder Problemstellung noch genauer spezifizieren
Schreiben ist die effizienteste Art zu lernen!
Hier noch ein Text der weitere Faktoren aufzeigt.