Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/server115293/ftp/www/dmtpl/de/wp-content/plugins/seo-ultimate/modules/class.su-module.php on line 1195
ZUSAMMENARBEIT MIT SORGE UM QUALITÄT | dmt - dedykowane systemy masowej przepustowości

ZUSAMMENARBEIT MIT SORGE UM QUALITÄT

Im Prozess der Softwareproduktion gehen wir davon aus, dass die Qualität der Software für den Kunden das Wichtigste ist, da sie sich direkt in niedrigeren Betriebskosten und einer besseren Wahrnehmung eines Unternehmens durch seine Kunden niederschlägt. Alle Prozesse unsererseits wurden dahingehend optimiert, dass eben die Qualität an erster Stelle steht.

Wir spezialisieren uns auf Massendatensysteme, die gigantische Datenmengen schnell verarbeiten oder kleinere Datenmengen in extrem kurzer und oft garantierter Zeit verarbeiten können (z. B. Transaktionssysteme). Einige dieser Lösungen bewegen sich – das ist offensichtlich – im Bereich der Big Data / Fast Data im weiten Sinne.

Bei der Betrachtung von „Qualität“ im Zusammenhang mit „Massendatensystemen“ wird schnell klar, das immer die Zeit der limitierende Faktor bei der Systementwicklung ist. Die Herausforderung für uns besteht also darin, dem Kunden ein qualitativ optimales System zur Verfügung zu stellen, das in der Lage ist, riesige Datenmengen zu verarbeiten – und innerhalb einer geschäftlich vertretbaren Zeit entwickelt und gewartet werden kann.

Zudem müssen wir bei der Entwicklung unserer Lösungen auch deren Lebensdauer berücksichtigen. Unsere Systeme sind für die anspruchsvollsten Aufgaben ausgelegt und ihr Lebenszyklus kann bis zu 20 Jahre betragen. Darum spielen nicht nur die Dauer der Entwicklung, sondern vor allem auch Erweiterbarkeit, Wartung und Support eine Rolle. Das bedeutet, dass das System von Anfang an im Hinblick auf eine langjährige, problemlose Nutzung und eine ebenso langfristige und kontinuierliche Entwicklungsfähigkeit entworfen werden muss.

Und eben darin liegt die Qualität eines Systems – die Notwendigkeit der Gewährleistung niedriger Entwicklungs- und Wartungskosten sowie einer möglichst kurzen Entwicklungszeit steht hinter den meisten hier beschriebenen Lösungen der Softwareproduktionstechnik.

AGILE ODER WATERFALL? – EINE HYBRIDE METHODE!MEHR

Wir entwickeln, implementieren und warten Software mit einer hybriden Methodik basierend auf den besten Praktiken dieser führenden globalen Ansätze.

Bei der Software-Entwicklung, insbesondere in der Angebotsphase, lässt sich der herkömmliche „Wasserfall“-Ansatz (Analyse, Entwurf, Implementierung, Tests, Installation, Wartung) nicht vermeiden. Dieser Ansatz findet Anwendung, um die geschätzten Kosten und den Zeitplan für ein Projekt zu bestimmen. Die auf diese Weise ermittelten Werte dienen als Grundlage für zukünftige Vereinbarungen, vor allem in Bezug auf Meilensteine. Da in der Angebotsphase die detaillierte Analyse und der Systementwurf noch nicht vorliegen (sie werden erst im Rahmen eines aus dem Angebot resultierenden Vertrags erstellt), ist es notwendig, sich auf allgemeine Annahmen zu beziehen und alle Ungewissheiten und Unklarheiten in der zu diesem Zeitpunkt verfügbaren Dokumentation eindeutig zu klären.

Dennoch gehen wir schon in dieser Phase davon aus, dass die ordnungsgemäße Umsetzung des Prozesses in Bezug auf die Meilensteine mit Hilfe agiler Methoden erfolgen wird. Auf diese Weise hat unser Kunde die Möglichkeit, von der Strenge der Wasserfallpläne abzuweichen. Das System kann völlig flexibel entwickelt, implementiert und gewartet werden, um dem sich wandelnden Geschäftsumfeld, Änderungen der unmittelbaren funktionalen Anforderungen und sogar Änderungen in Budget und Zeitplan Rechnung zu tragen. Wir begreifen „agil” als die Agilität unserer Kommunikation mit dem Kunden, die darauf ausgerichtet ist, unser Produkt oder unsere Dienstleistung präzise auf die Erwartungen des Kunden und seine Gegebenheiten zu einem bestimmten Zeitpunkt abzustimmen.

Agile Methoden passen auch perfekt in die DNA unseres Unternehmens: Die Wartung und Entwicklung von Anwendungen sind für uns von zentraler Bedeutung – in einigen Fällen warten wir Anwendungen bereits seit über 20 Jahren. Ohne einen agilen Ansatz wäre das absolut unmöglich.

Microservices - PTR AtomMEHR

Das Fundament unseres Ansatzes zur Softwareentwicklung sind – und das seit mehr als 20 Jahren – die Microservices. Wir haben diese Methode bereits angewandt, als sie noch nicht einmal einen Namen hatte. Wir mussten also unsere eigenen Lösungen in diesem Bereich schaffen. Heute – nach über 20 Jahren der Entwicklung – sind wir stolz, dass die Richtung die wir damals eingeschlagen haben, sich zu einem der führenden Trends in der Entwicklung der modernen IT gemausert hat.

Von Anfang an haben wir konsequent an der Entwicklung der Transaktions- und Zahlungsplattform „Atom“ gearbeitet, denn sie bot beispiellose Möglichkeiten für den Betrieb von Zehn- oder Hunderttausenden von Microservices.

Die Atom-Plattform:

  • beschleunigt die Entwicklung radikal, indem sie die parallele Arbeit der Programmierer ermöglicht;
  • macht das Testen von Microservices deutlich einfacher;
  • ermöglicht den leichten und flexiblen Aufbau komplexer und umfassender Dienste („chemischer Verbindungen“) aus einfachen und klar definierten Microservices („Atomen“);
  •  verfügt über integrierte Mechanismen für Clustering, Überwachung, SLA, COB, Sicherheit usw.;
  • kann vollautomatisch im unbeaufsichtigten Modus arbeiten.

DevOpsMEHR

Da wir recht häufig Software im Outsourcing-Modell entwickeln (wobei sowohl die Entwicklung als auch der spätere Support des Systems in unserer Verantwortung liegt), verwenden wir praktisch ständig DevOps-Mechanismen. Für uns bedeutet das:

  • Codierung basierend auf den besten bewährten Lösungen und Technologien. Anwendung von Versionskontrollsystemen (GitLab) sowohl für den Anwendungscode als auch für die Datenbank.
    Das ist wesentlich, da bei Massendatensystemen die Datenbankschicht besonders sorgfältig aufgebaut wird, um maximale Leistung und (was oft noch wichtiger ist) maximale Skalierbarkeit zu gewährleisten. Das Versionskontrollsystem muss also auch die Codeversionen und die Strukturen der Datenbank selbst kontrollieren.
    Wir verwenden Code Review für Schlüsselelemente des Codes. Dies geschieht zum Teil innerhalb des Entwicklerteams, aber wir haben auch eine eigene Abteilung, die ausschließlich für die Sicherstellung der korrekten Codequalität zuständig ist. Diese Abteilung ist ebenfalls für die Kontrolle des gesamten Codes aller neuen Mitarbeiter während ihrer Anpassungsphase verantwortlich.
    Die Konfiguration des Versionskontrollsystems und die „Merge“-Verfahren ermöglichen es uns, eine ungestörte Entwicklung der Anwendung einerseits und eine routinemäßige Fehlerbehebung andererseits zu gewährleisten.
  • Kontinuierliches Bauen – in unserer Umgebung unterliegt der erzeugte Quellcode dem Bauprozess – sowohl in Bezug auf Artefakte als auch auf die Anwendung selbst. Intern verwenden wir im Laufe der Softwareproduktion Anwendungen in einer containerisierten Version. Daher werden nach der Erstellung der Anwendung ein Bild des/der Docker-Container(s) sowie eine vollständige Umgebung basierend auf der Kubernetes-Orchestrierung erstellt.
  • Kontinuierliches Testen – in der oben beschriebenen Umgebung werden dann automatische Testmechanismen angewandt. Das bedeutet einerseits, dass die Testeinheiten automatisiert sind, andererseits verwenden wir aber auch konventionelle API- oder Benutzerschnittstellentests. Der Zweck der automatischen Tests (die von einem unabhängigen Team erstellt werden) besteht darin, sowohl Regressionstests (für Funktionen aus früheren Sprints) als auch Tests des aktuellen Sprints durchzuführen. Wichtig ist, dass diese Tests durchgeführt werden, noch bevor das System an die Abteilung für manuelle Tests weitergeleitet wird. Auf diese Weise schützen wir uns vor dem Albtraum vieler Implementierungen – wiederkehrenden Fehlern, die bei der Beseitigung anderer Fehler auftreten.
  • Verpackung/Lieferung – dank der Containerisierung liefern wir alle unsere Lösungen als fertige Container, die vom Kunden direkt von unserem internen Repository heruntergeladen werden können. Dadurch wird auch die Aktualisierung von Software extrem vereinfacht. Sogar für Kunden, die die Containerisierung noch nicht eingeführt haben, gestalten sich die Lieferprozesse deutlich einfacher.
  • Konfiguration – da wir Kubernetes (und ggf. Infrastruktur-as-a-Code-Tools) verwenden, ist die vorbereitete Anwendung vollständig als ein funktionsfähiger Satz der erforderlichen, miteinander verbundenen Server konfiguriert. In einem typischen Fall erfordert die Implementierung eines neuen Sprints vom Kunden lediglich eine einfache Aktualisierung der Container-Images und einen Neustart der Kubernetes-Orchestrierung.
  • Überwachung – die oben beschriebene Anwendung wird kontinuierlich überwacht. Dies ist vor allem im Hinblick auf die Sicherstellung eines angemessenen SLA-Niveaus in Bezug auf die Fehlerbehebung von Bedeutung.

ErgonomieMEHR

Benutzerfreundlichkeit und Zuverlässigkeit der Software ist jedoch nicht alles – Anwendungen von heute müssen funktional, intuitiv, ergonomisch und an den jeweiligen Benutzer angepasst sein.

Wir verwenden nutzerorientierte Entwurfsmethoden und moderne Werkzeuge für die Entwicklung von Webanwendungen, um qualitativ hochwertige, anspruchsvolle, dynamische und vollständig interaktive Benutzeroberflächen für unsere Kunden zu erstellen und sicherzustellen, dass sie sowohl funktional als auch benutzerfreundlich sind. Wir können solche Anwendungen auch in Versionen erstellen, die nicht nur auf PCs, sondern auch auf Tablets und anderen Mobilgeräten problemlos benutzt werden können. Dies entspricht dem zu beobachtenden Trend, anstatt mobiler Anwendungen als solche lieber universelle Versionen von Webseiten zu entwickeln, die auf besondere Weise auch auf tragbaren Geräten angezeigt werden können.

Tests, die Idee der verhaltensgetriebenen BeziehungMEHR

Um eine angemessene Softwarequalität zu gewährleisten, wird unsere Software auf vielen Ebenen getestet:

  • in Unit-Tests – direkt von den Programmierern für alle drei Schichten der Anwendung erstellt;
  • in manuellen Tests – durchgeführt von der Abteilung für manuelle Tests;
  • in automatischen Tests – durchgeführt von der Abteilung für automatische Tests und weitergeleitet an die Entwicklungsabteilung.

Der Mechanismus der sog. Unit-Tests bedeutet, dass alle unsere Anwendungen über spezielle Funktionen verfügen, die einzelne kleine Softwareeinheiten auf ihre Korrektheit überprüfen. Für jeden Auftrag erstellen die Programmierer spezielle Testverfahren, die dann vollautomatisch durchgeführt werden. Auf diese Weise konnten wir durch die Automatisierung von Regressionstests – der Überprüfung, ob ein Fehler schon einmal aufgetreten ist und ob er behoben wurde und nicht wieder auftrat – die Softwarequalität deutlich verbessern.

Mit Hilfe des Datenbank-Testmechanismus können wir die Qualität der gespeicherten Verfahren in der Datenbank automatisch prüfen. Diese Verfahren bilden das Fundament für den restlichen Teil der Anwendung – deshalb verwenden wir Werkzeuge, die imstande sind, eine enorme Anzahl von Tests automatisch durchzuführen und zu überprüfen, ob die gespeicherten Verfahren korrekt ausgeführt wurden, sogar in Bezug auf die kleinsten Änderungen. Die Tests auf dieser Ebene können als Tests der Datenbankschicht in der herkömmlichen dreischichtigen Anwendungsarchitektur verstanden werden.

Ergänzt wird der Testprozess durch den Testmechanismus der Programmierschnittstellen für eine Anwendung (REST). Das bedeutet, dass wir vor dem Testen der Benutzerschnittstelle automatisch die Programmierschnittstellen prüfen (welche die gespeicherten Verfahren ausführen und die in den Unit-Tests geprüften Anwendungseinheiten benutzen). Die Tests auf dieser Ebene können als Tests der Businessschicht verstanden werden.

Die oben genannten Testmechanismen verbinden wir mit den Tests der Benutzeroberflächen für Webanwendungen. Diese werden von der Prüfabteilung durchgeführt, u. a. mit Hilfe von Selenium- oder Katalonsoftware – einem Satz von Werkzeugen zum Schreiben von Testszenarien und deren anschließender automatischer Ausführung bei jeder, auch der geringsten Modifikation einer Anwendung, sogar wenn die betreffende Modifikation in keinerlei Beziehung zu anderen Anwendungskomponenten zu stehen scheint.

Wir haben eine Lösung implementiert, mit der die Anwendung nicht nur automatisch aus den von den Programmierern vorbereiteten Quellcodes erstellt werden kann, sondern vor allem alle oben beschriebenen Tests automatisch ausgeführt werden können (Kontinuierliche Integration).

Damit soll sichergestellt werden, dass jede noch so geringe Änderung eines beliebigen Teils des Anwendungsquellcodes alle automatischen Tests auslöst: Unit-Tests, Datenbanktests (gespeicherte Verfahren), Tests der Businessschicht und Tests der Benutzerschnittstelle.

Die oben genannten Tests können, je nach ihrer Position im Prozess, insbesondere als Regressionstests (durch Testen von Funktionen in einem gegebenen Sprint, die in vorhergehenden Sprints bereits abgeschlossen wurden), Abnahmetests – oder sonstige Testarten verwendet werden.

Um eine optimale Softwarequalität zu gewährleisten, arbeiten die Entwicklerabteilung, die Abteilung für manuelle Tests und die Abteilung für automatische Tests unabhängig voneinander. Sie teilen jedoch die Testszenarien, um eine größtmögliche Testabdeckung der Anwendung zu gewährleisten. Die Testszenarien sind streng definiert. Auf diese Weise können alle genannten Teams effektiv zur Qualität der endgültigen Anwendung beitragen.

Aufgrund der erwarteten hohen Qualität der Software sind die Tests ein zentraler Bestandteil des gesamten Prozesses. Abweichend von der TDD-Methode (Test-Driven Development), verwenden wir modifiziertes BDD (Behaviour-Driven Development). „Modifiziert“ – weil wir meinen, dass nicht nur die Entwicklung der Software dem erwarteten Verhalten des Systems untergeordnet werden sollte, sondern vielmehr alle Prozesse, die den Softwareanbieter mit dem Kunden verbinden.

Darum sprechen wir lieber von der verhaltensgetriebenen Beziehung oder Behaviour Driven Relation (BDR).

Bei der BDR gehen wir davon aus, dass sich alle Beziehungen zwischen uns – als Lieferant – und dem Kunden auf die spezifischen Funktionen/Verhaltensweisen der vom Kunden erwarteten Anwendung konzentrieren sollten. Darüber hinaus sollten diese Anforderungen in der Geschäftssprache formuliert werden, die für den Kunden am leichtesten zu verstehen ist. Dies ist ein klarer Bezug auf die DDD-Vision (Domain-Driven Design).

Aus unserer langjährigen Erfahrung wissen wir, dass es den Kunden in der Regel leichter fällt, an konkreten Beispiele zu beschreiben, wie eine Anwendung funktionieren soll, als ihre genaue Funktionsweise zu definieren, wie es in der „klassischen“ Analyse der Fall ist. Solche Beispiele für die Funktionsweise eines Systems können ein hervorragender Input für die Softwareentwicklung, eine Testspezifikation (für manuelle oder automatische Tests) oder sogar eine exzellente Ergänzung der Dokumentation sein (weil sie in einer Sprache und mit Begriffen verfasst werden, die der Kunde versteht).

Das bedeutet, dass wir das Verhalten eines Systems bereits in der Phase der Spezifizierung der Anforderungen für das System oder, enger gefasst – einen Meilenstein, einen Sprint oder sogar eine einzelne Funktion definieren, z. B. in der Gherkin-Sprache. Sobald wir wissen, wie sich die Anwendung verhalten soll, können wir bereits in der Analyse-/Entwurfsphase die entsprechenden Absprachen und Vereinbarungen mit dem Kunden auf eine ganz andere Art und Weise treffen. Dies ändert unsere Beziehungen zum Kunden radikal – die Absprachen betreffen jetzt nicht mehr eine einzelne Lieferung, sondern vielmehr eine bestimmte Funktionalität oder ein bestimmtes Verhalten, das der Kunde vom geschäftlichen Gesichtspunkt aus erwartet. Wir kommunizieren mit den Kunden nicht nur in der für das Software-Engineering typischen Sprache mit Begriffen wie “Deliverables”, “Sprints” oder “Backlog”, sondern vor allem in einer Sprache, die die spezifischen Effekte beschreibt, die unsere Kunden mit einer Anwendung erzielen wollen.

Dadurch verwandelt sich die typische Anbieter-Kunden-Beziehung in eine echte Partnerschaft, in der sich beide Parteien auf das Verhalten des Systems konzentrieren und seine Qualität zur obersten Priorität machen.

Koordination der Arbeiten/Wissensaustausch, KundendienstMEHR

Um sicherzustellen, dass die Arbeiten trotz der vielen Angelegenheiten, die bei jedem Projekt zu bewältigen sind, gut koordiniert werden, nutzen wir seit vielen Jahren die Lösungen des global führenden Unternehmens Atlassian:

  • Jira ist unser Schlüsselsystem für die Definition von Aufgaben, die Überwachung des Entwicklungsprozesses und der Arbeitsabläufe, die Definition von Anforderungen und sogar die Kommunikation mit den Kunden in der Phase der Absprachen und der Systementwicklung. Wir verwenden Jira für ein umfassendes Projektmanagement und zur Gewährleistung der rechtzeitigen Fertigstellung der einzelnen Aufträge ohne Qualitätseinbußen.
  • Confluence ist unser Schlüsselsystem für die Erstellung, Speicherung und Bereitstellung von Wissen. Wir verwenden es sowohl für das Wissen über das jeweilige System (für die Erstellung und Aktualisierung diverser Arten von Dokumentationen) als auch für das Betriebswissen (Verfahren der Zusammenarbeit, interne Regelungen usw.). Es ist ein spezialisierter Kollaborationsserver, den die Projektgruppen zur Erstellung und zum Austausch von Dokumenten, Ideen und Wissen nutzen können. Das Ergebnis der Implementierung ist ein internes Portal, in dem Dokumentationen gespeichert und Wissen im Zusammenhang mit spezifischen Aufträgen für Kunden ausgetauscht werden können, aufgeschlüsselt in Einzelfälle und deren Geschichte.

Diese beiden Werkzeuge werden durch eine Reihe von Plug-ins ergänzt, die diese Funktionalität um die notwendigen Elemente ergänzen (z. B. Arbeitszeitabrechnung, Definition von Tests usw.).

Wir bieten unseren Kunden die volle Betreuung des entwickelten und implementierten Systems, einschließlich:

  • der Bereitschaft zur Erbringung und Gewährleistung von Garantiedienstleistungen bestehend in der Fehlerbehebung und der technischen Unterstützung des Systems,
  • der Bereitschaft zur Erbringung jeglicher Dienstleistungen nach der Garantiezeit zwecks der Modifikation und Weiterentwicklung des Systems.
  • Um unseren Kunden Transparenz und einen erstklassigen Kundendienst zu gewährleisten, stellen wir ihnen ein in Jira integriertes, sehr intuitives Internet-Ticketsystem – dmt@work – zu Verfügung, das nicht nur zur Registrierung und Verfolgung des Fortschritts eines bestimmten Auftrags, sondern auch für den wechselseitigen Austausch von Informationen, Beobachtungen und Kommentaren zur jeweiligen Fragestellung in jeder Phase genutzt werden kann. dmt@work erfüllt somit in unserer Firma die Rolle einer interaktiven und dynamischen Plattform für die tägliche Zusammenarbeit und den Informationsaustausch zwischen dem dmt-Team und unseren Kunden.

Geh hinauf