SSI Software
Development

Als einzige Software Development Firma weltweit bieten wir unseren Kunden eine Probewoche, bzw. einen Probemonat mit unseren Entwicklern zu Sonderkonditionen an. Unser Ziel ist es, dass sich unser Kunde für uns entscheidet, weil wir exzellente Arbeit leisten und nicht weil wir ihn an Verträge binden.

Schon ein kleinstes Team kann gebucht und innerhalb einer Woche flexibel in der Größe angepasst werden. Buche jetzt einfach und schnell deinen kostenlosen Gesprächstermin und wir finden gemeinsam die perfekte Lösung für dich.

Wir liefern nicht nur Berater, Architekten, Software Entwickler und Tester, sondern auch DevOps, SecOps und MLOps. Grundsätzlich kann ein Entwickler auch für seinen Code langjährigen Service und Wartung übernehmen. Das ist ein Frage der Laufzeit des Vertrags. Sobald dann komplexe Applikationen auch innerhalb bestimmter Reaktionszeiten zu unterstützen sind, splitten unsere Kunden gerne das Entwicklerteam und stellen sich noch zum Entwicklerteam ein Service- und Supportteam auf. Das Support Team besteht oft aus DevOps und BackEnd-Entwicklern für den "1st Level Support" und "2nd Level Support". So ein Service- und Supportteam entlastet das Entwicklungsteam, welches dann den 3rd Level Support übernimmt und es kann sich sonst auf die Weiterentwicklung konzentrieren. StartUps neigen in der Regel dazu ihre Entwickler sowohl für die Produktentwicklung, als auch für Service- und Supportzwecke zu verwenden - das ist absolut "ok". Große Kunden haben bei uns auch 24/7 Service und Support Ressourcen gebucht, damit rund um die Uhr ein Mitarbeiter verfügbar ist und den Betrieb der Applikation sicherstellt.

Wir haben und betreiben auf der ganzen Welt eigene SSI Software-Entwicklungszentren. Dort haben wir einen „Pool“ an Mitarbeitern, z.Zt. ca. 500 Architekten, Entwickler und Tester. Aus diesem „Pool“ nehmen wir das, was unsere Kunden brauchen und stellen individuelle Teams zusammen. Falls wir mal eine Expertise nicht im Pool haben sollten, sucht unsere HR Abteilung nach dem richtigen Mitarbeiter und wir stellen ihn dann bei uns am Entwicklungszentrum ein.

Die Vertragsbedingungen legen unsere Verpflichtung zur Sicherung des geistigen Eigentums fest. Wir prüfen die Ressourcen und führen Hintergrund Überprüfungen durch. Ihr Vertrag enthält eine Vertraulichkeitsklausel. Die Teams besprechen keine geschützten Kundeninformationen miteinander.

Unser Büro ist rund um die Uhr durch Sicherheitspersonal gesichert, der Zugang wird durch biometrische Überprüfung kontrolliert und alles protokolliert. Sicherheitskameras zeichnen alle Aktivitäten auf. Die Rechner sind passwortgeschützt und nur befugte Personen haben Zugang. Server und Serverräume sind hinter Schloss und Riegel, und nur befugtes Personal hat Zugang. Die Aktivitäten auf den Wechseldatenträgern aller Rechner – sofern überhaupt vorhanden – werden überwacht und protokolliert. Serverräume/Cloud-Infrastruktur sind hinter Firewalls gesichert.

Ja, wir haben auch Data Scientisten, die mit den modernsten KI-Technologien arbeiten, abhängig ob wir Prozesse analysieren, Bilder erkennen oder mit Sprache und Text arbeiten.

Alle unsere Entwickler verwenden grundsätzlich "Clean Code" oder ähnliche Prinzipien zu Erstellung von intuitiv, verständlich und leicht zu änderbaren Code. Als Best Practices verwenden wir abhängig von Technologie, Architektur, Entwicklungsframeworks unterschiedliche Prozesse und Tools. "Clean Code" mit KISS und DRY Prinzipien ist zwar schon ziemlich "alt" wird aber bei uns gerne bei Front-End und App-Entwicklungen, z.B. mit IONOS verwendet. Das entscheidet der Kunde, so wie es in seine Technologie- und Tool Landschaft passt. Gerne sprechen wir auch eine Empfehlung aus. Dabei einigen wir uns dann meistens auch auf Code-Analyse Tools, z.B. den "ReSharper" der bei .NET und Azure Cloud Projekten schon beim Einchecken überwacht, ob die Entwickler diese Vorgaben eingehalten haben. Ob das manuell oder automatisch passiert hängt davon ab ob der Kunde ein hochautomatisiertes "Continuous Integration" oder "Continuous Deployment" mit "Nightly Builds" braucht, oder ob wir noch klassisch mit den Sprint Review Meetings das Ergebnis gemeinsam testen. Bei solchen hochautomatisierten Deployments wird die statische und dynamische Code-Analyse Teil einer Testautomatisierung. Man kann das bei kleinen Projekten aber selbstverständlich auch erstmal als Prinzip den Entwicklern zugrunde legen.