Randbedingungen - Archi-Lab/prox-documentation-gp-ws2018 GitHub Wiki

Inhalte auf dieser Seite

Zu Beginn unseres Projekts wurden Randbedingungen aufgestellt, bei denen Auftraggeber, Product Owner, Entwicklungsteam und Scrum Master (siehe Scrum-Rollen) involviert waren. Drei wichtige Vorgaben wurden hier deutlich: Softwarearchitektur, Teamprozess und Arbeitstage.

Softwarearchitektur

Vorgabe: Microservice-Architekturstil

In einem Hochschulkontext ist es wichtig, Softwaresysteme so zu entwickeln, dass diese nach Semesterende von neuen Studierenden weiterentwickelt werden können. Zudem ist es wünschenswert, wenn diese Systeme aus lose gekoppelten kleineren Einheiten bestehen, damit mehrere studentische Teams gleichzeitig und möglichst unabhängig voneinander daran entwickeln können. Der Microservice-Architekturstil eignet sich dafür besonders gut und erfreut sich seit einigen Jahren wachsender Beliebtheit. Insbesondere bei groß angelegten und komplexen Software-Projekten wird er gern verwendet, um dem hohen Entwicklungsaufwand mit mehreren unabhängigen Teams entgegentreten zu können. Wenn mehrere dieser kleinen Einheiten (Microservices), die für sich gesehen meist nur wenig Funktionalität bieten, integriert werden, bildet sich ein kohärentes System, dass selbst komplexe Aufgaben bewältigen kann und zudem gute Skalierungseigenschaften besitzt.

Teamprozess

Vorgabe: Scrum

Bei der Durchführung eines Projekts ist fast unabdingbar, sich auf einen Arbeits- bzw. Teamprozess zu einigen, um die Produktivität des Teams und die Qualität des Produkts zu steigern und die Komplexität zu bewältigen. Zusätzlich müssen Arbeitspakete genau geplant und organisiert werden. Für ein agiles Softwareprojekt, eignen sich dazu Vorgehensmodelle, wie bspw. „Scrum“. Im Falle von Scrum, kann wertvolles Feedback von allen involvierten Stakeholdern in kürzeren Feedback-Zyklen gesammelt werden. Unter anderem verhindert es damit Blindleistungen und das Entwicklungsteam kann iterativ nach jedem Zyklus auf sich ändernde Anforderungen reagieren. Die Seite Teamprozess, beschäftigt sich näher damit, wie und wozu wir Scrum in unserem Projekt verwendet haben.

Arbeitstage

Vorgabe: Zwei feste Arbeitstermine in der Woche, an den alle Teammitglieder präsent sein müssen

In einem Projekt mit komplexen Aufgaben ist es besonders wichtig Information zwischen den Teammitgliedern so effektiv wie möglich kommunizieren zu können. Nach der Medienreichhaltigskeitstheorie (engl. _Media richness theory*), ist Face-to-face-Kommunikation die effektivste Methode, um die Kommunikation komplexer Informationen zu optimieren. Daher wurde vor Projektbeginn festgelegt, wie oft und zu welchen Tagen sich das Entwicklungsteam wöchtentlich treffen würde, um die bevorstehende Arbeit zu leisten. Alle involvierten Parteien einigten sich auf zwei Arbeitstage je Woche. Die folgende Tabelle zeigt unseren genauen Arbeitstagen:

Zeitplan

Erzeugung von Backend-Applikationen

Vorgabe: Spring Boot

Entwickler sollten im Idealfall so schnell wie möglich damit anfangen, Anwendungen zu entwickeln, statt sich mit der Komplexität von Konfigurationsdateien auseinanderzusetzen. Nach dem Softwaredesign-Paradigma „Konvention vor Konfiguration“ wird der Konfigurationsaufwand reduziert, um Applikationen wartbarer zu gestalten. Die Entwickler müssen dabei nur die Konventionen hinter einem Framework kennen und verstehen, um ohne Umwege mit der Entwicklung von Softwarelösungen für Domänenprobleme zu beginnen. Spring Boot setzt dieses Paradigma im Bereich der Entwicklung von Spring-Applikationen um. Dabei nimmt es dem Entwickler fast die gesamte Konfiguration der Komponenten des zugrundeliegenden Spring Frameworks ab, welches den De-Facto-Standard zur Entwicklung moderner Java-Enterprise-Applikationen darstellt.

Entwicklung der Weboberfläche

Vorgabe: Angular

Angular ist ein TypeScript-basiertes Front-End-Webapplikationsframework, welches als Rahmenbedingung festgelegt und von der vorherigen Guided-Project-Gruppe für die Entwicklung von Prox verwendet wurde. In Anbetracht dessen verwendeten wir für die Neuentwicklung der Webanwendung (siehe Entscheidungsprotokoll) ebenfalls Angular. Die genaue Angular-Version die wir bei der Entwicklung des Frontends verwendeten lautet 7.1.4, da es sonst bei einer neueren Version zu einer Kompatibilitätsstörung mit Angular 4 HAL kam. Das Angular Framework wurde als grundlegendes Rahmenwerk für die Entwicklung des Frontends verwendet. Das heißt, dass die Kommunikation zwischen den TypeScript- und HTML-Dateien im Frontend mittels der bereitgestellten Funktionen von Angular geregelt wird. Wie genau Angular bei der Entwicklung eingesetzt wurde, wird im Abschnitt Struktur und Kommunikation verdeutlicht.