web-dev-qa-db-ja.com

アウトソーシングするときに適切なSoftware Deliveryガイドラインは何ですか？

私は非常に小さな会社で働き始めましたが、ソフトウェア開発を定期的に（あまり頻繁にではなく）アウトソーシングする必要があります。外部サプライヤーは、何かを提供する必要があります。私が今見たように、サプライヤは非常にさまざまな品質の成果物を提供します-これは、バイナリ実行可能ファイル（ソースなし）、ドキュメントの欠如、インターフェースの説明などをカバーする場合があります...
私は現在ソフトウェアの専門家ではないので、これをベースラインにしたいので、契約などに使用できるある種の標準/一般的なベストプラクティスを探しています。 ：

  • 実行可能ファイル
  • ソースコード
  • ツールチェーンの説明（コードのビルド方法のリファレンス）
  • ドキュメンテーション
  • インターフェースの説明
  • 一般的なコーディング標準（おそらくMISAR XYほど具体的ではないもの）

..そして（言及された点で）そのための最小値は何ですか-そして何が欠けていますか。その種のソフトウェア配信ガイドラインに利用できるIEEE/RFC/ITF標準はありますか？
私の最後の会社では、契約/サプライヤーごとにこの種のドキュメント（必要なドキュメント/成果物のリスト）を作成しているそのトピックに取り組んでいる専門家がいました。

licensingdevelopment-processcoding-standardsstandardscontract
3
m.weiloa

私はそのような基準を知りません。

最終的には、下請業者は、契約を結んでいるものは何でも提供する必要があります。ドキュメンテーションが必要な場合は、契約書にそのように書かれているはずです。同じことがソースコード、デザイン、その他にも当てはまります。

したがって、提供されるものに満足できない場合は、提供するように契約したものをよく見て、（会社として）下請けプロセスが十分に堅牢であるかどうかを自問してください。

バイナリといくつかのリリースノート以外のものを提供することは、下請業者の利益にはなりません。彼らがあなたにすべてを与えるなら、あなたは改善のために彼らを支払うのではなく、あなた自身で更新をすることができます。

2
Simon B

私の知る限り、これに関する標準はありませんが、会社のニーズに合わせてソフトウェアのベースラインを確実にサポートする必要があります。

基本的なプロジェクト構造も確立し、プロジェクトとその使用方法をよりよく整理することをお勧めします。

project root 
  \_ source
       \_ build.sh / build.bat
  \_ bin
      \_ project executable
      \_ resources
  \_ doc

Build.shまたはbuild.batを起動すると、binフォルダーにproject.exeが生成され、実行可能ファイルにはそれに応じた名前が付けられます。他の実行可能ファイルは、必要に応じて存在することができます。ソースフォルダは、開発チームにとって最も便利な方法で整理できます。同様に、binフォルダーは、実行可能ファイルに耐えながら、開発チームにとって最も便利な方法で編成できます。

Resourcesフォルダーは、実行可能ファイルが機能するために必要な追加のライブラリーまたは参照ファイルを提供するためのものです。

Docフォルダーは、基本的な使用法と呼び出し方法を提供するためのものです。追加の技術ドキュメントも追加できますが、基本的な呼び出しの使用法が存在している必要があります（ビルドの現在のバージョンを反映している必要があります）。実装するインターフェースがある場合は、そのインターフェースとその使用方法に関する完全なドキュメントが必要です。 （アクセスを容易にするために）各APIインターフェースごとに1つのそのようなドキュメント。

これを少し変更するのは自由ですが、このようなものは優れた基盤であり、開発者にとって柔軟性があります。

あなたへのいくつかのヒント、私は必然的にソースコードが毎回存在することを要求するでしょう。あなたの会社がソフトウェアの作成にお金を払っている場合、ソフトウェアコードはあなたがそれを完全にゼロから再作成することを可能にし、それを要求するのはあなたの権利です。

さらに別の言い方をすると、このサードパーティを信頼しない場合は、最初に実行可能ファイルが存在せず、毎回builtであることを主張する必要があります。これには時間がかかり、不便だと彼らは主張するかもしれませんが、プログラムがビルドされるソースコードに対応していることを保証するものです。

1
Neil