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

By 3. April 2020 Juli 16th, 2020 Allgemein, Inhaltliches

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 (kurz: CPSA-A), 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.

Bei einem Multiple Choice Test (also bei 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 dazu vielleicht nicht direkt 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 offensichtlich.

Nun sind die Prüfungsaufgaben selbst natürlich vertraulich (genau wie die 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…

Wie sieht eine Aufgabe grundsätzlich aus?
Das Fallbeispiel
Ihre Aufgabe
Ein Beispiel
Häufige Fragen zu Prüfungsaufgaben
Weitere Informationen
Ü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 einem Umfeld konfrontiert wird, das ihm völlig fremd ist. Auf Wunsch erhält der Prüfling kurze Abstracts (2-3 Sätze) von zwei verschiedenen Aufgabenstellungen und entscheidet sich dann für eine davon.

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 erheblich.

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 mitunter 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.

Ein Beispiel

Das iSAQB stellt eine Beispielaufgabe bereit: „BigSpender“. Es handelt sich um eine echte Aufgabe, die früher gestellt, mittlerweile aber aus dem Pool genommen wurde, nachdem sie einige Prüflinge bearbeiten durften. Sie können die Prüfungsaufgabe hier als PDF herunterladen.

Inhaltlich geht es in der Aufgabe um Spesenabrechnungen. Das Fallbeispiel enthält dabei folgende Inhalte:

  • Input 1 – Überblick (1 Seite, Text)
  • Input 2 – Fachlicher Kontext (Diagramm und kurze Beschreibung der Akteure)
  • Input 3 – Fachklassenmodell (Diagramm) und Glossar (als Tabelle)
  • Input 4 – Stakeholder (knapp gehaltene Liste)
  • Input 5 – Interview mit dem Auftraggeber (recht umfangreich, ca. 3 Seiten)
  • Input 6 – Exemplarische User Stories (10 Stück)
  • Input 7 – Verfügbarkeit des Systems (Anforderung, als Szenario)
  • Input 8 – Technische Randbedingungen (als kurzer Text)
  • Input 9 – Mengengerüst (Tabelle, Aussagen zu Benutzern, Standorten, Vorgängen …)

Die eigentliche Aufgabe besteht dann aus 6 Teilen.

  • Teilaufgabe 1 – Qualitätsanforderungen herausarbeiten, in Form von Qualitätszielen und -szenarien
  • Teilaufgabe 2 – Lösungsstrategie entwickeln, Umfang ca. eine Seite
  • Teilaufgabe 3 – Technischen Kontext abgrenzen, Diagramm und Beschreibung zu Akteueren und Kommunikation
  • Teilaufgabe 4 – Fachliche Strukturierung erarbeiten (Bausteinsicht)
  • Teilaufgabe 5 – Technologie-Entscheidungen treffen
  • Teilaufgabe 6 – Bewertung der Lösung vornehmen, anhand der Qualitätsszenarien aus Teilaufgabe 1

Details entnehmen Sie dem PDF. Und beachten Sie, dass sich die Prüfungsaufgaben wie geschildert stark unterscheiden und es sich bei „BigSpender“ um ein Beispiel handelt – wenn auch um ein echtes.

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 (methodisch, technisch und kommunikativ).

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.

Soll ich meine Lösung nach arc42 strukturieren?

Die Antwort ist hier ein klares nein. arc42 ist ein verbreiteter Gliederungsvorschlag für Architekturbeschreibungen, daher wäre die Idee naheliegend. Für Ihre Lösung ist aber ganz klar die Vorgabe, dass Sie diese den Teilaufgaben entsprechend strukturieren. Also pro Teilaufgabe ein Abschnitt. Sie ermöglichen den Prüfern auf diese Weise die einfache Durchsicht and den Abgleich mit Kriterien.

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 …

Eine erste Fassung dieses Beitrags erschien im Juni 2016. Sie wurde regelmäßig aktualisiert, zuletzt im April 2020.

Seminare bei embarc

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