Wie sehen iSAQB CPSA-Advanced Prüfungsaufgaben eigentlich aus?

diploma-3Der iSAQB-Einstiegslevel Foundation der Certified Professional for Software Architecture-Zertifierung (kurz: CPSA-F) sieht einen Multiple Choice Test als Prüfung vor. Bei der zweiten Stufe, dem Advanced Level, bearbeitet der Prüfling hingegen eine Hausarbeit. Seine Lösung verteidigt er (bzw. sie) dann im Rahmen eines Interviews vor zwei Prüfern, die diese vorher durchgesehen und gegen Kriterien gehalten haben.

Beim Multiple Choice Test (CPSA-F) ist relativ klar, was auf den Prüfling zukommt. Auch wenn einzelne Lernziele mit Ankreuzfragen nur schwer überprüfbar sind, und man sich konkrete Fragen vielleicht nur schwer vorstellen kann, gilt das zumindest für die Form der Prüfung. Zum Advanced-Level höre ich in Workshops oder per Mail dagegen immer wieder die Frage: Wie sieht eine solche Prüfungsaufgabe inhaltlich aus? Das ist nicht unmittelbar klar.

Nun sind die Prüfungsaufgaben selbst natürlich vertraulich (genau wie der Prüfungsfragen im Foundation Level). Vorlagen und Checklisten zur Erstellung von Aufgaben sind jedoch frei zugänglich (auf der Webseite des iSAQB). Sie sind nicht unbedingt leicht verdaulich — falsche Zielgruppe: sie sind für Leute gedacht, die sich neue Aufgaben ausdenken. Ich beschreibe daher im Folgenden mal, wie Aufgaben aufgebaut sind – für Leute, die demnächst ein solche Aufgabe lösen müssen. Was Sie als Advanced-Prüfling also grob erwartet…

Überblick Prüfungsaufgabe

Wie sieht eine Aufgabe grundsätzlich aus?

Die Aufgabenstellung einer Prüfungsaufgabe für CPSA-Advanced umfasst mindestens 10 Seiten und höchstens 25 (siehe Abbildung rechte, die Seitenzahlen sind Beispielwerte).

Jede Aufgabe ist einer Systemart zugeordnet. Aktuell sind das

  • Informationssystem
  • Embedded System
  • Websystem

Ein Kandidat gibt bei der Anmeldung zur Prüfung die gewünschte Systemart an und erhält dann eine Aufgabe aus diesem Bereich. Damit soll verhindert werden, dass ein Prüfling mit einer Umfeld konfrontiert wird. das ihm völlig fremd ist. Darüber hinaus ermöglicht ein kurzer Abstract (2-3 Sätze) zur Aufgabenstellung dem Prüfling zu entscheiden, ob die Aufgabe grob passt.

Jede Aufgabe selbst zerfällt dann in zwei grobe Blöcke: Ein Fallbeispiel in Form inhaltlicher Inputs, und die Aufgabenstellung selbst. Letztere ist in Teilaufgaben gegliedert. Die konkreten Prüfungsaufgaben variieren dabei in der Zusammenstellung der inhaltlichen Inputs und den Teilaufgaben.

Das Fallbeispiel

Prüfungsaufgaben: FallbeispielBeim Fallbeispiel handelt es sich um ein fiktives Projekt, eine Produktentwicklung, eine Migration oder ähnliches. Nach einem kurzen Überblick liegen konkrete Informationen dazu in Form inhaltlicher Inputs vor. Im Wesentlichen sind das Anforderungen, die der Prüfling in den späteren Teilaufgaben berücksichtigen muss. Denkbar sind etwa folgende Inhalte:

  • Funktionale Anforderungen (z.B. wichtige Use Cases, User Stories, …)
  • Qualitätsziele, ggf. verfeinert in Szenerien
  • Stakeholder (z.B. Liste, Personas)
  • Interviews mit Stakeholdern
  • Technische und/oder organisatorische Rahmenbedingungen
  • Fachlicher Kontext, Benutzer und Fremdsysteme
  • Normen und Konventionen
  • Risiken

Nicht jede Aufgabenstellung enthält dabei alle diese Inhalte. Weiterhin kann es sein, dass bestimmte Anforderungen explizit genannt sind, andere jedoch im Rahmen der Aufgabe erarbeitet werden müssen. Beispielsweise liegen Interviews mit Stakeholdern vor, und die Rahmenbedingungen oder Qualitätsziele muss der Prüfling dann im Rahmen einer Teilaufgabe herausarbeiten und ggf. priorisieren.

Ihre Aufgabe

Prüfungsaufgaben: TeilaufgabenGanz ähnlich wie das Fallbeispiel mit seinen inhaltlichen Inputs ist auch die Aufgabe unterteilt — in mindestens 5 und maximal 10 Teilaufgaben, die unterschiedliche Aspekte der Architekturarbeit abdecken. In Summe soll die Bearbeitung zeigen, dass der Prüfling in der Lage ist, aus Anforderungen methodisch eine Architektur zu entwerfen und festzuhalten, sie zu reflektieren und zu kommunizieren. Analog zu den denkbaren Inputs oben beim Fallbeispiel hier mögliche Teilaufgaben:

  • Kontext abgrenzen
  • Qualitätsziele identifizieren, Qualitätsbaum und -szenarien erarbeiten
  • Offene Fragen an Stakeholder formulieren
  • Lösungsstrategie/Architekturvision anfertigen
  • Architekturentscheidungen treffen
  • Technische Fragestellung inkl. Alternativen und Begründung bearbeiten
  • System strukturieren, fachlich zerlegen, Verantwortlichkeiten festlegen
  • Schnittstellen entwerfen
  • technische und/oder übergreifende Aspekte bearbeiten
  • Lösung qualitativ bewerten
  • Risiken identifizieren und adressieren

Es gibt dabei Überschneidungen in inhaltlichen Inputs und Teilaufgaben: Der Systemkontext könnte etwa mit dem Fallbeispiel gegeben sein (als inhaltlicher Input) oder muss alternativ als Teilaufgabe erarbeitet werden.
Prüfungsaufgaben: FAQ

Häufige Fragen zu Prüfungsaufgaben

Wie wird sichergestellt, dass die Aufgabe zu den von mir besuchten Schulungen passt?

Eigentlich gar nicht. Durch die Angabe der Systemart (z.B. Web, Embedded) wird lediglich abgesichert, dass es technologisch grob passt. Ansonsten sind die Aufgaben nicht an bestimmte Module gebunden. Die Teilaufgaben (+ Interview) decken lediglich die drei Kompetenzbereiche („Säulen“) des Advanced-Levels ab.

Welchen Umfang hat meine Lösung?

Sie halten Ihre Lösung auf maximal 40 DIN A4-Seiten (inklusive Abbildungen) fest. Dazu haben Sie maximal 3 Monate Zeit (Details siehe Prüfungsordnung). Vom Aufwand sind die Teilaufgaben so bemessen, dass ein Prüfling sie in 40 Stunden erledigen kann.

Was wenn Technologien oder Methoden gefordert sind, die ich nicht beherrsche?

Die Aufgabenstellungen lassen Ihnen angemessenen Spielraum bezüglich Technologien, Werkzeugen, Notation und Ähnlichem. Wenn etwas explizit gefordert ist, so ist sichergestellt, dass Informationen dazu frei zugänglich sind. Entweder es liegt der Aufgabe bereits in den inhaltlichen Inputs oder in einem Anhang bei, oder es wird darauf verwiesen. Es kann natürlich vorkommen, dass Sie sich zur Lösung der Aufgabe noch Wissen aneignen müssen.

Was wenn mir die gegebenen Anforderungen zur Lösung nicht ausreichen?

Wie im richtigen Leben kann es sein, dass Ihnen zur Lösung der Aufgabe Informationen fehlen. Im Einzelfall scheinen sich Anforderungen sogar zu widersprechen (beispielsweise Aussagen in Interviews von Stakeholdern mit unterschiedlichen Prioritäten). Normalerweise klären sie das im Projekt mit den Beteiligten, finden Kompromisse, etc. Da Ihnen die Leute im Rahmen Ihrer Hausaufgabe nicht zur Verfügung stehen, treffen Sie Annahmen. Diese kennzeichnen Sie in Ihrer Lösung explizit als solche. Achten Sie darauf, dass diese sinnvoll und konsistent untereinander und zur Aufgabenstellung sind.

Weitere Informationen

Ich hoffe, ich konnte einen Eindruck vermitteln, wie die Prüfungsaufgaben im CPSA-Advanced-Level grundsätzlich aussehen. Wenn Sie Fragen zu dem Thema haben, kommen Sie gerne auf mich zu. Ansonsten: Auf der iSAQB-Seite finden Sie vieles rund um den Advanced-Level. Hier noch ein paar weiterführende Links …

One Comment

  • Rolf sagt:

    Danke für die ausführlichen Informationen. Bin gerade an der Advanced Reihe dran. Hier habe ich einige gute Inputs zu den Aufgaben der Prüfung erhalten. Offengestanden ging ich davon aus, dass man dabei ggf. auch implementieren/umsetzen muss und ggf. auf einer bestehenden Codebasis aufsetzt. Ich werde mich definitiv für Websysteme entscheiden, da ich in diesem Kontext auch beruflich unterwegs bin und da wohl die wenigsten Überraschungen erleben werden. Das Aufgabenbeispiel hier hat mir sehr geholfen die Messlatte etwas einzuschätzen. Letztlich (so nehme ich an) gibt es wie sooft in der Architektur und im Entwurf von Systemen kein richtig oder falsch. Vielmehr scheint man die erlernten Methoden aus dem Foundation Level und aus der täglichen Arbeit mit gesundem Menschenverstand anwenden und priorisieren zu müssen. Das hilft mir in jedem Fall enorm weiter.

Leave a Reply