序文の代わりに
そしてまた、良い一日！ソフトウェア構成管理の基本に関する一連のメモを続けます。 前の2つのシリーズの要約を長い間語り直さないために、それらへのリンクを提供します。
- ソフトウェア構成管理の基本に関する一連の記事 。 SMとは何か、そのタスクとは何か、プロジェクトCMエンジニアの責任は何か。
- ソフトウェア構成管理//構成とベースライン 。 SCMの観点から機能する製品とは何か、構成とは何か、それはどのように安定化されるのか、また基本的な構成は何なのか-ベースライン。
変更要求の追跡
まず、プロジェクトでどのように変更が行われますか？ いくつかのオプションのみがあります。
- 新しい製品機能が作成されます。
- 計画的な改善（リファクタリングなど）中の機能または内部構造の変更。
- 見つかったエラーは修正されます。
すべての作業成果物は変更できます-ソースコードと要件、テストの両方である可能性があります-一般に、以前の資料にリストされたすべてのものです。 このすべての変更、および変更を制御する必要があることが重要です。
変更のタイプと製品に応じて、彼の要求のソースも異なります。 新しい機能の場合は、マネージャーまたはエンドユーザーのいずれかである可能性が高くなります。 リファクタリングでは、技術マネージャーまたはプロジェクト開発者。 エラーを修正するとき-システムのすべてのユーザーが、原則として、これはテスターです。
したがって、変化の必要性があり、この必要性を表明する人がいます。 動き始めます。 移動の開始は、変更要求を送信することです。 変更要求は、製品改善提案であり、変更要求追跡システムのエントリとして表されます。 英語のソースでは、このような要求は変更要求（CR）と呼ばれます 。 問題または変更要求（PCR）という用語も見つかります。 将来的には、略語CR （「siar」と読みます）を使用します。
同様に、変更要求追跡システムは、製品変更の提案を記録し、それらに対する責任を管理できるソフトウェア環境です。 用語チェーン全体のキーワードは、 要求、変更、および責任追跡です。 ロシア語のソースでは、 「エラー追跡システム」という用語がよく使用されます。 英語の文献には、 変更要求管理システム、バグ追跡システム、問題追跡システムがあります。
原則として、データベースはそのようなシステムのリポジトリであり、1つのCRはその中の1つのレコード（多くの場合、関連するレコードのセット）です。 機関が以下の必要な情報を入手した後のCR：
- 誰が記録を開始したか（送信者）;
- レコードの短い名前（サブジェクト）;
- 変更可能なシステムの使用バージョン。
- 要求または問題の詳細な説明。
- システムの予想される動作の説明（エラーの場合）。
- ソフトウェアおよびハードウェア構成。
- システム操作ログの断片（「ログ」）。
- 有限状態マシン（状態マシン）。各状態は、独自のフィールドセットによって特徴付けられます。
- 作業が進むにつれて、既存のフィールドの内容が変更され、コメントが追加されるレコード。
典型的なシナリオを見てみましょう。 記録が開始されました。作業を開始する必要があります。 ただし、制御不能な変更は行わないでください。 したがって、作業を開始する前に、管理者の承認を取得する必要があります。管理者は、変更要求の影響を受ける機能を担当します。 管理ロールは、プロジェクト内のプロジェクトの変更を管理する権限を持つグループである構成管理委員会によって実行されます。 変更管理委員会という用語とCCBという略語も時々使用されます。
簡単なスクリプト
さらに作業を進めるために、ステートマシンの形で追跡システムを使用します。これはより明白です。 スキーム1の一連の状態は必要最小限であり、より大きなサイズに拡張し、いくつかのライフサイクルパターンに分割できます。 詳細については、このセットを使用します。
図1.変更要求のライフサイクル
レコードが該当する最初の状態は最初の状態です。 添付の図では、これはNewです。 この時点で、レコードの作成者は、設計開発プロセスに必要なすべての初期データを導入します。 次に、CRがCCBに表示されます。 どの開発者が問題を解決するかを決定します。
CRを機能させるために、レコードは次の状態- 割り当て済み （「担当者に割り当て済み」）に転送されます。 同時に、レコードは開発者に「割り当て」られます。つまり、 彼は彼女に責任を負います。
ただし、誰かにタスクを割り当てても、タスクがすぐに解決され始めるわけではありません。 結局のところ、複数のタスクを1人の開発者に割り当てることができます-1つは他の開発者よりも重要であり、すべてを昨日行う必要があります。 そのため、開発者が実際にタスクに従事し始めると、レコードはオープン状態（「作業開始」）になります。 作業を追跡するCCBは、タスクが循環することを確認します。 タスク自体は、原則として、開発者に「割り当てられた」ままです。
作業の過程で、責任者はコードの所有者に応じて変わる可能性があり、これはCRで説明されている動作に影響します。 再マッピングはCCBを行います。 さらに、問題が既に誰かによって発見されており、そのCRが開始されていることが判明する場合があります。 この場合、問題は複製されます。 閉じられ、対応するフィールドに以前に確立されたレコードの番号が追加されます。 この時点から、レコードはクローズされたと見なされます。 また、説明されている問題は作業のエラーではない（つまり、WADであり、設計どおりに動作する）か、要求された機能をさまざまな理由で実装できないことが判明する場合があります。 この場合、レコードは終了します 。 問題の作業が継続しない理由についてのコメントで締めくくります。
それにもかかわらず、作業が継続する場合、遅かれ早かれ終了します。開発者は必要な変更を加え、さらに統合する準備を整えます。 この時点で、彼はレコードを解決済み状態（「修正済み 」または「解決策が見つかりました」）にします。 このステップで、ソリューションに任命された人は責任を軽減し、彼の意見では問題を解決する必要がある変更を示します。 この状態では、CCBは再び担当者を任命する必要があります。 彼は、CRで設定されたタスクが実際に正しく解決され、すべてが少なくとも以前と同様に機能することを確認します。 したがって、この段階で、テスターまたはレコードの作成者のいずれかが任命されます。 予約後、多くの場合リクエストの作成者である検証者（ "verifier" 、 "verifier"）が検証を開始します。 結果は2つの結果です。
- 問題が解決しない場合の初期化。
- バグが修正された場合、またはリクエストに記載されている新しい機能が機能している場合は、 クローズ状態に移行します。
実装と微調整について
ところで、変更要求追跡システムは、プロジェクトの割り当ておよび追跡システムとしても使用されることを追加する価値があります。 結局のところ、プロジェクトで発生するタスクには、管理者による監視が必要です。 そして、ほとんどのタスクの結果は、再び、ある種の変化です。 したがって、すべての目的で1つのシステムを使用するのが論理的です。 タスク追跡システムは、一般的にヘルプデスクとも呼ばれます 。 ただし、意味はこれから変わることはありません。変更要求追跡システムとしても分類します。
提案されたライフサイクルが何らかの理由で適切でない場合、ほとんどの追跡システムでは、日常のタスクを解決するのに必要なだけ、このサイクルを変更してそのタイプをいくつか作成できます。 ちなみに、これが新しい機能の開発を追跡し、バグを修正するプロセスを追跡するために別のテンプレートを作成することが多い理由です。 新機能の開発には要件、設計、テストの開発も必要であるという理由だけで、このために、リストされた目的のために中間状態またはフィールドが導入されています。
私の意見では、作業のサイクルを柔軟に設定できるシステムを選択する必要があります。 少なくとも、誰かの未知の作業計画によって一度定められたことが、あなたのプロジェクトの教義にならないようにするためです。 時間が経つにつれて、ツールの制限のためにそれを超えることは難しくなり、プロジェクトは「混雑」し始めます。 柔軟なカスタマイズが私たちの選択です！
変更要求を追跡するシステムの実装は、世界中のプログラマーのお気に入りの娯楽です。 誰かが彼のシステムが確かにすべての利用可能なものを食い止めると信じています。 残りの部分では、彼が必要としているものから何かが抜けていると誰かが確信しています。 そして、誰かが自分の喜びのためにそれをします。 それぞれに-彼自身。 誰かが自分の二輪車を発明したくない場合、彼は既存の自転車公園に精通することができます。 さて、そのタスクに最適な自転車を選んでください。 ところで、著者は偶然 、上記のリストで言及したeTraxisの開発に参加しました。 この機会にぜひお勧めします。
しかし、CMエンジニアはどうでしょうか？
変更要求は追跡することを学びました。 CMプロジェクトエンジニアの役割は何ですか？ 彼らは以下を担当します：
- 開発プロセスにおける追跡システムの実装。
- これらのシステムの使用に関するポリシーの開発。
- 確立されたルールの実装を監視します。
多くのコピーが最初のタスクで故障します-多くのシステムがあり、最適なものを選択する必要があります。 このケースにはいくつかのヒントがありますが、関連資料も作成されています...しかし、それは少し後に公開されますので、お楽しみに:)
視野を広げるリンク
- http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems-変更要求会計システムの比較。
- http://www.etraxis.org/-作成者が積極的に参加したリクエスト追跡システム。
- 以前の記事のリンクも参照してください。それらへのリンクは、ノートの冒頭にあります。
次の部分では、おそらくSCMプラクティスの最も重要な兆候であるバージョン管理について説明します。 ところで、変更要求の追跡はそこで再び影響を受けます-それなしでは、どこにもありません。
だから、継続する。