Certified Professional for Software Architecture (CPSA) Advanced Level

Transkript

1 Curriculum für Certified Professional for Software Architecture (CPSA) Advanced Level Modul: Architekturdokumentation

2 Inhaltsverzeichnis Seite 2 von 15 Stand 27. September 2012

3 Seite 3 von 15 Stand 27. September 2012

4 0 Einleitung: Allgemeines zum isaqb Advanced Level 0.1 Was vermittelt ein Advanced Level Modul? Der isaqb Advanced-Level bietet eine modulare Ausbildung in drei Kompetenzbereichen mit flexibel gestaltbaren Ausbildungswegen. Er berücksichtigt individuelle Neigungen und Schwerpunkte. Die Zertifizierung erfolgt als Hausarbeit. Die Bewertung und mündliche Prüfung wird durch vom isaqb benannte Experten vorgenommen. 0.2 Was können Absolventen des Advanced-Level (CPSA-A)? CPSA-A Absolventen können: Eigenständig und methodisch fundiert mittlere bis große IT-Systeme entwerfen. In IT-Systeme mittlerer bis hoher Kritikalität technische und inhaltliche Verantwortung übernehmen. Konzeption, Entwurf und Dokumentation von Maßnahmen zur Erreichung nichtfunktionaler Anforderungen. Begleitung des Entwicklungsteams bei der Umsetzung dieser Maßnahmen durchführen. Architekturrelevante Kommunikation in mittleren bis großen Entwicklungsteams steuern und durchführen 0.3 Voraussetzungen zur CPSA-A Zertifizierung Eine erfolgreiche Ausbildung und Zertifizierung zum CPSA-F (Certified Professional for Software Architecture, Foundation Level) Mindestens drei Jahre Vollzeit-Berufserfahrung in der IT-Branche, dabei Mitarbeit an Entwurf und Entwicklung von mindestens zwei unterschiedlichen IT-Systemen o Ausnahmen auf Antrag zulässig (etwa: Mitarbeit in Open Source Projekten) Aus- und Weiterbildung im Rahmen von isaqb-advanced Level Schulungen im Umfang von mindestens 70 Credit-Points aus mindestens zwei unterschiedlichen Kompetenzbereichen (detailliert geregelt in Abschnitt ). o Bestehende Zertifizierungen (etwa Sun/Oracle Java-Architect, Microsoft-CSA o.ä.) können auf Antrag auf diese Credit-Points angerechnet werden. o Sonstige Aus- und Weiterbildungen können auf Antrag beim isaqb ebenfalls anerkannt werden, sofern ein Bezug zu Software-Architektur vorliegt. Die Entscheidung hierüber trifft im Einzelfall die Arbeitsgruppe Advanced-Level des isaqb. Erfolgreiche Bearbeitung der CPSA-A Zertifizierungsprüfung. Seite 4 von 15 Stand 27. September 2012

5 1 Grundlegendes zum Modul Architekturdokumentation 1.1 Gliederung des Lehrplans für Architekturdokumentation und empfohlene zeitliche Aufteilung Grundbegriffe von Softwarearchitekturdokumentation (mind. 1.25h) Dokumentation und Vorgehen (mind. 2.5h) Bestandteile von Architekturdokumentation (mind. 3h) Werkzeuge (mind. 2h) Dokumentation bewerten (2h) Beispiele für die Dokumentation von Softwarearchitekturen (mind. 2h) (Zeiten jeweils inklusive Übungen) Grundbegriffe Vorgehen Bestandteile Werkzeuge Bewerten Beispiele 1.2 Dauer, Didaktik und weitere Details Die genannten Zeiten sind Empfehlungen. Die Dauer entsprechender Schulungen sollte mindestens 2 Tage betragen, kann aber länger sein. Anbieter können sich durch Dauer, Didaktik, Art- und Aufbau der Übungen sowie der detaillierten Kursgliederung voneinander unterscheiden. Insbesondere die Art (fachliche und technische Domänen) der Beispiele und Übungen lässt der Lehrplan komplett offen. Das Modul kann unabhängig von einer CPSA-F Zertifizierung besucht werden. 1.3 Voraussetzungen für das Modul Architekturdokumentation Teilnehmer sollten folgende Kenntnisse und/oder Erfahrung mitbringen: Grundlagen der Beschreibung von Architekturen mit Hilfe verschiedener Sichten, übergreifender Konzepte, Entwurfsentscheidungen, Randbedingungen etc., wie es im CPSA-F Foundation Level vermittelt wird. Wünschenswert sind eigene Erfahrungen in der Erstellung und Pflege technischer Dokumentation von Software, insbesondere der Architektur von Software- oder Softwarenahen Systemen. Hilfreich für das Verständnis einiger Konzepte sind darüber hinaus: Seite 5 von 15 Stand 27. September 2012

6 Kenntnis typischer Herausforderungen bei Erstellung und Pflege von technischer Dokumentation: o Auswahl geeigneter Dokumentationsstrukturen, Notationen, Ergebnistypen (Stakeholderorientierung) o Behandlung großer Dokumentationen (insbesondere vorhandener oder veralteter Dokumentation) o Auswahl, Konfiguration und Einführung von Werkzeugketten (mit welchen Mitteln kann Dokumentation angemessen erstellt und gepflegt werden), o Versionierung von Dokumenten (Modelle und Texte) o Dokumentation in Teams, arbeitsteilige Erstellung und Pflege o Inhaltsbezogene und formale Reviews von Dokumentation 1.4 Gliederung des Lehrplans für Architekturdokumentation Die einzelnen Abschnitte des Lehrplans sind gemäß folgender Gliederung beschrieben: Begriffe/Konzepte: Wesentliche Kernbegriffe dieses Themas. Unterrichts-/Übungszeit: Legt die Unterrichts- und Übungszeit fest, die für dieses Thema bzw. dessen Übung in einer akkreditierten Schulung mindestens aufgewendet werden muss. Lernziele: Beschreibt die zu vermittelnden Inhalte inklusive ihrer Kernbegriffe und -konzepte. Dieser Abschnitt skizziert damit auch die zu erwerbenden Kenntnisse in entsprechenden Schulungen. Die Lernziele werden differenziert in folgende Kategorien bzw. Unterkapitel: Was sollen die Teilnehmer können? Diese Inhalte sollen die Teilnehmer nach der Schulung selbständig anwenden können. Innerhalb der Schulung werden diese Inhalte durch Übungen abgedeckt und sind Bestandteil der Abschlussprüfung des isaqb Advanced Levels. Was sollen die Teilnehmer verstehen? Diese Inhalte können geprüft werden. Was sollen die Teilnehmer kennen? Diese Inhalte (Begriffe, Konzepte, Methoden, Praktiken oder Ähnliches) können das Verständnis unterstützen oder das Thema motivieren. Diese Inhalte sind nicht Bestandteil der Prüfung, werden in Schulungen thematisiert, aber nicht notwendigerweise ausführlich unterrichtet. 1.5 Ergänzende Informationen, Begriffe, Übersetzungen Soweit für das Verständnis des Lehrplans erforderlich, haben wir Fachbegriffe ins isaqb Glossar aufgenommen, definiert und bei Bedarf durch die Übersetzungen der Originalliteratur ergänzt. 1.6 Credit Points für diese Schulung Vom isaqb e.v. lizensierte Schulungen gemäß diesem Lehrplan geben 20 Credit Points im Bereich der methodischen Kompetenz. Seite 6 von 15 Stand 27. September 2012

7 2 Einführung in das isaqb Zertifizierungsprogramm Dauer: 15 Min (optional) Übungszeit: keine Dieser Abschnitt ist nicht prüfungsrelevant. Falls Teilnehmer bereits CPSA-F zertifiziert sind, kann dieser Abschnitt entfallen. 2.1 Begriffe und Konzepte isaqb, Advanced-Level Zertifizierung und Voraussetzung dazu. 2.2 Lernziele Die Teilnehmer lernen den Kontext des isaqb Zertifizierungsprogrammes und der zugehörigen Prüfungen beziehungsweise Prüfungsmodalitäten kennen Was sollen die Teilnehmer kennen? isaqb als Verein Advanced Level in Abgrenzung zu anderen Level Randbedingungen und Vorgehen beim isaqb Zertifizierungsprogramm Seite 7 von 15 Stand 27. September 2012

8 3 Grundbegriffe von Softwarearchitekturdokumentation Dauer: 55 Min Übungszeit: ca. 20 Min 3.1 Begriffe und Konzepte Softwarearchitektur, Dokumentation, Stakeholder, Notation, Vorgehensmodell 3.2 Lernziele Was sollen die Teilnehmer können? den Nutzen und die verschiedenen Ziele von Architekturdokumentation beschreiben und überzeugend vertreten können Massgebliche Nutzer und die Bedeutung von Architekturdokumentation für unterschiedliche Stakeholder erklären können Arbeitsergebnisse aus der Architekturdokumentation gegen Ergebnisse anderer Disziplinen (Anforderungsmanagement, Projektmanagement, ) abgrenzen können Typische Notationen für Architekturdokumentation nennen können Konkrete Vorgehensmodelle und ihren Beitrag bezüglich Architekturdokumentation nennen können Was sollen die Teilnehmer verstehen? Architekturdokumentation ist kein Selbstzweck. Architekturdokumentation unterstützt beim Lösungsentwurf, und bei der Kommunikation der Lösung dem Team und anderen (z.b. Auftraggebern) gegenüber. Verschiedene Vorgehensmodelle machen ausführliche bis gar keine Vorgaben bezüglich konkreter Ergebnisse Je nach Vorgehen und Rahmenbedingungen des Vorhabens sind sehr unterschiedliche Dokumentationsarbeiten zu leisten UML ist im Zusammenhang mit Architekturdokumentation etabliert, aber nicht zwingend erforderlich Was sollen die Teilnehmer kennen? Entfällt. Seite 8 von 15 Stand 27. September 2012

9 4 Dokumentation und Vorgehen Dauer: 90 Min Übungszeit: ca. 60 Min 4.1 Begriffe und Konzepte Vorgehensmodell, Rolle, Artefakt, iterativ/inkrementell, Lebenszyklus, agil 4.2 Lernziele Teilnehmer können für gegebene Situation angemessene Vorgehensweise für die Dokumentation bestimmen/entwerfen Was sollen die Teilnehmer können? Architekturdokumentation für folgende Situationen erstellen: o Erstellung neuer Systeme o Weiterentwicklung bestehender Systeme mit vorhandener Dokumentation o Nachdokumentation bestehender Systeme ohne vorhandene Dokumentation o Dokumentation in Ausnahmesituationen (wenig Budget, wenig Zeit, wenig verfügbare Informationsquellen etc) Zielgruppen und Ziele der Dokumentation ermitteln Zu erstellende Bestandteile bedarfsgerecht auswählen die Vorteile fester Gliederungen und Strukturen für (technische) Dokumentation argumentieren können Was sollen die Teilnehmer verstehen? Dokumentation entsteht im Idealfall begleitend zu Architektur und Entwicklung, nicht hinterher. Agilität und Dokumentation stehen nicht im Widerspruch zueinander Was sollen die Teilnehmer kennen? Die Rolle von Architekturdokumentation in verschiedenen konkreten Vorgehensmodellen Verschiedene Vorschläge und Vorlagen für Standardgliederungen (z.b. arc42, SEI) Seite 9 von 15 Stand 27. September 2012

10 5 Bestandteile von Architekturdokumentationen Dauer: 90 Min Übungszeit: ca. 90 Min 5.1 Begriffe und Konzepte Sichten, Entscheidungen, übergreifende Konzepte und Themen, Schnittstellen, Strukturen, Randbedingungen, Risiken, Qualitätsziele 5.2 Lernziele Was sollen die Teilnehmer können? Die Architektur mittlerer bis großer IT-Systeme selbständig dokumentieren, sowohl entwicklungsbegleitend wie bei Bedarf auch a posteriori ( Nachdokumentation ). Vorhandene Architekturdokumentation weiterentwickeln und pflegen, dabei die Qualität der Dokumentation systematisch verbessern. Für mittlere bis große Systeme spezifisch geeignete Arten und Strukturen der Architekturdokumentation erarbeiten oder auswählen. Faktoren, die Einfluss auf Softwarearchitektur haben, identifizieren und geeignet dokumentieren, z.b. o Randbedingungen o Qualitätsziele o Technische Risiken Architekturentscheidungen nachvollziehbar festhalten Unterschiedliche Sichten auf Softwarearchitektur mit geeigneten Beschreibungsmitteln anfertigen o Verschiedene Aspekte von Bausteinsichten erklären und dokumentieren (Darstellung als hierarchische Verfeinerung, Dokumentation wiederkehrender Strukturen oder Muster, Beschreibung interner Schnittstellen, Zusammenhang von Bausteinen zu Quellcode) o Laufzeitszenarien, insbesondere zur Erfüllung der wesentlichen Systemfunktionen, Darstellung unvollständiger Szenarien, Darstellung über verschiedene Verfeinerungsebenen o Notationen (etwa: UML, SysML o.ä.) zur Beschreibung von Sichten Schnittstellen beschreiben Technische und oder übergreifende Konzepte zielgruppengerecht anfertigen Konsistenz zwischen unterschiedlichen Bestandteilen der Architekturdokumentation prüfen bzw. herstellen Bestandteile in Dokumenten strukturieren Was sollen die Teilnehmer verstehen? Für eine nachvollziehbare Softwarearchitektur reicht es nicht, die Lösung zu dokumentieren. Auch architekturrelevante Anforderungen und Begründungen sind festzuhalten. Seite 10 von 15 Stand 27. September 2012

11 5.2.3 Was sollen die Teilnehmer kennen? IEEE 1471 ( Recommended Practice for Architecture Description of Software-Intensive Systems ) Alternative Vorschläge für konkrete Sichten, zum Beispiel o Rational Unified Process (4+1) o Meta-/Sichtenmodell vom Software Engineering Institute o arc42 Grafische Notationen für Sichten FMC (Fundamental Modeling Concepts) RM-ODP (Reference Model of Open Distributed Processing) Seite 11 von 15 Stand 27. September 2012

12 6 Werkzeuge Dauer: 90 Min Übungszeit: ca. 30 Min 6.1 Begriffe und Konzepte Analoge und digitale Werkzeuge, Modellierungstools, Toolkette 6.2 Lernziele Was sollen die Teilnehmer können? Die richtigen Werkzeuge für die verschiedenen Aktivitäten auswählen: o Erstellung und Pflege von Bestandteilen von Architekturdokumentation o Verwaltung der Bestandteile o Kommunikation von Inhalten mit Unterstützung der Bestandteile Analoge und digitale Dokumentationswerkzeuge situations- und bedarfsgerecht einsetzen und die Ergebnisse sichern Eine vollständige Toolkette zur Architekturdokumentation anhand konkreter Anforderungen, Randbedingungen und weiterer Einflussfaktoren nachvollziehbar auswählen Was sollen die Teilnehmer verstehen? Werkzeuge können bei sehr verschiedenen Aktivitäten rund um Architekturdokumentation unterstützen. Dokumentation sollte, analog zu Quellcode, versioniert und releasefähig verwaltet werden. Zu jedem definierten Stand der Software sollte der zugehörige Stand der (Architektur- )Dokumentation wieder hergestellt oder generiert werden können Was sollen die Teilnehmer kennen? Jeweilige Stärken, Schwächen und typische Herausforderungen beim Einsatz und der Integration von verbreiteten Werkzeugenkategorien, konkret: o Wikis o Modellierungswerkzeuge o Zeichenprogramme o Textverarbeitungen o Versionsverwaltungen o Sonstige (etwa: Blogs, Issue-Tracker etc.) Konkrete vollständige Werkzeugketten, welche sämtliche Aktivitäten rund um Architekturdokumentation adressieren Seite 12 von 15 Stand 27. September 2012

13 7 Dokumentation bewerten Dauer: 75 Min Übungszeit: ca. 45 Min 7.1 Begriffe und Konzepte Review, Checklisten, Fragenkataloge 7.2 Lernziele Was sollen die Teilnehmer können? Zwischen inhaltlicher und formaler Begutachtung einer Architekturdokumentation differenzieren Review einer Dokumentation von der Bewertung der Architektur abgrenzen Unterschiedliche Ziele beim Review der Dokumentation erklären Angemessene Review-Schritte auswählen, planen und durchführen Ziele für ein Review festlegen und verbindlich an die Gutachter kommunizieren Checklisten und Fragenkataloge für Reviews erstellen Im Rahmen einer Review-Sitzung o In der Rolle des Autors mit Einwänden angemessen umgehen o In der Rolle eines Gutachters konstruktive Rückmeldungen an Autoren geben o In der Rolle des Moderators ein fachliches Review leiten Was sollen die Teilnehmer verstehen? Die Überprüfung der Dokumentation auf Gebrauchstauglichkeit ist ein essentieller Erfolgsfaktor Was sollen die Teilnehmer kennen? IEEE "IEEE Standard for Software Reviews and Audits" Verschiedene Beispiele von Architekturdokumentation Seite 13 von 15 Stand 27. September 2012

14 8 Beispiele für Dokumentation von Softwarearchitekturen Dauer: 60 Min Übungszeit: keine Dieser Abschnitt ist nicht prüfungsrelevant. 8.1 Begriffe und Konzepte Innerhalb jeder akkreditierten Schulung muss mindestens ein Beispiel einer dokumentierten Software-Architektur vorgestellt werden. Art und Ausprägung der vorgestellten Beispiele können von der Schulung bzw. den Interessen der Teilnehmer abhängen und werden seitens isaqb nicht vorgegeben. 8.2 Lernziele Die Dokumentation (mindestens) einer realen Softwarearchitektur sehen und deren Vor- und Nachteile diskutieren Was sollen die Teilnehmer können? Erklären, wie methodische Dokumentation im Beispiel umgesetzt wurde, Stärken und Schwächen des vorgestellten Beispiels analysieren können Was sollen die Teilnehmer verstehen? n.z Was sollen die Teilnehmer kennen? Weitere Beispiele (möglichst) realitätsnaher Architekturdokumentationen 8.3 Referenzen Keine. Schulungsanbieter sind für die Auswahl und Beschreibung von Beispielen verantwortlich. Seite 14 von 15 Stand 27. September 2012

15 9 Quellen und Referenzen zu Softwarearchitekturdokumentation Dieser Abschnitt enthält Quellenangaben, die ganz oder teilweise im Curriculum referenziert werden. [Bachmann 2000] Bachmann, F., L. Bass, et al.: Software Architecture Documentation in Practice. Software Engineering Institute, CMU/SEI-2000-SR-004. [Bass+2003] Bass, L., Clements, P. und Kazman, R. (2003): Software Architecture in Practice. Addison-Wesley, Reading, Mass [Clements+2003] Clements, P., F. Bachmann, L. Bass, D. Garlan, J. Ivers et al: Documenting Software Architectures Views and Beyond. Addison Wesley, [Hargis+2004] Hargis, Gretchen et. al: Quality Technical Information: A Handbook for Writers and Editors. Prentice Hall, IBM Press, [Kruchten 1995] Kruchten, P.: Architectural Blueprints The 4-1 View Model of Architecture. IEEE Software November 1995; 12(6), p [Starke 2011] Starke, G. (2011): Effektive Software-Architekturen - Ein praktischer Leitfaden. 5. Auflage 2011, Carl Hanser Verlag, München. [Zörner 2012] Zörner, Stefan: Softwarearchitekturen dokumentieren und kommunizieren, Hanser Verlag 2012 Seite 15 von 15 Stand 27. September 2012