SCMに関する一連のメモを続けます 。 前回、 バージョン管理システムの使用に関するトピックが取り上げられました。 偶発者から得られる利点から判断すると、このトピックは多くの人に関連したままです。 一元化された分散制御システムを検討するために、バージョン管理に関する話を続けるつもりです。 しかし、その前に少し離れて、構成管理の正式な側面について少し話をして、一般的な理論的トピックを閉じます（そして、ホリバーに移ります）。
だから-正式化について。 先日、人々が彼らのプロジェクトでどのような指標を使用しているかを調べるために調査を実施しました。 怖かった。 一般的に何かを選択する（つまり、棄権しない）ことを決定した人のうち、 半分は単にメトリックを収集するだけでなく、そうではありません。 おそらく、文書化プロセスはさらに悪化します。
したがって、私は彼のプロジェクトがどこに向かっているのか、そしてチームがどの程度効率的に機能するのかについて少し考えている人たちに今日のメモに取り組んでいます。
メトリックコレクション
プロジェクトで起こっていることの全体像が彼の目の前で展開されるべきであるとき、マネージャーにとって何が重要ですか？ もちろん、これらは数字です。 状況を制御するために、リーダーは現在利用可能なものだけでなく、以前に利用可能であったものも確認する必要があります。 したがって、この全体的な見方を持っているだけで、プロジェクトの将来を予測し、タイミングを調整することができます-一般に、通常の管理活動を行います。
CMはそれと何の関係がありますか？ 彼が変更を制御するという事実にもかかわらず。 プロジェクトが成果物の変更であると考える場合、CMを介してプロジェクト全体のすべての変更がパスします。 したがって、管理者にプロジェクトの経時変化のビジョンを提供できるのは、まさにソフトウェア構成管理ツールです。 通常、このようなビジョンは数字で表されます。
CMエンジニアの手を介して毎日通過するものからどのような数値指標（ メトリック ）を取得できますか？
まず第一に、これはすべて製品変更要求の会計処理に関するものです。
- オープン/クローズ/インサービスリクエストの総数。
- 各参加者へのリクエストのセクション-誰が何に戸惑い、どのような仕事の状態にあるのか。
- さまざまな状態のリクエストに費やされる時間は、リクエストごとの平均時間です。
さらに、製品コードの行数やコンポーネントなど、コードに関する一般的な情報は常に興味深いものです。 通常、それらはCLOC、NCLOCでカウントされます。 変更に関するすべてに興味がある：
- 各リリースのデルタサイズ（LOC）。
- 個々の変更要求のデルタサイズ（ツールキットで許可されている場合）。
- 循環的複雑さ;
- 占有メモリサイズ（RAM、ROM）。
- 時間内の占有メモリの変化。
ところで、CMエンジニア自身が行った作業に関するレポートも興味深いかもしれません。
- 処理された統合リクエストの数。
- リリースの数。
- リリースにかかる平均時間はどれくらいですか。
もちろん、すべてのデータはテキストレポートの形式で提供されるだけでなく、さまざまな図の形式でも提供されます。幸いなことに、それらには多くの種類がありました。 さらに、多くの指標について、経時的な値の推移を追跡できます。
合計：メトリックの収集は、大規模プロジェクトのCMに不可欠な部分です。 小規模プロジェクトの場合、メトリックの収集は単純化されるか、無効化されます。 ただし、プロジェクト管理者が（コード内の）下位レベルで何が起こっているかを把握するほど、日常の作業をより効果的に構築できます。
CMアクティビティのドキュメント
プロジェクトのCMエンジニアによって確立されたすべてのポリシー、手順、およびルールは、プロジェクトのすべての参加者に伝達する必要があります。 この情報を提供する形式はそれほど重要ではありません。主なことは、情報を時間通りに提供し、誰でも常に利用できるようにすることです。 原則として、CMで記述され形式化されたすべてのものは、通常、「 プロジェクト構成管理計画 」という用語と組み合わされます 。 英語のソースでは、 SCMP-Software Configuration Management Planという略語を使用しています。
この計画では、プロジェクト構成管理が動作するすべてのものを説明します。 これには次の情報が含まれます。
- プロジェクト構成のすべての要素の説明：タイプ、配置、使用者、変更者。
- プロジェクトで使用されるツール。 目的を説明し、ダウンロードとインストールのリンクを提供します。
- 変更要求を追跡するためのシステムは、要求のライフサイクル、ユーザーグループ、その権利、使用規則など、個別に説明されています。 通常、グループの構成はシステム自体で決定されるため、ドキュメントにグループをリストする必要はありません。
- バージョン管理システムを使用する手順について説明します。 使用するツール、クライアントパーツのインストール手順、ユーザーグループ。 ブランチとラベルの命名形式を個別に説明します。これは、単純な開発者の観点から最も重要な部分の1つです。
- バージョン管理システムの対象ではないリリースおよびその他の要素のリポジトリが決定され、それらを操作する手順が説明されています。
- 構成の安定化と基本リリースのリリースのプロセスの説明が提供されます-誰がそれを開始し、どの手順が適用され、どこにあり、誰がリリースの責任を負いますか。 これには、メトリックのコレクションの説明も含まれます。
- プロジェクト内で複数のコンポーネントまたは製品ラインが開発されている場合、それらのCMアクティビティに固有の手順が説明されています。
SCMPは、個別のドキュメントとしても、開発チームの使用済みワークフローシステム（Wikiなど）の一連の出版物としても実行できます。 主なことは、情報が完全でタイムリーであり、エンドユーザーがアクセスできることです。
結論の代わりに
SCMの正式な側面、メトリック、およびドキュメントについては、上記で説明しました。 これが誰かに考える理由を与え、おそらく、正しい方向に何らかの動きをすることを願っています。
提供される情報は、1）生活と個人的な経験2） 標準SEI CMM / CMMIから取得されます。
質問してください。
まあ、全体としてのSCMについて-継続する。