Wessen Code sollte für die Software sein, die Sie drucken?

Arbeitsbildschirm und geliefertes Produkt sind nicht identisch

Stellen Sie sich vor, dass für Ihr Unternehmen eine Ausschreibungsanwendung entwickelt wurde. Mitarbeiter melden sich an, wählen Produkte aus und erhalten ein PDF. Im täglichen Gebrauch scheint es, als wäre die Arbeit erledigt. Wenn jedoch der Entwickler, der die Preistabelle ändern wird, das Unternehmen verlässt, ist noch nicht bekannt, ob ein anderes Team die Anwendung ausführen kann. An dieser Stelle wird das Problem mit dem Quellcode wichtig. Besprechen Sie zu Beginn des Projekts die Möglichkeiten, den Bildschirm zu nutzen, die Software zu ändern und sie an einem anderen Ort separat auszuführen. Behandeln Sie diese nicht als Einsendungen, die dasselbe bedeuten; Machen Sie deutlich, welche Datei und welches Dokument für jeden von ihnen bereitgestellt wird.

Dieser Artikel bestimmt nicht den rechtlichen Ausgang eines Vertrags. Der Umfang der Rechte bemisst sich nach der Vereinbarung, den eingesetzten Bestandteilen und dem anwendbaren Recht. Überprüfen Sie die Vertragsklauseln bei Bedarf mit einem Rechtsexperten. Das Einzige, was technisch möglich ist, besteht darin, die erwarteten Ergebnisse in eine verständliche Liste zu übersetzen. Welcher Teil wird speziell für Sie entwickelt, welcher Teil wird als vorgefertigter Service genutzt und welcher Teil basiert auf einer Bibliothek eines Drittanbieters? Ohne diese Unterscheidung kann es irreführend sein anzunehmen, dass der gesamte Code mit derselben Bedingung geliefert wird.

Bestimmt das von Ihnen benötigte Liefermodell

Bei einem vorgefertigten Abonnementdienst kann vom Anbieter nicht erwartet werden, dass er den Quellcode liefert. Stattdessen werden Datenexport, Zugriff bei Dienstende und Integrationsmöglichkeiten evaluiert. Im konkreten Anwendungsfall kann es erforderlich sein, dass die Schweißwanne, die Einbaubeschreibung und die Änderungsbedingungen im Lieferumfang enthalten sind. Beide Modelle erfüllen unterschiedliche Anforderungen. Treffen Sie Ihre Entscheidung nicht allein auf der Grundlage des Anfangspreises. Wenn die Anwendung das Kerngeschäft des Unternehmens ausführt, ist die Notwendigkeit, mit einem anderen Anbieter fortzufahren, möglicherweise offensichtlicher.

Die angeforderte Lieferung sollte mit dem Projektumfang kompatibel sein. Wenn Sie beispielsweise die Bildschirme der Anwendung für Sie schreiben lassen, können Sie die interne Software des Cloud-Dienstes nicht verwenden. Möglicherweise möchten Sie jedoch dokumentieren, welche Daten an diesen Dienst gesendet wurden und wie die Verbindung hergestellt wurde. Anstatt davon auszugehen, dass eine Lieferung, die nicht im Angebot enthalten ist, später automatisch erfolgt, klären Sie die Frage schriftlich.

Welche Informationen sollten neben dem Code enthalten sein?

Die Quelldateien in einem Ordner zu haben, ist ein guter Anfang; Allein reicht für eine nachhaltige Lieferung nicht aus. Welche Version des Codes ist live, welches Entwicklungstool wird verwendet und wie werden Abhängigkeitsversionen behoben? Die Namen der Konfigurationsvariablen, ihre Instanzwerte und die sichere Bereitstellungsmethode sollten dokumentiert werden. Tatsächliche Passwörter oder Schlüssel sollten nicht im Code-Repository abgelegt werden. Das neue Team sollte in der Lage sein, die Anwendung zu installieren, indem es die Geheimnisse in einem separaten, autorisierten Prozess erlangt. Die eindeutige Angabe vertraulicher Informationen über die Produktionsumgebung im Lieferdokument erleichtert die Lieferung nicht; schafft ein neues Risiko.

Datenbankstruktur, Installationsschritte, Beispieltestdaten und Anweisungen zur Backup-Wiederherstellung sollten ebenfalls im Paket enthalten sein. Speichern Sie geplante Aufgaben, externe Dienstverbindungen und Dateispeicherorte. Diese Anforderung muss bekannt sein, wenn ein Bericht nur mit der Schriftart auf einem bestimmten Server generiert wird. Beschreiben Sie außerdem die Benutzerrollen und Aktionen, die der Administrator ausführen kann. Diese Dokumente müssen nicht jedes Detail der Anwendung in einem langen Buch beschreiben; Das neue Team muss umfassende Informationen zum sicheren Betrieb des Systems bereitstellen.

Separate Abhängigkeiten und Nutzungsbedingungen

Die Anwendung verwendet möglicherweise eine Open-Source-Bibliothek, eine kostenpflichtige Komponente oder ein gemeinsam genutztes Modul des Anbieters. Ihre Nutzungsbedingungen sind nicht identisch. Führen Sie eine Bestandsaufnahme des Komponentennamens, der Version, der Lizenzquelle und der Erneuerungsanforderungen. Wenn im Konto des Entwicklers eine kostenpflichtige Komponente registriert ist, erkundigen Sie sich vorab, wie diese im neuen Team verwendet werden soll. Der Kauf bedeutet nicht unbedingt eine unbegrenzte Übertragung oder Nutzung in jeder Umgebung. Überprüfen Sie den entsprechenden Zustand anhand des tatsächlichen Lizenzdokuments. Treffen Sie Ihre Entscheidung nicht auf der Grundlage allgemeiner Annahmen.

Die Aufbewahrung des Code-Repositorys in einem Geschäftskonto kann den Zugriff erleichtern; Der Besitz eines Accounts allein erklärt nicht alle Nutzungsrechte. Welche Beiträge der Entwickler erbringt und welche Grenzen bestehen, sollte im Vertrag ersichtlich sein. Ebenso sollten das Dateneigentum und die Möglichkeit zur Datenmigration getrennt vom Code gehandhabt werden. Wenn Sie Kundendatensätze beim Wechsel zu einem neuen Team nicht exportieren können, kann es sein, dass Sie Probleme bei der Migration haben, selbst wenn der Code bereitgestellt wurde. Datenübertragung zwischen Systemen also in den Lieferplan einbeziehen.

Überprüfen Sie die Lieferung mit einem kleinen Abnahmetest

Richten Sie am Ende des Projekts eine saubere Testumgebung ein, anstatt nur Dateien zu zählen. Führen Sie die Anwendung mithilfe des Lieferdokuments aus, melden Sie sich mit dem Beispielbenutzer an und führen Sie einen grundlegenden Vorgang aus. Stellen Sie dann die Sicherung wieder her und exportieren Sie die Beispieldaten. Wenn während des Prozesses ein Schritt erforderlich ist, der nicht im Dokument enthalten ist, fügen Sie ihn hinzu. Führen Sie Tests durch, ohne Produktionsdaten zu verbreiten und das Live-System zu ändern. Somit ist der Unterschied zwischen der Auslieferung der Datei und der Nutzbarkeit der Auslieferung deutlich erkennbar.

Halten Sie die Repository-Adresse, die Lieferversion, das Installationsrezept, das Abhängigkeitsinventar, den Datenexport, den Betreuer und die Trennungsschritte in der endgültigen Checkliste zusammen. Diese Liste wird aktualisiert, wenn Änderungen vorgenommen werden. Das Ziel besteht nicht darin, für alle Projekte denselben Vertrag zu verwenden, sondern darin, die Lieferung zu definieren, die Ihr Unternehmen unterstützt. Wenn das zu Beginn besprochene Modell, Angebot und Abnahmeprotokoll zueinander passen, wird der Lieferantenwechsel zu einer verständlicheren technischen Aufgabe.

Häufig gestellte Fragen

Reicht es aus, nur den Quellcode zu erhalten?

Nein. Installationsdokumentation, Abhängigkeiten, ordnungsgemäße Nutzungsbedingungen und die Überprüfung der Ausführung in einer sauberen Umgebung sind ebenfalls erforderlich.

Wird in jeder Software eine Codebereitstellung erwartet?

Das Liefermodell des vorgefertigten Abonnementdienstes und der speziell für Sie entwickelten Software kann unterschiedlich sein. Legen Sie Modell und Umfang im Vertrag klar fest.

Wie teste ich einen Lieferantenwechsel?

Beziehen Sie in die Abnahmetests ein, dass ein neues autorisiertes Team die Testumgebung mit dem Lieferpaket einrichtet und die Beispieldaten exportiert.