Certified Professional for Software Architecture (CPSA) Foundation Level

Größe: px
Ab Seite anzeigen:

Download "Certified Professional for Software Architecture (CPSA) Foundation Level"

Transkript

1 Curriculum für Certified Professional for Software Architecture (CPSA) Foundation Level Version 2.0 (1. Juli 2009)

2 Inhaltsverzeichnis M bfkibfqrkd= Q MKN t^p=sbrjfqqbiq=bfkb=clrka^qflk=ibsbi=p`erirkd\=q MKO difbabrrkd=abp=ibermi^kp=rka=bjmcleibkb=wbfqif`eb=^rcqbfirkd= Q MKP a^rbri=afa^hqfh=rka=tbfqbrb=abq^fip=^hhrbafqfbrqbr=p`erirkdbk=q MKQ slr^rppbqwrkdbk= R MKR difbabrrkd=abr=fp^n_=ibermi^kjlarib= R MKS ^_drbkwrkd= R MKT brdûkwbkab=fkclrj^qflkbki=_bdrfccbi= _brpbqwrkdbk= S MKU bfkc errkd=fk=a^p=fp^n_=wbrqcfwfbrrkdpmrldr^jj= S MKV _bdrfccb=rka=hlkwbmqb= S MKNM ibrkwfbib= S N drrka_bdrfccb=slk=plcqt^rbj^r`efqbhqrrbk= T NKN _bdrfccb=rka=hlkwbmqb= T NKO ibrkwfbib= T NKP RbcbRbkwbk= V O _bp`erbf_rkd=rka=hljjrkfh^qflk=slk=plcqt^rbj^r`efqbhqrrbk= NM OKN _bdrfccb=rka=hlkwbmqb= NM OKO ibrkwfbib= NM OKP RbcbRbkwbk= NN P bkqtf`hirkd=slk=plcqt^rbj^r`efqbhqrrbk= NO PKN _bdrfccb=rka=hlkwbmqb= NO PKO ibrkwfbib= NO PKP RbcbRbkwbk= NQ Q plcqt^rbj^r`efqbhqrrbk=rka=nr^ifqûq= NR QKN _bdrfccb=rka=hlkwbmqb= NR QKO ibrkwfbib= NR QKP RbcbRbkwbk= NS R tbrhwbrdb=c R=plcqt^RbJ^R`efqbhqbk= NT RKN _bdrfccb=rka=hlkwbmqb= NT RKO ibrkwfbib= NV RKP RbcbRbkwbk= NV Seite 2 von 23 Stand 1. Juli 2009

3 S _bfpmfbib=c R=plcqt^RbJ^R`efqbhqrRbk= OM SKN _bdrfccb=rka=hlkwbmqb= OM SKO ibrkwfbib= OM SKP RbcbRbkwbk= OM T nrbiibk=rka=rbcbrbkwbk=wr=plcqt^rbj^r`efqbhqrr= ON Seite 3 von 23 Stand 1. Juli 2009

4 0 Einleitung 0.1 Was vermittelt eine Foundation Level Schulung? Eine akkreditierte Schulung Certified Professional for Software Architecture Foundation Level vermittelt den Teilnehmern: den Begriff und die Bedeutung von Software-Architektur, die Aufgaben und Verantwortung von Software-Architekten, die Rolle von Software-Architekten in Projekten, State-of-the-Art Methoden und Techniken zur Entwicklung von Software-Architekturen, sowie folgende Fähigkeiten: mit anderen Projektbeteiligten aus den Bereichen Anforderungsmanagement, Projektmanagement, Test und Entwicklung wesentliche Software-Architekturentscheidungen abzustimmen, Software-Architekturen auf Basis von Sichten, Architekturmustern und technischen Konzepten zu dokumentieren und kommunizieren, die wesentlichen Schritte beim Entwurf von Software-Architekturen zu verstehen und für kleine und mittlere Systeme selbständig durchzuführen Die Schulung für den Foundation Level vermittelt das notwendige Wissen und die notwendigen Fähigkeiten, um für kleine und mittlere Systeme ausgehend von einer hinreichend detailliert beschriebene Anforderungsspezifikation eine dem Problem angemessene Software-Architektur zu entwerfen und zu dokumentieren, die dann als Implementierungsgrundlage bzw. -vorlage genutzt werden kann. Teilnehmer erhalten das Rüstzeug, um problembezogene Entwurfsentscheidungen auf der Basis ihrer vorab erworbenen Praxiserfahrung zu treffen. 0.2 Gliederung des Lehrplans und empfohlene zeitliche Aufteilung 0.3 Dauer, Didaktik und weitere Details akkreditierter Schulungen Die genannten Zeiten sind Empfehlungen. Die Dauer einer Schulung sollte mindestens 3 Tage betragen, kann aber durchaus 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. Seite 4 von 23 Stand 1. Juli 2009

5 0.4 Voraussetzungen Teilnehmer sollten folgende Kenntnisse und/oder Erfahrung mitbringen: Ausreichende praktische Erfahrung in Softwareentwicklung, erworben anhand unterschiedlicher Projekte oder Systeme außerhalb der Ausbildung Kenntnisse und praktische Erfahrung in mindestens einer höheren Programmiersprache Grundlagen der Modellierung Grundlagen von UML (Klassen-, Paket-, Komponenten- und Sequenzdiagramme) und deren Abbildung auf Quellcode Praktische Erfahrung mit verteilten Systemen (Entwicklung irgend eines Systems das nicht nur auf einem Rechner ausgeführt wird) Hilfreich für das Verständnis einiger Konzepte sind darüber hinaus: Kenntnisse der Objektorientierung Praktische Erfahrung in mindestens einer objektorientierten Programmiersprache Praktische Erfahrung in der Konzeption und Implementierung verteilt ablaufender Anwendungen, wie etwa Client/Server-Systeme oder Web-Anwendungen. Erfahrung in CORBA, RMI, Web-Services Praktische Erfahrung in technischer Dokumentation, insbesondere in der Dokumentation von Quellcode, Systementwürfen oder technischen Konzepten. 0.5 Gliederung der isaqb Lehrplanmodule Die einzelnen Module des Lehrplans sind gemäß folgender Gliederung beschrieben: Begriffe/Konzepte: Wesentliche Kernbegriffe dieses Lehrplanmoduls. 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 Prüfung zum "Foundation Level". Was sollen die Teilnehmer verstehen? Diese Inhalte können in der Prüfung zum Foundation Level 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. Referenzen: Verweise auf weiterführende Literatur, Standards oder andere Quellen. Eine ausführliche Liste von Büchern und weiteren Quellen findet sich auf isaqb-fachlichequellen. 0.6 Abgrenzung Dieser Lehrplan stellt keine vollständige Beschreibung des Wissensgebiets Software-Architektur dar. Er reflektiert lediglich den aus heutiger Sicht der isaqb-mitglieder notwendigen und sinnvollen Inhalt zur Erreichung der Lernziele des Foundation Level Folgende Themen oder Konzepte sind nicht Bestandteil des Foundation Level: Konkrete Implementierungstechnologien, -frameworks oder bibliotheken Programmierung oder Programmiersprachen Grundlagen der Modellierung Umfassende Darstellung von UML Systemanalyse, Requirements Engineering Projektmanagement Seite 5 von 23 Stand 1. Juli 2009

6 0.7 Ergänzende Informationen, Begriffe, Übersetzungen Soweit für das Verständnis des Lehrplan erforderlich, haben wir Fachbegriffe ins isaqb Glossar aufgenommen, definiert und bei Bedarf durch die Übersetzungen der Originalliteratur ergänzt. 0.8 Einführung in das isaqb Zertfizierungsprogramm Dauer: 15 Min Übungszeit: keine Dieser Abschnitt ist nicht prüfungsrelevant. 0.9 Begriffe und Konzepte isaqb, Zertifizierung, Foundation- und Advanced Level, Prüfung 0.10 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 Foundation Level in Abgrenzung zu weiteren Level Randbedingungen und Vorgehen beim isaqb Zertifizierungsprogramm Andere Zertifizierungsprogramme (zum Beispiel TOGAF) Seite 6 von 23 Stand 1. Juli 2009

7 1 Grundbegriffe von Software-Architekturen Dauer: 135 Min Übungszeit: 45 Min 1.1 Begriffe und Konzepte Software-Architektur, Struktur, Bausteine/Komponenten, Schnittstellen, Beziehungen, übergreifende Konzepte/Aspekte, Architekturziele Software-Architekten und deren Verantwortlichkeit, Aufgaben und benötigte Fähigkeiten, nichtfunktionale und funktionale Anforderungen an Systeme, Randbedingungen, Einflussfaktoren, Typen von IT-Systemen (eingebettete Systeme, Echtzeitsysteme, Informationssysteme etc.) 1.2 Lernziele Was sollen die Teilnehmer können? Definition von Software-Architektur Vergleich mehrerer De nitionen von Software-Architektur (u.a. SEI, Booch etc.) und deren Gemeinsamkeiten benennen: Komponenten und Bausteine mit Schnittstellen und Beziehungen Strukturen und übergreifende Konzepte übergreifende Entwurfsentscheidungen mit systemweiten Konsequenzen Design als Architektur-im-Kleinen Unsere Definition von Software-Architektur und Komponenten und der Bezug zum Code Was ist eine Software-Architektur in diesem Kurs? Was ist eine Komponenten, eine Schnittstelle, Beziehungen zw. Komponenten in diesem Kurs? Wie kann man sich die Abbildung dieser Definitionen (SW-Architekturen/Komponenten /Schnittstellen/Beziehungen) auf den Code vorstellen? Analogie von Software-Architektur mit Konstruktionszeichnungen, Bauplänen erklären können Software-Architektur als Beschreibung der Lösung Software-Architektur als Unterstützung des Erstellungsprozesses, insbesondere der Implementierung Nutzen und Ziele von Software-Architektur Ziele von Software-Architekten und Software-Architekturen benennen und erklären Fokus von Software-Architektur liegt auf Qualitätsmerkmalen wie Langlebigkeit, Wartbarkeit, Änderbarkeit als Differenzierung gegenüber reiner Funktionalität. Architekturziele sind in der Regel langfristig, Projektziele oftmals kurzfristig Einordnung von Software-Architektur in die gesamte Entwicklung von IT-Systemen erklären Rolle von Software-Architekt im Zusammenhang zu anderen Stakeholdern, kennen und erkären, insbesondere den Zusammenhang zu: Anforderungsanalyse (Systemanalyse, Requirements Management, Fachbereich) Implementierung Projektleitung und -management Qualitätssicherung IT-Betrieb (Produktion, Rechenzentren) [zutreffend primär für Informationssysteme] Hardware-Entwicklung Seite 7 von 23 Stand 1. Juli 2009

8 Aufgaben von Software-Architekten Software-Architekten tragen die Verantwortung für die Erreichung der geforderten oder notwendigen Qualität der Lösung. Sie müssen diese Verantwortung mit der Gesamtverantwortung der Projektleitung koordinieren. Aufgaben von Software-Architekten benennen und beschreiben können Anforderungen und Randbedingungen klären und hinterfragen, bei Bedarf verfeinern. Hierzu zählen neben den funktionalen Anforderungen (required features) insbesondere die geforderten Qualitätsmerkmale (required constraints). Konsequenzen dieser Randbedingungen auf die Architektur aufzeigen, siehe [Hofmeister+2000 Global Analysis], [Hofmeister+2005] Strukturentscheidungen hinsichtlich Systemzerlegung und Bausteinstruktur treffen, dabei Abhängigkeiten und Schnittstellen zwischen den Bausteinen festlegen Übergreifende technische Konzepte entscheiden (beispielsweise Persistenz, Kommunikation, GUI) und bei Bedarf umsetzen Software-Architektur kommunizieren und dokumentieren Umsetzung und Implementierung der Architektur überwachen, Rückmeldungen der beteiligten Stakeholder bei Bedarf in die Architektur einarbeiten, Konsistenz von Quellcode und Software-Architektur prüfen und sicherstellen Software-Architektur bewerten, insbesondere hinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale Ergebniszusammenhänge zwischen den Aufgaben benennen und beschreiben: Welche Aufgabe liefert oder beeinflusst welches Arbeitsergebnis? Zusammenhang zwischen Anforderungen und Lösungen erläutern Randbedingungen und Einflussfaktoren für die Architekturgestaltung finden und gewichten Auf Basis bestehender Anforderungen Architekturziele identifizieren und präzisieren Konsequenzen von Architekturentscheidungen erkennen, aufzeigen und gegenüber anderen Stakeholdern argumentieren. Selbständig die Notwendigkeit von Iterationen bei allen Aufgaben erkennen und Möglichkeiten für entsprechende Rückmeldung aufzeigen Architektur- und Entwurfsentscheidungen Bedeutung von Architekturzielen, Randbedingungen und Einflussfaktoren für die Gestaltung von Software-Architekturen aufzeigen können. Erklärung von Anforderungen, sowohl required features als auch required constraints Erklärung von Randbedingungen / Einflussfaktoren Erklärung von (langfristigen) Architekturzielen sowie deren Abgrenzung gegen (kurzfristige) Projektziele Entscheidungen über Strukturen und technische Konzepte, insbesondere die möglichen gegenseitigen Abhängigkeiten dieser Entscheidungen Notwendigkeit expliziter und operationalisierter Architekturziele erläutern können. Nur anhand solcher Ziele kann der Erfolg von Architekturen oder Architekturentwürfen bewertet werden Einfluss iterativen Vorgehens auf Architekturentscheidungen erläutern (hinsichtlich Risiken und Prognostizierbarkeit) Was sollen die Teilnehmer verstehen? Software-Architekturen sind eine Beschreibung einer Lösung, nicht die Lösung selbst Software-Architekturen unterstützen die Erreichung nichtfunktionaler Qualitätsmerkmale Software-Architekten tragen die Verantwortung für die Erreichung der geforderten oder notwendigen Qualität der Lösung Software-Architekten müssen ihre Aufgaben aktiv angehen Software-Architekten sollten Annahmen oder Voraussetzungen explizit darstellen und implizite Annahmen vermeiden Seite 8 von 23 Stand 1. Juli 2009

9 Software-Architekten müssen aufgrund inhärenter Unsicherheit oftmals iterativ arbeiten und entscheiden. Dabei müssen sie bei anderen Stakeholdern systematisch Rückmeldung einholen. Qualitätsanforderungen (Required constraints) wie Änderbarkeit, Effizienz, Sicherheit etc. beeinflussen Software-Architekturen erheblich mehr als funktionale Anforderungen Differenzierung von Software-Architektur für unterschiedliche Typen von IT-Systemen verstehen: Zusammenhang mit der System- oder Gesamtarchitektur für eingebettete oder hardwarenahe Systeme. Besonderheiten des Hardware-/Software-Codesigns verstehen (zeitliche und inhaltliche Abhängigkeiten von Hard- und Softwareentwurf) Zusammenhang mit Geschäfts- und Betriebsprozessen für Informationssysteme Zusammenhang mit Geschäfts- und Betriebsprozessen für Entscheidungsunterstützungssysteme (Data Warehouse, Management InformationSystems) Was sollen die Teilnehmer kennen? Weitere Ebenen von Architektur, z.b. Enterprise-IT-Architektur, Geschäftsarchitektur, Infrastrukturarchitektur (etwa nach [Dern 2006]): Es gibt innerhalb der IT von Informationssystemen mehrere Ebenen von Architekturen: Infrastruktur-Architektur: Struktur der technischen Infrastruktur, Hardware, Netze etc. Hardware-Architektur (für hardwarenahe Systeme) Software-Architektur: Struktur einzelner Software-Systeme. Dies ist der Fokus von Software- Architekten im Sinne des isaqb. Unternehmens-IT-Architektur, Enterprise-IT-Architektur: Struktur von Anwendungslandschaften. Nicht inhaltlicher Fokus von isaqb. Geschäftsprozess-Architektur, Business-Architektur: Struktur von Geschäftsprozessen (nicht inhaltlicher Fokus von isaqb). Taxonomie Qualitätsmerkmale nach ISO 9126 (ohne deren exakte Definition) 1.3 Referenzen [Bass+2003] [Hofmeister+2000] [Posch 2004] [Reussner+2006] [Siedersleben 2004] [Starke 2008] [Vogel+2005] Seite 9 von 23 Stand 1. Juli 2009

10 2 Beschreibung und Kommunikation von Software-Architekturen Dauer: 150 Min Übungszeit: 90 Min 2.1 Begriffe und Konzepte Sichten, Strukturen, (technische) Konzepte, Dokumentation, Kommunikation, Beschreibung Meta- Strukturen zur Beschreibung und Kommunikation, Bausteine, Bausteinsicht, Laufzeitbaustein, Laufzeitsicht, Verteilungssicht, Knoten, Kanal, Verteilungsartefakte, Mapping von Bausteinen auf Verteilungsartefakte, Beschreibung von Schnittstellen Dieser Teil des Lehrplans hängt eng mit dem Folgekapitel zusammen. 2.2 Lernziele Was sollen die Teilnehmer können? Software-Architekturen stakeholdergerecht beschreiben und kommunizieren. Definition wesentlicher Architektursichten und deren Bedeutung erläutern Dokumentieren verschiedener Architektursichten Baustein- oder Komponentensicht (Aufbau des Systems aus Softwarebausteinen) Laufzeitsicht (dynamische Sicht, Zusammenwirken der Softwarebausteine zur Laufzeit, Zustandsmodelle) Verteilungs-/Deploymentsicht (Abbildung von Softwarebausteinen auf Hardware oder Ausführungsumgebungen) Bedeutung übergreifender technischer Konzepte beziehungsweise Architekturaspekte erklären Einige typische Konzepte benennen (z.b. Persistenz, Ablaufsteuerung, GUI, Verteilung/Integration) Beschreibung und Kommunikation von Schnittstellen Definition von Schnittstellen, insbesondere externer Schnittstellen resourcenorientierter Ansatz serviceorientierter Ansatz Wesentliche Grundlagen und Qualitätsmerkmale technischer Dokumentation erläutern: Qualitätsmerkmale technischer Dokumentation: Verständlichkeit, Korrektheit, Effizienz Was sollen die Teilnehmer verstehen? Beschreibung (a.k.a. Dokumentation) ist schriftliche Kommunikation Die Beschreibungsmittel für Software-Architekturen unterstützen auch bei deren Entwurf und Erstellung UML Diagramme, die zur Notation von Architektursichten nützlich sind Klassen-, Paket- und Komponentendiagramme Verteilungsdiagramme Sequenzdiagramme Nutzen von template-/schablonenbasierter Dokumentation Blackbox- und Whitebox Templates Templates für Entwurf/Dokumentation von Knoten oder Kanälen Templates zur Dokumentation von Schnittstellen Grundsätze guter technischer Dokumentation Seite 10 von 23 Stand 1. Juli 2009

11 Sprache und Ausdrucksmittel technischer Dokumentation sollte an den Fähigkeiten und Zielen der Leser ausgerichtet werden Verständlichkeit technischer Dokumentation kann nur von Lesern beurteilt werden Wesentliche Qualitätsmerkmale technischer Dokumentation sind: Korrektheit Verständlichkeit Effizienz, sowohl beim Lesen als auch beim Schreiben Dokumentieren Sie wichtige Architekturentscheidungen Erklären Sie Architekturentscheidungen durch Begründungen und Herleitungen Beschreibung von Software-Architekturen stellt besondere Anforderungen aufgrund der vielseitigen Stakeholder Unterschiedliche Leserkreise: Management, Entwickler, QS sowie andere Software- Architekten Unterschiedliche Autoren: Software-Architekten, Entwickler und ggfs. weitere Was sollen die Teilnehmer kennen? Grundlagen mindestens zweier, am besten mehrerer der publizierten Frameworks zur Beschreibung von Software-Architekturen: TOGAF FMC RM/ODP IEEE-1471 arc42 Ideen und Beispiele von Checklisten für die Erstellung, Dokumentation und Prüfung von Software-Architekturen Mögliche Werkzeuge zur Erstellung und Pflege von Architekturdokumentation 2.3 Referenzen [Clements+2003] [Hargis+2004] [Starke 2008] [Starke+2009] Seite 11 von 23 Stand 1. Juli 2009

12 3 Entwicklung von Software-Architekturen Dauer: 270 Min Übungszeit: 90 Min 3.1 Begriffe und Konzepte Entwurf, Vorgehen beim Entwurf, Entwurfsentscheidung, Sichten, technischer Konzepte Architekturmuster, Entwurfsprinzipien, fachliche und technische Architekturen, modellbasierter Entwurf, iterativ/inkrementeller Entwurf, domain driven design, Top-Down und Bottom-Up Vorgehen 3.2 Lernziele Dieser Teil führt Vorgehensweisen und Hilfsmittel für Entwurf und Entwicklung von Software- Architekturen ein. Die Teilnehmer erarbeiten in Übungen eine oder mehrere Architekturentwürfe und nutzen dabei die Ergebnisse des Kapitels Was sollen die Teilnehmer können? Vorgehen und Heuristiken zur Architekturentwicklung benennen, beschreiben und erklären: Modell- und sichtenbasierte Architekturentwicklung Modellbasierter Entwurf und Domain Driven Design Iterativer und inkrementeller Entwurf Notwendigkeit von Iterationen, insbesondere bei unter Unsicherheit getroffenen Entscheidungen Rückmeldungen zu Entwurfsentscheidungen auf Basis von Quellcode sowie qualitativer Betrachtung Top-Down und Bottom-Up Vorgehen beim Entwurf Einflussfaktoren und Randbedingungen als Beschränkungen beim Architekturentwurf (Global Analysis) Entwurf von Architekturen auf Basis bekannter funktionaler und nichtfunktionaler Anforderungen für nicht sicherheits- oder unternehmenskritische Software-Systeme durchführen und angemessen dokumentieren Blackbox- und Whitebox-Begriff erklären und zielgerichtet anwenden Schrittweise Verfeinerung und Präzisierung von Bausteinen (Hierarchisierung) anwenden Entwurf einzelner Architektursichten, insbesondere Verteilungs-, Baustein- und Laufzeitsicht und deren Konsequenzen auf den zugehörigen Quellcode beschreiben Abbildung der Architektur auf den Code festlegen, entwerfen, sich überlegen und die damit verbundenen Konsequenzen Trennung fachlicher und technischer Bestandteile in Architekturen begründen und anwenden Fachliche Strukturen entwerfen und begründen Fachliche Bausteine (Entitäten, Services) identifizieren, begründen und dokumentieren Abstraktionen zum Übergang fachliche Bestandteile zu technischen Bestandteilen erklären und anwenden Einfluß von Qualitätsanforderungen auf Architekturen Einfluß technischer Entscheidungen und Konzepte auf Architekturen, insbesondere Bausteinstrukturen Grundlegende Konzepte der Architekturentwicklung benennen, erklären und anwenden Bausteine von Software-Architekturen und deren Eigenschaften benennen und erklären: Seite 12 von 23 Stand 1. Juli 2009

13 wünschenswerte Eigenschaften (Kapselung, Information Hiding, Geheimnisprinzip) von Bausteinen Blackbox und Whitebox Bausteine Arten der Zusammensetzung von Bausteinen (Schachtelung, Benutzung/Delegation, Vererbung) UML-Notation für verschiedene Bausteine und deren Zusammensetzung Pakete als semantisch schwache Form der Aggregation von Bausteinen Komponenten mit fest definierten Schnittstellen als semantisch präzisere Form der Aggregation Wichtige Architekturmuster beschreiben, erklären und angemessen anwenden können Schichten Pipes und Filter Model-View-Controller Entwurfsprinzipien erläutern anwenden können Geheimnisprinzip Kopplung und Kohäsion Trennung von Verantwortlichkeiten (Separation of Concern) Offen-Geschlossen-Prinzip (Open-/Closed-Principle) Umkehrung von Abhängigkeiten durch Schnittstellen Dependency Injection zur Externalisierung von Abhängigkeiten Zusammenhang zwischen Abhängigkeiten im Modell und im Quellcode von Programmiersprachen Abhängigkeiten und Kopplung von Bausteinen verstehen und gezielt einsetzen Konsequenzen von Kopplung erkennen Arten der Kopplung (strukturell, zeitlich, über Datentypen, über Hardware etc.) aufzeigen können Möglichkeiten zur Auflösung bzw. Reduktion von Kopplung kennen Schnittstellen / Interfaces entwerfen und beschreiben können Was sollen die Teilnehmer verstehen? Details zu Kopplung und deren Konsequenz in Programmiersprachen Umsetzung von Beziehungen in (objektorientierten) Programmiersprachen Konstruktoren Factory-Muster Dependency-Injection Architekturmuster bedarfsgerecht einsetzen nach POSA (Schichten, Pipes und Filter, Blackboard, Microkernel) nach Fowler/PoEAA nach Hohpe (Messaging, async-muster) sonstige Muster Sprachunabhängige Entwurfsmuster einsetzen Adapter, Wrapper, Gateway Facade Registry Broker Was sollen die Teilnehmer kennen? Weitere Entwurfsmuster (Design Patterns), die nicht unbedingt Bestandteil einer akkreditierten Schulung sein müssen Factory Seite 13 von 23 Stand 1. Juli 2009

14 Wesentliche Quellen für Architekturmuster POSA-Serie Pattern-Konferenzen Beispiele weiterer Pattern-Languages Organizational Patterns Reengineering Patterns Security Patterns Client/Server Patterns Patterns für Distributed Systems Weitere je nach Schwerpunkt der jeweiligen Schulung 3.3 Referenzen [Martin+2003] [Fowler 2003] POSA-Serie, insbesondere [POSA-1] und [POSA-4] [Demeyer+2002] Seite 14 von 23 Stand 1. Juli 2009

15 4 Software-Architekturen und Qualität Dauer: 60 Min Übungszeit: 60 Min 4.1 Begriffe und Konzepte Qualität, Qualitätsmerkmale, DIN/ISO 9126, ATAM, Szenarien, Qualitätsbaum, Kompromisse (bei der Umsetzung von Qualitätsmerkmalen), qualitative Architekturbewertung 4.2 Lernziele In diesem Teil lernen die Teilnehmer sowohl Maßnahmen zur Erreichung bestimmter Qualitätsmerkmale in Software-Systemen kennen, als auch methodisches Vorgehen zur qualitativen Bewertung von Software-Architekturen Was sollen die Teilnehmer können? Begriff der Qualität (angelehnt an DIN/ISO 9126) und Qualitätsmerkmalen erklären Qualitätsmodelle (wie etwa DIN/ISO 9126) erklären Zusammenhang und Wechselwirkungen von Qualitätsmerkmalen erläutern Taktiken, Praktiken sowie technische Möglichkeiten zur Erreichung wichtiger Qualitätsziele von Software-Systemen (unterschiedlich für eingebettete Systeme bzw. Informationssysteme) erklären und anwenden, beispielsweise: Effizienz/Performance Wartbarkeit, Änderbarkeit, Erweiterbarkeit, Flexibilität Qualitative Bewertung von Software-Architekturen nach ATAM durchführen Vorgehen bei qualitativer Bewertung erklären und durchführen Erstellung von Szenarien und Qualitätsbäumen erklären und durchführen Analyse von Software-Architekturen hinsichtlich Szenarien und Identifikation entsprechender Risiken selbständig durchführen Bewertung von Software-Architekturen im Hinblick auf ihre Umsetzung durchführen, d.h. die Frage beantworten, in wie weit eine Architektur auch im Code umgesetzt wurde. Wie kann man Architekturen im Code überprüfen (und dies operationalisieren und im Prozess integrieren, beispielsweise als Teil des Check-In-Vorgangs, im Build etc.) Metriken und andere Messinstrumente, um Architektur beurteilen zu können Was sollen die Teilnehmer verstehen? Taktiken, Praktiken sowie technische Möglichkeiten zur Erreichung weiterer Qualitätsziele von Software-Systemen erklären und anwenden: Sicherheit Verständlichkeit, Nachvollziehbarkeit Robustheit, Fehlertoleranz Skalierbarkeit Prototypen oder technische Durchstiche zur Überprüfung von Architekturqualität einsetzen Metriken zur Bewertung von Artefakten erklären Zur Einschätzung und Bewertung von Architekturen können weitere Medien und Informationen zu Rate gezogen werden, etwa: Quellcode bekannte Fehler in Quellcode, insbesondere Fehlercluster Seite 15 von 23 Stand 1. Juli 2009

16 4.2.3 Was sollen die Teilnehmer kennen? Weitere Metriken, insbesondere Lines-of-Code, zyklomatische Komplexität, ein- und ausgehende Abhängigkeiten, Instabilität, Abstraktheit, Distanz 4.3 Referenzen [Bass+2003] [Clements+2002] [Martin 2003] [Starke 2008] Seite 16 von 23 Stand 1. Juli 2009

17 5 Werkzeuge für Software-Architekten Dauer: 45 Min Übungszeit: keine 5.1 Begriffe und Konzepte Folgende Kategorien von Werkzeugen sind wichtige Arbeitsmittel für Architekten: Modellierungswerkzeuge Unterstützung bei diesen Aufgaben des Architekten: Entwurf und Kommunikation von Software-Architekturen Vorgabe für detailliertes Design und Implementierung, gegebenenfalls auch Codegenerierung Kriterien: Unterstützung mehrerer Benutzer Validierung / formale Überprüfung von Modellen Unterstützung für Codegenerierung (siehe auch: Generierungswerkzeuge) Unterstützung für Reverse Engineering Unterstützung bei der Erzeugung von Dokumentation Unterstützung des Konfigurationsmanagements (Versionierung, Vergleich, Merge von Modellen) Werkzeuge zur statischen Analyse Unterstützung bei diesen Aufgaben des Architekten: Bewertung bestehender Software-Systeme bzgl. Qualitätseigenschaften, z.b. Komplexität - kann Grundlage für Refactoring sein Analysieren, ob die Umsetzung den Vorgaben in der Architektur entspricht (z.b. werden Regeln bezüglich zulässiger Abhängigkeiten befolgt) Kriterien: Automatisierbarkeit Aufbereitung und Visualisierung der Ergebnisse Unterstützte Analysekriterien und Metriken Werkzeuge zur dynamischen Analyse Unterstützung bei diesen Aufgaben des Architekten: Gezielte Untersuchung bestehender Software-Systeme bzgl. Performance- und Lasteigenschaften Generierungswerkzeuge Unterstützung bei diesen Aufgaben des Architekten: Vorgabe eines Rahmens für die Implementierung Übereinstimmung von Architekturmodell und Implementierung gewährleisten Kriterien: Konfigurierbarkeit der Code Generierung Lesbarkeit des generierten Codes Seite 17 von 23 Stand 1. Juli 2009

18 Ggf. Zertifizierung für sicherheitskritische Anwendungen Wiederholbarkeit des Generierungsschritts Schnittstelle zwischen generiertem und manuell implementiertem Code Anforderungsmangementwerkzeuge Unterstützung bei diesen Aufgaben des Architekten: Analyse der Anforderungen für das zu entwerfende Software-System Kriterien: Unterstützung der Traceability zwischen Anforderungen und Architektur Dokumentationswerkzeuge Unterstützung bei diesen Aufgaben des Architekten: Kommunikation der Architektur Kriterien: Automatisierte Generierung aktueller Dokumentation aus Architekturmodellen - hierbei ist auch wichtig, Detaillierungsgrad und Umfang zielgruppengerecht wählen zu können Unterstützung mehrerer Benutzer Unterstützung des Konfigurationsmanagement der Dokumentation (Versionierung, Nachvollziehbarkeit von Änderungen) Build-Systeme/-Werkzeuge Unterstützung bei diesen Aufgaben des Architekten Automatisierung des Kompilier-, Paketier- und Test-Vorgangs Überprüfung auf Einhaltung struktureller Vorgaben Ansteuerung eines kontinuierlichen Standbaus inkl. QS Kriterien: Performance Anpassbarkeit Homogenität Unterstützung proprietärer Werkzeugen Konfigurationsmanagement Unterstützung bei diesen Aufgaben des Architekten Zuordnung und Selektion von Konfigurationselementen zu einer Konfiguration Inventarisierung Rekonstruktion einer Konfiguration Kriterien: Performance Skalierbarkeit (Konfigurationen sowohl aufgrund der enormen Größe als auch aufgrund der Varianten) Methodische Integration mit anderen Werkzeugen (Versionsverwaltung, Issue-Tracker, Requirements-Management-Werkzeuge...) Seite 18 von 23 Stand 1. Juli 2009

19 5.2 Lernziele Was sollen die Teilnehmer können? Teilnehmer sollen die wichtigsten Kategorien von Werkzeugen sowie deren Stärken und Schwächen für die Arbeit von Software-Architekten benennen und erläutern können Was sollen die Teilnehmer verstehen? Die Arbeitsumgebung und die Arbeitsmittel von Software-Architekten hängen von den jeweiligen Randbedingungen und Einflussfaktoren ab Was sollen die Teilnehmer kennen? Einige Vertreter typischer Werkzeuge aus eigener praktischer Erfahrung. Hierzu zählen: Modellierungswerkzeuge (UML-Werkzeuge) Generierungswerkzeuge (MDA- oder MDSD-Werkzeuge) Dokumentationswerkzeuge (Wikis, Repository-basierte sowie Datei-basierte Dokumentenverwaltung) Werkzeuge zum Build- und Konfigurationsmanagement 5.3 Referenzen Keine. Seite 19 von 23 Stand 1. Juli 2009

20 6 Beispiele für Software-Architekturen Dauer: 60 Min Übungszeit: keine Dieser Abschnitt ist nicht prüfungsrelevant. 6.1 Begriffe und Konzepte Innerhalb jeder akkreditierten Schulung müssen mindestens ein, besser zwei Beispiele von Software- Architekturen vorgestellt und besprochen 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. 6.2 Lernziele Vorstellung und Besprechung mindestens einer, besser zwei Beispielarchitekturen Was sollen die Teilnehmer können? n.z Was sollen die Teilnehmer verstehen? n.z Was sollen die Teilnehmer kennen? Einige Beispiele (möglichst) realitätsnaher Architekturen. 6.3 Referenzen Keine. Schulungsanbieter sind für die Auswahl und Beschreibung von Beispielen verantwortlich. Seite 20 von 23 Stand 1. Juli 2009

21 7 Quellen und Referenzen zu Software-Architektur 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 [Bosch 2000] Bosch, J.: Design & Use of Software Architectures. Addison-Wesley, 2000 [Buschmann+96] Buschmann, F., R. Meunier, H. Rohnert,, P. Sommerlad,, M. Stal: A System of Patterns. Pattern Oriented Software. Architecture. Wiley [Buschmann+2007] Frank Buschmann, Kevlin Henney, Doug Schmidt: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing (v. 4). Wiley, `= [Clements+2002] Clements, P., R. Kazman, M. Klein: Evaluating Software Architectures Methods and Case Studies. Addison Wesley, [Clements+2003] Clements, P., F. Bachmann, L. Bass, D. Garlan, J. Ivers et al: Documenting Software Architectures Views and Beyond. Addison Wesley, a= [Demeyer+2002] Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz. Object Oriented Reengineering Patterns. Morgan Kaufman, [Dern 2006] Dern, Gernot: Management von IT-Architekturen. Informationssysteme im Fokus von Architekturplanung und -entwicklung. Vieweg, Edition CIO, 2. Auflage, b= [Evans 2004] Evans, E.: Domain Driven Design. Addison-Wesley, Zugehöri-ge Website: Seite 21 von 23 Stand 1. Juli 2009

22 c= [Fowler 2003] Fowler, M. (2003): Patterns of enterprise application architecture. Addison-Wesley. d= [Gamma 1995] Gamma, E., R. Helm, R. Johnson, J. Vlissides: Design Patterns. Addison-Wesley, [Gordon 2006] Gordon, I.: Essential Software Architecture. Springer e= [Hargis+2004] Hargis, Gretchen et. al Developing Quality Technical Information. A Handbook for Writers and Editors. Prentice Hall, [Hatley2000] Hatley, D., P. Hruschka, I. Phirbai: Process for System Architecture and Requirements Engineering. Dorset House, [Hofmeister+2000] Hofmeister, C., Nord, R. und Soni, D. (2000): Applied Software Architecture. Addison-Wesley. [Hofmeister+2005] Hofmeister, Christine, R. Nord, D. Soni. Global Analysis: Moving from Software equirements Specification to Structural Views of the Software Architecture, IEE Proceedings Software, Vol. 152, Issue 4, pp , August [Hohpe+2003] Hohpe, G., B. Woolf: Enterprise Integration Patterns: Design ing, Build-ing, and Deploying Messaging Solutions. Addison Wesley, h= [Keller 2006] Keller, Wolfgang: IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen IT- Unterstützung. dpunkt, [Kruchten 1995] Kruchten, P.: Architectural Blueprints The 4-1 View Model of Architecture. IEEE Software November 1995; 12(6), p j= [Martin 2003] Martin, R. C. (2003): Agile Software Development, Principles, Patterns, and Practices. Pearson Education, Upper Saddle River. l= [Open Group 09] Seite 22 von 23 Stand 1. Juli 2009

23 The Open Group: TOGAF, Version 9. Online: m= [Parnas 1972] Parnas, D. L.: On the Criteria to be Used in Decomposig Systems into Modules. Communications of the ACM 1972; 15: p [POSA-1] siehe [Buschmann+96] [POSA-4] siehe [Buschmann+2007] [Posch 2004] Posch, T., K. Birken, M. Gerdom: Basiswissen Softwarearchitektur: Verstehen, entwerfen, bewerten und dokumentieren. Dpunkt, [Putman 2000] Putman, J.: Architecting with RM-ODP. Prentice Hall, 2000 R= [Rechtin+2000] Rechtin. E., M. Maier: The Art of Systems Architecture. CRC Press, 2000 [Reussner+2006] Reussner, R. und Hasselbring, W. (eds.) (2006): Handbuch der Software-Architektur. dpunkt.verlag, Heidelberg. p= [Schmidt2000] Schmidt, D., M. Stal, H. Rohnert, F. Buschmann: Pattern-Oriented Software-Architecture Patterns for Concurrent and Networked Objects. Vol. 2. Wiley, [Shaw 1996] Shaw, M., D. Garlan: Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice Hall, [Siedersleben 2004] Siedersleben, J. (2004): Moderne Softwarearchitektur: Umsichtig planen, robust bauen mit Quasar. dpunkt.verlag, Heidelberg [Starke 2008] Starke, G. (2008): Effektive Software-Architekturen - Ein praktischer Leitfaden. 3. aktualisierte und erweiterte Auflage 2008, Carl Hanser Verlag, München. [Starke+2009] Starke, Gernot und Peter Hruschka: Software-Architektur kompakt. Spektrum Akademischer Verlag, s= [Vogel+2005] Vogel, O., u.a.: Software-Architektur: Grundlagen Konzepte Praxis. Spektrum, 2005 Seite 23 von 23 Stand 1. Juli 2009

Ein standardisiertes Aus- und Weiterbildungsschema für Software-Architekten: der isaqb CPSA-F Lehrplan

Ein standardisiertes Aus- und Weiterbildungsschema für Software-Architekten: der isaqb CPSA-F Lehrplan Ein standardisiertes Aus- und Weiterbildungsschema für Software-Architekten: der isaqb CPSA-F Lehrplan ITech Progress GmbH 2012 Wer bin ich? Mahbouba Gharbi Geschäftsführerin der ITech Progress GmbH Trainerin,

Mehr

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter

Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0. Weitere Informationen oder Bestellungen unter Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im Buchhandel.

Mehr

Certified Professional for Software Architecture (CPSA) Advanced Level

Certified Professional for Software Architecture (CPSA) Advanced Level Curriculum für Certified Professional for Software Architecture (CPSA) Advanced Level Modul: Architekturdokumentation Inhaltsverzeichnis Seite 2 von 15 Stand 27. September 2012 Seite 3 von 15 Stand 27.

Mehr

Curriculum für. CPSA Certified Professional for Software Architecture. Advanced Level. Modul: Architekturdokumentation

Curriculum für. CPSA Certified Professional for Software Architecture. Advanced Level. Modul: Architekturdokumentation Curriculum für CPSA Certified Professional for Software Architecture Advanced Level Modul: Architekturdokumentation Version 1.5 (Februar 2015) (Copyright), International Software Architecture Qualification

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

Mehr

Curriculum für. Certified Professional for Software Architecture (CPSA) Foundation Level. isaqb. Version 2.93 ( 4. Februar 2014)

Curriculum für. Certified Professional for Software Architecture (CPSA) Foundation Level. isaqb. Version 2.93 ( 4. Februar 2014) Curriculum für Certified Professional for Software Architecture (CPSA) Foundation Level Version 2.93 ( 4. Februar 2014) Curriculum für Foundation Level (Copyright), International Software Architecture

Mehr

vii Inhaltsverzeichnis 1 Einleitung 1

vii Inhaltsverzeichnis 1 Einleitung 1 vii 1 Einleitung 1 1.1 Softwarearchitektur als Disziplin im Software Engineering........ 2 1.2 isaqb International Software Architecture Qualification Board.......... 4 1.3 Certified Professional for Software

Mehr

Softwarearchitekten. Basiswissen für. dpunkt.verlag. Foundation Level

Softwarearchitekten. Basiswissen für. dpunkt.verlag. Foundation Level Mahbouba Gharbi Arne Koschel Andreas Rausch Gernot Starke Basiswissen für Softwarearchitekten Aus- und Weiterbildung nach isaqb-standard zum Certified Professional for Software Architecture - Foundation

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

Mehr

Umsichtig planen, robust bauen

Umsichtig planen, robust bauen Umsichtig planen, robust bauen iks Thementag Mehr Softwarequalität Best practices für alle Entwicklungsphasen 19.06.2012 Autor: Christoph Schmidt-Casdorff Agenda Softwarearchitektur Architekturkonformität

Mehr

Certified Professional for Software Architecture (CPSA) Foundation Level

Certified Professional for Software Architecture (CPSA) Foundation Level Curriculum für Certified Professional for Software Architecture (CPSA) Foundation Level Version 3. 01 ( 05. Mai 2015) (Copyright), International Software Architecture Qualification Board e. V. (isaqb e.

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Kapitel 1 Applikations-Architektur VI

Kapitel 1 Applikations-Architektur VI Kapitel 1 Applikations-Architektur VI Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile

Mehr

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.1 Darstellung der Architektur Darstellung der Architektur Was macht ein Architekt? Viele Pläne! Endkunde Elektro Bauarbeiter Sanitär Softwaretechnik

Mehr

Übungsklausur vom 7. Dez. 2007

Übungsklausur vom 7. Dez. 2007 Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

Der Rational Unified Process

Der Rational Unified Process Philippe Kruchten Der Rational Unified Process Eine Einführung Deutsche Übersetzung von Cornelia Versteegen An imprint of Pearson Education München Reading, Massachusetts Menlo Park, California New York

Mehr

Effektive Software- Architekturen

Effektive Software- Architekturen Gemot Starke Effektive Software- Architekturen Ein praktischer Leitfaden 4., aktualisierte und erweiterte Auflage HANSER Inhalt Vorwort Vorwort zur vierten Auflage XIII XIV 1 Einleitung 1 1.1 Software-Architekten

Mehr

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 9 Dr. H. Ehler, S. Wagner 11. Januar 2007 Übungen zu Softwaretechnik Aufgabe 15 Systemerstellung / Systemarchitektur nach dem V- Modell XT Machen Sie sich mit den

Mehr

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Softwaretechnik I Wintersemester 2015 / 2016 www.ias.uni-stuttgart.de/st1 st1@ias.uni-stuttgart.de

Mehr

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

Mehr

Klausur Softwaretechnik 3 22. Feb. 2008

Klausur Softwaretechnik 3 22. Feb. 2008 Klausur Softwaretechnik 3 22. Feb. 2008 Hinweise Bevor Sie mit der Bearbeitung der Aufgaben beginnen, müssen Sie auf allen Blättern Ihren Namen und Ihre Matrikelnummer eintragen. Prüfen Sie Ihre Klausur

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

Validierung und Verifikation

Validierung und Verifikation Martin Glinz Harald Gall Software Engineering Kapitel 7 Validierung und Verifikation Universität Zürich Institut für Informatik 2005, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter Prof. Dr. Dr. h.c. Manfred Broy Sommersemester Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter Einführung in die Softwaretechnik Übung 6: Feinentwurf Aufgabe 17: Entwurfsmuster

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

SERVICE SUCHE ZUR UNTERSTÜTZUNG

SERVICE SUCHE ZUR UNTERSTÜTZUNG SERVICE SUCHE ZUR UNTERSTÜTZUNG VON ANFORDERUNGSERMITTLUNG IM ERP BEREICH MARKUS NÖBAUER NORBERT SEYFF ERP SYSTEME Begriffsbestimmung: Enterprise Resource Planning / Business Management Solution Integrierte

Mehr

Architekturplanung und IS-Portfolio-

Architekturplanung und IS-Portfolio- Architekturplanung und IS-Portfolio- management Gliederung 1.Einführung 2.Architekturplanung 3.IS-Portfoliomanagement 4.AP und IS-PM 5.Fazit 2 1. Einführung Problem: Verschiedene Software im Unternehmen

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Requirements Engineering für IT Systeme

Requirements Engineering für IT Systeme Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig

Mehr

Requirements Engineering Research Group!

Requirements Engineering Research Group! Martin Glinz Harald Gall Software Engineering Herbstsemester 2011 Einleitung zur Vorlesung! Requirements Engineering Research Group! 2006, 2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe

Mehr

Software Qualität: Übung 3

Software Qualität: Übung 3 1. Informationen Formales Software Qualität: Übung 3 ISO/IEC 9126 Quality Function Deployment Zielbäume CMMI Abgabetermin: Freitag 8. Juni 2007, 18.00 CET (Central European Time) Abgaben per e-mail an

Mehr

Neue Funktionen in Innovator 11 R5

Neue Funktionen in Innovator 11 R5 Neue Funktionen in Innovator 11 R5 Innovator for Enterprise Architects, Java Harvester und Prüfassistent 12.11.2013 Agenda 1 2 3 Einführung Was ist neu in Innovator 11 R5? Szenario Enterprise Architektur

Mehr

Software Engineering. Produktivitätsfaktoren! Kapitel 18

Software Engineering. Produktivitätsfaktoren! Kapitel 18 Martin Glinz Thomas Fritz Software Engineering Kapitel 18 Produktivitätsfaktoren 2007-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen Gebrauch

Mehr

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation

Mehr

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System

Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Anne Thomas TU Dresden Dr. B. Demuth Pre Press GmbH (Dresden) T. Reuter Gliederung Einleitung Vorgehensweise Kontext

Mehr

Erfolgreiche Realisierung von grossen Softwareprojekten

Erfolgreiche Realisierung von grossen Softwareprojekten Software Engineering Erfolgreiche Realisierung von grossen Softwareprojekten Requirements Management Fachhochschule Lübeck, 7. Dezember 2001 Thomas Dahlmanns dahlmanns@pixelpark.com (040) 43203 26 >> 1

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Langlebige Softwarearchitekturen

Langlebige Softwarearchitekturen Langlebige Softwarearchitekturen Dr. Carola Lilienthal Carola.Lilienthal@wps.de www.wps.de //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG Die zwei Architekturziele für diesen Vortrag Architekturziel 1:

Mehr

Vorstellung. Wie entsteht Architektur in Scrum

Vorstellung. Wie entsteht Architektur in Scrum Vorstellung Thema Architektur - Begriffsdefinition Eine Architektur (vοn griechisch αρχή = Anfang, Ursprung und lateinisch tectum = Haus, Dach) beschreibt in der Informatik im Allgemeinen das Zusammenspiel

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

Softwareentwicklungsprozess im Praktikum. 23. April 2015

Softwareentwicklungsprozess im Praktikum. 23. April 2015 Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit

Mehr

Praktikant / Abschlussarbeit im Bereich Softwareentwicklung / Mechatronik (m/w)

Praktikant / Abschlussarbeit im Bereich Softwareentwicklung / Mechatronik (m/w) Praktikant / Abschlussarbeit im Bereich Softwareentwicklung / Mechatronik (m/w) Automatisiertes Erstellen von Berichten in EasyConfig V4 EasyConfig ist eine bei der entwickelte Software zur Auslegung und

Mehr

Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte!

Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte! Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte! Aufgabe 1: Grundlagen (5 Punkte) a) Definieren Sie kurz Usability und User Experience.

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress BPM im Kontext von Unternehmensarchitekturen Konstantin Gress Agenda 1 Worum geht s BPM, EA und SOA im Überblick 2 Link zwischen EA und BPM 3 Link zwischen SOA und BPM 4 Wie spielt das zusammen? 5 Q&A

Mehr

Effektive Software-Architekturen Ein praktischer Leitfaden

Effektive Software-Architekturen Ein praktischer Leitfaden Gernot Starke Effektive Software-Architekturen Ein praktischer Leitfaden ISBN-10: 3-446-41215-8 ISBN-13: 978-3-446-41215-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41215-6

Mehr

Konsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt

Konsolidierung und Neuimplementierung von VIT. Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Konsolidierung und Neuimplementierung von VIT Aufgabenbeschreibung für das Software Engineering Praktikum an der TU Darmstadt Inhaltsverzeichnis 1 Was ist der Kontext?... 1 2 VIT: Ein sehr erfolgreiches

Mehr

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Maintenance & Re-Zertifizierung

Maintenance & Re-Zertifizierung Zertifizierung nach Technischen Richtlinien Maintenance & Re-Zertifizierung Version 1.2 vom 15.06.2009 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0

Mehr

Dokumentation, Analyse, Optimierung,

Dokumentation, Analyse, Optimierung, Dokumentation, Analyse, Optimierung, Automatisierung als gemeinsame Sprache für Business, Architektur und Entwicklung DOAG SIG BPM, Folie 1 Vortragende Software Engineer Dr. Projektleiter Folie 2 Zühlke:

Mehr

A Domain Specific Language for Project Execution Models

A Domain Specific Language for Project Execution Models A Domain Specific Language for Project Execution Models Eugen Wachtel, Marco Kuhrmann, Georg Kalus Institut für Informatik Software & Systems Engineering Inhalt Einführung und Hintergrund Problembereiche

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING

FUTURE NETWORK 20.11.2013 REQUIREMENTS ENGINEERING 18/11/13 Requirements Engineering 21 November 2013 DIE GRUNDFRAGEN Wie erhält der Kunde den größten Nutzen? Wie kann der Kunde am besten spezifizieren, was er haben will? Welchen Detailierungsgrad braucht

Mehr

Systemanalyse I Software-Entwicklung. Die Phase Design.? Prof. Dr. Susann Kowalski

Systemanalyse I Software-Entwicklung. Die Phase Design.? Prof. Dr. Susann Kowalski Die Phase Design Design Entwerfen der Benutzeroberfläche, des Bedienablaufs und der Softwarearchitektur Umsetzen des fachlichen Modells auf technische Möglichkeiten; Spezifikation der Systemkomponenten

Mehr

Curriculum für. CPSA Certified Professional for Software Architecture. - Foundation Level -

Curriculum für. CPSA Certified Professional for Software Architecture. - Foundation Level - Curriculum für CPSA Certified Professional for Software Architecture - Foundation Level - Version 4. 2 ( Juli 2017) (Copyright), International Software Architecture Qualification Board e. V. (isaqb e.

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

Mehr

Certified Professional for Software Architecture

Certified Professional for Software Architecture Curriculum: Certified Professional for Software Architecture (CPSA) Foundation Level Version 4. 2 ( Juli 2017) (Copyright), International Software Architecture Qualification Board e. V. (isaqb e. V.) 2009

Mehr

Certified Professional for Software Architecture

Certified Professional for Software Architecture Curriculum: Certified Professional for Software Architecture (CPSA) Foundation Level Version 4. 1.1 ( Januar 2017) (Copyright), International Software Architecture Qualification Board e. V. (isaqb e. V.)

Mehr

IGT-Richtlinie 01: Anforderungen an Smarthome-Systeme

IGT-Richtlinie 01: Anforderungen an Smarthome-Systeme Bewertungskriterien inklusive Vorlagen zur Unterscheidung der Funktionalität von Smarthome- Systemen aus Nutzersicht bzw. aus technischer Sicht. Version 03, August 2015 Prof. Dr. Michael Krödel IGT - Institut

Mehr

Hauptseminar Entwicklung von Informationssystemen

Hauptseminar Entwicklung von Informationssystemen Hauptseminar Entwicklung von Informationssystemen Wintersemester 2012/2013 Vorläufige Übersicht Vorläufiger Ablauf Woche Termin Uhrzeit Inhalt Raum * September 2012 * Themenvorstellung Seminarraum EG 42

Mehr

Übung: Verwendung von Java-Threads

Übung: Verwendung von Java-Threads Übung: Verwendung von Java-Threads Ziel der Übung: Diese Übung dient dazu, den Umgang mit Threads in der Programmiersprache Java kennenzulernen. Ein einfaches Java-Programm, das Threads nutzt, soll zum

Mehr

Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.

Vermeiden Sie es sich bei einer deutlich erfahreneren Person dranzuhängen, Sie sind persönlich verantwortlich für Ihren Lernerfolg. 1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich

Mehr

Software Engineering. Dokumentation. Wintersemester 2005/06. Kapitel 21. Universität Zürich Institut für Informatik

Software Engineering. Dokumentation. Wintersemester 2005/06. Kapitel 21. Universität Zürich Institut für Informatik Martin Glinz Harald Gall Software Engineering Wintersemester 2005/06 Kapitel 21 Dokumentation Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe

Mehr

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005

Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005 Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005 Hinweise: Bearbeitungszeit: 90 Minuten Erlaubte Hilfsmittel: im Anhang, sonst keine Bitte notieren Sie Ihre Antworten ausschließlich auf dem Aufgabenblatt!

Mehr

----------------------------------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------------------------------- 0 Seite 0 von 20 03.02.2015 1 Ergebnisse der BSO Studie: Trends und Innovationen im Business Performance Management (BPM) bessere Steuerung des Geschäfts durch BPM. Bei dieser BSO Studie wurden 175 CEOs,

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

P030 The Open Group Architecture Framework (TO-GAF) als Unternehmensarchitektur Methode für die Bundesverwaltung

P030 The Open Group Architecture Framework (TO-GAF) als Unternehmensarchitektur Methode für die Bundesverwaltung Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB P030 The Open Group Architecture Framework (TO-GAF) als Unternehmensarchitektur Methode für die Bundesverwaltung Klassifizierung:

Mehr

E-MAIL-KONVERTIERUNG LEVIGO SOLUTIONS DAY 24.10.2013, 13:45 14:15 WAS PASSIERT MIT NICHT KONVERTIERBAREN ANHÄNGEN?

E-MAIL-KONVERTIERUNG LEVIGO SOLUTIONS DAY 24.10.2013, 13:45 14:15 WAS PASSIERT MIT NICHT KONVERTIERBAREN ANHÄNGEN? E-MAIL-KONVERTIERUNG WAS PASSIERT MIT NICHT KONVERTIERBAREN ANHÄNGEN? LEVIGO SOLUTIONS DAY 24.10.2013, 13:45 14:15 J. MÄSTLING LEVIGO SOLUTIONS GMBH J. CLARYSSE CENIT AG LEVIGO ANSATZ & LEITFAFDEN Präsentationsfolien

Mehr

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003 Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen

Mehr

Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010

Dr. Simon Giesecke Falko Basner Dr. Jörg Friebe. Bad Honnef, 3. Mai 2010 Architekturentscheidungen für große langlebige Softwaresysteme: Vendor-Lock-in- und Netz-Effekte Menschen beraten Menschen beraten BTC zeigt Wege auf - Sie entscheiden BTC zeigt Wege auf - Sie entscheiden

Mehr

16.4 Wiederverwendung von COTS-Produkten

16.4 Wiederverwendung von COTS-Produkten 16.4 Wiederverwendung von COTS-Produkten COTS = commercial of the shelf im Handel erhältliche Software-Produkte Anpassung für Kunden ohne Änderung am Quellcode Quellcode in der Regel nicht einsehbar (Ausnahme

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

Mehr

9.6 Korrekturmaßnahmen, Qualitätsverbesserung

9.6 Korrekturmaßnahmen, Qualitätsverbesserung Teil III Organisation und Infrastruktur Kapitel 9: Qualitätsmanagementsystem Inhalt 9.1 Grundlagen 9.2 Qualitätspolitik 9.3 Qualitätsorganisation 9.4 Maßnahmen 9.5 Qualitätsaufzeichnungen 9.6 Korrekturmaßnahmen,

Mehr

2.1 Ist-Anwendungslandschaften... 65 2.2 Programme zur Gestaltung von Anwendungslandschaften

2.1 Ist-Anwendungslandschaften... 65 2.2 Programme zur Gestaltung von Anwendungslandschaften xiii Teil I Ein typisches Projekt 1 1 Mit Christoph Kolumbus reisen 3 1.1 Prolog........................................... 3 1.2 Episode 1 Zuhören............................... 4 1.3 Episode 2 Orientierung

Mehr

ITIL & TOGAF die Doppelspitze für IT Governance

ITIL & TOGAF die Doppelspitze für IT Governance 1 ITIL Day 2014 ITIL & TOGAF die Doppelspitze für IT Governance Referenten: Arif Chughtai, Matthias Gessenay 2 Referenten Arif Chughtai mail@arifchughtai.org www.arifchughtai.org Matthias Gessenay matthias.gessenay@corporatesoftware.ch

Mehr

Fragebogen: Abschlussbefragung

Fragebogen: Abschlussbefragung Fragebogen: Abschlussbefragung Vielen Dank, dass Sie die Ameise - Schulung durchgeführt haben. Abschließend möchten wir Ihnen noch einige Fragen zu Ihrer subjektiven Einschätzung unseres Simulationssystems,

Mehr

Übungsbeispiele für die mündliche Prüfung

Übungsbeispiele für die mündliche Prüfung Übungsbeispiele für die mündliche Prüfung Nr. Frage: 71-02m Welche Verantwortung und Befugnis hat der Beauftragte der Leitung? 5.5.2 Leitungsmitglied; sicherstellen, dass die für das Qualitätsmanagementsystem

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Überprüfung der Bildungsstandards in den Naturwissenschaften. Chemie Marcus Mössner

Überprüfung der Bildungsstandards in den Naturwissenschaften. Chemie Marcus Mössner Überprüfung der Bildungsstandards in den Naturwissenschaften Bildungsstandards im Fach Chemie für den Mittleren Bildungsabschluss (Beschluss vom 16.12.2004) Die Chemie untersucht und beschreibt die stoffliche

Mehr

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

Mehr

crm-now/ps Webforms Webdesigner Handbuch Erste Ausgabe

crm-now/ps Webforms Webdesigner Handbuch Erste Ausgabe crm-now/ps Webforms Webdesigner Handbuch Erste Ausgabe crm-now/ps Webforms: Webdesigner Handbuch Copyright 2006 crm-now Versionsgeschichte Version 01 2006-08-21 Release Version crm-now c/o im-netz Neue

Mehr

Architektur und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

Mehr

INNOVATOR im Entwicklungsprozess

INNOVATOR im Entwicklungsprozess Erfahrungsbericht INNOVATOR im Entwicklungsprozess Basis für Host- und Java-Anwendungen Dr. Carl-Werner Oehlrich, Principal Consultant MID GmbH Das Modellierungswerkzeug INNOVATOR Geschäftsprozess-Modellierung

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Skills-Management Investieren in Kompetenz

Skills-Management Investieren in Kompetenz -Management Investieren in Kompetenz data assessment solutions Potenziale nutzen, Zukunftsfähigkeit sichern Seite 3 -Management erfolgreich einführen Seite 4 Fähigkeiten definieren und messen Seite 5 -Management

Mehr