ソフトウェア開発ライフサイクルデータ``テンプレート
ソフトウェア開発ライフサイクルデータ``テンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
ソフトウェア開発ライフサイクル属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
Activity
|
発生した特定の`プロセスステップ`または`イベント`の名前。例えば、「`課題`作成」や「`マージリクエスト`マージ済み」など。 | ||
|
説明
この
その重要性
取得元
GitLabのイベントストリーム内のイベントタイプと状態変更から導出されるか、またはIssueおよびマージリクエストの「created_at」、「merged_at」、「closed_at」などのタイムスタンプフィールドを解釈することによって導出されます。
例
問題作成開発開始マージリクエストマージ済み`パイプライン`失敗本番環境にデプロイ済み
|
|||
|
開始時刻
StartTime
|
アクティビティまたはイベントの開始時点を示すタイムスタンプ。 | ||
|
説明
この
その重要性
この
取得元
GitLabの様々なタイムスタンプフィールドから抽出されます。例えば、Issueの「created_at」、「updated_at」、「closed_at」、およびマージリクエストの「merged_at」などです。
例
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
開発項目
DevelopmentItem
|
機能、`バグ`修正、`タスク`など、`作業`単位の一意の`識別子`であり、主要な`ケース識別子`として機能します。 | ||
|
説明
開発 開発
その重要性
これは、すべての
取得元
これは通常、
例
1024512PRJ-2345
|
|||
|
`プロジェクト名`
ProjectName
|
開発`アイテム`が属する`GitLab``プロジェクト`の名前。 | ||
|
説明
この
その重要性
製品、アプリケーション、またはコンポーネント別にプロセス分析をセグメント化でき、対象を絞った改善活動を促進します。
取得元
例
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Assignee
Assignee
|
`イベント`発生時に`課題`または`マージリクエスト`に割り当てられたユーザー。 | ||
|
説明
その重要性
誰が作業を行ったかを追跡し、ワークロード分析、リソース割り当ての効率化、および引き継ぎによる遅延の特定を可能にします。
取得元
例
jdoeasmithr.williams
|
|||
|
終了日時
EndTime
|
アクティビティまたはイベントが完了した時点を示すタイムスタンプ。 | ||
|
説明
EndTimeは、アクティビティが終了した正確な日時を示します。GitLabの多くの原子的なイベント、例えば「Issue Created」では、EndTimeはStartTimeと同じです。期間を持つアクティビティ、例えば「Code Review」では、最終承認が与えられたときなど、完了のタイムスタンプを表します。 この属性は、個々のアクティビティの期間(処理時間)を正確に計算するために不可欠です。タスクで実際に作業した時間とタスク間の待機時間を区別することで、詳細なボトルネック分析に役立ちます。
その重要性
正確なアクティビティ期間(処理時間)の計算を可能にし、プロセスの非効率なステップを特定するための鍵となります。
取得元
アトミックな
例
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
重大度
Severity
|
開発`アイテム`の`重大度レベル`。通常は`バグ`や`インシデント`向けです。 | ||
|
説明
この
その重要性
作業の優先順位付けと、重大度の高い
取得元
GitLab Issueに適用された「ラベル」から導出されます。「S1」、「S2」のようなラベルを重要度レベルとして解釈するためのマッピングが必要です。
例
1 - Critical2 - High3 - Medium4 - Low
|
|||
|
開発項目タイプ
DevelopmentItemType
|
開発`アイテム`の分類。例えば、「機能」、「`バグ`」、「`タスク`」、「保守」など。 | ||
|
説明
この 開発
その重要性
取得元
通常、GitLabのIssueに適用される「ラベル」から導出されます。特定のラベルを標準化されたタイプに変換するためのマッピングロジックが必要です。
例
機能バグタスク`技術的負債`
|
|||
|
`パイプライン``ステータス`
PipelineStatus
|
`CI/CDパイプライン`実行の`ステータス`。例えば、「成功」、「失敗」、「実行中」など。 | ||
|
説明
この この
その重要性
自動ビルドとテストの成否を追跡し、手戻りループやコード品質、テスト自動化の問題点を浮き彫りにします。
取得元
例
success失敗runningキャンセル済み
|
|||
|
サイクルタイム
CycleTime
|
開発`アイテム`の最初のアクティビティから最後のアクティビティまでの経過総時間。 | ||
|
説明
サイクルタイムは、ケースの合計期間を測定する計算されたメトリックです。通常、単一の開発項目について、最初のイベント(例:「Issue Created」)と最後のイベント(例:「Deployed to Production」)の間の時間差として計算されます。 これは、全体的なプロセス効率を測定するための主要なKPIです。「SDLC End-to-End Cycle Time」のようなダッシュボードの主要なメトリックであり、改善を追跡し、システム的な問題を示唆する可能性のある長期間実行中のケースを特定するために使用されます。
その重要性
これは、開発ライフサイクルのエンドツーエンドの効率を測定する
取得元
プロセスマイニングツールによって、各一意のCaseIdの最大開始時刻(Maximum StartTime)から最小開始時刻(Minimum StartTime)を差し引くことで計算されます。
例
10日4時間23時間15分35 days
|
|||
|
ソースシステム
SourceSystem
|
`データ`のソース元`システム`を特定します。 | ||
|
説明
この この
その重要性
データガバナンスや複数のエンタープライズシステムからのデータ統合時に不可欠な、データソースの明確性を保証します。
取得元
これは、
例
GitLab
|
|||
|
ターゲットブランチ
TargetBranch
|
`マージリクエスト`の宛先`ブランチ`の名前。 | ||
|
説明
その重要性
宛先ブランチによって
取得元
例
main開発release/v2.1.0hotfix/user-auth-bug
|
|||
|
チーム名
TeamName
|
`プロジェクト`または`アサイニー`に関連付けられた開発チーム。 | ||
|
説明
チーム名とは、開発 この
その重要性
異なるチーム間でのパフォーマンス分析とプロセス比較を可能にし、チーム固有のボトルネックやベストプラクティスの特定に役立ちます。
取得元
多くの場合、
例
フロントエンド-Alphaバックエンドサービスプラットフォーム-`インフラ`
|
|||
|
ハンドオフ待ち時間
HandoffWaitTime
|
異なる担当者によって実行された2つの連続するアクティビティ間の計算されたアイドル時間。 | ||
|
説明
この これは、「平均引き継ぎ
その重要性
異なる個人またはチーム間の引き継ぎにおける
取得元
プロセスマイニングツールによって計算されます。ケース内の連続するイベントを分析し、「Assignee」が異なるかどうかを確認し、その時間差を計算する必要があります。
例
1日2時間15分8時間
|
|||
|
マージリクエスト`ステータス`
MergeRequestStatus
|
`イベント`に関連付けられた`マージリクエスト`の`ステータス`。例えば、「オープン済み」、「マージ済み」、「クローズ済み」など。 | ||
|
説明
この
その重要性
取得元
例
openedmergedクローズ済みlocked
|
|||
|
マイルストーンの`タイトル`
MilestoneTitle
|
開発`アイテム`が割り当てられている`マイルストーン`または`スプリント`の`タイトル`。 | ||
|
説明
GitLabにおけるマイルストーンは、スプリントやリリースバージョンなど、特定の目標や時間枠に対する作業を追跡するために使用されます。この属性は、そのマイルストーンの名前またはタイトルを捕捉します。 この属性により、特定のスプリントや計画期間のコンテキスト内でプロセスパフォーマンスを分析できます。これにより、サイクルタイムがスプリントごとに改善されているかどうかを確認したり、プロセスビューをフィルタリングして、今後のリリースに関連する作業のみを表示したりすることができます。
その重要性
開発作業を
取得元
例
2023年`Q4リリース``スプリント` 23.11`フェーズ`1: `MVP`
|
|||
|
リリースバージョン
ReleaseVersion
|
デプロイメントに関連付けられた計画または実際のソフトウェアバージョン`タグ`。 | ||
|
説明
この これは「リリース
その重要性
開発項目を特定のソフトウェアリリースに接続します。これはリリース進捗とスケジュール順守を追跡する上で非常に重要です。
取得元
これは
例
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
最終データ更新
LastDataUpdate
|
このイベントのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この この情報は、
その重要性
取得元
この
例
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
処理時間
ProcessingTime
|
単一のアクティビティの期間。その終了時刻と開始時刻の差として計算されます。 | ||
|
説明
この
その重要性
個々の
取得元
プロセスマイニングツールによって、アクティビティの終了時刻(EndTime)と開始時刻(StartTime)の差として計算されます。
例
2時間30分0分3日8時間
|
|||
|
手戻り
IsRework
|
アクティビティが手戻りループの一部であるかを示すブール値フラグです。 | ||
|
説明
この この
その重要性
手戻りを直接的に指摘し定量化することで、プロセスの非効率性や品質問題の原因と影響を容易に分析できます。
取得元
プロセスマイニングツールによって、各ケースのアクティビティのシーケンスを分析し、手戻りを示すパターンを特定することで計算されます。
例
truefalse
|
|||
|
開発項目ステータス
DevelopmentItemStatus
|
`イベント`発生時の開発`アイテム`の`ステータス`。例えば、「オープン」、「進行中」、「クローズ済み」など。 | ||
|
説明
この
その重要性
取得元
主要な
例
openedクローズ済み進行中審査中
|
|||
ソフトウェア開発ライフサイクルアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
マージリクエストマージ済み
|
この`アクティビティ`は、`コードレビュー`および統合`プロセス`の正常な完了を示します。これは、ユーザーが`マージリクエスト`の`ブランチ`を`ターゲットブランチ`にマージしたときに発生する明示的な`イベント`です。 | ||
|
その重要性
これは、開発とレビューが完了したことを示す主要な
取得元
これは、「merge_requests」
取得
マージリクエストの
イベントタイプ
explicit
|
|||
|
マージリクエスト作成済み
|
初期開発作業が完了し、`コード`がレビューと統合の準備が整ったことを示します。これは`GitLabワークフロー`における明示的な主要`イベント`であり、開発者が新しい`マージリクエスト`(`MR`)をオープンした際に捕捉されます。 | ||
|
その重要性
これは、開発からレビューおよびテストへの引き継ぎを示す重要な
取得元
これは、「merge_requests」
取得
マージリクエストの
イベントタイプ
explicit
|
|||
|
問題作成
|
この`アクティビティ`は、新しい作業`アイテム`(機能、`バグ`、`タスク`など)の作成を表し、開発ライフサイクルの開始を示します。`GitLab`でユーザーが新しい`課題`を作成したときに明示的に捕捉され、その作成`timestamp`が記録されます。 | ||
|
その重要性
これはエンドツーエンド
取得元
これは、「issues」
取得
Issueの
イベントタイプ
explicit
|
|||
|
本番環境にデプロイ済み
|
この`アクティビティ`は、`コード`がライブ本番環境に正常にデプロイされ、エンドユーザーが利用可能になったことを示します。これは、`GitLab CI/CDパイプライン`内の特定の「deploy to production」`ジョブ`が正常に完了したときに捕捉されます。 | ||
|
その重要性
これは
取得元
本番デプロイ用に特別に指定された成功したCI/CDジョブの「finished_at」タイムスタンプから取得されます。GitLabの環境機能がこれを明示的に追跡します。
取得
成功した本番デプロイのCIジョブから
イベントタイプ
explicit
|
|||
|
`パイプライン`失敗
|
この`アクティビティ`は、`ビルドエラー`やテスト失敗など、`CI/CDパイプライン`実行がどの`ステージ`でも失敗したときに発生します。`GitLab`はすべての`パイプライン`の最終`ステータス`を明示的に記録するため、失敗を容易に特定できます。 | ||
|
その重要性
取得元
「ci_pipelines」
取得
パイプラインレコードを「failed」ステータスでフィルタリングし、「finished_at」タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
`パイプライン`開始
|
`ビルド`、テスト、セキュリティ`スキャン`を通常実行する`自動化されたCI/CDパイプライン`の開始を表します。`GitLab`は、`コミット`や`MR`の作成などによって`パイプライン`がトリガーされるたびに、開始`timestamp`を持つ`パイプライン`レコードを明示的に作成します。 | ||
|
その重要性
取得元
「ci_pipelines」テーブル内のパイプラインレコードの「created_at」または「started_at」タイムスタンプ、あるいはパイプラインAPIを通じて取得されます。
取得
MRのブランチに関連付けられたパイプライン実行レコードからタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
コードレビュー開始
|
`マージリクエスト`の`ピアレビュープロセス`の開始を示します。この`イベント`は、作成者以外の人物による最初のコメントや`スレッド`など、最初のレビュー関連`アクション`から推測されます。 | ||
|
その重要性
取得元
取得
イベントタイプ
inferred
|
|||
|
デプロイメント開始
|
`ステージング`や本番環境などの特定の環境に`コード`をリリースする`プロセス`の開始を表します。`GitLab`では、これは`CI/CDパイプライン`内の「deploy」`ジョブ`の開始に対応します。 | ||
|
その重要性
デプロイメントの開始を追跡することは、デプロイメント
取得元
デプロイジョブとして設定されたCI/CDジョブの「started_at」タイムスタンプから取得されます。これはGitLabの環境およびデプロイ機能の一部です。
取得
デプロイタスクのCIジョブログから
イベントタイプ
explicit
|
|||
|
承認が追加されました
|
レビュアーによる`マージリクエスト`内の`コード`変更の正式な承認を表します。これは、`GitLab`でユーザーが「Approve」`ボタン`をクリックしたときに捕捉される明示的な`イベント`です。 | ||
|
その重要性
承認は重要な品質ゲートです。これらを追跡することで、必要な承認を得るのにかかる時間を分析し、レビューポリシーへのコンプライアンスを確保するのに役立ちます。
取得元
マージリクエストの承認イベントから取得されます。これらは承認APIを通じて利用可能であるか、MRの履歴で確認できます。
取得
マージリクエスト承認イベントログからタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
課題クローズ済み
|
作業`アイテム`の最終的な管理上の`クローズ`を表し、通常は変更がデプロイされ検証された後に行われます。これは、ユーザーが`GitLab`で課題を`クローズ`したときに捕捉される明示的な`イベント`です。 | ||
|
その重要性
Issueをクローズすることは、関連するすべての作業の最終的な終了を意味することがよくあります。これをデプロイ時間と比較することで、デプロイ後の検証や管理プロセスにおける遅延が明らかになる場合があります。
取得元
これは、「issues」
取得
Issueの
イベントタイプ
explicit
|
|||
|
課題割り当て済み
|
課題が特定の開発者またはチームに割り当てられたことを表し、作業の`オーナーシップ`が確立されたことを示します。これは、`GitLab`が課題の`アサイニー``フィールド`が入力または変更されるたびに`ログ`に記録する明示的な`イベント`です。 | ||
|
その重要性
割り当てを追跡することは、リソース配分、チーム
取得元
GitLabのIssueのシステムノートから取得されます。これは「assignee」が追加または変更されたときに記録されます。イベントタイムスタンプはノートに記録されます。
取得
Issueのシステムノートから「担当者変更」イベントを抽出します。
イベントタイプ
explicit
|
|||
|
開発開始
|
この`アクティビティ`は、`課題`に対するアクティブな`コーディング`作業の開始を示します。`GitLab`には明示的な「開発開始」`ボタン`がないため、これは通常、`課題`に関連付けられた`ブランチ`にプッシュされた最初の`コードコミット`から推測されます。 | ||
|
その重要性
取得元
課題に関連付けられた
取得
課題IDに関連付けられたブランチで最初のコミットの
イベントタイプ
inferred
|
|||