Szoftverfejlesztési életciklusának adatsablonja

A Development Item az elsődleges esetazonosító, amely egy különálló, nyomon követett munkaegységet jelöl. Összekapcsolja az adott elemhez tartozó összes tevékenységet a kezdeti ötlettől és tervezéstől a fejlesztésen és tesztelésen át az éles bevezetésig.

A process mining elemzésben ez az attribútum alapvető az egyes munkaelemek teljes útjának rekonstruálásához. Segítségével megjeleníthetők a folyamatok, kiszámítható a teljes ciklusidő, és azonosíthatók az egyes funkciók vagy hibajavítások folyamatváltozatai. Az összefüggő folyamattérkép elkészítéséhez a napló minden eseményét egy Development Item elemhez kell kapcsolni.

Ez az alapvető azonosító kapcsolja össze egyetlen folyamatpéldánnyá az összes kapcsolódó fejlesztési tevékenységet, így minden munkaelem teljes életciklusa elemezhető.

Ez az azonosító általában a storykat, hibákat vagy feladatokat kezelő táblák elsődleges kulcsa, például a ServiceNow „rm_story”, „rm_bug” vagy „task” táblájából.

Ez az attribútum adja meg a fejlesztési életciklus egyes tevékenységeinek rögzítési dátumát és időpontját. Nélkülözhetetlen az események időrendi sorrendbe állításához és minden időalapú elemzéshez.

A process mining során a kezdési idő alapján számítható ki a tevékenységek közötti időtartam, azonosíthatók a várakozási idők, és mérhető a folyamat teljes ciklusideje. Teljesítményt elemző dashboardokhoz is szükséges, például az SDLC teljes ciklusidejét vizsgáló elemzéshez, valamint olyan KPI-k kiszámításához, mint a kódellenőrzés átfutási ideje.

Ez az időbélyeg szükséges az események helyes sorrendbe állításához és minden teljesítménymutató kiszámításához, beleértve a ciklusidőket, az időtartamokat és a várakozási időket.

Általában a rendszer által létrehozott időbélyegmezőkben található, például az auditnapló vagy a feladattáblák „sys_updated_on” vagy „sys_created_on” mezőjében.

Ez az attribútum rögzíti a szoftverfejlesztési életciklus során elvégzett mérföldkövek és feladatok nevét. Ezek a tevékenységek alkotják a folyamat egymást követő lépéseit a létrehozástól az éles bevezetésig.

A process mining elsődleges feladata e tevékenységek sorrendjének és gyakoriságának elemzése. Ez teszi lehetővé a folyamattérkép elkészítését, a lépések közötti szűk keresztmetszetek feltárását, valamint a szabályoktól eltérő vagy nem hatékony folyamatváltozatok felismerését. A meghatározott tevékenységek közé tartoznak a fő szakaszok, például a tervezés, a fejlesztés, a tesztelés és az éles bevezetés.

Meghatározza a folyamattérkép lépéseit, így elemezhető a folyamat menete, feltárhatók a szűk keresztmetszetek, és felismerhetők a szabványos SDLC-től való eltérések.

Általában az állapotváltozások, eseményrekordok vagy naplóbejegyzések egységes tevékenységnevekhez rendelésével állapítható meg. Például a „state” mező „In Progress” értékre váltása a „Fejlesztés megkezdve” tevékenységnek felelhet meg.

Ez az attribútum az eseményadatok forrásrendszerét jelöli. Ennél a folyamatnál az értéke mindig „ServiceNow DevOps”.

Bár az érték állandónak tűnhet, a forrásrendszer feltüntetése fontos az adatirányítás szempontjából, különösen akkor, ha több rendszerből, például a Jirából vagy az Azure DevOpsból származó adatokat egyesítenek. Egyértelművé teszi az adatok eredetét, és segít az adatminőségi vagy kinyerési problémák feltárásában.

Biztosítja az adatok nyomon követhetőségét és integritását, különösen akkor, ha több fejlesztőeszköz adatait kapcsolják össze.

Állandó érték, amelyet az adatok kinyerése és átalakítása során kell hozzáadni.

Ez az attribútum rögzíti, mikor nyerték ki vagy frissítették utoljára az adatkészletet a ServiceNow DevOps rendszerből. A teljes adatkészletre vonatkozik, nem az egyes eseményekre.

Ez az időbélyeg megmutatja, mennyire frissek az elemzés adatai. Tájékoztatja a felhasználókat arról, hogy mennyire aktuálisak a folyamatra vonatkozó megállapítások, és segít megtervezni az adatfrissítéseket. Ha ez az információ megjelenik a dashboardokon, kontextust ad a mutatókhoz és az ábrákhoz, így a döntések naprakész adatokon alapulhatnak.

Megmutatja, mennyire frissek az adatok, így a felhasználók tisztában vannak azzal, hogy milyen aktuális a folyamatelemzés.

Az adatok kinyerésekor jön létre és kerül hozzáadásra, rögzítve a kinyerés időpontját.

Ez az attribútum a fejlesztési munkát az érintett rendszerkomponens szerint kategorizálja. Ilyen lehet például egy mikroszolgáltatás, felhasználói felületi komponens vagy háttérrendszeri alkalmazás.

A folyamat modul vagy komponens szerinti bontása segít az adott területre jellemző szűk keresztmetszetek azonosításában. A „Komponensenkénti szűk keresztmetszetek” dashboard és a „Szakasz átlagos időtartama komponensenként” KPI ezt az attribútumot használja annak feltárására, hogy a kódbázis egyes részeihez rendszeresen hosszabb fejlesztési ciklus, több utómunka vagy gyakoribb telepítési hiba társul-e. Így a fejlesztési erőfeszítések oda összpontosíthatók, ahol a legnagyobb szükség van rájuk.

Lehetővé teszi az alkalmazás vagy komponens szerinti elemzést, így elkülöníthetők a rendszer egyes részeihez kötődő szűk keresztmetszetek és minőségi problémák.

Ez gyakran egy egyéni mező vagy a Configuration Management Database (CMDB) rekordjára mutató hivatkozás, amely a munkaelemet egy „cmdb_ci” rekordhoz kapcsolja. További információért tekintse meg a ServiceNow DevOps dokumentációját.

Ez az attribútum a fejlesztési tétel hivatalos állapotát mutatja a ServiceNow rendszerben. A tevékenységek a folyamat lépéseit jelölik, az állapot pedig a rendszerben rögzített formális szakaszt.

Az állapotból gyakran levezethetők a tevékenységek. Adatellenőrzésre és a folyamat egyszerűbb, magas szintű áttekintésére is használható. Az egyes állapotokban eltöltött idő elemzése például más képet adhat a szűk keresztmetszetekről, mint a tevékenységek közötti idő vizsgálata. Az attribútum arra is alkalmas, hogy azonosítsa az elakadt vagy már lezárt tételeket.

Megadja a munkaelem hivatalos rendszerbeli állapotát. Ez gyakran a tevékenységek levezetésének alapja, és adatellenőrzésre, valamint az állapotok magas szintű elemzésére is használható.

A ServiceNow feladatokhoz kapcsolódó tábláiban ez általában egy szabványos mező, amelynek neve „state” vagy „stage”.

Ez a számított mutató egyetlen fejlesztési tétel teljes, elejétől a végéig tartó időtartamát adja meg. Esetenként az első és az utolsó tevékenység időbélyege közötti különbségként számítjuk ki.

Ez az SDLC-folyamat egyik fő teljesítménymutatója, és közvetlenül támogatja az „SDLC átlagos ciklusideje” KPI-t. Magas szinten mutatja a folyamat sebességét és hatékonyságát. Ha ezt az értéket időben, illetve különböző szempontok, például prioritás vagy csapat szerint elemzi, nyomon követheti a folyamatfejlesztési kezdeményezések hatását.

A munkaelem teljes, elejétől a végéig tartó időtartamát mutatja. Ez a folyamat általános hatékonyságának és sebességének fontos mérőszáma.

Ez nem szerepel a forrásrendszer mezői között. A process mining eszköz számítja ki úgy, hogy esetenként kivonja a legkisebb StartTime értéket a legnagyobb StartTime értékből.

Ez az attribútum megkülönbözteti az SDLC-folyamaton áthaladó munka különböző típusait. Egy kritikus hiba javítása például eltérő, gyorsabb folyamatot követhet, mint egy új funkció fejlesztése.

A munkaelem típusa szerinti elemzés árnyaltabb képet ad a teljesítményről. Segít megválaszolni például az ilyen kérdéseket: „A hibák esetében magasabb az utómunka aránya, mint az új funkcióknál?” vagy „Elfogadható a technikai adósság csökkentésének átfutási ideje?” Ez a bontás többet mutat, mint ha minden munkát egyetlen folyamatként vizsgálnánk.

Megkülönbözteti a különböző munkatípusokat, például a funkciókat és a hibákat, amelyek eltérő folyamatútvonalat, prioritást és várható időtartamot követhetnek.

A rekord forrástáblája alapján is meghatározható, például „rm_story” vagy „rm_bug”, illetve egy általános feladattáblán található „type” mezőből.

Ez az attribútum azonosítja a munkaelemhez rendelt csapatot, például a „Frontend fejlesztők”, a „Backend szolgáltatások” vagy a „Minőségbiztosítási csapat” csoportot. A munkaelem a folyamat során gyakran több felelős csoport között kerül átadásra.

A felelős csoport nyomon követése elengedhetetlen a csapatok közötti együttműködés és átadások megértéséhez. Segít feltárni azokat a rendszeres késéseket, amelyek akkor jelentkeznek, amikor a munka egyik csapattól a másikhoz kerül. Az attribútum támogatja a csapatszintű teljesítmény és terhelés elemzését, valamint annak azonosítását, hogy mely csapatok jelentenek szűk keresztmetszetet a teljes folyamatban.

Nyomon követi, melyik csapat felel a munkáért. Segítségével elemezhető a csapatok teljesítménye és terhelése, valamint a csapatok közötti átadások hatékonysága.

Ezt az információt az „assignment_group” mező tárolja, amely a ServiceNow feladatokhoz kapcsolódó tábláinak szabványos mezője.

Ez az attribútum azonosítja az adott feladat vagy tevékenység végrehajtásáért felelős személyt. Értéke változhat, ahogy a fejlesztési elem különböző szakaszok és csapatok között halad.

Ez az attribútum fontos az erőforrások elosztásának, a munkaterhelésnek és az átadásoknak az elemzéséhez. Közvetlenül támogatja a „Fejlesztői munkaterhelés és átadások” dashboardot és a „Tevékenységek száma fejlesztőnként” KPI-t. A mező változásainak követésével mérhető az átadások ideje, és feltárhatók a fejlesztők, illetve a fejlesztési és QA-csapatok közötti együttműködés szűk keresztmetszetei.

Nélkülözhetetlen az erőforrások szerinti elemzéshez, például a munkaterhelés eloszlásának és az átadások hatékonyságának vizsgálatához, valamint a csapatokra jellemző teljesítményminták feltárásához.

Ez az információ általában a ServiceNow feladatokhoz kapcsolódó tábláinak „assigned_to” mezőjében található.

Ez az attribútum az üzleti sürgősségük alapján sorolja kategóriákba a fejlesztési elemeket. A prioritási szintek segítenek a csapatoknak a legsürgősebb feladatokra összpontosítani, és gyakran az SLA-k, valamint az érintettek elvárásainak kezelésére is használják őket.

A process miningben a prioritás fontos összehasonlítási szempont. Segítségével a folyamattérkép a kiemelt prioritású elemekre szűrhető, így látható, hogy ezek gyorsabb vagy eltérő útvonalon haladnak-e. A „Kiemelt prioritású funkciók szállítási ideje” dashboard és KPI kiszámításához is szükséges, mert megmutatja, hogy a kritikus elemek valóban gyorsabban készülnek-e el.

Lehetővé teszi a különböző prioritású folyamatok szűrését és összehasonlítását, így ellenőrizhető, hogy a kiemelt prioritású elemek gyorsabban és hatékonyabban haladnak-e.

Ez egy szabványos mező, amelynek neve a ServiceNow feladatokhoz kapcsolódó tábláiban gyakran „priority”.

Ez a származtatott attribútum azonosítja azokat a tevékenységeket, amelyek akkor történnek, amikor a folyamat visszalép egy korábbi szakaszba. Ha például ugyanannál a tételnél a „Fejlesztés megkezdése” tevékenység a „QA-tesztelés befejezése” után következik, a rendszer utómunkaként jelöli meg.

Ez a jelző szükséges az utómunka méréséhez és megjelenítéséhez. Közvetlenül támogatja az „Utómunka és elutasítás folyamatának elemzése” dashboardot, és az „Utómunka aránya tesztelés után” KPI kiszámítására is használható. A jelölt események alapján az elemzők könnyen szűrhetnek, és megvizsgálhatják az utómunka gyakoriságát, okait, valamint a teljes ciklusidőre gyakorolt hatását.

A jelzővel egyszerűen mérhető és elemezhető az utómunka. Segít felmérni a folyamat minőségét és feltárni az ismétlődő munka okait.

Ezt az attribútumot a process mining eszköz számítja ki az egyes esetek tevékenységsorrendjének elemzésével, hogy felismerje a folyamatban történő visszalépéseket.

Ez az attribútum adja meg, mikor fejeződött be a fejlesztési életciklus egyes tevékenysége. Különösen hasznos a mérhető időtartamú tevékenységeknél, például a „Kódellenőrzés elvégezve” vagy a „QA-tesztelés” esetében.

A process mining során a kezdési és befejezési idő együttesen lehetővé teszi a tevékenységek feldolgozási idejének pontos kiszámítását, elkülönítve azt a tevékenységek közötti várakozási időtől. Így megállapítható, hogy a késést a hosszú feladatok vagy az erőforrásokra való várakozás okozza-e. Az azonnalinak tekintett eseményeknél, például a „Build elindítva” eseménynél, a befejezési idő megegyezhet a kezdési idővel.

Lehetővé teszi a tevékenység feldolgozási idejének pontos kiszámítását, így elkülöníthető a tényleges munkával és a várakozással töltött idő.

Előfordulhat, hogy ezt az értéket ki kell számítani. Lehet a következő tevékenység kezdési időbélyege, vagy származhat a forrásrendszer külön „end date” mezőjéből, ha ilyen rendelkezésre áll.

Ez az attribútum közvetlen kapcsolatot teremt a fejlesztési tétel és a forráskód-tárolóban, például a Gitben végrehajtott konkrét kódmódosítás között. A rendszer a „Code Committed” tevékenység rögzítésekor menti el.

A process mining során a Commit ID a folyamatadatokat mérnöki adatokkal egészíti ki. Az elemzők visszakereshetik, hogy egy problémás telepítés pontosan melyik kódmódosításhoz kapcsolódik, vagy összevethetik a kód összetettségi mutatóit a fejlesztési ciklusidőkkel. Ez részletesebb, műszaki szintű gyökérok-elemzést tesz lehetővé.

A folyamat eseményét egy konkrét kódmódosításhoz kapcsolja, így a folyamatmutatók és a kódszintű részletek összevetésével mélyebb gyökérok-elemzés végezhető.

Ezt a ServiceNow DevOps Githez vagy SVN-hez hasonló forráskód-kezelő rendszerekkel való integrációi rögzítik. Az adatok a fejlesztési tételhez kapcsolódó táblákban találhatók.

Ez az attribútum rögzíti az adott környezetbe történő telepítés eredményét. Fontos információ a kiadási folyamat megbízhatóságának és stabilitásának megértéséhez.

Ez az attribútum szükséges a „Sikeres és sikertelen telepítések alakulása” dashboardhoz és a „Sikertelen telepítések aránya” KPI-hoz. A telepítési hibák gyakoriságának és alakulásának elemzésével a szervezetek feltárhatják a tesztelés, az infrastruktúra vagy a kiadások összehangolása mögött meghúzódó problémákat. Az eredmények segítenek a szoftverkiadás minőségének és megbízhatóságának javítására összpontosítani.

Közvetlenül méri a telepítési tevékenységek sikerességét. Ez szükséges a sikertelen telepítések arányának kiszámításához és a kiadási folyamat stabilitásának elemzéséhez.

Ezt az állapotot általában a telepítéseket nyomon követő feladatok vagy a ServiceNow DevOps rendszerbe integrált CI/CD-folyamatok végrehajtási rekordjai rögzítik.

Ez az attribútum egy konkrét, tervezett kiadáshoz kapcsolja a fejlesztési tételt, például a „2.3-as verzióhoz” vagy a „2023. negyedik negyedévi kiadáshoz”. A projektmenedzsment és a kiadástervezés fontos eleme.

A process mining szempontjából ez az attribútum szükséges a „Kiadási terv teljesülésének nyomon követése” dashboardhoz. A tényleges befejezési dátumok és a tervezett kiadási dátumok összevetésével a csapatok mérhetik az ütemterv betartását, azonosíthatják a kiadásból várhatóan kimaradó tételeket, és elemezhetik a késések okait. Közvetlen kapcsolatot teremt a fejlesztési folyamat részletei és a magas szintű üzleti célok között.

A fejlesztési munkát konkrét kiadásokhoz kapcsolja, így elemezhető az ütemterv betartása és a folyamat késéseinek hatása a kiadási határidőkre.

Ezt az információt általában a „release” vagy „planned_release” mező tárolja, amely gyakran a ServiceNow kiadáskezelési táblájára hivatkozik. További információért tekintse meg a ServiceNow DevOps dokumentációját.

Ha egy tétel nem felel meg a QA- vagy UAT-tesztelésen, ez az attribútum rögzíti a hiba okát. Ilyen lehet egy konkrét hibakategória, a követelmények félreértése vagy egy környezeti probléma.

Ez az információ fontos hátteret ad az „Utómunka és elutasítás folyamatának elemzése” dashboardhoz. Az elemzők nemcsak azt látják, hogy történt-e utómunka, hanem annak okát is megérthetik. Így célzott fejlesztések végezhetők, például pontosabban meghatározhatók a követelmények, bővíthető az egységtesztelés, vagy stabilabbá tehetők a tesztkörnyezetek, csökkentve az utómunka teljes arányát.

Segít megérteni, miért van szükség utómunkára. Ez lehetővé teszi a célzott folyamatfejlesztést, a minőség javítását és az ismétlődő munkafázisok csökkentését.

A teszt sikertelensége esetén ez a „close_notes” mezőben vagy egy erre szolgáló egyéni „rework_reason” mezőben szerepelhet. További információért tekintse meg a ServiceNow DevOps dokumentációját.