Am 14.11.2016 wurde in der Veranstaltung Softwaretechnik 1 durch Mitarbeiterinnen des Hochschulreferats Qualitätsmanagement ein Teaching Analysis Poll (TAP) durchgeführt. Die Resultate habe ich in der letzten Woche mit den Studierenden diskutiert. Die Ergebnisse finden Sie hier:
Nachfolgend sind einige Hinweise aufgeführt, die Ihnen für die Veranstaltung Softwaretechnik 1 helfen können, die Praktikumsaufgaben zu bearbeiten. Ich werde diese Serie in unregelmäßigen Abständen fortführen, um Ihnen möglichst zu allen behandelten UML-Diagrammen Hilfestellungen in Form von Videos anbieten zu können.
Hinweise zum UML-Tool Modelio
Die folgenden Videos geben Ihnen nützliche Tips, wie Sie mit Modelio besser arbeiten können – allgemeine Tips, Hinweise auf etwas versteckte Features, etc.
1. Allgemeine kurze Einführung zur Benutzung von Modelio
2.1. Use Cases in Modelio
2.2.1 Allgemeine Hinweise für das fachliche Datenmodell mit Modelio
2.2.2 Assoziationen beim fachlichen Datenmodell in Modelio
2.3.1 Clustering mit Hilfe von Modelio => Video nicht mehr aktuell, rausgenommen
2.3.2 Hinweise zu Komponentendiagrammen in Modelio
5.2 Interfaces für Komponenten in Modelio
5.3 Sequenzdiagramme in Modelio
Allgemeine Hinweise zu UML
Die nachfolgenden UML-Videos wurden von den Kollegen Winter und Valbert-Polenske produziert, die sie uns freundlicherweise zur Verfügung gestellt haben. Die Videos bilden eine sehr gelungene Ergänzung zur Vorlesung und zu UML-Handbüchern.
Aus urheberrechtlichen Gründen sind die Links passwortgeschützt. Wenn Sie Teilnehmer der Veranstaltung Softwaretechnik sind, dann haben Sie das Passwort über eine ILIAS-Mail erhalten.
2.1. Use-Case-Diagramm (Winter, Valbert-Polenske)
2.2.1. Objektdiagramm (Winter, Valbert-Polenske)
2.2.2. Klassendiagramm Teil 1 (Winter, Valbert-Polenske)
2.2.3. Klassendiagramm Teil 2 (Winter, Valbert-Polenske)
4.1 Aktivitätsdiagramme (Winter, Valbert-Polenske)
Ab Oktober 2016 befindet sich mein Büro in dem Ferchau Neubau (Gebäude LC 6), Raum 1506 (erster Stock). Als Orientierungshilfe: Der Haupteingang des Gebäudes ist in einer Fußgängerzone (siehe roter Pfeil), und zwar direkt gegenüber (10 m Luftlinie) vom Eingang der Schwalbe-Arena, dem Spielort des VfL Gummersbach.
Eine detaillierte Anfahrtsbeschreibung zu meinem Büro und unseren Besprechungsräumen am Campus Gummersbach finden Sie hier.
Bearbeiter der Masterarbeit
Alex Maier
Abgabe
Februar 2017
Inhalt der Arbeit
In der Berufswirklichkeit wird der agile Entwicklungsprozess erst nach längerer praktischer Einarbeitung von einem Team beherrscht. Wenn die Hochschullehre auf diese Entwicklungsmethodik vorbereiten soll, so muss den Studierenden die Möglichkeit gegeben werden, sich nicht nur theoretisches Prozesswissen anzueignen, sondern die agilen Prozesse auch praktisch zu üben. Nur so kann sich der Studierende eine Grundlage für die spätere Praxis verschaffen.
Es muss also ein Lernraum geschaffen werden, der die Simulation eines agilen Softwareentwicklungsteams darstellt, und gleichzeitig den Rahmenbedingungen und Grenzen einer Hochschul-Lehrverstaltung Rechnung trägt. Hier ist insbesondere das enge Zeitbudget (normalerweise höchstens ein Tag pro Woche pro Lehrveranstaltung) sowie das potentiell geringere Maß an Verbindlichkeit in studentischen Veranstaltungsteam zu nennen. Studierende belegen in einem Semester parallel mehrere Projekte und Veranstaltungen, und können somit nicht voll in einem Projekt nach vorgegeben Vorgehen arbeiten. Dies führt dazu, dass im Lehrkontext zum Beispiel ein 3-Wochen-Sprint nach SCRUM de facto nur drei Arbeitstage umfasst. Die kleine Teamgröße führt zwangsläufig zur Übernahme mehreren Rollen. Alle diese Faktoren stellen ein Hindernis dar beim Lernen und Leben der agilen Prozesse.
Neben dem agilen Vorgehen hat eine Lehrveranstaltung immer auch einen softwaretechnischen Schwerpunkt. Werden beispielsweise bestimmte Architekturmuster und/oder Frameworks vorgeschrieben, müssen sich die Studierenden auch in diese Themen einarbeiten. Eine weitere Herausforderung ist es daher, beide Lernziele (Softwaretechnik und agile Prozessbeherrschung) gegeneinander abzuwägen und auszubalancieren.
Zielsetzung der Arbeit
Ein geeignetes Format für die Simulation einer agilen Entwicklungssituation ist das „Guided Project“ im Studiengang Informatik Master der TH Köln. In einem Guided Project sollen die Studierenden in Teams eine fachliche Aufgabenstellung im Rahmen eines Projekts bearbeiten. Der Dozent leitet die Studierenden intensiv an, damit diese die gesetzten Lernziele erreichen können. Eins der Ziele ist es, das Gelernte durch praktische Erfahrungen zu festigen. Weitere wichtige Ziele sind die Förderung von Problemlösungskompetenz, Selbstmanagementfähigkeit sowie der Fähigkeit zum selbstständigen wissenschaftlichen Arbeiten.
Am Beispiel dieser konkreten Veranstaltung soll ein ganzheitliches Lehrkonzept „Agilität“ entwickelt werden, das die beschriebenen Herausforderungen adressiert. Dabei sind verschiedene Aspekte zu berücksichtigen:
- Welche Kompetenzen sind für das agile Vorgehen relevant?
- Wie kann ein „maßgeschneiderter“ agiler Prozess aussehen, um das agile Vorgehen den Studierenden im Rahmen der Veranstaltung näher zu bringen?
- Welche Werkzeuge/Tools sind essentiell um das agile Vorgehen praxisnahe zu erleben? Wie können diese in einem Hochschulkontext effizient betrieben werden, mit möglichst hohem Freiheitsgrad für die Studierenden?
- Wie kann agile Prozessbeherrschung bewertet werden (Benotung), beispielsweise durch pragmatische KPIs zur Messung von agiler Prozesstreue und Softwarequalität?
Download
Bearbeiter der Masterarbeit
Kamil Szuster
Abgabe
Anfang 2017
Inhalt der Arbeit
Aufgrund der steigenden Popularität von Microservice- (MS) Architekturen und den damit einhergehenden Vor- und Nachteilen gegenüber einer monolithischen Softwarearchitektur stellt sich Unternehmen, Architekten und Entwickler die Frage, ob sie diesem Trend in bestehenden und neuen Projekten folgen sollten.
In der Masterarbeit mit dem Titel „Eine Heuristik zur Eignungsprüfung von Microservice-Architekturen“ wird ein Vorgehen erarbeitet, mit dem die Entscheidung einer Neuentwicklung auf Basis von MS oder der Transition von einem Deployment-Monolithen hin zu einer MS Architektur evaluiert werden kann.
Die Heuristik ist an die Architecture Tradeoff Analysis Method (ATAM), einer bewährten Evaluierungsmethode von Softwarearchitekturen, angelehnt. Sie greift die Idee der szenarienbasierten Evaluation sowie den Utility Tree auf, um Entscheidern zu helfen, sich die richtigen Fragen mit Bezug zum Projektkontext zu stellen.
Unter Berücksichtigung der wichtigsten Qualitätsmerkmale des Projektes (Bewertung von voraussichtlichen Kosten und Nutzen sowie einer Einschätzung der Auswirkung von Nachteilen) soll eine fundierte Entscheidung bezüglich MS im Projektkontext getroffen werden können. Reichen die Informationen für eine solche Entscheidung nicht aus, kann die Heuristik zumindest als Wegweiser dienen, um bestimmte Fragestellungen näher zu untersuchen.
Die Basis dieser Heuristik stellt die aktuelle Literatur sowie das Wissen und die in Projekten gewonnenen Erfahrung von Experten dar.
Download
Bearbeiter der Masterarbeit
Markus Engelke
Abgabe
Die Arbeit wurde im Januar 2017 abgegeben. Sie wurde in Zusammenarbeit mit einem Versicherungskonzern als Projektpartner erstellt und ist mit einem Sperrvermerk versehen, da konkrete KPI-Ansätze des Konzerns als Untersuchungsgegenstand dienten.
Inhalt der Arbeit
Die Nutzung von Kennzahlensystemen in (finanz-)wirtschaftlichen Geschäftsbereichen gehört dank guter Quantifizierbarkeit von monetären Größen und der großen Anzahl wissenschaftlicher Beiträge in Form von Modellen und Kennzahlenkatalogen zur gängigen Praxis. Obwohl einige Beiträge im Bereich des Enterprise Architecture Management bereits wesentliche Aspekte, wie KPI-Kataloge oder EAM-KPI-Systeme adressieren, muss die Anzahl dieser Beiträge bislang als wenig zufriedenstellend bezeichnet werden. Dabei sieht sich insbesondere der EAM-Kontext mit sich dynamisch verändernden Anforderungen und deren hohe Komplexität konfrontiert, und erfordert daher umso mehr quantifizierbare Messgrößen für eine sinnvolle Überwachung oder gar Steuerung. Es kann daher davon ausgegangen werden, dass ein funktionsgerechtes KPI-System einen Mehrwert für den Bereich EAM bieten kann.
Beobachtungen zufolge beschränkt sich der Einsatz von KPI Systemen zu häufig auf IT-bezogene Qualitätslegitimierung, und steht weniger im Dienst der Business-Anforderungen selbst. Diese Arbeit vertritt hingegen die These, dass sich nachhaltige Lösungen durch die Unterstützung geschäftsstrategiebezogene Steuerung auszeichnen. Dies kann z.B. dadurch ermöglicht werden, indem Handlungsnotwendigkeiten und deren Ursachen dort aufgezeigt werden, wo strategiebezogene Geschäftsanforderungen nur unzureichend erfüllt sind. Doch auch auf die Strategie des Unternehmens ausgerichtete Kennzahlen können in ihrer Praxis scheitern. So können veraltete Datenbestände oder die Vernachlässigung von nötigen Anpassungen aufgrund von verändernder Anforderung weitere „Stolpersteine“ für eine nachhaltige Nutzung von KPI Systemen sein.
Abgeleitete Forschungsfrage
Wie können KPIs im EAM Umfeld nachhaltig erhoben und nutzbar gemacht werden?
- Was zeichnet nachhaltige KPIs im EAM-Umfeld aus?
- Ist es möglich und/oder sinnvoll, KPI-Systeme so zu modellieren, dass sie sowohl der strategiebezogenen als auch der operativen Steuerung dienen?
- Wie kann eine nachhaltige Datenerhebung und die festgelegte Nutzung sichergestellt werden?
Die Untersuchung des Collaborative Enterprise Architecture Ansatzes im Rahmen einer Einzelfallstudie im Umfeld eines komplexen IT Projektes
Bearbeiter der Masterarbeit
Christian Schwaiger, Donau-Universität Krems
Abgabe
Die Arbeit wurde im September 2016 abgeschlossen. Sie trägt einen Sperrvermerk.
Inhalt der Arbeit
Ist ein Einsatz von Enterprise Architecture (EA) Bottom-up und Quick-Win orientiert, unter Einsatz eines möglichst SMARTen Ansatzes, möglich? Im Kontext einer IT Abteilung kann Bottom-up bedeuten, dass ein komplexes IT Projekt als Initiator und Treiber von EA fungiert. Der Quick-Win könnte hierbei durch schnell verwertbare aber auch wiederverwendbare Ergebnisse (Artefakte) erzielt werden die beispielsweise den Zusammenhang zwischen Geschäftsprozessen und IT Systemen im Umfeld des IT Projektes visualisieren. Konkretisiert man die eingangs gestellte Frage, für dieses Beispiel mit der Grundidee von EA, müsste sie lauten: Kann der Einsatz von Enterprise Architecture auf Ebene eines IT Projektes starten um schnell wiederverwertbare Artefakte zu generieren die einerseits einen Quick-Win generieren und andererseits eine kurz oder mittelfristige Skalierung ermöglichen? Dies stellt den Ausgangspunkt für die weitere Recherche dar.
Im Umfeld der Enterprise Architecture landet man auf der Suche nach Lösungsansätzen sehr schnell bei der TOGAF Architecture Development Method (ADM), die einen umfassenden, holistischen aber auch evolutionären Ansatz zur Entwicklung einer Enterprise Architecture bietet. Sucht man nach SMARTen Ansätzen landet man rasch bei agilen Methoden der Softwareentwicklung und des Projektmanagements. Agile Methoden wie Scrum, KANBAN, eXtreme Programming und viele weitere versprechen den Kundennutzen in den Fokus zu stellen, Entwicklungszeiten zu verkürzen, schnellere Marktreife von Produkten zu ermöglichen und vieles mehr.
Aus langjähriger und persönlicher Projekterfahrung kann bestätigt werden, dass der Einsatz agiler Methoden sehr schnell zu verwertbaren Ergebnissen führen kann. An dieser Stelle sei aber auch angemerkt das agile Methoden kein Allheilmittel darstellen. Speziell in sehr komplexen Situationen ermöglichen sie aber, sich auf das Wesentliche zu konzentrieren und auf neue oder sich ändernde Anforderungen flexibler reagieren zu können. Eine Kombination aus dem ganzheitlichen TOGAF ADM und agilen Methoden könnte eine mögliche Antwort auf die einleitend adressierten Fragen bieten.
Collaborative Enterprise Architecture stellt so eine Kombination dar in dem sie, unter anderem, die TOGAF ADM mit der agilen Methodik KANBAN kombiniert. Im Rahmen einer Einzelfallstudie soll anhand eines konkreten IT Projektes die Anwendbarkeit dieses Ansatzes untersucht und überprüft werden. Ziel ist es alle Phasen des Collaborative-Enterprise-Architecture-Modells zu durchlaufen und wiederverwendbare Artefakte zu generieren.
Der Verlauf des gesamten Prozesses wird im Rahmen einer teilnehmenden und direkten Bobachtung begleitet. Die Erkenntnisse aus der Beobachtung und der Verlauf werden in einem Forschungstagebuch dokumentiert. Alle im Verlauf des Prozesses erstellten Artefakte und das Forschungstagebuch werden in einer Forschungsdatenbank, zur späteren Auswertung, strukturiert erfasst. Im Rahmen der Auswertung werden die Ergebnisse analysiert, mit der Theorie reflektiert und zusammengefasst dargestellt. Ein Ausblick hinsichtlich weiterer Einsatzmöglichkeiten im Unternehmen und möglicher weiterer Forschungsoptionen bilden den Abschluss der Master Thesis.
In Zusammenarbeit mit dem Projektpartner Codecentric wird in dieser Masterarbeit eine empirische Anforderungsanalyse zu den agilen Rollen Scrum Master und Product Owner durchführt. Erstbetreuer der Arbeit ist Prof. Dr. Siegfried Stumpf, wir betreuen die Arbeit gemeinschaftlich.
Dies erfolgt durch Befragung von Experten (erfahrene Scrum-Mitglieder)
- welche Kompetenzen (Fähigkeiten, Einstellungen usw.) müssen erfolgreiche Scrum Master und Product Owner mitbringen?
- Einsatz verschiedene empirischer Methoden eingesetzt werden, vom geführten Interview bis hin zur Onlineumfrage
Co-Betreuung durch Prof. Stumpf (Organisationspsychologie) und Prof. Bente (agile Methoden). Ein Expertennetzwerk existiert über Prof. Bente, eigene (Firmen-)Kontakte können eingebracht werden.
Hier findet sich die vollständige Beschreibung der Arbeit.
Bearbeiter
Frederik Delißen
Abschluss der Arbeit
vorauss. Herbst 2018
Projektpartner
Codecentric
Die mündlichen Prüfungen für ST2 (dieses Semester) und ST1 (zur Veranstaltung bei mir im WS15/16) finden an folgenden Terminen statt:
- Mi 21.9.
- Di 27.9.
- Mi 28.9.
Uhrzeit: Die genaue Terminvergabe wird über unser Doodle (http://doodle.com/poll/456yrztzvig6rdzh) geregelt. Bei Rückfragen wenden Sie sich bitte an Fabian Krampe (fabian.krampe@th-koeln.de).
Ort: Die Prüfungen finden im Gebäude LC6 (Ferchau-Neubau) statt, in Raum 1513. Das Gebäude ist noch so neu, dass noch nicht alles reibungslos klappt – z.B. können Sie im Moment das Gebäude nur über den Seiteneingang auf dem Parkplatz gegenüber Bistro Halle32 Süd betreten.
Noch ein Hinweis an diejenigen, die bei Prof. Jochum Prüfung machen möchten: Bitte kontaktieren Sie Herrn Jochum direkt, wir organisieren die Termine nur für die Prüfungen bei mir (Bente).
Problembeschreibung
Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabhängigen vertikalen Modulen aufzubauen. Diese können (weitgehend) unabhängig voneinander deployed und betrieben werden und benötigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt über leichtgewichtige Protokolle wie etwa REST.
Dieser Architekturstil erlaubt es, Anwendungen nach Geschäftsfähigkeiten zu segmentieren, die jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können. Das ist insbesondere bei Webportalen mit seinen schnellen Update-Zyklen ein deutlicher Vorteil. Beispielsweise kann so der Produktkatalog eines Webshops und die Zahlungsabwicklung durch unabhängige Microservices realisiert sein, so dass eine explorative Weiterentwicklung des Produktkatalogs den operativen Zahlungsverkehr nur minimal gefährden kann.
Projektbeschreibung
Ziel des Projekts ist es, für eine Beispielanwendung (Buchauskunft mit Bewertungsmöglichkeit und Suche) eine Microservice-Architektur zu konzipieren und umzusetzen bzw. weiterzuentwickeln. Dabei sollen die Stärken, Schwächen, Risiken und Grenzen dieses Ansatzes im Projektreport evaluiert werden.
Die genaue Aufgabenstellung ist hier dokumentiert.
Die Entwicklung erfolgt mittels jeweils geeigneter Technologie-Stacks (gemäß des Microservice-Ansatzes hat das verantwortliche Team weitgehende Freiheiten in der Technologiewahl). Diese Technologien werden wir gemeinsam in einem Kickoff-Workshop festlegen.
- Kandidat 1 für serverseitige Technologie ist das von dem Projektpartner Capgemini vorangetriebene Open-Source-Projekt Open Application Standard Platform (OASP, https://oasp.github.io/). OASP hat es sich zur Aufgabe gemacht, bewährte Open-Source-Frameworks zu einem „Best-of-Breed“-Anwendungspaket zu bündeln. Mit Hilfe von OASP können Softwareprojekte für kostensensitive Kunden (z.B. öffentliche Auftraggeber) ohne Zeitverlust durch die sonst übliche „Technologie-Findungsphase“ realisiert werden. Außerdem vermeidet man technologischen Wildwuchs, da OASP eine in sich konsistente Basisarchitektur darstellt. Zufallsarchitektur (Accidental Architecture) wird so zumindest bei der Technologieplattform vermieden.
- Kandidat 2 für serverseitige Technologie ist Java EE 7. Ein gewünschtes Ergebnis des Projekts ist in diesem Fall ein Vergleich dieser Technologien in Form eines „Wettstreit“ zwischen den Teams bei der Umsetzung von Mikroservices mit OASP respektive Java EE. Java EE ist bei Individualentwicklungen weiterhin verbreitet und durch die Vereinfachungen aus Java EE 6 / 7 effizient einsetzbar.
Clientseitig werden wir in diesem Projekt das Google-Framework AngularJS verwenden.
Projektmethodik
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf und seinem Team methodisch begleitet. Die agilen Teams wählen jeweils einen Scrum Master und einen Product Owner. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Ein Vertreter von Capgemini wird bei den Entwicklungs-Demos am jeden Sprints als Kunde zugegen sein.
Nach jetziger Planung wird es eine Unterstützung von Seiten Capgeminis in Form eines 1-tägigen „Scrum Kickstart“-Seminars geben, mit der Option zur Zertifizierung zum Professional Scrum Master. Zusätzlich wird Prof. Bente während des Projekts als Ansprechpartner in Fragen der agilen Methodik verfügbar sein.
Technologisch werden wir den Entwicklungsprozess durch eine professionelle Umsetzung von Continuous Integration mittels Jenkins, Maven und Docker begleiten. Die Qualitätssicherung erfolgt durch automatische Tests.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen und deren Umsetzung in webbasierter Software-Entwicklung
- Methodik zur systematischen Evaluierung eines Architekturstils
- Erfahrungen mit Erstellung von AngularJS-basierten Webanwendungen
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Interesse an professioneller Software-Entwicklung mit Java und/oder JavaScript
- Interesse an der Softwarearchitektur sowie Gestaltung von Nutzeroberflächen
- Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
- Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
- Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen
Externe Projektpartner
Capgemini, Niederlassung Köln
Kontakt
- Mail: stefan.bente (at) th-koeln.de
- Tel.: +49 2261 8196 6367
- Mobil: +49 176 8072 2689
- Skype: stefan.bente
- Adresse: Steinmüllerallee 1, 51643 Gummersbach, Gebäude LC6, Raum 1506. (Anfahrtsbeschreibung)
- Sprechstunde nach Vereinbarung Terminanfrage: https://calendly.com/bente/termine. Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.