[et_pb_section fb_built=”1″ _builder_version=”4.6.5″ _module_preset=”default” custom_padding=”30px||0px||false|false”][et_pb_row _builder_version=”4.7.3″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.7.3″ _module_preset=”default”][et_pb_text _builder_version=”4.7.3″ _module_preset=”default”]<\/p>\n
Das Dokumentieren einer Softwarearchitektur ist f\u00fcr den Projekterfolg unabdinglich. Entw\u00fcrfe, Entscheidungen und L\u00f6sungen m\u00fcssen nachvollziehbar und wirkungsvoll festgehalten werden. Hierzu geh\u00f6rt idealerweise auch die Beschreibung der verworfenen Alternativen. Denn es stellt sich die Frage, wer nach einem Monat oder auch l\u00e4nger noch alle Gr\u00fcnde wei\u00df, weshalb man sich nun f\u00fcr die eine oder andere Variante entschieden hat. Oder eben auch gegen die eine oder anderen Variante.<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” text_line_height=”1.3em” custom_padding=”20px||||false|false”]<\/p>\n
Typische Fragen in Softwareprojekten sind beispielsweise:<\/strong><\/span><\/p>\n \u201eWie sieht das Schichtenmodell aus?”<\/p>\n \u201eWelche Design Patterns wurden verwendet?”<\/p>\n \u201eWelche externen Webservices werden verwendet?”<\/p>\n \u201eWieso habt Ihr das so gemacht? Ist das nicht zu kompliziert?”<\/p>\n <\/p>\n Und wenn die Antworten dann lauten:<\/strong><\/p>\n \u201eDas war schon so, als ich ins Projekt kam.”<\/p>\n \u201eEs wurde in einem Meeting entschieden.”<\/p>\n \u201eEs gibt keine Dokumentation, weil wir agil vorgehen.”<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” custom_margin=”||||false|false” custom_padding=”20px||||false|false” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n \u2026dann entfachen immer wieder die gleichen Diskussionen. Durch die Entw\u00fcrfe, die Diagramme und die Konzepte der Architekturdokumentation sollen allen Projektbeteiligten bessere Antworten auf diese Fragen in Softwareprojekten parat stehen. Eine ausf\u00fchrliche Architekturdokumentation kann also sehr kl\u00e4rend wirken, die Kommunikation unterst\u00fctzen und Konflikte vorbeugen. Der Softwarearchitekt hat folglich die Aufgabe, eine angemessene L\u00f6sung zu entwerfen, um eine Nachvollziehbarkeit und gleichzeitig Lerneffekte zu gew\u00e4hrleisten.<\/span><\/p>\n F\u00fcr alle Arten von Architekturdokumentation gelten daher einige \u00fcbergreifende Anforderungen und Regeln, die Sie bei der Erstellung solcher Dokumente ber\u00fccksichtigen sollten. Softwarearchitekten ben\u00f6tigen dabei ein grundlegendes Verst\u00e4ndnis der Beschreibung von Softwarearchitekturen. Lernen Sie effektiv und praxisorientiert Softwarearchitekturen zu dokumentieren und zielgruppengerecht zu kommunizieren. Erfahren Sie, wie die Architekturdokumentation zu einem integralen Kommunikations- und Arbeitsmittel wird. Lernen Sie architekturrelevante Einflussfaktoren und zentrale Entscheidungen festzuhalten.<\/p>\n Unser 2-t\u00e4giges Softwarearchitektur-Training \u201aArchitekturdokumentation (ADOC)\u2018 vermittelt neben fachlichen Aspekten auch die wichtigen organisatorischen und sozialen Faktoren der Architekturdokumentation. Neben den Grundbegriffen der Architekturdokumentation bekommen Sie das Wissen rund um die Bestandteile, Vorgehensmodelle, Werkzeuge, Vorgaben und Bewertung an die Hand.<\/p>\n Am Ende dieses Softwarearchitektur-Trainings haben Sie das R\u00fcstzeug, um die Architekturdokumentation eines mittleren oder gro\u00dfen Systems zu erstellen, zu bewerten und das Vorgehen zur Dokumentation eines solchen Systems zu definieren. Das Softwarearchitektur-Training \u201aArchitekturdokumentation (ADOC)\u2018 deckt einen Bereich der methodischen Kompetenzen des CPSA Advanced Levels (CPSA-A) ab und ist entsprechend beim iSAQB lizenziert. Wenn Sie die CPSA-A Zertifizierung anstreben, k\u00f6nnen Sie sich mit der Teilnahme 20 Credit Points anrechnen lassen.<\/p>\n Hier kommen Sie zu weiteren Informationen und zur Anmeldung.<\/a><\/p>\n