Yazılım Geliştirme Yaşam Döngüsü Veri Template'iniz

Bu öznitelik, geliştirme yaşam döngüsündeki her etkinliğin ne zaman kaydedildiğine dair tarih ve saat bilgisini sağlar. Event'lerin kronolojik sıralaması ve tüm zamana dayalı analizler için esastır.

Process Mining'de başlangıç zamanı, etkinlikler arasındaki süreleri hesaplamak, bekleme sürelerini belirlemek ve sürecin genel döngü süresini ölçmek için kullanılır. SDLC Uçtan Uca Döngü Süresi Analizi gibi performansı analiz eden Dashboard'lar ve Kod İncelemesi Teslim Süresi gibi temel performans göstergelerini hesaplamak için kritik bir bileşendir.

Bu zaman damgası, event'leri doğru bir şekilde sıralamak ve döngü süreleri, süreler ve bekleme süreleri dahil olmak üzere tüm performans metriklerini hesaplamak için esastır.

Tipik olarak denetim izi veya görev tablolarından 'sys_updated_on' veya 'sys_created_on' gibi sistem tarafından oluşturulan zaman damgası alanlarında bulunur.

Bu öznitelik, yazılım geliştirme yaşam döngüsü içinde tamamlanan her dönüm noktası veya görevin adını kaydeder. Bu etkinlikler, oluşturmadan dağıtıma kadar sürecin sıralı adımlarını oluşturur.

Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining'in birincil işlevidir. Süreç haritasının oluşturulmasını sağlar, adımlar arasındaki bottleneck'leri (darboğazları) belirlemeye yardımcı olur ve uyumlu olmayan veya verimsiz süreç varyasyonlarını vurgular. Tanımlanan etkinlik kümesi, tasarım, geliştirme, test ve dağıtım gibi temel aşamaları içerir.

Süreç haritasındaki adımları tanımlar; süreç akışının analizini, bottleneck'lerin (darboğazların) belirlenmesini ve standart SDLC'den sapmaların keşfedilmesini sağlar.

Bu, tipik olarak durum değişiklikleri, event kayıtları veya denetim izi girişlerini standartlaştırılmış bir etkinlik adı listesine eşleyerek türetilir. Örneğin, bir 'state' alanının 'Devam Ediyor' olarak değişmesi 'Geliştirme Başlatıldı' ile eşleşebilir.

Geliştirme Öğesi, izlenen ayrı bir iş birimini temsil eden birincil case tanımlayıcısı olarak hizmet eder. İlk konsept ve planlamadan geliştirme, test ve dağıtıma kadar o belirli öğeye yönelik tüm etkinlikleri birbirine bağlar.

Process Mining analizinde, bu öznitelik her bir iş öğesinin uçtan uca yolculuğunu yeniden yapılandırmak için temeldir. Süreç akışlarının görselleştirilmesine, toplam döngü sürelerinin hesaplanmasına ve bireysel özellikler veya hata düzeltmeleri için süreç varyantlarının belirlenmesine olanak tanır. Tutarlı bir süreç haritası oluşturmak için Event Log'daki her event'in bir Geliştirme Öğesi ile ilişkilendirilmesi gerekir.

Bu, ilgili tüm geliştirme etkinliklerini tek bir süreç örneğine bağlayan temel tanımlayıcıdır ve her iş öğesinin tam yaşam döngüsünü analiz etmeyi mümkün kılar.

Bu tanımlayıcı, genellikle ServiceNow'daki 'rm_story', 'rm_bug' veya 'task' tabloları gibi story'leri, bug'ları veya görevleri yöneten tabloların birincil anahtarıdır.

Bu öznitelik, event verisinin kaynak sistemini belirtir. Bu süreç için tutarlı bir şekilde 'ServiceNow DevOps' olacaktır.

Statik görünse de, kaynak sistemini açıkça dahil etmek, veri yönetimi için ve verilerin Jira veya Azure DevOps gibi birden fazla sistemden birleştirilebileceği ortamlarda çok önemlidir.

veri izlenebilirliğini sağlar ve özellikle birden fazla geliştirme aracından veri entegre ederken veri bütünlüğünü korumak için hayati öneme sahiptir.

Bu, veri çekimi ve dönüştürme süreci sırasında eklenmesi gereken statik bir değerdir.

Bu öznitelik, veri kümesinin ServiceNow DevOps'tan en son ne zaman ayıklandığını veya güncellendiğini kaydeder. Bireysel event'lerden ziyade tüm veri kümesine uygulanır.

Bu zaman damgası, analizin güncelliğini anlamak için hayati öneme sahiptir. Kullanıcılara süreç içgörülerinin ne kadar güncel olduğunu bildirir ve veri yenilemelerini planlamaya yardımcı olur. Bu bilgiyi Dashboard'larda görüntülemek, tüm metrikler ve görselleştirmeler için bağlam sağlayarak kararların zamanında verilere dayanmasını sağlar.

Verilerin güncelliği hakkında kritik bağlam sunarak, kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamalarını sağlar.

Bu zaman damgası, data extraction işlemi sırasında oluşturulur ve eklenir; extraction işleminin ne zaman yürütüldüğünü kaydeder.

Bu öznitelik, bir iş öğesine atanmış ekibi tanımlar; örneğin 'Frontend Geliştiriciler', 'Backend Hizmetleri' veya 'QA Ekibi'. Bir iş öğesi ilerledikçe, genellikle farklı atama grupları arasında aktarılır.

Atama grubunu izlemek, çapraz fonksiyonel işbirliğini ve aktarımları anlamak için çok önemlidir. İş bir ekipten diğerine geçtiğinde ortaya çıkan sistemik gecikmeleri belirlemeye yardımcı olur. Bu öznitelik, ekip düzeyinde performans, iş yükü analizi ve genel akıştaki bottleneck (darboğaz) ekiplerini belirlemeyi destekler.

İşten hangi ekibin sorumlu olduğunu izler; ekip performansının, iş yükü dengelemesinin ve ekipler arasındaki aktarımların verimliliğinin analizini sağlar.

Bu bilgi, ServiceNow'daki görevle ilgili tablolarda standart bir alan olan 'assignment_group' alanında saklanır.

Bu öznitelik, belirli bir görevi veya etkinliği yürütmekten sorumlu kişiyi tanımlar. Dinamiktir ve geliştirme öğesi farklı aşamalar ve ekipler arasında hareket ettikçe değişebilir.

Bu öznitelik, kaynak tahsisi, iş yükü ve aktarımların analizi için kritik öneme sahiptir. 'Geliştirici İş Yükü ve Aktarımlar' Dashboard'unu ve 'Geliştirici Başına Etkinlik Hacmi' KPI'ını doğrudan destekler. Bu alandaki değişiklikleri izleyerek, aktarım sürelerini ölçmek ve geliştiriciler veya geliştirme ile QA ekipleri arasındaki işbirliği bottleneck'lerini (darboğazlarını) belirlemek mümkündür.

Bu, iş yükü dağıtımı, aktarım verimliliği ve ekibe özel performans kalıplarını belirleme dahil olmak üzere kaynak tabanlı analiz için esastır.

Bu bilgi, genellikle ServiceNow'daki görevle ilgili tablolarda 'assigned_to' alanında saklanır.

Bu öznitelik, geliştirme işini sistemin etkilediği kısmına göre kategorize eder. Bu, belirli bir microservice, bir UI bileşeni veya bir backend uygulaması olabilir.

Süreci modüle veya bileşene göre segmentlere ayırmak, yerelleşmiş bottleneck'leri (darboğazları) belirlemek için çok önemlidir. 'Bileşene Özel Bottleneck İçgörüleri' Dashboard'u ve 'Bileşene Göre Ortalama Aşama Süresi' KPI'ı, kod tabanının belirli kısımlarının sürekli olarak daha uzun geliştirme döngüleri, daha yüksek yeniden işleme oranları veya daha sık dağıtım hatalarıyla ilişkilendirilip ilişkilendirilmediğini belirlemek için bu özniteliğe dayanır. Bu, iyileştirme çabalarını en çok ihtiyaç duyulan yere odaklamaya yardımcı olur.

Analizin uygulama veya bileşen bazında segmentlere ayrılmasını sağlayarak, sistemin belirli bölümlerine özgü darboğazları veya kalite sorunlarını izole etmeye yardımcı olur.

Bu, genellikle özel bir alan veya Yapılandırma Yönetimi Veritabanına (CMDB) bir referanstır ve iş öğesini bir 'cmdb_ci' kaydına bağlar. ServiceNow DevOps belgelerine danışın.

Bu öznitelik, tek bir geliştirme öğesi için uçtan uca süreyi temsil eden hesaplanmış bir metriktir. Her case için en ilk etkinlik ile en son etkinlik arasındaki zaman damgasının farkı bulunarak hesaplanır.

Bu, tüm SDLC süreci için birincil bir temel performans göstergesidir ve 'Ortalama SDLC Döngü Süresi' KPI'ını doğrudan destekler. Süreç hızının ve verimliliğinin üst düzey bir ölçümünü sağlar. Bu metriği zaman içinde ve öncelik veya ekip gibi farklı boyutlarda analiz etmek, süreç iyileştirme girişimlerinin etkisini izlemeye yardımcı olur.

Bir iş öğesi için toplam uçtan uca süreyi temsil eder; bu, genel süreç verimliliğini ve hızını ölçmek için önemli bir metriktir.

Bu, kaynak sisteminde bir alan değildir. Process Mining aracında, her CaseId için maksimum Başlangıç Zamanı'ndan minimum Başlangıç Zamanı çıkarılarak hesaplanır.

Bu öznitelik, ServiceNow içindeki geliştirme öğesinin resmi durumunu yansıtır. Etkinlikler türetilmiş süreç adımları olsa da, state sistemin Workflow'undaki resmi aşamayı temsil eder.

State, genellikle etkinliklerin türetildiği kaynaktır. Veri doğrulama ve sürecin daha basit, üst düzey görünümlerini oluşturmak için kullanılabilir. Örneğin, her state'te harcanan süreyi analiz etmek, etkinlikler arasındaki süreyi analiz etmeye kıyasla bottleneck'lerin (darboğazların) farklı bir görünümünü sağlayabilir. Ayrıca takılı kalan veya çözülmüş öğeleri belirlemek için de kullanışlıdır.

Bir iş öğesinin resmi sistem durumunu sağlar; bu durum, genellikle etkinlikleri türetmek için bir kaynak olup doğrulama ve üst düzey durum analizi için kullanılabilir.

Bu, genellikle ServiceNow'daki görevle ilgili tablolarda 'state' veya 'stage' olarak adlandırılan standart bir alandır.

Bu öznitelik, SDLC süreci boyunca akan farklı iş türleri arasında ayrım yapar. Örneğin, kritik bir hatayı düzeltme süreci, yeni bir özellik geliştirme sürecinden farklı ve daha hızlı olabilir.

Süreci iş öğesi türüne göre analiz etmek, performansın daha ayrıntılı bir şekilde anlaşılmasını sağlar. 'Hataların yeni özelliklerden daha yüksek bir yeniden işleme oranı var mı?' veya 'Teknik borç azaltma döngü süremiz kabul edilebilir mi?' gibi soruları yanıtlamaya yardımcı olur. Bu segmentasyon, tek tip bir süreç görünümünden daha derin içgörüler sağlar.

Farklı süreç yolları, öncelikler ve beklenen süreleri olabilecek özellikler ve hatalar gibi farklı iş türleri arasında ayrım yapar.

Bu, kaydın kaynak tablosundan (örn. 'rm_story' veya 'rm_bug') veya genel bir görev tablosundaki 'type' alanından belirlenebilir.

Bu öznitelik, geliştirme öğelerini iş aciliyetlerine göre kategorize eder. Öncelik düzeyleri, ekiplerin en kritik görevlere odaklanmasına yardımcı olur ve genellikle SLA'ları ve paydaş beklentilerini yönetmek için kullanılır.

Process Mining'de öncelik, karşılaştırmalı analiz için önemli bir boyuttur. Süreç haritasını filtreleyerek yüksek öncelikli öğelerin daha hızlı veya farklı bir yol izleyip izlemediğini görmeye olanak tanır. 'Yüksek Öncelikli Özellik Teslim Süresi' Dashboard'u ve KPI'ı için temeldir, kritik öğelerin gerçekten hızlandırılıp hızlandırılmadığını doğrulamaya yardımcı olur.

Farklı öncelik seviyeleri için süreçleri filtrelemeye ve karşılaştırmaya olanak tanıyarak, yüksek öncelikli kalemlerin daha hızlı ve verimli işlenip işlenmediğini doğrulamaya yardımcı olur.

Bu, genellikle ServiceNow'daki görevle ilgili tablolarda 'priority' olarak adlandırılan standart bir alandır.

Bu, bir süreç önceki bir aşamaya geri döndükten sonra meydana gelen etkinlikleri tanımlayan türetilmiş bir özniteliktir. Örneğin, aynı öğe için 'QA Testleri Tamamlandı' etkinliğinden sonra bir 'Geliştirme Başlatıldı' etkinliği meydana gelirse, yeniden işleme (rework) olarak işaretlenir.

Bu bayrak, yeniden işlemeyi nicel olarak ölçmek ve görselleştirmek için esastır. 'Yeniden İşleme ve Reddetme Akış Analizi' Dashboard'unu doğrudan destekler ve 'Test Sonrası Yeniden İşleme Oranı' KPI'ını hesaplamak için kullanılır. Bu event'leri işaretleyerek, analistler yeniden işlemenin sıklığını, nedenlerini ve genel döngü süresi üzerindeki etkisini kolayca filtreleyebilir ve analiz edebilirler.

Bu bayrak, yeniden işlemeyi (rework) nicel olarak ölçmeyi ve analiz etmeyi kolaylaştırır, süreç kalitesini ölçmeye ve tekrarlanan işin temel nedenlerini belirlemeye yardımcı olur.

Bu öznitelik, süreç akışındaki geriye doğru hareketleri tespit etmek için her case için etkinlik dizisini analiz ederek Process Mining aracı içinde hesaplanır.

Bu öznitelik, geliştirme yaşam döngüsündeki her etkinliğin ne zaman tamamlandığına dair tarih ve saat bilgisini sağlar. Özellikle 'Kod İncelemesi Yapıldı' veya 'QA Testi' gibi ölçülebilir bir süresi olan etkinlikler için kullanışlıdır.

Process Mining'de hem başlangıç hem de bitiş zamanına sahip olmak, etkinlik işlem sürelerinin hassas bir şekilde hesaplanmasına olanak tanır ve bunları etkinlikler arasındaki bekleme süresinden ayırır. Bu, gecikmelerin uzun görevlerden mi yoksa kaynaklar için uzun beklemelerden mi kaynaklandığını belirlemeye yardımcı olur. 'Yapı Tetiklendi' gibi anlık kabul edilen event'ler için Bitiş Zamanı, Başlangıç Zamanı ile aynı olabilir.

Etkinlik işlem süresinin kesin olarak hesaplanmasını sağlayarak, çalışma süresi ile bekleme süresi arasındaki ayrımı yapmaya yardımcı olur.

Bu durumun türetilmesi gerekebilir. Bir sonraki etkinliğin başlangıç zamanının zaman damgası olabilir veya kaynak sistemde mevcutsa ayrı bir 'bitiş tarihi' alanından alınabilir.

Bu öznitelik, bir geliştirme öğesinden Git gibi kaynak kodu deposundaki belirli kod değişikliğine doğrudan bir bağlantı sağlar. 'Kod Committed' etkinliği gerçekleştiğinde yakalanır.

Process Mining'de Commit ID, süreç verilerini mühendislik verileriyle bağlayarak analizi zenginleştirir. Analistlerin sorunlu bir dağıtımı tam kod değişikliğine kadar takip etmesine veya kod karmaşıklığı metriklerini geliştirme döngü süreleriyle ilişkilendirmesine olanak tanır. Bu, çok daha derin, daha teknik bir kök neden analizi katmanı sağlar.

Süreç olayını belirli bir kod değişikliğine bağlar, bu sayede süreç metriklerini kod seviyesi detaylarla ilişkilendirerek daha derinlemesine kök neden analizi yapılmasını sağlar.

Bu, ServiceNow DevOps entegrasyonları tarafından Git veya SVN gibi kaynak kod yönetimi sistemleriyle yakalanır. Veri, geliştirme öğesine bağlı ilgili tablolarda bulunur.

Bu öznitelik, belirli bir ortama yapılan bir dağıtımın sonucunu kaydeder. Release sürecinin güvenilirliğini ve kararlılığını anlamak için kritik bir bilgi parçasıdır.

Bu öznitelik, 'Dağıtım Başarısı ve Hata Trendleri' Dashboard'u ve 'Dağıtım Hata Oranı' KPI'ı için esastır. Dağıtım hatalarının sıklığını ve trendlerini analiz ederek, kuruluşlar test, altyapı veya release koordinasyonundaki temel sorunları belirleyebilirler. Yazılım teslimatının kalitesini ve güvenilirliğini iyileştirme çabalarını odaklamaya yardımcı olur.

Dağıtım faaliyetlerinin başarısını doğrudan ölçer; bu, dağıtım hata oranını hesaplamak ve sürüm istikrarını analiz etmek için kritik öneme sahiptir.

Bu durum, genellikle ServiceNow DevOps ile entegre dağıtım izleme görevlerinde veya CI/CD pipeline yürütme kayıtlarında kaydedilir.

Bu öznitelik, bir geliştirme öğesini 'Sürüm 2.3' veya '2023 Q4 Sürümü' gibi belirli, planlanmış bir release'e bağlar. Proje yönetimi ve release planlaması için temel bir unsurdur.

Process Mining için bu öznitelik, 'Release Planına Uyumluluk İzleme' Dashboard'u için kritik öneme sahiptir. Gerçek tamamlanma tarihlerini planlanan release tarihlerine karşılaştırarak, ekipler zaman çizelgesi uyumluluğunu ölçebilir, bir release'i kaçırma riski taşıyan öğeleri belirleyebilir ve release gecikmelerinin nedenlerini analiz edebilir. Düşük seviyeli geliştirme süreci ile üst düzey iş hedefleri arasında doğrudan bir bağlantı sağlar.

Geliştirme çalışmalarını belirli sürümlerle ilişkilendirerek, takvime uyumu ve süreç gecikmelerinin sürüm zaman çizelgeleri üzerindeki etkisini analiz etmeyi sağlar.

Bu bilgi, genellikle ServiceNow'daki bir release management tablosuna atıfta bulunan 'release' veya 'planned_release' alanında saklanır. ServiceNow DevOps belgelerine danışın.

Bir öğe QA veya UAT'yi geçemediğinde, bu öznitelik hatanın nedenini yakalar. Bu, belirli bir bug kategorisi, gereksinimlerin yanlış anlaşılması veya çevresel bir sorun olabilir.

Bu bilgi, 'Yeniden İşleme ve Reddetme Akış Analizi' Dashboard'u için kritik bir bağlam sağlar. Analistler, sadece yeniden işlemenin gerçekleştiğini bilmek yerine, neden gerçekleştiğini anlayabilirler. Bu, genel yeniden işleme oranını azaltmak için daha iyi gereksinim tanımı, geliştirilmiş birim testi veya daha kararlı test ortamları gibi hedefe yönelik iyileştirmelere olanak tanır.

Yeniden işleme nedenlerine dair niteliksel içgörüler sunarak, kaliteyi artırmak ve yeniden işleme döngülerini azaltmak için hedefe yönelik süreç iyileştirmeleri yapılmasını sağlar.

Bu, bir test başarısız olduğunda 'close_notes' alanında veya özel bir 'rework_reason' özel alanında yakalanabilir. ServiceNow DevOps belgelerine danışın.