소프트웨어 개발 수명 주기 데이터 템플릿
소프트웨어 개발 수명 주기 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- ServiceNow DevOps 데이터 추출 안내
소프트웨어 개발 수명 주기 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 개발 항목 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 | |||
소프트웨어 개발 수명 주기 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 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 | |||
데이터 추출 가이드
단계
- 상태 모델 파악: 보고서를 만들기 전에 개발 항목의 상태 필드에 어떤 값이 사용되는지 문서화하고, 각 값이 어떤 활동에 해당하는지 확인합니다. 예를 들어 Story
[rm_story]또는 Defect[rm_defect]테이블의 상태 값 '진행 중'을 '개발 시작' 활동에 매핑할 수 있습니다. - 보고서 생성 화면으로 이동: ServiceNow 인스턴스에 로그인합니다. Filter navigator에서
Reports > View / Run으로 이동한 다음Create a report버튼을 클릭합니다. - 상태 변경 보고서 생성: 상태 변경에 따른 활동을 기록할 첫 번째 보고서를 만듭니다. 다음과 같이 설정합니다.
- 보고서 이름:
ProcessMind - State Change Events - 소스 유형:
Table - 테이블:
Audit [sys_audit] - 유형:
List - 열 구성:
Document key,Created on,Table name,Field name,Old value,New value를 추가합니다. - 필터:
Table name은 개발 항목 테이블 중 하나(예:Story)로,Field name은 상태 필드(예:State)로 설정합니다. 원하는 기간에 맞춰Created on필드에 날짜 필터를 추가합니다.
- 보고서 이름:
- 항목 생성 보고서 만들기: 최초 생성 이벤트를 기록할 새 보고서를 만듭니다.
- 보고서 이름:
ProcessMind - Item Creation Events - 소스 유형:
Table - 테이블:
Story [rm_story](또는 기본 개발 항목 테이블) - 유형:
List - 열 구성:
Number,Created on,Assigned to,Priority,State등 필요한 속성의 열을 추가합니다. - 필터:
Created on필드에 날짜 필터를 적용합니다.
- 보고서 이름:
- 코드 커밋 보고서 만들기: 커밋과 관련된 DevOps 이벤트를 기록할 보고서를 만듭니다.
- 보고서 이름:
ProcessMind - Commit Events - 소스 유형:
Table - 테이블:
Commit [sn_devops_commit] - 유형:
List - 열 구성:
Work item,Commit time,Author등의 열을 추가합니다. - 필터:
Commit time필드에 날짜 필터를 적용합니다.
- 보고서 이름:
- 빌드 및 배포 보고서 만들기: 앞 단계와 같은 방식으로
Build [sn_devops_build]및Deployment [sn_devops_deployment]테이블의 보고서를 만듭니다. 이 테이블에는Build Triggered,Deployment to Production Started,Deployed to Production,Deployment Failed활동에 해당하는 레코드가 있습니다. - 보고서 내보내기: 만든 보고서를 하나씩 실행합니다. 각 보고서에서 컨텍스트 메뉴 아이콘(점 3개 또는 아래쪽 화살표)을 클릭하고
Export > CSV또는Export > Excel을 선택합니다. 모든 파일을 저장합니다. - 데이터 결합 및 변환: 내보낸 파일을 스프레드시트 프로그램에서 열거나 데이터 준비 도구를 사용합니다. 모든 파일의 데이터를 하나의 시트로 수동 결합합니다. 필요한 이벤트 로그 열(
DevelopmentItem,ActivityName,EventTime등)을 만들고 소스 열의 데이터를 매핑합니다. 예를 들어 감사 보고서의Document key와 Story 보고서의Number를DevelopmentItem열에 매핑합니다. - 활동 이름 매핑: 소스 데이터를 변환해
ActivityName열을 만듭니다. 상태 변경 보고서에는 문서화한 상태 모델을 적용해New value값을 활동 이름에 매핑합니다(예: 상태 '테스트'를 'QA 테스트 시작'에 매핑). 나머지 보고서는 각 행에 고정된 활동 이름을 지정합니다(예: 커밋 내보내기 파일의 모든 행에 '코드 커밋' 지정). - 마무리 및 저장: 모든 행에 고정값을 적용해
SourceSystem및LastDataUpdate열을 추가합니다. 모든 타임스탬프의 형식이 일관적인지 확인합니다. 최종 데이터를 하나의 CSV 파일로 저장하면 ProcessMind에 업로드할 준비가 완료됩니다.
구성
- 필수 테이블: 추출에 필요한 주요 테이블은 추론된 이벤트를 확인하는
Audit [sys_audit], 개발 항목별 테이블(예:Story [rm_story],Defect [rm_defect]), 그리고 ServiceNow DevOps의 핵심 테이블인Commit [sn_devops_commit],Build [sn_devops_build],Deployment [sn_devops_deployment]입니다. - 주요 필터: 가장 중요한 필터는 날짜 범위입니다.
Created on,Commit time,시작 시간과 같은 타임스탬프 필드에 설정하고 모든 보고서에 동일하게 적용해야 합니다.sys_audit보고서에서는 관련 상태 변경만 추출하도록Table name(예:rm_story)과Field name(예:state)을 반드시 필터링해야 합니다. - 권장 날짜 범위: 성능 문제를 일으키지 않으면서 대표성 있는 데이터 세트를 확보하려면 3~6개월의 데이터를 추출하는 것이 좋습니다. 규모가 큰 시스템에서는 월별로 나누어 추출하는 방안을 고려하세요.
- 상태 모델 정의: 조직의 작업 항목 상태 모델을 명확히 파악해야 합니다. 그래야
sys_audit테이블에 기록된 상태 값을 'QA Testing Started' 또는 'UAT Approved'와 같은 해당 업무 활동에 올바르게 매핑할 수 있습니다. - 사전 요구 사항: 데이터를 추출하는 사용자에게는 보고서를 만들고 실행할 수 있는
report_user역할 또는 이에 준하는 권한이 필요합니다. 위에 언급한 DevOps 및 애플리케이션 개발 테이블에 대한 읽기 권한도 있어야 합니다. ServiceNow DevOps 플러그인을 설치하고 SCM 및 CI/CD 도구와 연동해야 합니다.
샘플 쿼리 sql
/*
This extraction method uses the ServiceNow report builder UI. The following sections describe the configuration for each report that must be created and exported.
The exported data must then be manually combined and transformed into a single event log file.
*/
---
-- REPORT 1: Item Creation Events
---
Report_Name: ProcessMind - Item Creation Events
Source_Table: rm_story
Report_Type: List
Columns:
- Number (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- 'Development Item Created' (create a formula or static column for ActivityName)
- Assigned to (maps to AssignedDeveloper)
- Priority (maps to DevelopmentItemPriority)
- State (maps to DevelopmentItemState)
- cmdb_ci (maps to ModuleComponentAffected)
- Type (maps to DevelopmentItemType)
- Assignment group (maps to AssignmentGroup)
Filters:
- sys_created_on ON Last 6 months
---
-- REPORT 2: Inferred State Change Events
---
Report_Name: ProcessMind - State Change Events
Source_Table: sys_audit
Report_Type: List
Columns:
- documentkey (maps to DevelopmentItem)
- sys_created_on (maps to EventTime)
- newvalue (maps to ActivityName, requires translation)
- user (maps to AssignedDeveloper)
ActivityName_Mapping_Logic (Example):
- WHEN newvalue IS '[Your Design State]' THEN 'Design Started'
- WHEN newvalue IS '[Your In Progress State]' THEN 'Development Started'
- WHEN newvalue IS '[Your QA State]' THEN 'QA Testing Started'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your In Progress State]' THEN 'Rework Identified'
- WHEN oldvalue IS '[Your QA State]' AND newvalue IS '[Your UAT State]' THEN 'QA Testing Completed'
- WHEN newvalue IS '[Your UAT State]' THEN 'UAT Started'
- WHEN newvalue IS '[Your UAT Approved State]' THEN 'UAT Approved'
- WHEN newvalue IS '[Your Release Ready State]' THEN 'Prepared For Release'
- WHEN newvalue IS '[Your Cancelled State]' THEN 'Development Item Cancelled'
Filters:
- tablename = 'rm_story'
- fieldname = 'state'
- sys_created_on ON Last 6 months
---
-- REPORT 3: Code Commit Events
---
Report_Name: ProcessMind - Commit Events
Source_Table: sn_devops_commit
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- commit_time (maps to EventTime)
- 'Code Committed' (create a formula or static column for ActivityName)
- author.name (maps to AssignedDeveloper)
Filters:
- commit_time ON Last 6 months
---
-- REPORT 4: Build Events
---
Report_Name: ProcessMind - Build Events
Source_Table: sn_devops_build
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime)
- 'Build Triggered' (create a formula or static column for ActivityName)
Filters:
- start_time ON Last 6 months
---
-- REPORT 5: Deployment Events
---
Report_Name: ProcessMind - Deployment Events
Source_Table: sn_devops_deployment
Report_Type: List
Columns:
- work_item.number (maps to DevelopmentItem)
- start_time (maps to EventTime for 'Started' activities)
- end_time (maps to EventTime for 'Completed' or 'Failed' activities)
- state (maps to ActivityName, requires translation)
ActivityName_Mapping_Logic:
- WHEN state IS 'in_progress' THEN 'Deployment to Production Started'
- WHEN state IS 'successful' THEN 'Deployed to Production'
- WHEN state IS 'failed' THEN 'Deployment Failed'
Filters:
- start_time ON Last 6 months
- [Filter for production deployments based on your environment configuration]
---
-- Additional events like 'Code Review Performed' may require a separate report
-- on a table like `sn_devops_pull_request` if available and configured.
--- 단계
- 사전 요건: ServiceNow 인스턴스에 네트워크로 접속할 수 있는지 확인하고, 읽기 권한이 있는 전용 서비스 계정을 발급받습니다. 시작 권한으로
itil및sn_devops.viewer역할을 사용할 수 있습니다. 이 계정은rm_story,sys_audit,sn_devops_*스키마 등의 테이블에 접근할 수 있어야 합니다. - ServiceNow ODBC 드라이버 설치: ServiceNow 지원 포털에서 운영 체제에 맞는 ODBC 드라이버를 다운로드합니다. 제공된 설치 안내에 따라 설치합니다.
- DSN 구성: 쿼리를 실행할 컴퓨터에서 새 시스템 DSN(Data Source Name)을 설정합니다. ODBC 데이터 원본 관리자에서 ServiceNow 드라이버를 추가하고 인스턴스 URL(예:
yourinstance.service-now.com), 사용자 이름, 비밀번호를 입력합니다. - SQL 클라이언트로 연결: DBeaver, Microsoft SQL Server Management Studio(연결된 서버 사용)와 같은 SQL 클라이언트나 ODBC 라이브러리를 사용하는 Python 스크립트로, 구성한 DSN을 통해 ServiceNow에 연결합니다.
- 상태 모델 확인: 쿼리를 실행하기 전에 개발 항목 테이블(예:
rm_story,rm_defect)의state필드에 조직에서 실제로 사용하는 값을 확인해야 합니다. 제공된 쿼리에는 'In Progress', 'In QA'와 같은 일반적인 예시가 있으므로 조직의 실제 값으로 바꿔야 합니다. - SQL 쿼리 맞춤 설정: 제공된 SQL 쿼리를 클라이언트에 복사합니다. 쿼리 상단의 자리표시자를 수정해 추출 시작일과 개발 수명 주기 활동에 해당하는 상태 값을 지정합니다.
- 쿼리 실행: ODBC 연결을 통해 ServiceNow 데이터베이스에서 SQL 쿼리 전체를 실행합니다. 날짜 범위와 데이터 양에 따라 상당한 시간이 걸릴 수 있습니다.
- 데이터 검토: 쿼리가 완료되면 반환된 데이터 세트를 간단히 검토합니다. 다양한 활동이 포함되어 있는지,
DevelopmentItem,ActivityName,EventTime등의 주요 열이 예상대로 채워졌는지 확인합니다. - CSV로 내보내기: 결과 전체를 CSV 파일로 내보냅니다. 파일은 UTF-8로 인코딩하고 열 머리글은
DevelopmentItem,ActivityName,EventTime등 ProcessMind에서 요구하는 속성 이름과 일치시킵니다. - 업로드 준비: 최종 CSV 파일 끝에 빈 행이 없는지 확인합니다.
EventTime및LastDataUpdate의 날짜 형식은 일관적이어야 하며 ProcessMind에서 지원하는 형식(예:YYYY-MM-DD HH:MM:SS)이어야 합니다.
구성
- 사전 요건: DevOps 모듈이 활성화된 ServiceNow 인스턴스에 접근할 수 있어야 합니다. 필요한 테이블에 대한 읽기 권한이 있는 전용 사용자 계정이 필요합니다. 클라이언트 컴퓨터에 ServiceNow ODBC 드라이버를 설치하고 구성해야 합니다.
- ODBC 드라이버 구성: 연결하려면 인스턴스 URL, 사용자 이름, 비밀번호 또는 OAuth 토큰이 필요합니다. 복잡한 쿼리를 실행하기 전에 DSN 연결을 테스트해야 합니다.
- 날짜 범위 필터링: 제공된 쿼리에는 추출 데이터 양을 제한하는
s.sys_created_on >= '2023-01-01'자리표시자가 포함되어 있습니다. 쿼리 실행 시간을 관리할 수 있도록 최근 6~12개월과 같이 기간을 정해 데이터를 추출하는 것이 좋습니다. - 상태 모델 맞춤 설정: 추론 이벤트의 정확도는 상태 모델에 전적으로 달려 있습니다. 자리표시자 상태 값(예:
[Your 'In Progress' State Value],[Your 'In QA' State Value])을 ServiceNow 구성에서 사용하는 정확한 값으로 바꿔야 합니다. 대소문자를 구분합니다. - 작업 항목 테이블: 이 쿼리는 Story 테이블(
rm_story)을 대상으로 작성되었습니다. 조직에서 Defect(rm_defect), Enhancement(rm_enhancement) 또는 다른 작업 유형도 사용한다면 초기DevItems공통 테이블 식(CTE)에UNION ALL로 추가해야 합니다. - 성능: 운영 중인 ServiceNow 인스턴스에 직접 쿼리를 실행하면 성능에 영향을 줄 수 있습니다. 대량 추출은 사용량이 적은 시간대에 실행하는 것이 좋습니다. 데이터가 매우 많다면
sys_updated_on필드를 기준으로 증분 추출하는 방안을 고려하세요.
샘플 쿼리 sql
WITH DevItems AS (
-- This CTE selects the base set of development items to analyze.
-- Add other tables like rm_defect or rm_enhancement here using UNION ALL if needed.
SELECT
s.sys_id,
s.number,
s.sys_created_on,
s.sys_updated_on,
s.assigned_to,
s.priority,
s.state,
s.cmdb_ci, -- Module/Component Affected
s.sys_class_name, -- Development Item Type
s.assignment_group,
DATEDIFF(second, s.sys_created_on, s.closed_at) AS cycle_time_seconds
FROM rm_story s
WHERE s.sys_created_on >= '2023-01-01' -- *** Placeholder: Set your desired start date ***
),
StateChanges AS (
-- This CTE unnests the audit trail for state changes, which are used for inferred activities.
SELECT
a.documentkey AS item_sys_id,
a.sys_created_on AS change_time,
a.oldvalue,
a.newvalue,
-- *** Placeholder: Define the numeric order of your states to detect rework. Adjust values and names. ***
CASE a.oldvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS old_state_order,
CASE a.newvalue
WHEN '1' THEN 1 -- Open
WHEN '[Your 'Design' State Value]' THEN 2
WHEN '[Your 'In Progress' State Value]' THEN 3
WHEN '[Your 'In QA' State Value]' THEN 4
WHEN '[Your 'In UAT' State Value]' THEN 5
ELSE 0
END AS new_state_order
FROM sys_audit a
WHERE a.tablename = 'rm_story' AND a.fieldname = 'state'
)
-- 1. Development Item Created
SELECT
i.number AS DevelopmentItem,
'Development Item Created' AS ActivityName,
i.sys_created_on AS EventTime,
'ServiceNow DevOps' AS SourceSystem,
GETDATE() AS LastDataUpdate,
us.name AS AssignedDeveloper,
i.priority AS DevelopmentItemPriority,
i.state AS DevelopmentItemState,
ci.name AS ModuleComponentAffected,
i.sys_class_name AS DevelopmentItemType,
grp.name AS AssignmentGroup,
i.cycle_time_seconds AS DevelopmentItemCycleTime,
CAST(0 AS BIT) AS IsRework
FROM DevItems i
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id
LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id
LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 2. Design Started
SELECT i.number, 'Design Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Design'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 3. Development Started
SELECT i.number, 'Development Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In Progress'' State Value]' AND sc.old_state_order < 3 -- *** Placeholder: Adjust state value and order ***
UNION ALL
-- 4. Code Committed
SELECT i.number, 'Code Committed', c.committed_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_commit c JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 5. Build Triggered
SELECT i.number, 'Build Triggered', b.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_build b JOIN sn_devops_commit_build cb ON b.sys_id = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
UNION ALL
-- 6. Code Review Performed
SELECT i.number, 'Code Review Performed', pr.closed_at, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_pull_request pr JOIN DevItems i ON pr.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE pr.state = 'merged' -- Or 'closed', depending on process
UNION ALL
-- 7. QA Testing Started
SELECT i.number, 'QA Testing Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In QA'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 8. Rework Identified
SELECT i.number, 'Rework Identified', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(1 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.new_state_order < sc.old_state_order AND sc.new_state_order > 1 -- Moved to an earlier state
UNION ALL
-- 9. QA Testing Completed
SELECT i.number, 'QA Testing Completed', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In QA'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 10. UAT Started
SELECT i.number, 'UAT Started', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''In UAT'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 11. UAT Approved
SELECT i.number, 'UAT Approved', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.oldvalue = '[Your ''In UAT'' State Value]' AND sc.new_state_order > sc.old_state_order -- *** Placeholder: Adjust state value ***
UNION ALL
-- 12. Prepared For Release
SELECT i.number, 'Prepared For Release', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Ready for Release'' State Value]' -- *** Placeholder: Adjust state value ***
UNION ALL
-- 13. Deployment to Production Started
SELECT i.number, 'Deployment to Production Started', se.start_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' -- *** Placeholder: Adjust stage name ***
UNION ALL
-- 14. Deployed to Production
SELECT i.number, 'Deployed to Production', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'SUCCESS' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 15. Deployment Failed
SELECT i.number, 'Deployment Failed', se.end_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, i.state, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM sn_devops_step_execution se JOIN sn_devops_artifact_build sab ON se.deployable = sab.sys_id JOIN sn_devops_commit_build cb ON sab.build = cb.build JOIN sn_devops_commit c ON cb.commit = c.sys_id JOIN DevItems i ON c.work_item = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE se.stage_name = 'Production' AND se.result = 'FAILURE' -- *** Placeholder: Adjust stage name and result value ***
UNION ALL
-- 16. Development Item Cancelled
SELECT i.number, 'Development Item Cancelled', sc.change_time, 'ServiceNow DevOps', GETDATE(), us.name, i.priority, sc.newvalue, ci.name, i.sys_class_name, grp.name, i.cycle_time_seconds, CAST(0 AS BIT)
FROM StateChanges sc JOIN DevItems i ON sc.item_sys_id = i.sys_id
LEFT JOIN sys_user us ON i.assigned_to = us.sys_id LEFT JOIN cmdb_ci ci ON i.cmdb_ci = ci.sys_id LEFT JOIN sys_user_group grp ON i.assignment_group = grp.sys_id
WHERE sc.newvalue = '[Your ''Cancelled'' State Value]'; -- *** Placeholder: Adjust state value *** 시작할 준비가 되셨나요?
오늘부터 소프트웨어 개발 수명 주기를 개선해 보세요. 이 데이터 템플릿으로 숨은 비효율을 찾아내고 지속적인 개선을 추진할 수 있습니다.
더 미루지 말고 지금 소프트웨어 개발 수명 주기를 최적화하세요
비효율을 찾아 SDLC 주기를 30% 이상 단축하세요.
신용카드 없이 지금 바로 최적화를 시작하세요