コードが破損したり、クライアントの手や神の行動の外で異常が発生したりした場合に、契約に保証条項を保証または追加する必要がありますか？

もしそうなら、その言語は何を言うべきですか？

クライアントが何らかの保証を要求しない限り、保証を提供しないでください。多くのクライアントは、あなたを年季奉公に強制するためにそれを使用することになります。

彼らはそれを要求する場合でも、弁護士に相談してください。それ以外の場合は、大惨事に備えています。

コードが破損したり、クライアントの手や神の行動の外で異常が発生したりした場合に、契約に保証条項を保証または追加する必要がありますか？

いいえ、決して

必要に応じて、仕事をしないでください。これはあり得ない状況です。コードが壊れたり、機能しなくなったりする可能性がある変更可能な項目のリストに終わりはありません。

無料で作業するのが好きでない限り、次に進みましょう。

これに対応する標準的な方法は、サポートまたはメンテナンス条項を追加することです-「最初の10時間の作業は無料で含まれ、残りは次のレートで利用できます：」。

私はAdamの「やらない」を賛成しましたが、商用ソフトウェア製品にそのような保証を提供することは、顧客から多くの好意的な注目を集めるかもしれません。また、他の業界と比較して巨大なコジョーネがあったこともわかります。:-)

次の状況では、保証の提供を検討する場合があります。

• 他の人のための仕事のための仕事とは対照的に、それは私の製品です。
• 仕様、プログラミング、テスト、ドキュメントなど、ソフトウェアの開発とリリースのプロセス全体を管理しました。
• 保証が適用されるソフトウェアを実行できる状況をドキュメントで注意深く指定しました。たとえば、ハードウェア要件、OSエミュレーターでの実行なしなど。
• 保証期間を限定しました。
• ソフトウェアの品質には本当に自信があった

その場合、「購入日から1年間、ユーザーマニュアルに記載されているようにソフトウェアが実質的に実行されない場合、修正して無料で発行することを保証します。更新。"

それは多くの保証のようには聞こえませんが、ほとんどの商用ソフトウェアが持っているよりもはるかに多く、バグを修正することを顧客に安心させます。

それが誰かのための契約プログラミングなら、それを忘れてください。私はかつてそのような状況に陥り、WindowsプログラムをMacに移植し、契約に署名する前にクライアントが都合よく言及しなかったWindowsバージョンの実際に隠された機能である「バグ」を修正するために数万ドルを失いました、私たちは繰り返しスペックを求めてきましたが。その経験は、定額契約をやめる主な理由の1つでした。

プロジェクト終了後の特定の期間（たとえば3〜6か月）は、バグ修正を含む保証を提供するのが一般的です。これは、あなたがあなたのコードの後ろに立っていることをクライアントに言います、そして率直に言って、あなたはあなたのコードで提供する問題に対していくらかの責任を負うべきです。

私たちのプロジェクトで私たちが通常行うことは、重大度のレベルに応じてバグとは何かを修正するためのスケジュールとバグを定義するSLA（サービスレベルアグリーメント）を提供することです。たとえば、ライブプロジェクトの重大な問題は、レポートを受け取ってから1時間以内に解決する（少なくとも試行する）必要があります。視覚的な問題と小さなバグは48時間以内に解決されます。

バグが何であるかを明確に定義することは非常に重要です-クライアントはしばしばバグレポートとして（時には意図せずに）新しい機能で作業を試みるためです。これらの定義は常にいくらか解釈に対して開放的であるため、意見の相違を調停できる調停者（通常は開発言語/プラットフォームの権限）を割り当てる必要があります。

契約の文言には、次のようなものを記載する必要があります。

1. このコードを拡張することはできません
2. このコードをリバースエンジニアリングすることはできません
3. このコードをフレームワークに統合することはできません（＃1と同様ですが、ビジネスのレイヤー全体になるという点で異なります）。
4. このコードを他のオペレーティングシステムに移植することはできません（UNIXへのIEウィンドウ）

考えられるのはほんの少しです。