소프트웨어 개발 수명 주기 데이터 템플릿

ServiceNow DevOps
소프트웨어 개발 수명 주기 데이터 템플릿

소프트웨어 개발 수명 주기 데이터 템플릿

이 템플릿은 소프트웨어 개발 수명 주기를 최적화하는 데 필요한 데이터를 수집하는 방법을 안내합니다. 수집할 필수 속성과 추적할 주요 활동을 설명하고, ServiceNow DevOps에서 데이터를 추출하는 실용적인 방법도 제공합니다. 이 자료를 활용해 프로세스 분석에 필요한 이벤트 로그를 구성하세요.
  • 수집 권장 속성
  • 추적할 주요 활동
  • ServiceNow DevOps 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

소프트웨어 개발 수명 주기 속성

소프트웨어 개발 수명 주기를 분석하려면 이벤트 로그에 다음 데이터 필드를 포함하는 것이 좋습니다.
5 필수 8 권장 5 선택 사항
이름 설명
개발 항목
DevelopmentItem
기능, 버그, 태스크처럼 개발 수명 주기를 거치는 개별 작업 단위를 식별하는 고유 ID입니다.
설명

개발 항목은 추적 대상인 개별 작업 단위를 나타내는 기본 케이스 식별자입니다. 해당 항목의 초기 구상과 계획부터 개발, 테스트, 배포까지 모든 활동을 연결합니다.

process mining 분석에서 이 속성은 각 작업 항목의 엔드투엔드 진행 과정을 재구성하는 데 기본이 됩니다. 프로세스 흐름을 시각화하고 전체 주기 시간을 계산하며 개별 기능이나 버그 수정의 프로세스 변형을 찾을 수 있습니다. 일관된 프로세스 맵을 만들려면 로그의 모든 이벤트를 개발 항목과 연결해야 합니다.

중요한 이유

관련된 모든 개발 활동을 하나의 프로세스 인스턴스로 연결하는 기본 식별자입니다. 이를 통해 각 작업 항목의 전체 수명 주기를 분석할 수 있습니다.

확보 방법

일반적으로 ServiceNow의 'rm_story', 'rm_bug', 'task' 테이블처럼 스토리, 버그, 태스크를 관리하는 테이블의 기본 키를 사용합니다.

예시
STRY0010015BUG0034092TASK0050118
시작 시간
EventTime
특정 활동이나 이벤트가 발생한 시점을 나타내는 정확한 타임스탬프입니다.
설명

이 속성은 개발 수명 주기의 각 활동이 기록된 날짜와 시간을 제공합니다. 이벤트를 시간순으로 정렬하고 시간 기반 분석을 수행하는 데 필요합니다.

process mining에서는 시작 시간을 사용해 활동 간 소요 시간과 대기 시간을 파악하고 전체 프로세스 주기 시간을 측정합니다. SDLC 엔드투엔드 주기 시간 분석과 같은 성과 대시보드 및 코드 검토 리드 타임과 같은 KPI를 계산하는 데도 중요합니다.

중요한 이유

이 타임스탬프는 이벤트를 올바른 순서로 정렬하고 주기 시간, 소요 시간, 대기 시간을 비롯한 모든 성과 지표를 계산하는 데 필요합니다.

확보 방법

감사 추적 또는 태스크 테이블의 'sys_updated_on', 'sys_created_on'과 같은 시스템 생성 타임스탬프 필드에서 찾을 수 있습니다.

예시
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
활동명
ActivityName
'Development Started' 또는 'Code Review Performed'와 같이 발생한 특정 개발 수명 주기 이벤트의 이름입니다.
설명

이 속성은 소프트웨어 개발 수명 주기에서 완료된 각 이정표나 태스크의 이름을 기록합니다. 이러한 활동은 생성부터 배포까지 프로세스를 구성하는 순차적인 단계입니다.

이러한 활동의 순서와 빈도를 분석하는 것이 process mining의 주된 기능입니다. 이를 통해 프로세스 맵을 만들고 단계 간 병목을 찾으며 규정을 준수하지 않거나 비효율적인 프로세스 변형을 확인할 수 있습니다. 정의된 활동에는 설계, 개발, 테스트, 배포와 같은 주요 단계가 포함됩니다.

중요한 이유

프로세스 맵의 단계를 정의하므로 프로세스 흐름을 분석하고 병목을 찾으며 표준 SDLC에서 벗어난 부분을 확인할 수 있습니다.

확보 방법

일반적으로 상태 변경, 이벤트 레코드, 감사 추적 항목을 표준 활동명 목록에 매핑해 도출합니다. 예를 들어 'state' 필드가 'In Progress'로 변경되면 'Development Started'에 매핑할 수 있습니다.

예시
개발 시작코드 커밋QA 테스트 완료프로덕션 배포 완료
마지막 데이터 업데이트
LastDataUpdate
소스 시스템에서 이벤트 로그 데이터를 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다.
설명

이 속성은 ServiceNow DevOps에서 데이터 세트를 마지막으로 추출하거나 업데이트한 시점을 기록합니다. 개별 이벤트가 아니라 데이터 세트 전체에 적용됩니다.

이 타임스탬프는 분석에 사용된 데이터의 최신성을 파악하는 데 중요합니다. 사용자에게 프로세스 인사이트가 얼마나 최신인지 알려주고 데이터 새로 고침 일정을 정하는 데 도움이 됩니다. 대시보드에 표시하면 모든 지표와 시각화의 기준 시점을 알 수 있어 최신 데이터를 바탕으로 의사결정할 수 있습니다.

중요한 이유

데이터의 최신성을 파악하는 데 필요한 정보를 제공해 사용자가 프로세스 분석이 얼마나 최신인지 알 수 있도록 합니다.

확보 방법

데이터 추출 과정에서 타임스탬프를 생성해 추가하며, 추출이 실행된 시점을 기록합니다.

예시
2023-11-15T08:00:00Z
소스 시스템
SourceSystem
데이터를 추출한 시스템을 나타냅니다. 여기서는 ServiceNow DevOps입니다.
설명

이 속성은 이벤트 데이터의 원본 시스템을 나타냅니다. 이 프로세스에서는 항상 'ServiceNow DevOps'로 기록됩니다.

고정값처럼 보일 수 있지만, 소스 시스템을 명시하면 데이터 거버넌스를 지원하고 Jira 또는 Azure DevOps와 같은 여러 시스템의 데이터를 병합하는 환경에서 출처를 명확히 할 수 있습니다. 또한 데이터 품질이나 추출 문제를 진단하는 데 도움이 됩니다.

중요한 이유

데이터 추적성을 보장하고 데이터 무결성을 유지하는 데 필요합니다. 특히 여러 개발 도구의 데이터를 통합할 때 중요합니다.

확보 방법

데이터 추출 및 변환 과정에서 추가해야 하는 고정값입니다.

예시
ServiceNow DevOps
개발 항목 상태
DevelopmentItemState
이벤트 발생 시점의 개발 항목 상태입니다. 예: '열림', '진행 중', '종료됨'.
설명

이 속성은 ServiceNow에서 개발 항목에 설정된 공식 상태를 나타냅니다. 활동은 프로세스 단계를 바탕으로 도출되지만, 상태는 시스템 워크플로에서 공식적으로 지정된 단계를 나타냅니다.

활동은 대개 상태를 바탕으로 도출됩니다. 상태는 데이터 검증이나 프로세스를 간결한 상위 수준으로 보여주는 데 활용할 수 있습니다. 예를 들어 각 상태에 머문 시간을 분석하면 활동 간 소요 시간을 분석할 때와 다른 관점에서 병목을 파악할 수 있습니다. 진행이 멈춘 항목이나 해결된 항목을 식별하는 데도 유용합니다.

중요한 이유

작업 항목의 공식 시스템 상태를 제공합니다. 이 상태는 활동을 도출하는 기준으로 자주 사용되며, 데이터 검증과 상위 수준의 상태 분석에도 활용할 수 있습니다.

확보 방법

ServiceNow의 작업 관련 테이블에서 일반적으로 'state' 또는 'stage'라는 이름으로 제공되는 표준 필드입니다.

예시
대기 중작업 진행 중테스트 준비 완료완료 후 종료
개발 항목 유형
DevelopmentItemType
작업 항목의 분류입니다. 예: '기능', '버그', '기술 부채', '작업'.
설명

이 속성을 사용하면 SDLC 프로세스에서 진행되는 작업을 유형별로 구분할 수 있습니다. 예를 들어 심각한 버그를 수정하는 프로세스는 새 기능을 개발하는 프로세스보다 빠르고 다를 수 있습니다.

작업 항목 유형별로 프로세스를 분석하면 성과를 더 세밀하게 파악할 수 있습니다. '버그는 새 기능보다 재작업률이 높은가?', '기술 부채를 줄이는 데 걸리는 주기는 적절한가?'와 같은 질문에 답하는 데 도움이 됩니다. 이처럼 유형별로 나누면 모든 작업을 하나의 프로세스로 보는 것보다 더 구체적인 인사이트를 얻을 수 있습니다.

중요한 이유

기능이나 버그처럼 작업 유형을 구분합니다. 유형에 따라 프로세스 경로, 우선순위, 예상 소요 시간이 다를 수 있습니다.

확보 방법

레코드의 원본 테이블(예: 'rm_story' 또는 'rm_bug')이나 일반 작업 테이블의 'type' 필드에서 확인할 수 있습니다.

예시
기능버그작업기술 검토
개발 항목 주기 시간
DevelopmentItemCycleTime
개발 항목이 생성된 시점부터 최종 종료 또는 배포될 때까지 걸린 총 시간입니다.
설명

이 속성은 개발 항목 하나의 전체 처리 시간을 나타내는 계산 지표입니다. 각 케이스에서 첫 번째 활동의 타임스탬프와 마지막 활동의 타임스탬프 간 차이를 계산합니다.

SDLC 프로세스 전반의 주요 성과 지표로, '평균 SDLC 주기 시간' KPI를 뒷받침합니다. 프로세스의 속도와 효율성을 상위 수준에서 측정할 수 있습니다. 우선순위나 팀 등 여러 기준으로 시간에 따른 지표를 분석하면 프로세스 개선 활동의 효과를 추적할 수 있습니다.

중요한 이유

작업 항목의 전체 처리 시간을 나타내며, 프로세스 전반의 효율성과 속도를 측정하는 주요 지표입니다.

확보 방법

원본 시스템의 필드가 아닙니다. process mining 도구에서 각 CaseId의 최소 StartTime을 최대 StartTime에서 빼 계산합니다.

예시
15일 4시간3일 12시간32일 8시간
담당 개발자
AssignedDeveloper
활동이 발생한 시점에 개발 항목을 담당한 개발자 또는 사용자의 이름이나 ID입니다.
설명

이 속성은 특정 작업이나 활동을 수행할 책임이 있는 담당자를 나타냅니다. 개발 항목이 여러 단계와 팀을 거치면서 담당자가 바뀔 수 있습니다.

이 속성을 활용하면 리소스 배분, 업무량, 인계 현황을 분석할 수 있습니다. '개발자 업무량 및 인계' 대시보드와 '개발자별 활동량' KPI를 지원합니다. 이 필드의 변경 내역을 추적하면 인계에 걸리는 시간을 측정하고 개발자 간 또는 개발팀과 QA팀 간 협업 과정의 병목을 파악할 수 있습니다.

중요한 이유

업무량 분포, 인계 효율, 팀별 성과 패턴을 파악하는 등 리소스 기반 분석에 필요합니다.

확보 방법

일반적으로 ServiceNow의 태스크 관련 테이블에서 'assigned_to' 필드에 저장됩니다.

예시
David MillerAnna WilliamsJames Brown
담당 그룹
AssignmentGroup
활동 시점에 개발 항목을 담당하는 팀 또는 그룹입니다.
설명

이 속성은 '프런트엔드 개발팀', '백엔드 서비스팀', 'QA팀'처럼 작업 항목을 담당하는 팀을 나타냅니다. 작업 항목이 진행되는 동안 담당 그룹이 바뀌는 경우가 많습니다.

담당 그룹을 추적하면 여러 기능 조직 간의 협업과 인계 과정을 파악할 수 있습니다. 작업이 한 팀에서 다른 팀으로 넘어갈 때 발생하는 반복적인 지연을 찾는 데 도움이 됩니다. 이 속성을 활용해 팀별 성과와 업무량을 분석하고, 전체 흐름에서 병목이 되는 팀을 식별할 수 있습니다.

중요한 이유

작업 담당 팀을 추적해 팀별 성과와 업무량 균형을 분석하고, 팀 간 인계가 얼마나 원활한지 파악할 수 있습니다.

확보 방법

이 정보는 ServiceNow의 작업 관련 테이블에 있는 표준 필드인 'assignment_group'에 저장됩니다.

예시
플랫폼 엔지니어링모바일 앱 팀품질 보증DevOps
영향을 받는 모듈/구성 요소
ModuleComponentAffected
개발 항목과 관련된 특정 소프트웨어 모듈, 애플리케이션 또는 구성 요소입니다.
설명

이 속성은 시스템의 어느 부분에 영향을 미치는지에 따라 개발 작업을 분류합니다. 특정 마이크로서비스, UI 구성 요소 또는 백엔드 애플리케이션 등이 해당할 수 있습니다.

모듈이나 구성 요소별로 프로세스를 나누면 특정 영역의 병목을 파악하는 데 도움이 됩니다. '구성 요소별 병목 분석' 대시보드와 '구성 요소별 평균 단계 소요 시간' KPI는 이 속성을 사용해 코드베이스의 특정 부분에서 개발 주기가 반복적으로 길어지는지, 재작업률이 높은지, 배포 실패가 잦은지 확인합니다. 이를 통해 개선이 필요한 영역에 집중할 수 있습니다.

중요한 이유

애플리케이션이나 구성 요소별로 분석을 나눠 시스템의 특정 부분에서 발생하는 병목이나 품질 문제를 파악할 수 있습니다.

확보 방법

사용자 지정 필드이거나 Configuration Management Database (CMDB)를 참조하는 필드인 경우가 많으며, 작업 항목을 'cmdb_ci' 레코드에 연결합니다. ServiceNow DevOps 문서를 참조하세요.

예시
결제 서비스사용자 인증 UI보고 데이터베이스API 게이트웨이
우선순위
DevelopmentItemPriority
'High', 'Medium', 'Low'와 같이 개발 항목에 지정된 우선순위입니다.
설명

이 속성은 비즈니스 긴급도에 따라 개발 항목을 분류합니다. 우선순위는 팀이 중요한 태스크에 집중하도록 돕고 SLA와 이해관계자의 기대를 관리하는 데 자주 사용됩니다.

process mining에서 우선순위는 비교 분석을 위한 주요 기준입니다. 프로세스 맵을 필터링해 우선순위가 높은 항목이 더 빠르거나 다른 경로를 따르는지 확인할 수 있습니다. 'High-Priority Feature Delivery Time' 대시보드와 KPI에 필요하며, 중요 항목이 실제로 신속히 처리되는지 검증하는 데 도움이 됩니다.

중요한 이유

우선순위별로 프로세스를 필터링하고 비교해 우선순위가 높은 항목이 더 빠르고 효율적으로 처리되는지 확인할 수 있습니다.

확보 방법

ServiceNow의 태스크 관련 테이블에 있는 표준 필드로, 보통 'priority'라는 이름을 사용합니다.

예시
1 - 긴급2 - 높음3 - 보통4 - 낮음
재작업 여부
IsRework
테스트 후 개발 단계로 돌아가는 경우처럼 활동이 재작업 루프에 포함되면 true로 설정되는 불리언 플래그입니다.
설명

이 파생 속성은 프로세스가 이전 단계로 되돌아간 뒤 발생한 활동을 식별합니다. 예를 들어 같은 항목에서 'QA 테스트 완료' 활동 후 '개발 시작' 활동이 발생하면 재작업으로 표시합니다.

이 플래그는 재작업을 수치화하고 시각화하는 데 필요합니다. '재작업 및 반려 흐름 분석' 대시보드와 '테스트 후 재작업률' KPI를 뒷받침합니다. 이벤트에 플래그를 지정하면 재작업의 빈도와 원인, 전체 주기 시간에 미치는 영향을 쉽게 필터링하고 분석할 수 있습니다.

중요한 이유

이 플래그를 사용하면 재작업을 쉽게 수치화하고 분석할 수 있어 프로세스 품질을 측정하고 반복 작업의 근본 원인을 찾는 데 도움이 됩니다.

확보 방법

process mining 도구에서 각 케이스의 활동 순서를 분석해 프로세스 흐름이 이전 단계로 되돌아가는지 확인하고 계산합니다.

예시
truefalse
배포 상태
DeploymentStatus
배포 활동의 결과를 나타냅니다. 일반적으로 '성공' 또는 '실패'로 표시됩니다.
설명

이 속성은 특정 환경에 배포한 결과를 기록합니다. 릴리스 프로세스의 신뢰성과 안정성을 파악하는 데 중요한 정보입니다.

'배포 성공 및 실패 추이' 대시보드와 '배포 실패율' KPI를 산출하는 데 필요합니다. 배포 실패 빈도와 추이를 분석하면 테스트, 인프라 또는 릴리스 조율 과정의 근본적인 문제를 찾을 수 있습니다. 이를 바탕으로 소프트웨어 제공의 품질과 신뢰성을 높이는 데 집중할 수 있습니다.

중요한 이유

배포 활동의 성공 여부를 직접 측정합니다. 배포 실패율을 계산하고 릴리스 안정성을 분석하는 데 중요합니다.

확보 방법

일반적으로 배포 추적 작업이나 ServiceNow DevOps와 연동된 CI/CD 파이프라인 실행 기록에 상태가 저장됩니다.

예시
성공실패경고와 함께 완료
예정된 릴리스 버전
PlannedReleaseVersion
개발 항목을 제공할 예정인 소프트웨어 릴리스 또는 버전입니다.
설명

이 속성은 개발 항목을 '버전 2.3' 또는 '2023년 4분기 릴리스'와 같은 특정 예정 릴리스에 연결합니다. 프로젝트 관리와 릴리스 계획에 중요한 정보입니다.

process mining에서는 '릴리스 계획 준수 모니터링' 대시보드에 이 속성이 필요합니다. 실제 완료일과 계획된 릴리스 일정을 비교해 일정 준수 여부를 측정하고, 릴리스에 맞추지 못할 위험이 있는 항목을 찾아 지연 원인을 분석할 수 있습니다. 이를 통해 세부 개발 프로세스와 상위 수준의 비즈니스 목표를 연결할 수 있습니다.

중요한 이유

개발 작업을 특정 릴리스에 연결해 일정 준수 여부와 프로세스 지연이 릴리스 일정에 미치는 영향을 분석할 수 있습니다.

확보 방법

이 정보는 일반적으로 'release' 또는 'planned_release' 필드에 저장되며, ServiceNow의 릴리스 관리 테이블을 참조하는 경우가 많습니다. ServiceNow DevOps 문서를 참조하세요.

예시
v3.4.12024년 1분기 릴리스프로젝트 피닉스 가동 시작
재작업 사유
ReworkReason
테스트 후 개발 항목을 재작업해야 했던 이유를 분류하거나 설명하는 정보입니다.
설명

항목이 QA 또는 UAT를 통과하지 못하면 이 속성에 실패 사유를 기록합니다. 특정 버그 유형, 요구사항 오해 또는 환경 문제가 원인일 수 있습니다.

이 정보는 '재작업 및 반려 흐름 분석' 대시보드에 맥락을 더해 줍니다. 재작업이 발생했다는 사실뿐 아니라 그 이유도 파악할 수 있습니다. 이를 바탕으로 요구사항 정의를 개선하고, 단위 테스트를 강화하거나, 테스트 환경을 안정화하는 등 재작업률을 낮추기 위한 개선을 진행할 수 있습니다.

중요한 이유

재작업이 발생하는 이유를 정성적으로 파악해 품질을 높이고 반복 작업을 줄이는 데 필요한 프로세스 개선을 추진할 수 있습니다.

확보 방법

테스트 실패 시 'close_notes' 필드에 기록하거나 전용 사용자 지정 필드인 'rework_reason'에 저장할 수 있습니다. ServiceNow DevOps 문서를 참조하세요.

예시
요구사항을 잘못 해석함회귀 버그성능 테스트 실패UI/UX 문제
종료 시간
EventEndTime
활동이 완료된 시점을 나타내는 정확한 타임스탬프입니다. 즉시 발생하는 이벤트의 경우 시작 시간과 같습니다.
설명

이 속성은 개발 수명 주기의 각 활동이 완료된 날짜와 시간을 제공합니다. 'Code Review Performed' 또는 'QA Testing'처럼 소요 시간을 측정할 수 있는 활동에 특히 유용합니다.

process mining에서 시작 시간과 종료 시간을 모두 사용하면 활동 처리 시간을 정확히 계산하고 활동 간 대기 시간과 구분할 수 있습니다. 이를 통해 지연이 긴 작업 때문인지, 리소스를 기다리는 시간이 길기 때문인지 파악할 수 있습니다. 'Build Triggered'처럼 즉시 발생하는 이벤트는 종료 시간이 시작 시간과 같을 수 있습니다.

중요한 이유

활동 처리 시간을 정확히 계산해 실제 작업 시간과 대기 시간을 구분할 수 있습니다.

확보 방법

이 값을 별도로 도출해야 할 수 있습니다. 다음 활동의 시작 타임스탬프를 사용하거나, 소스 시스템에 별도의 'end date' 필드가 있으면 해당 값을 사용할 수 있습니다.

예시
2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
커밋 ID
CommitId
개발 작업과 관련된 소스 코드 커밋의 고유 식별자입니다.
설명

이 속성을 사용하면 개발 항목을 Git과 같은 소스 코드 저장소의 특정 코드 변경에 직접 연결할 수 있습니다. '코드 커밋' 활동이 발생할 때 기록됩니다.

process mining에서 커밋 ID를 활용하면 프로세스 데이터와 엔지니어링 데이터를 연결해 분석할 수 있습니다. 문제가 발생한 배포를 해당 코드 변경까지 추적하거나, 코드 복잡도 지표와 개발 주기 간의 관계를 분석할 수 있습니다. 이를 통해 근본 원인을 기술적인 수준까지 자세히 파악할 수 있습니다.

중요한 이유

프로세스 이벤트를 특정 코드 변경에 연결해 프로세스 지표와 코드 수준의 세부 정보를 함께 분석하고, 근본 원인을 더 깊이 파악할 수 있습니다.

확보 방법

Git이나 SVN과 같은 소스 코드 관리 시스템과 ServiceNow DevOps를 연동해 기록합니다. 데이터는 개발 항목과 연결된 관련 테이블에 저장됩니다.

예시
a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
필수 권장 선택 사항

소프트웨어 개발 수명 주기 활동

정확한 프로세스 탐색과 최적화를 위해 이벤트 로그에 기록할 주요 프로세스 단계와 마일스톤입니다.
7 권장 9 선택 사항
활동 설명
QA 테스트 완료
QA팀이 개발 항목의 테스트를 성공적으로 마쳤음을 나타냅니다. 보통 항목 상태가 테스트 단계에서 'Ready for UAT' 또는 'Done'과 같은 상태로 변경될 때 추정합니다.
중요한 이유

주요 품질 확인 단계의 완료를 나타내는 이정표입니다. 이후 진행되는 사용자 인수 테스트나 릴리스 준비의 선행 조건입니다.

확보 방법

'In QA'와 같은 테스트 상태에서 'Ready for UAT' 또는 'Resolved'와 같은 테스트 이후 상태로 변경된 타임스탬프를 바탕으로 추정합니다.

기록

'Testing'에서 다음 상태로 변경된 타임스탬프를 기준으로 합니다.

이벤트 유형 inferred
UAT 승인
사용자 인수 테스트 후 비즈니스 관계자가 개발 항목을 공식 승인했음을 나타냅니다. 'In UAT'에서 'Ready for Release' 또는 'Approved'로 변경되는 등의 상태 전환을 바탕으로 추정하는 주요 이정표입니다.
중요한 이유

항목을 프로덕션에 배포하기 전에 받는 최종 비즈니스 승인입니다. 품질과 거버넌스를 확인하는 중요한 단계입니다.

확보 방법

UAT가 성공적으로 완료되었음을 나타내는 개발 항목 레코드의 상태 전환을 바탕으로 추정합니다. 해당 항목의 활동 이력에 기록됩니다.

기록

'UAT'에서 승인 또는 릴리스 준비 상태로 변경된 기록을 바탕으로 추정합니다.

이벤트 유형 inferred
개발 시작
개발자가 개발 항목의 코딩이나 구현을 실제로 시작한 시점을 나타냅니다. 보통 항목 상태가 'In Progress', 'Development' 또는 'Coding'으로 변경된 기록을 바탕으로 추정합니다.
중요한 이유

가치가 더해지는 구현 단계의 시작을 알리는 중요한 이정표입니다. 개발자 리드 타임과 코드 검토 주기를 측정하는 데 필요합니다.

확보 방법

개발 항목 레코드(예: Story [rm_story])의 'State' 필드가 'In Progress' 또는 이에 해당하는 상태로 변경된 타임스탬프를 바탕으로 추정합니다.

기록

'In Progress' 또는 이에 해당하는 값으로 상태가 변경된 타임스탬프를 기준으로 합니다.

이벤트 유형 inferred
개발 항목 생성
이 활동은 ServiceNow에서 스토리, 버그, 에픽과 같은 새 개발 항목을 생성한 시점을 나타냅니다. 보통 Story [rm_story] 테이블과 같은 관련 테이블에 새 레코드가 추가될 때 명시적으로 기록됩니다.
중요한 이유

SDLC 프로세스의 기본 시작 이벤트입니다. 전체 엔드투엔드 주기를 측정하고 초기 수요가 접수된 시점을 추적할 수 있습니다.

확보 방법

Story [rm_story], Epic [rm_epic], Defect [rm_defect]와 같은 개발 관련 테이블에 레코드가 생성되면 sys_audit 또는 sys_history_line 테이블에 기록됩니다. 생성 타임스탬프는 보통 해당 레코드에 저장됩니다.

기록

개발 항목 레코드의 생성 타임스탬프에서 가져옵니다.

이벤트 유형 explicit
배포 실패
개발 항목을 프로덕션에 배포하려는 시도가 실패했음을 나타냅니다. CI/CD 파이프라인이 실패를 보고하면 ServiceNow DevOps가 이를 명시적으로 수집합니다.
중요한 이유

중요한 실패 종료 지점입니다. 발생 빈도와 원인을 분석하면 릴리스 안정성을 높이고 배포 실패율을 낮출 수 있습니다.

확보 방법

Pipeline Execution [sn_devops_pipeline_execution] 레코드의 'completion_status'에서 가져옵니다. 종료 시점의 'Failed' 상태가 이 이벤트를 나타냅니다.

기록

프로덕션 배포 파이프라인에서 실패 상태를 보고하면 기록됩니다.

이벤트 유형 explicit
코드 검토 완료
보통 pull request 또는 merge request와 관련된 동료 코드 검토가 완료된 것을 나타냅니다. DevOps 연동으로 이벤트를 명시적으로 수집하거나 관련 레코드의 상태 변경을 바탕으로 추정할 수 있습니다.
중요한 이유

중요한 품질 확인 단계입니다. 소요 시간을 분석하면 SDLC 지연의 흔한 원인인 검토 프로세스의 병목을 찾을 수 있습니다.

확보 방법

ServiceNow의 Git 연동에서 Pull Request 레코드가 'Merged' 또는 'Completed'로 변경된 이벤트를 가져오거나, 개발 항목 상태가 'Code Review Complete'로 변경된 기록을 바탕으로 추정할 수 있습니다.

기록

작업 항목과 연결된 Pull Request가 병합되면 기록됩니다.

이벤트 유형 explicit
프로덕션 배포 완료
프로덕션 환경으로의 배포가 성공적으로 완료된 시점을 나타냅니다. CI/CD 도구에서 파이프라인이 성공적으로 완료되었다고 보고하면 ServiceNow DevOps가 이를 명시적으로 수집합니다.
중요한 이유

SDLC 프로세스의 기본 성공 종료 지점입니다. 가치 흐름이 완료되는 시점으로, 전체 주기 시간을 계산하는 데 필요합니다.

확보 방법

Pipeline Execution [sn_devops_pipeline_execution] 레코드 또는 연결된 Stage Execution Run의 'completion_status'에서 가져옵니다. 종료 시점의 'Success' 상태가 이 이벤트를 나타냅니다.

기록

프로덕션 배포 파이프라인이 성공적으로 완료되면 기록됩니다.

이벤트 유형 explicit
QA 테스트 시작
정식 품질 보증 테스트 단계의 시작을 나타냅니다. 거의 항상 개발 항목 상태가 'In QA', 'Testing' 또는 'Ready for Test'와 같은 값으로 변경된 기록을 바탕으로 추정합니다.
중요한 이유

개발팀에서 QA팀으로 업무가 넘어가는 시점을 나타냅니다. 테스트 단계의 소요 시간을 측정하고 테스트 리소스의 병목을 찾을 수 있습니다.

확보 방법

개발 항목 레코드(예: Story, Defect)의 'State' 필드가 QA 관련 상태로 변경된 타임스탬프를 바탕으로 추정합니다.

기록

'Testing' 또는 이에 해당하는 상태로 변경된 타임스탬프를 기준으로 합니다.

이벤트 유형 inferred
UAT 시작
비즈니스 관계자가 기능을 검증하는 사용자 인수 테스트의 시작을 나타냅니다. 상태가 'UAT', 'In UAT' 또는 'User Acceptance Testing'으로 변경된 기록을 바탕으로 추정합니다.
중요한 이유

개발된 기능이 비즈니스 요구사항을 충족하는지 확인하는 중요한 단계입니다. 소요 시간을 분석하면 사용자 참여나 요구사항 불일치와 관련된 문제를 찾을 수 있습니다.

확보 방법

개발 항목 레코드의 상태 전환을 바탕으로 추정합니다. 고객의 상태 모델에 UAT를 나타내는 별도 상태가 있어야 합니다.

기록

'UAT' 상태로 변경된 기록을 바탕으로 추정합니다.

이벤트 유형 inferred
개발 항목 취소
개발 항목이 완료되기 전에 종료된 경우를 나타냅니다. 일반적으로 항목 상태가 'Cancelled' 또는 'Closed Incomplete'로 설정된 것을 바탕으로 추정하는 대체 종료 상태입니다.
중요한 이유

취소를 추적하면 낭비된 노력을 파악하고 범위 변경이나 우선순위 조정의 이유를 이해하는 데 도움이 됩니다. 가능한 프로세스 결과를 더 완전하게 파악할 수 있습니다.

확보 방법

개발 항목 레코드의 'State' 필드가 'Cancelled'와 같은 미완료 종료 상태로 변경된 타임스탬프를 바탕으로 추정합니다.

기록

'Cancelled' 또는 이에 해당하는 종료 상태로 변경된 기록을 바탕으로 추정합니다.

이벤트 유형 inferred
릴리스 준비 완료
개발 항목이 모든 품질 확인 단계를 통과하고 특정 릴리스에 포함되었음을 나타냅니다. 항목이 Release 레코드와 연결되거나 상태가 'Ready for Deployment'로 변경된 기록을 바탕으로 추정할 수 있습니다.
중요한 이유

항목의 기술적·기능적 작업이 완료된 단계입니다. 이 상태에 머문 시간은 예정된 배포 시점을 기다리는 대기 시간일 수 있습니다.

확보 방법

'State' 필드가 'Ready for Release'로 변경된 기록을 확인하거나 개발 항목 레코드의 'Release' 필드가 입력 또는 업데이트된 시점을 추적해 추정합니다.

기록

상태 변경이나 Release 레코드와의 연결을 바탕으로 추정합니다.

이벤트 유형 inferred
빌드 시작
코드 커밋으로 시작되는 경우가 많은 CI/CD 파이프라인 빌드의 시작을 나타냅니다. ServiceNow DevOps는 이를 파이프라인 실행으로 기록하고, 시작된 개발 항목과 연결합니다.
중요한 이유

개발과 자동화된 테스트 또는 배포를 잇는 활동입니다. 커밋부터 빌드 시작까지 걸린 시간을 분석하면 CI/CD 프로세스의 지연을 찾을 수 있습니다.

확보 방법

연동된 CI/CD 도구(예: Jenkins, Azure DevOps)에서 빌드가 시작되면 Pipeline Execution [sn_devops_pipeline_execution] 테이블에 명시적으로 기록됩니다.

기록

Pipeline Execution 테이블 레코드의 시작 시간에서 가져옵니다.

이벤트 유형 explicit
설계 시작
개발 항목의 기술 설계나 솔루션 아키텍처를 작성하는 단계입니다. 보통 개발 항목 레코드의 상태 필드가 'Design' 또는 'Solutioning'과 같은 값으로 변경된 것을 바탕으로 추정합니다.
중요한 이유

설계 단계의 소요 시간을 분석하면 개발을 시작하기 전에 요구사항을 설계로 구체화하거나 솔루션을 계획하는 과정에서 발생하는 병목을 찾을 수 있습니다.

확보 방법

개발 항목 레코드(예: Story [rm_story])의 상태 전환을 바탕으로 추정합니다. 'State' 또는 사용자 지정 'Stage' 필드가 설계 관련 값으로 변경된 기록을 확인합니다.

기록

'Design' 또는 이에 해당하는 상태로 변경된 기록을 바탕으로 추정합니다.

이벤트 유형 inferred
재작업 확인
테스트 중 문제가 발견되어 항목을 개발 단계로 되돌려야 하는 경우를 나타냅니다. 'In QA'에서 'In Progress'로 상태가 바뀌는 등 프로세스 흐름이 이전 단계로 돌아간 기록을 바탕으로 추정합니다.
중요한 이유

재작업을 추적하면 품질 문제와 프로세스 비효율을 파악할 수 있습니다. 이 활동이 자주 발생하면 개발이나 요구사항 명확성에 문제가 있을 수 있습니다.

확보 방법

sys_audit 또는 sys_history_line 테이블에서 'State' 필드의 변경 이력을 분석해 추정합니다. 'Testing'과 같은 후반 단계 상태에서 'In Progress'와 같은 이전 단계 상태로 바뀌면 재작업으로 봅니다.

기록

상태가 이전 단계로 되돌아간 기록을 바탕으로 추정합니다. 예: 'Testing' -> 'In Progress'.

이벤트 유형 inferred
코드 커밋
개발자가 개발 항목과 연결된 버전 관리 시스템 저장소에 코드를 커밋한 것을 나타냅니다. ServiceNow DevOps는 Git 또는 GitHub와 같은 연동 SCM 도구에서 이 이벤트를 명시적으로 수집합니다.
중요한 이유

커밋을 추적하면 개발 진행 상황과 활동 빈도를 자세히 확인할 수 있습니다. 특정 코드 변경 사항을 상위 개발 항목과 연결하는 데도 도움이 됩니다.

확보 방법

연동된 소스 코드 관리 시스템의 웹훅으로 데이터가 입력되는 ServiceNow DevOps의 Commits [sn_devops_commit] 테이블에서 명시적으로 가져옵니다.

기록

SCM 도구에서 커밋 웹훅을 수신하면 기록됩니다.

이벤트 유형 explicit
프로덕션 배포 시작
프로덕션 환경으로 배포하는 파이프라인이 시작된 시점을 나타냅니다. ServiceNow DevOps는 CI/CD 파이프라인의 프로덕션 단계가 실행되기 시작할 때 이를 명시적 이벤트로 수집합니다.
중요한 이유

수명 주기의 마지막이자 가장 중요한 경우가 많은 단계의 시작을 나타냅니다. 이 시점을 추적하면 배포 소요 시간을 분석하고 자동화 기회를 찾을 수 있습니다.

확보 방법

Stage Execution Run [sn_devops_stage_execution] 테이블에서 프로덕션 환경과 관련된 단계를 필터링해 명시적으로 기록합니다.

기록

Pipeline Execution에서 프로덕션 배포 단계가 시작된 시간을 가져옵니다.

이벤트 유형 explicit
권장 선택 사항

데이터 추출 가이드

ServiceNow DevOps에서 데이터 가져오기

시작할 준비가 되셨나요?

오늘부터 소프트웨어 개발 수명 주기를 개선해 보세요. 이 데이터 템플릿으로 숨은 비효율을 찾아내고 지속적인 개선을 추진할 수 있습니다.

더 미루지 말고 지금 소프트웨어 개발 수명 주기를 최적화하세요

비효율을 찾아 SDLC 주기를 30% 이상 단축하세요.

무료 체험 시작

신용카드 없이 지금 바로 최적화를 시작하세요