印刷するソフトウェアには誰のコードを使用する必要がありますか?

動作画面と納品された製品が異なります

あなたの会社用に入札アプリケーションが開発されたと想像してください。従業員はログインして製品を選択し、PDF を受け取ります。日常的な使用という点では、仕事は終わったように見えるかもしれません。ただし、価格表を変更する開発者が去った場合、別のチームがアプリケーションを実行できるかどうかはまだわかりません。この時点でソースコードの問題が重要になります。プロジェクトの開始時に、画面の使用、ソフトウェアの変更、別の場所での実行の可能性について個別に話し合います。これらを同じ意味の提出物として扱わないでください。それぞれにどのファイルとどのドキュメントが与えられるかを明確にしてください。

この記事は、契約の法的結果を決定するものではありません。権利の範囲は、契約、使用されるコンポーネント、適用法に従って評価されます。必要に応じて、法律の専門家と契約条項を確認してください。技術的にできる唯一のことは、期待される成果物をわかりやすいリストに変換することです。どの部分が自社専用に開発され、どの部分が既製のサービスとして使用され、どの部分がサードパーティのライブラリに基づいていますか?この区別がないと、すべてのコードが同じ条件で配信されると誤解される可能性があります。

必要な配信モデルを決定します

既製のサブスクリプション サービスでは、プロバイダーがソース コードを提供することを期待していない場合があります。代わりに、データのエクスポート、サービス終了時のアクセス、統合の可能性が評価されます。お客様の特定の用途では、溶接タンク、設置の説明、および変更条件を納入範囲に含めることが要求される場合があります。どちらのモデルも異なる要件を満たしています。初期価格だけで判断しないでください。アプリケーションが企業の中核ビジネスを実行している場合、別のベンダーと継続できる必要性がより明らかになる可能性があります。

要求された納品はプロジェクトの範囲と互換性がある必要があります。例えば、アプリケーションの画面を書いてもらっても、クラウドサービスの内部ソフトウェアを使ってもらうことはできません。ただし、どのようなデータがそのサービスに送信されたか、および接続がどのように確立されたかを文書化したい場合があります。 オファーに含まれていない納品が後で自動的に行われると想定するのではなく、質問を書面で明確にしてください。

コードの横にどのような情報を含める必要がありますか?

ソース ファイルをフォルダーに入れるのが良いスタートです。それだけでは持続可能な配送には不十分です。コードのどのバージョンがライブであり、どの開発ツールが使用されていますか? 依存関係のバージョンはどのように修正されていますか?構成変数の名前、そのインスタンス値、およびプロビジョニングの安全な方法を文書化する必要があります。実際のパスワードやキーをコード リポジトリに配置しないでください。新しいチームは、別の承認されたプロセスでシークレットを取得することで、アプリケーションをインストールできる必要があります。本番環境に関する機密情報を納品文書に明確に記載しても、納品は容易になりません。新たなリスクを生み出します。

データベース構造、インストール手順、サンプル テスト データ、バックアップ リカバリ手順もパッケージに含まれている必要があります。スケジュールされたタスク、外部サービス接続、ファイルの保存場所を保存します。特定のサーバー上のフォントのみを使用してレポートが生成される場合は、この要件を知っておく必要があります。また、ユーザーの役割と管理者が実行できるアクションについても説明します。これらの文書は、アプリケーションの詳細をすべて長い本で説明する必要はありません。新しいチームは、システムを安全に運用する方法に関する完全な情報を提供する必要があります。

依存関係と使用条件を分離する

アプリケーションは、プロバイダーのオープンソース ライブラリ、有料コンポーネント、または共有モジュールを使用する場合があります。それらの利用条件は同じではありません。コンポーネント名、バージョン、ライセンス ソース、および更新要件のインベントリを管理します。開発者のアカウントに有料コンポーネントが登録されている場合は、新しいチームでの使用方法を事前に問い合わせてください。購入したからといって、必ずしも無制限に転送したり、あらゆる環境で使用できるわけではありません。実際のライセンス文書から関連条件を確認してください。一般的な仮定に基づいて決定を下さないでください。

コード リポジトリをビジネス アカウントに保持すると、アクセスが容易になる場合があります。アカウントの所有権だけでは、すべての使用権が説明されるわけではありません。開発者がどのような貢献を提供し、どのような制限が存在するかは契約で確認する必要があります。同様に、データの所有権とデータを移行する機能は、コードとは別に処理する必要があります。新しいチームに移行するときに顧客レコードをエクスポートできない場合は、コードが配信されていたとしても、移行で問題が発生する可能性があります。 システム間のデータ転送 なので、配送計画に含めてください。

簡単な受け入れテストで納品を検証する

プロジェクトの最後には、ファイルを数えるだけではなく、クリーンなテスト環境をセットアップします。配布ドキュメントを使用してアプリケーションを実行し、サンプル ユーザーでログインし、基本的な操作を完了します。次に、バックアップを復元し、サンプル データをエクスポートします。プロセス中にドキュメントに含まれていないステップが必要な場合は、追加します。運用データを配布したり、稼働中のシステムを変更したりすることなく、テストを実行します。したがって、配信中のファイルと使用可能な配信との違いが明確にわかります。

リポジトリ アドレス、配信バージョン、インストール レシピ、依存関係インベントリ、データ エクスポート、メンテナ、および切り離しの手順を最終チェックリストにまとめてください。このリストは、変更が行われると更新されます。目標は、すべてのプロジェクトで同じ契約を使用することではなく、ビジネスを維持するための納品方法を定義することです。冒頭で説明したモデル、オファー、受け入れ記録が一致すると、サプライヤーの変更はより理解しやすい技術的なタスクになります。

よくある質問

ソースコードを入手するだけで十分ですか?

いいえ。インストールに関するドキュメント、依存関係、適切な使用条件、クリーンな環境での実行の検証も必要です。

コードの配信はすべてのソフトウェアで期待されていますか?

既製のサブスクリプション サービスとお客様向けに特別に開発されたソフトウェアの配信モデルは異なる場合があります。契約書でモデルと範囲を明確に定義します。

サプライヤーの切り替えをテストするにはどうすればよいですか?

承認された新しいチームによる納品パッケージを使用したテスト環境のセットアップとサンプル データのエクスポートを受け入れテストに含めます。