Requirements for Software Architects

Requirements for Software Architects

Requirements for Software Architects

Agile Requirements Engineering und seine Rollen
 

 

Willkommen zurück zum zweiten Artikel in unserer Blog-Serie „Requirements for Software Architects“. Wir widmen uns in diesem Beitrag dem agilen Requirements Engineering und seinen Rollen.

Grundbegriffe von Softwarearchitektur

Definition

Es befinden sich zahlreichen Definitionen von Softwarearchitektur. Wir beschränken uns deshalb nur auf zwei davon:

  1. Die grundlegenden Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert in seinen Elementen, Beziehungen und in den Prinzipien seines Designs und seiner Entwicklung. (ISO/IEC/IEEE 42010)
  2. Die Softwarearchitektur einer Software oder Computersystems ist die eine oder mehrere Strukturen des Systems, welche die Softwareelemente, die extern sichtbaren Eigenschaften dieser Elemente und die Beziehungen zwischen ihnen, umfassen. (Bass, Clements, Kazman Software Architecture in Practice, Addison Wesley, 2003.) 
Aufgaben von Softwarearchitekten

Softwarearchitekten haben die Aufgabe die Softwarearchitektur aktiv zu gestalten und ihre Umsetzung und Wirksamkeit sicherzustellen. Dabei sollen sie im Wesentlichen die folgenden Ziele in einem Projekt erreichen:

  • Unterstützung von Entwurf, Implementierung, Pflege und Betrieb des Systems
  • Erfüllbarkeit der funktionalen Anforderungen sicherstellen
  • Qualitätsanforderungen in gewünschtem Maße erreichen
  • Komplexität systematisch reduzieren
  • Architekturrelevante Richtlinien für Implementierung und Betrieb spezifizieren

Die Arbeit eines Architekten kann dabei in sechs Tätigkeiten gegliedert werden:

  • Anforderungen klären
  • Strukturen entwerfen
  • Querschnittskonzepte erstellen
  • Architekturen bewerten
  • die Umsetzung begleiten
  • Architekturen kommunizieren

Der erste Schritt „Anforderungen klären“ stellt dabei die Schnittstelle unter anderem zum Requirements Engineering dar. Hierbei probiert der Architekt herauszufinden, welche Anforderungen architektonisch relevant sind.

ASR: Architektonisch bedeutende Anforderungen

Architecturally Significant Requirements (ASRs) umfassen die wichtigsten architektonischen Anforderungen. Dabei ist es egal, ob es sich um Funktionale oder nicht Funktionale Anforderungen handelt. Somit sind ASRs Anforderungen, die sich direkt auf das Architekturdesign auswirken.

Ein Architekt sollte alle NFRs mit den Stakeholdern abgestimmt und dokumentiert haben. Es ist üblich, dass eine funktionale oder nichtfunktionale Anforderung in unterschiedlichen Phasen des Software-Lebenszyklus den Status einer ASR erlangen oder verlieren kann.

Sein Entwurf und insbesondere seine Entwurfsentscheidungen sollten daher transparent machen auf Basis welcher ASRs eine Entscheidung oder ein Entwurf beruht, um Nachvollziehbarkeit zu erlangen und eine wirksame Architektur sicherzustellen.

Abbildung 9: Architecture in Technical Perspective View

Um diese zu erreichen, sollen Softwarearchitekten diese Anforderungen stets überprüfen und die Unterschiede und Besonderheiten erklären. Insbesondere der PO, RE und BA, aber auch andere Akteure, sollten für ein besseres Verständnis und eine bessere Kommunikation sensibilisiert werden .

Einige gängige Quellen für ASRs sind,

  • Anforderungsdokumentation (z.B. Product Backlog)
  • Vereinbarung zum Servicelevel (SLA)
  • Fachwissen
  • Anwendbare Standards, Richtlinien oder Richtlinien

 Solange ASRs in der Dokumentation vorhanden sind, können sie von Softwarearchitekten analysiert und verbessert werden. Sind sie jedoch nicht oder unvollständig dokumentiert, so besteht das Risiko einer unwirksamen Architektur. Eine unwirksame Architektur ist nicht in der Lage die funktionalen und nichtfunktionalen Anforderungen zu erfüllen und stellt nicht nur ein signifikantes Projektrisiko dar, sondern ist mit fortschreitender Projektlaufzeit zudem teuer zu ändern.

Architecturally Significant Requirements (ASRs) müssen deshalb Vorrang bei der Identifizierung und Dokumentation haben, um das Architekturdesign in die richtige Richtung zu leiten.

Agile Requirements Engineering

Wie bereits zuvor etabliert sollen Anforderungen nicht nur korrekt erhoben werden, sondern auch verständlich kommuniziert und ihre Erreichung geprüft werden. Dabei sind Anforderungen stetig um Wandel und bedürfen Pflege.

Agile Requirements Engineering ist ein kooperativer, iterativer und inkrementeller Ansatz, der dies erreichen soll. Er gliedert sich groß in zwei Phasen: Die Definitionsphase (Anforderungserstellung) und die eigentliche Umsetzungsphase (Entwicklung). Im Gegensatz zu den herkömmlichen Vorgehensweisen laufen die beiden Phasen, Definition und Implementierung, parallel ab.

Daraus ergeben sich viele Vorteile. Zu diesen Vorteilen gehört die schnelle und flexible Reaktion auf veränderte oder neue Gegebenheiten.

Dies wird dadurch gewährleistet, dass die Anforderungsbeschreibung nie abgeschlossen und während der gesamten Entwicklungsdauer ständig neu erfasst und angepasst wird. Das heißt, wenn einzelne Aspekte eines Prozesses von den akzeptablen Grenzen abweichen oder das resultierende Produkt nicht akzeptabel ist, muss der Prozess oder die erzielten Ergebnisse angepasst werden. Eine Anpassung sollte so schnell wie möglich erfolgen, um weitere Abweichungen zu reduzieren. Dieser Ansatz folgt vier Zielen:

  1. Kenntnis der relevanten Anforderungen auf einem angemessenen Detaillierungsgrad (zu jedem Zeitpunkt während des Systementwicklungsprozesses).
  2. Ausreichende Übereinstimmung über Anforderungen unter den Stakeholdern erreichen.
  3. Erfassen und Dokumentieren der Anforderungen gemäß der Einschränkungen und Vorgaben der Organisation.
  4. Durchführung aller anforderungsbezogenen Aktivitäten gemäß den Prinzipien des agilen Manifests.

Requirements Engineering Aktivitäten sind sehr weit gefächert und von der Art des zu entwickelnden Systems und der Organisationsspezifikation abhängig. Nichtsdestotrotz gehören auch im agile Requirements Engineering folgende vier zentrale Tätigkeiten, die von IREB etabliert wurden, dazu:

 

  • Anforderungserhebung: Die Anforderungen werden anhand unterschiedlicher Methoden möglichst effizient, vollständig und fehlerfrei ermittelt. Auch Detaillierung und Verfeinerung gehören dazu.
  • Anforderungsdokumentation: Die Anforderungen müssen adäquat und qualitativ hochwertig beschrieben werden, um die Anforderungsspezifikation mit allen relevanten Anforderungen entstehen zu lassen.
  • Anforderungsprüfung und -abstimmung: Die Anforderungsspezifikation wird auf ihre Gesamtqualität geprüft. Dazu gehört auch die inhaltliche Abstimmung mit den Stakeholdern.
  • Anforderungsverwaltung: Auch Anforderungsmanagement genannt, geht es bei der Verwaltung der Anforderungen darum, sie zur Nutzung bereitzustellen, die Versionsstände zu pflegen, eine Priorisierung zu erstellen, etc.
Der Unterschied zwischen Requirements Engineering und Requirements Management

 Die Begriffe Requirements Engineering und Requirements Management werden oft fälschlicherweise als Synonym verwendet. Wenn man von einem ganzheitlichen Requirements-Engineering-Ansatz spricht, muss man das streng genommen immer im Sinne des Anforderungsmanagements tun. Rückblickend auf die bereits genannten vier zentralen Aktivitäten bezieht sich Requirements Engineering hauptsächlich auf die ersten drei Punkte. Requirement Engineering, was ins Deutsche übersetzt wird, bedeutet Anforderungsmanagement und umfasst damit die vierte zentrale Aktivität.

Die beiden Fachtermini sind jedoch untrennbar miteinander verbunden und gehen Hand in Hand mit Requirements Management: Ohne Ermittlung gibt es keine Verwaltung und ohne effiziente Verwaltung und Aufbereitung hat die Ermittlung von Anforderungen keinen Nutzen.

Die Product Owner (PO), Business Analyst (BA) und Requirements Engineer (RE) Rollen

 Agiles Requirements Engineering geschieht nicht ad-hoc, sondern über unterschiedlichen Rollen. In der Praxis kommt es oft vor, dass es nur eine Rolle gibt (wie PO, BA, RE oder alle zusammen). Unabhängig davon wie viele Rollen in der Praxis vorhanden sind, kann die Unterteilung genutzt werden, um die unterschiedlichen Tätigkeiten und Verantwortlichkeiten des Requirements Engineering und Management gewinnbringend zu gliedern und die eigene Arbeit zu strukturieren.

Der Product Owner ist für die Wertsteigerung, genauer gesagt die Rentabilität (= ROI, Return of Investment) verantwortlich, nicht nur was das Produkt angeht, sondern auch in Bezug auf das Projektteam. Es handelt sich also um eine anspruchsvolle Aufgabe. Hierbei sind ihm drei zentrale Aufgaben zugeordnet:

  1. Vertretung der Kundeninteressen
  2. Zusammenarbeit mit dem Entwicklungsteam und Scrum Master
  3. Verwaltung des Product Backlogs

Dabei sollte er die richtige Funktionalität in der richtigen Priorität ins Projekt bringen. Daraus abgeleitet sollte er die folgenden Skills und Aufgaben meistern können:

  • Stakeholder Analyse
  • Erhebungstechniken
  • Konfliktmanagement
  • Priorisierung (z.B. Priority Poker)

Ähnlich zur PO-Rolle sollte der Business Analyst (BA) über Kreativitäts- und Erhebungstechniken verfügen. Zudem unterstützt er den Product Owner bei der Erhebung fachlicher Anforderungen, deren Akzeptanzkriterien und der Prüfung, ob und wie die Anforderungen zu den Geschäftsprozessen passen.

Zu guter Letzt kümmert sich der Requirements Engineer (RE) für die nachhaltige Spezifizierung von Anforderungen und ihre Übersetzung in das technische Umfeld.

Alle drei Rollen sollten über die folgenden Skills verfügen:

  • Stakeholder Analyse
  • Kreativitätstechniken
  • Erhebungstechniken (typischerweise mittels Befragung, Design Thinking, Persona usw.),
  • Dokumentationstechniken
  • Modellierung (typischerweise mittels UML)
  • Priorisierung von Anforderungen

Alle diese Skills können je nach Bedarf und Aufgabengebiet verwendet werden.

 

Welche verschiedenen modernen Techniken in Requirement Engineerings eingesetzt werden können, sehen wir uns im nächsten und letzten Teil der Blog-Serie an. Wir freuen uns schon Sie wiederzusehen.

 

Quellen
  • Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
  • Andreas Wintersteiger, Scrum Schnelleinstieg
  • McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
  • https://t2informatik.de/
  • North, Introducing Behaviour Driven Development
  • Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
  • Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
  • “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
  • Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
  • https://www.scrum.org/
  • http://agilemanifesto.org/
  • https://www.isaqb.org/
  • https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

 

 

Abbildungen

Abbildung 9: https://media.geeksforgeeks.org/wp-content/uploads/20200704172739/Untitled-Diagram160.png

Requirements for Software Architects

Requirements for Software Architects

Requirements for Software Architects

Mit Requirements Engineering zu den besten Anforderungen

 

 

Herzlich Willkommen zu unserer neuen Blog-Serie, Requirements for Software Architects!
Erfahren Sie in dieser dreiteiligen Reihe etwas über die Signifikanz von Anforderungen Ihrer Kunden, die verschiedenen Rollen des Agile Requirement Engineerings und moderne Techniken.

Abbildungs 1: Wie Projekte wirklich funktionieren

Einführung und Überblick

Requirements Engineering und Softwarearchitektur sind in der Welt der Softwareentwicklung Tätigkeitsbereiche, die große Teilverantwortungen tragen, um Softwareentwicklungsprojekte erfolgreich abzuschließen. Letztlich geht es darum, die Kundenbedürfnisse zu erfüllen und den Kunden zufrieden zu stellen. Um dies zu erreichen, muss man den Kunden richtig verstehen und wissen, was er tatsächlich braucht.
In diesem Stadium sind Anforderungen und deren Management Hauptakteure im Softwareentwicklungsprozess .
Anforderungen sind in Softwareprojekten das Abbild der Kundenwünsche. Sie dienen als zentrale Briefings für fast alle weiteren Tätigkeiten. Die korrekte Erhebung, Erfassung, Überprüfung, Pflege und Verfeinerung von Anforderungen beeinflusst folglich den gesamten Software-Lebenszyklus und ist somit entscheidend für den Erfolg von Softwareentwicklungsprojekten.
Im Software-Lebenszyklus sind die Phasen der Anforderung und der Softwarearchitektur direkt aufeinander folgend und daher besonders stark miteinander verzahnt, fehlerhaftes Anforderungsmanagement hat dementsprechend direkte, schwerwiegende Folgen auf architektonische Entscheidungen.

Abbildung 2: Software-Lebenszyklus

An dieser Stelle geht es nicht nur darum, dass der Requirements Engineer oder der Product Owner die richtigen Anforderungen (von den Kunden) aufgenommen hat, vielmehr geht es darum, dass der Softwarearchitekt den Product Owner richtig versteht und die von ihm bereitgestellten Anforderungen überprüft und analysiert, um darauf aufbauend seine architektonische Entscheidung treffen zu können.
In den folgenden Abschnitten geben wir einen Überblick über Anforderungsmanagement und Softwarearchitektur, bzw. wie sie sich einander ergänzen und gegenseitig beeinflussen. Dazu betrachten wir die beiden Rollen des Softwarearchitekten und eines Product Owners, sowie ihre Verantwortlichkeiten und Aufgaben in Softwareentwicklungsprojekten. Zuvor klären wir einige Grundbegriffe.
Anforderungen Definition und Grundbegriffe

„Requirement“ (englisch) bedeutet so viel, wie „Vorausgesetztes“ oder „verpflichtendes Erfordernis“, aber auch Erwartung. Wie bei vielen Begriffen aus der IT-Welt gibt es für den Begriff „Anforderung“ zahlreiche Definitionen.

Requirements Engineering Board (IREB) definiert Anforderung hingegen als:
• ein Bedürfnis, das von einem Stakeholder wahrgenommen wird.
• eine Fähigkeit oder Eigenschaft, die ein System haben soll.
• eine dokumentierte Darstellung eines Bedarfs, einer Fähigkeit oder eines Eigentums.

Für das International Institute of Business Analysis (IIBA) ist eine Anforderung eine brauchbare Darstellung eines Bedürfnisses, die in der Regel durch Dokumente beschrieben wird.
Daraus abgeleitet können Anforderungen als eine Aussage über den zu erreichenden Merkmalen oder die zu erbringenden Leistungen für eine Software oder System definiert werden.

Arten von Anforderungen

In der Literatur gibt es viele Unterteilungen oder Klassifizierungen von Anforderungen. Zum Zwecke dieses Inhalts betrachten wir nur zwei (bekannte) Hauptkategorien, funktionale (FR) und nicht-funktionale Anforderungen (NFR).
Nichtfunktionalen Anforderungen fallen wiederum in zwei Kategorien: Die Qualitätsanforderung oder Qualitätskriterien und die Einschränkungen (eng. constraints)

Abbildung 3: Gute vs. schlechte Anforderungen

Funktionale Anforderungen

Das „WAS“ legt die Funktionale Anforderungen fest, was das Produkt tun soll. Ein Beispiel:
„Das System soll die geleisteten Arbeitsstunden eines Mitarbeiters für einen bestimmten Zeitraum berechnen.“
Das bedeutet, dass sich die funktionalen Anforderungen lediglich auf die Verhaltensergebnisse beziehen, die die Funktionalität des Systems oder der Software liefern soll.

Nichtfunktionale Anforderungen (NFRs)

Die nicht-funktionalen Anforderungen (NFR) beschreiben, wie gut das System die Leistung erbringen soll und unter welchen Rahmenbedingungen und sind eine Herausforderung für jeden PO. Sie werden typischerweise in zwei Bereiche untergliedert:
• Qualitätskriterien
• Einschränkungen

Qualitätskriterien

… sind Anforderungen, die sich auf ein Qualitätsproblem beziehen, das nicht durch funktionale Anforderungen abgedeckt ist.
Diese werden (z.B. nach Volere) in Ausführungsqualität und Weiterentwicklungsqualität gegliedert.

Ausführungsqualität (während des Betriebs / zur Laufzeit)

  • Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
  • Aussehen und Handhabung (Look-and-feel)
  • Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
  • Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)
  • Sicherheitsanforderungen (Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit)
  • Korrektheit (Ergebnisse fehlerfrei)

Weiterentwicklungs- und Evolutionsqualität

  • Betriebs- und Umgebungsbedingungen
  • Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
  • Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
  • Flexibilität (Unterstützung von Standards)
  • Skalierbarkeit (Änderungen des Problemumfangs bewältigen)

Eine andere Aufteilung von Nichtfunktionalen Anforderungen findet man in der ISO 25010. Hier werden die Qualitätsanforderungen anhand 8 Kriterien beschrieben.

Abbildung 7: Standard ISO/IEC 25010. Software product quality model

1. Funktionale Eignung
  • Funktionelle Vollständigkeit
  • Korrekte Funktionalität
  • Angemessene Funktionalität
2. Verlässlichkeit
  • Reife
  • Verfügbarkeit
  • Fehlertoleranz
  • Wiederherstellbarkeit
3. Leistungseffizienz
  • Zeitverhalten
  • Ressourcennutzung
  • Kapazitätsaufwand
4. Nutzbarkeit
  • Angemessene Erkennbarkeit
  • Erlernbarkeit
  • Bedienbarkeit
  • Schutz vor Fehlbedienung durch den Nutzer
  • User-Interface Ästhetik
  • Zugänglichkeit
5. Wartbarkeit
  • Modularität
  • Wiederverwendbarkeit
  • Analysierbarkeit
  • Modifizierbarkeit
  • Testfähigkeit
6. Sicherheit
  • Datenschutz
  • Integrität
  • Unmanipulierbarkeit
  • Administrationsfähigkeit
  • Authentifizierbarkeit
7. Kompatibilität
  • Co-Existenz (zu weiterer Software)
  • Interoperabilität
8. Portierbarkeit
  • Anpassungsfähigkeit
  • Installierbarkeit
  • Austauschbarkeit
Einschränkungen

… sind Anforderungen, die den Lösungsraum über das hinaus beschränken, was zur Erfüllung spezifizierter funktionaler Anforderungen und Qualitätsanforderungen erforderlich ist.

Es gibt verschiedene Arten von Einschränkungen, z.B. zeitliche Terminplanbeschränkung, regulatorische oder gesetzliche Beschränkungen usw.

In Softwareprojekten spricht man von Einschränkungen, wenn Faktoren wie Zeit, Geld, Umfang (das sogenannte „Magische Dreieck“) oder Ressourcen, wie Ausrüstung oder Personalmangel das Projekt beeinflussen.

 

Abbildung 8: Das magische Dreieck

Die Einschränkungen hängen auch von dem Tätigkeitsbereich des Unternehmens sowie den Dienstleistungen ab, welches es anbietet.

Im Gesundheitswesen beispielsweise können bestimmte Vorschriften oder Gesetze die Qualität von Software oder sogar die Implementierung der gesamten Softwarearchitektur beeinträchtigen.

Aus allen diesen Gründen ist es wichtig, dass sich der Softwarearchitekt bereits zu Beginn des Projekts mit den verschiedenen Einschränkungen auseinandersetzt und mit den Key Rollen abklärt.

 

Wir freuen uns schon, Sie beim nächsten Artikel unserer Blog-Serie wieder begrüßen zu dürfen – dem Agile Requirements Engineering und seine Rollen.

 

Quellen
  • Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
  • Andreas Wintersteiger, Scrum Schnelleinstieg
  • McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
  • https://t2informatik.de/
  • North, Introducing Behaviour Driven Development
  • Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
  • Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
  • “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
  • Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
  • https://www.scrum.org/
  • http://agilemanifesto.org/
  • https://www.isaqb.org/
  • https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

 

Abbildungen

Abbildung 1: https://cdn-images-1.medium.com/max/1200/1*ApoaIZicyU0b7Jgg9MMJhw.jpeg

Abbildung 2: ITech Progress CPSA-Foundation Kurs (Präsentation) – Kapitel 1: Grundbegriffe – Einordnung der Softwarearchitektur in Software-Lebenszyklus

Abbildung 3: https://www.softwareone.com/-/media/global/social-media-and-blog/content/requirements-engineering-4-graph1.png?mw=1024&rev=bc1dea2cb4d145c79f1f5b544e3a10cd&sc_lang=de-at&hash=43114D2C3FE79F36503891506BDBA9FA

Abbildung 4: https://www.nasa.gov/images/content/549928main_jfk_speech_226.jpg

Abbildung 5: https://www.nasa.gov/sites/default/files/styles/side_image/public/62297main_neil_on_moon_full.jpg?itok=1c8GTfbJ

Abbildung 6: https://miro.medium.com/max/1762/0*ohypH8bVpf2O0uIc.png

Abbildung 7: https://www.researchgate.net/profile/Lina-Garces/publication/326584873/figure/fig2/AS:652083346808834@1532480193500/Standard-ISO-IEC-25010-Software-product-quality-model-and-system-quality-in-use-model.png

Abbildung 8: https://i.pinimg.com/originals/a1/3c/ed/a13cedd07eb87e2fab0baa483d9877fd.png

Zauberhafte Weihnachten im Herzen von Nürnberg

Zauberhafte Weihnachten im Herzen von Nürnberg

Zauberhafte Weihnachten im Herzen von Nürnberg

Die Feste bilden eins der schönsten Bande der gesellschaftlichen Verbindung der Menschheit – es ist der Jubel der Gesellschaft über das, was sie fertiggebracht hat – und sie werden die Menschheit bis ans Ende ihrer Tage begleiten.

Rudolf von Jhering (1818 – 1892)

H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

Im Herzen der Nürnberger Altstadt fand unsere Weihnachtsfeier im Marmorsaal des Presseclubs statt. Hierbei waren zahlreiche Kollegeninnen und Kollegen sowie Familienangehörige herzlich eingeladen. Nicht nur das abwechslungsreiche Programm, das ayurvedische Buffet und die Bar die sowohl für Kinder als auch für Fußballbegeisterte hergerichtet wurde, sondern auch die prächtige Architektur des Saales sorgten für eine großartige Atmosphäre.

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
Das sitzende Publikum bei H. Tiemeyers Vortrag. Die Zuhörer sind von hinten zu sehen, vorne die Präsentation.
H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

Nach dem Treffen am Christkindlmarket, wo wir zu Glühwein und Kinderpunsch am Stand der Feuerzangenbowle von unserem Kollegen Jürgen eingeladen waren, machten wir uns auf den Weg in den Saal. Dort erwartete uns ein abwechslungsreiches Buffet vom Mount Lavinia, dem ältesten ceylonesischen Restaurant in Deutschland, das auch für seine gesunde ayurvedische Küche bekannt ist. Die Gäste konnten ihre Tanzkünste bis in die Nacht unter Beweis stellen und rundeten den orientalischen Tanz der Bauchtänzerinnen ab!

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.

Auf übertriebene und humorvolle Art und Weise zeichnete uns über den gesamten Abend ein Porträtkarikaturist. So konnten wir unsere Gesichtszüge und Hobbys auf lustige und künstlerische Art und Weise bewundern.

ITech Progress Messestand auf der JFS 2022

Zwei Jahre lang haben wir uns digital getroffen und gefeiert. Umso mehr haben wir uns gefreut dieses Fest gemeinsam in Präsenz zu verbringen. Wir bedanken uns für den tollen gemeinschaftlichen Abend in diesem Jahr und wünschen allen eine schöne und vor allem gesunde Weihnachtszeit!

 

ITech Progress Sommerfest 2022

ITech Progress Sommerfest 2022

ITech Progress Sommerfest 2022

Am Freitag, den 09.09.2022 fand das Sommerfest der ITech Progress GmbH statt. Um den Sommer gemeinsam ausklingen zu lassen, traf sich das Team in Nürnberg, denn dort befindet sich neben dem Hauptsitz in Ludwigshafen ein weiterer Standort der ITech Progress GmbH. Im Mittelpunkt stand nach den vielen Einschränkungen der COVID-19-Pandemie und verschärften Homeoffice-Regelungen das Kennenlernen aller neuen Kolleg:innen.

Spaghetti, Marshmallows &
Metermaß

Für das erste Kennenlernen versammelten wir uns in einem Seminarraum der Deutschen Jugendherberge Nürnberg. Sie liegt direkt neben der Kaiserburg und gilt als modernste Jugendherberge in einem wunderschönen historischen Gebäude. Mit ihren breiten Gewölbemauern und Sandsteinbögen lädt sie mit einem ganz eigenen Charme zum Verweilen ein.

Drei Mitarbeiter lachen, weil ihr Spaghetti-Turm umfällt, wenn dieser nicht festgehalten wird.
Zwei Mitarbeiter:innen freuen sich über einen verbogenen Spaghetti-Turm

Um langwierige Kennenlernspiele zu vermeiden, wurde ein Ice-Breaker vorbereitet, der selbst täglich strategisch denkende Teams ins Schwitzen bringt. Mit 20 Spaghetti und einem Meter Kreppband sollten Fünfergruppen in 15 Minuten den höchsten von selbst stehenden Turm bauen. Ein Marshmallow markierte als krönender Abschluss nicht nur den Messpunkt, sondern stellte die Statik des Turms auf die Probe. Mit den verschiedensten Lösungsansätzen versprachen die Gruppen sich den eigenen Sieg. Schlussendlich überzeugten zwei der fünf Türme mit ihrer Standhaftigkeit ohne zusätzliche Stütze.

Stadtrallye: Immer der Nase nach!

Bei der darauffolgenden Stadtrallye wurden Teamfähigkeit und Koordination gefragt, denn wir erlebten Kunst, Kultur, Kulinarisches und natürlich auch die Geschichte Nürnbergs auf eine abenteuerliche Art und Weise. Mit Hilfe von Fotos, Rätseln und Fragen fanden wir in drei Gruppen, die nicht nur gegen die anderen Teams, sondern auch gegen die Zeit spielten, unseren Weg durch Nürnbergs Geschichte. Eine wunderbare Stadtrallye führte uns durch die Nürnberger Altstadt, wobei die Aufgaben nicht ausschließlich mit der Hilfe des Internets lösbar waren. Foto-Aufgaben, bei denen zum Beispiel das Abendmahl nachgestellt, die Stadtwappen gefunden oder ein Sprichwort („Immer der Nase nach.“) verkörpert werden sollte, lockerten die Atmosphäre auf.

Mitarbeiter:innen stellen das Bild "Abendmahl" nach.

Neuinszenierung Abendmahl

Mitarbeiter stehen vor einem Torbogen. Darüber hängen die Stadtwappen Nürnbergs.
Mitarbeiter berührt den goldenen Ring am schönen Brunnen.

Da die Gruppen selbst entscheiden konnten, welche Aufgaben sie durchführen oder auslassen wollten, war die Rallye für alle ein individuelles Erlebnis. Es bestanden die Möglichkeiten, die Kaiserburg zu besuchen, das Albrecht Dürer Haus zu sehen, den Hauptmarkt zu erkunden und den goldenen Ring am schönen Brunnen zu drehen, wodurch der Sage nach ein Kinderwunsch in Erfüllung gehen soll.

Probieren geht über studieren

Auch typische Nürnberger Spezialitäten durften im Programm natürlich nicht fehlen! Zum Probieren standen drei Nürnberger im Weck, „Kaiserin“ Lebkuchen, der Burggeist (Kräuter-Schnaps), Rotbier und der Hammelhoden (Wein) auf dem Plan.

Gruppe posiert vor dem großen nürnberger Stadtwappen.
Gruppe probiert Nürnberger "Kaiserin" Lebkuchen.
Das Siegerteam der Stadtrallye freut sich.

Vor allem die Beschaffung des Hammelhodens trug zur Belustigung unseres gesamten Teams bei, als beim Abendessen davon erzählt wurde, wie eine unserer Kolleginnen diese Aufgabe angegangen ist. Mitten in der belebten Altstadt lief sie zu einem Restaurantmitarbeiter und fragte diesen laut vor allen Gästen und ohne weitere Erklärung: „Haben Sie einen Hammelhoden?“ Als der Mann sichtlich überrascht und verwirrt reagierte, wurde klar, dass in heutiger Zeit vermutlich nicht mehr jede:r Nürnberger:in weiß, was genau dieser alte Begriff beschreibt.

Unsere Einkehr im Heilig-Geist-Spital rundete den gelungenen Tag ab. Dort wurden wir nicht nur hervorragend verköstigt, sondern konnten unsere Erlebnisse erzählen und das Siegerteam der Stadtrallye (Team Alpha) mit einer kleinen Aufmerksamkeit ehren.

Gruppenfoto des ITech teams beim Sommerfest 2022.

Desiree Weber

Werkstudentin Marketing

13.09.2022

ITech Progress auf dem Java Forum Stuttgart

ITech Progress auf dem Java Forum Stuttgart

ITech Progress auf dem Java Forum Stuttgart

Die Java Forum Stuttgart ist eine jährlich stattfindende, eintägige Konferenz mit Java als Leitmotiv. Sie wird von der Java User Group Stuttgart (JUGS) veranstaltet und ist für Entwickler und Entscheider konzipiert. Das Forum bietet den Teilnehmenden die Möglichkeit, sich umfassend über Themenfelder wie Java bzw. im Java- sowie JVM-Umfeld zu informieren. Aufgrund der hohen Teilnehmerzahlen wird als Veranstaltungsort das zentrale Kongresszentrum Liederhalle in Stuttgart genutzt.

JFS 2022: Eingang der Liederhalle Stuttgart

Am 07. Juli war es so weit, die ITech Progress GmbH konnte als Sponsor mit einem Ausstellungsstand und einem Vortrag endlich wieder an einer Präsenzkonferenz teilnehmen.

Nur ein Tag, dafür aber 8 Vortragssäle, über 50 Vorträge und mehr als 30 Aussteller: Auf dem Java Forum Stuttgart wurde ein intensives Programm geboten und wir waren mittendrin.

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
Das sitzende Publikum bei H. Tiemeyers Vortrag. Die Zuhörer sind von hinten zu sehen, vorne die Präsentation.
H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

Der von der ITech Progress GmbH präsentierte Vortrag erreichte im Beethovensaal über 100 interessierte Zuhörer:innen. „Kontrollverlust in Softwaresystemen? Strukturen zur Beherrschung der neuen Unübersichtlichkeit und die Unendlichkeit von Software.“ war der Titel des unterhaltsamen und lehrreichen Exkurses, der hohe Resonanz und Zustimmung bei dem Publikum fand.

Am neuen Ausstellungsstand mit unserem Claim „Software-Architektur ist unsere DNA!“ bekamen wir ebenfalls guten Zuspruch und unterhielten uns mit einigen interessierten Teilnehmer:innen. Für alle, die sich in der ITech Academy weiterbilden wollten, haben wir ein Gewinnspiel angeboten, bei dem als Hauptgewinn mit etwas Glück die kostenlose Kursteilnahme an einer iSAQB-Schulung des Academy Programms nach freier Wahl ergattert werden konnte. Die vielen Glückspielversuche sprechen zu unserer Freude für das Interesse an unserem Trainingsportfolio. Denn als iSAQB-Trainingsprovider bietet die ITech Academy zum Certified Professional for Software Architecture (CPSA) Foundation Level auch 17 iSAQB CPSA Advanced Level Module an.

Das Messeteam der ITech Progress GmbH steht am Messestand.
Gewinnspielaufsteller
ITech Progress Messestand auf der JFS 2022

Alles in allem sehen wir die Java Forum Stuttgart als gelungene Konferenz mit einem interessant gestalteten Schwerpunktgebiet. Wir freuen uns auf die nächsten Veranstaltungen, hoffentlich weiterhin auch mit hohem Präsenzanteil.