Szoftverfejlesztési életciklus: adatsablon

Az esemény kezdési időpontja azt a pontos dátumot és időt jelöli, amikor egy tevékenység elkezdődött. Ez határozza meg az egyes esetek eseményeinek időrendi sorrendjét, ami elengedhetetlen a folyamat pontos rekonstruálásához.

Az időbélyegek képezik az időalapú process mining elemzések alapját. Segítségükkel kiszámíthatók a fontos teljesítménymutatók, például a ciklusidő, a várakozási idő és a tevékenységek közötti feldolgozási idő. Az időbélyegek elemzése feltárja a szűk keresztmetszeteket, segít mérni a folyamat hatékonyságát, és megmutatja a fejlesztési életciklus egyes szakaszainak időtartamát. Például a „Kód beküldve felülvizsgálatra” és a „Kódellenőrzés befejezve” közötti időből kiderülhet, ha késések vannak a felülvizsgálat során.

Ez az időbélyeg szükséges az események helyes sorrendbe állításához és az időalapú mutatók, például a ciklusidő kiszámításához, valamint a szűk keresztmetszetek feltárásához.

Az eseménynaplókban, auditnaplókban vagy a fejlesztési munkaelemek változásait rögzítő előzménytáblákban található.

A fejlesztési munkaelem azonosítója az elsődleges kulcs, amely egyedileg azonosítja az egyes eseteket a szoftverfejlesztési életciklus során. Minden azonosító egy különálló munkát jelöl, például egy user storyt, feladatot vagy hibajavítást, a létrehozástól a végleges megoldásig vagy élesítésig.

A process mining elemzésben ez az attribútum elengedhetetlen az egyes munkaelemek teljes útjának rekonstruálásához. Segítségével az eszköz összekapcsolja a kapcsolódó tevékenységeket, például a „Fejlesztés megkezdve”, a „Kódellenőrzés befejezve” és az „Éles környezetbe telepítve” eseményeket, így összeáll a folyamat egységes képe. Az egyes fejlesztési munkaelemek életciklusának elemzése feltárja az adott munkához kapcsolódó eltéréseket, késéseket és ismétlődő javítási köröket.

Ez az alapvető esetazonosító szükséges ahhoz, hogy a fejlesztési munkaelemek teljes életciklusa az elejétől a végéig nyomon követhető legyen.

Általában a szoftverfejlesztést kezelő rendszer fő munkaelem- vagy hibajegy-nyilvántartó tábláiban található.

A tevékenység neve a fejlesztési folyamat egy konkrét lépését vagy állapotváltozását írja le. Ezek a tevékenységek alkotják a folyamattérkép csomópontjait, és olyan fontos mérföldköveket jelölnek, mint a „Fejlesztésre jóváhagyott munkaelem”, a „Kód beküldve felülvizsgálatra” vagy a „QA-tesztelés befejezve”.

Ez az attribútum elengedhetetlen a folyamat megjelenítéséhez és az események sorrendjének megértéséhez. A különböző tevékenységek elemzésével a csapatok feltárhatják a leggyakoribb útvonalakat és a folyamat eltéréseit, valamint megmérhetik az egyes szakaszok időtartamát. Ez adja a szűk keresztmetszetek elemzésének, az ismételt munka feltárásának és a célfolyamathoz való megfelelés ellenőrzésének alapját.

Meghatározza a folyamat lépéseit, így megjeleníthető és elemezhető a fejlesztési munkafolyamat.

Gyakran a fejlesztési munkaelemekhez kapcsolódó állapotváltozási naplókból, eseményadatokból vagy auditelőzményekből származik.

Az adatok utolsó frissítése attribútum rögzíti, mikor nyerték ki vagy frissítették legutóbb az adatokat a forrásrendszerből. Ez egyértelműen jelzi, mennyire frissek és relevánsak az adatok.

Ez az információ segít biztosítani, hogy az elemzések és a dashboardok aktuális adatokra épüljenek. Az érintettek egy pillantással láthatják, mennyire naprakész a folyamat képe, így jobban bízhatnak az abból levont következtetésekben. Az adatfolyamatok kezeléséhez és az adatfrissítések ütemezéséhez is fontos metaadat.

Jelzi az adatok frissességét, így az elemzés időben rendelkezésre áll a döntéshozatalhoz, és releváns információkra épül.

Ezt az értéket általában az adatkinyerést, -átalakítást és -betöltést végző ETL-folyamat állítja elő és tárolja.

A forrásrendszer attribútum azonosítja azt az alkalmazást vagy platformot, amelyben a fejlesztési életciklus adatait rögzítették. Ez különösen hasznos olyan környezetben, ahol több fejlesztőeszközt használnak, például a Jira rendszert hibajegyek kezelésére és a GitLabot a forráskód kezelésére.

Az elemzés során a forrásrendszer megadása segíti az adatok ellenőrzését, és kontextust ad a folyamatadatok értelmezéséhez. Lehetővé teszi a különböző rendszerekben kezelt folyamatok összehasonlítását, és segít helyesen értelmezni az adatokat, mivel a mezőnevek és a folyamatszabályok rendszerenként eltérhetnek. Az elemzés egy adott eszköz adataira is szűrhető vele.

Megadja az adatok eredetét, ami fontos az adatok ellenőrzéséhez és a több integrált rendszert érintő elemzésekhez.

Ez általában az adatkinyerés során hozzáadott állandó érték, amely azonosítja a rekordok forrását.

Ez az attribútum azonosítja azt a csapatot, squadot vagy csoportot, amely a fejlesztési tétel megvalósításáért felel. A nagyobb szervezetekben a munka gyakran több szakosodott csapat között oszlik meg, például a „Frontend”, a „Backend”, a „Mobile” vagy a „Platform” csapat között.

A csapat neve szerinti elemzés lehetővé teszi a teljesítmény összehasonlítását és a bevált gyakorlatok megosztását. Segít megválaszolni például, hogy „Melyik csapatnál a legrövidebb az átfutási idő?” vagy „Van olyan csapat, ahol több utómunkára van szükség?”. Az elemzés feltárhatja a munkafolyamatok, a készségek vagy az erőforrások elérhetősége közötti különbségeket, amelyek befolyásolják a teljesítés eredményességét. Ezek alapján célzottan fejleszthetők a folyamatok.

Lehetővé teszi a csapatok teljesítményének összehasonlítását, és segít azonosítani a bevált gyakorlatokat, valamint a fejlesztendő területeket.

Gyakran a felelős felhasználóhoz kapcsolódik, vagy közvetlen mezőként szerepel a projekt vagy a munkatétel adatlapján.

Az esemény befejezési ideje jelzi egy tevékenység végét. Sok folyamatlépést pillanatnyi eseményként rögzítenek, ilyenkor a kezdési és befejezési idő megegyezik. Más tevékenységeknek mérhető időtartamuk van. Például a „Code Review” tevékenységnek külön kezdési és befejezési ideje lehet.

Ez az attribútum szükséges az egyes feladatok aktív feldolgozási idejének kiszámításához, és segít elkülöníteni azt a várakozási időtől. Az esemény kezdési és befejezési ideje közötti időtartamot összehasonlítva az elemzők megmérhetik, mennyi időt fordítottak értékteremtő tevékenységekre. Így részletesebben elemezhető az erőforrások kihasználtsága, és azonosíthatók azok a feladatok, amelyek a legtöbb aktív munkaidőt igénylik.

Lehetővé teszi az egyes tevékenységek aktív feldolgozási idejének kiszámítását, elkülönítve azt a várakozási időtől, így pontosabban látható, mennyi munkát igényeltek.

Az eseménynaplókban található meg, vagy az adott munkatétel következő tevékenységének időbélyegéből vezethető le.

A fejlesztési tétel állapota azt mutatja, milyen állapotban volt a munkatétel egy adott időpontban. A tevékenység neve az állapotváltozás eseményét rögzíti, ez az attribútum pedig magát az állapotot. Segítségével elemezhető, milyen állapotban volt a munka egy esemény bekövetkezésekor.

Ezt az attribútumot gyakran a tevékenység nevének létrehozásához használják, de további kontextust is adhat. Az állapotmező elemzésével például megállapítható, mennyi időt töltenek a tételek egy adott állapotban, például „Blokkolva” vagy „Ellenőrzésre vár”. A nem produktív állapotokban töltött idő ismerete segít feltárni a rendszeres késéseket és javítani a folyamat áramlását.

Lehetővé teszi a különböző állapotokban töltött idő elemzését, így azonosíthatók a késések és az olyan, értéket nem teremtő állapotok, mint a „Blokkolva”.

A munkatétel vagy a hibajegy adatlapján alapmezőként érhető el, és az előzményekben is rögzítik.

A prioritás attribútum a munkatétel üzleti vagy műszaki sürgősségét jelzi. Értéke általában „Magas”, „Közepes” vagy „Alacsony”, és segít a csapatoknak eldönteni, mivel foglalkozzanak először.

A process mining elemzésekben a prioritás fontos szempont. Segítségével ellenőrizhető, hogy a magas prioritású tételek valóban gyorsabban haladnak-e, mint az alacsony prioritásúak. A különböző prioritási szintek átfutási idejének összehasonlítása megmutatja, hogy a folyamat figyelembe veszi-e az üzleti prioritásokat. Ha a magas prioritású tételek gyakran késnek, az tervezési, erőforrás-elosztási vagy munkafolyamat-tervezési problémára utalhat.

Segít ellenőrizni, hogy a magas prioritású munka gyorsabban halad-e a folyamatban, és feltárja azokat a szűk keresztmetszeteket, amelyek aránytalanul hátráltatják a kritikus tételeket.

A legtöbb fejlesztéskezelő rendszerben a munkatétel vagy a hibajegy adatlapjának alapértelmezett mezője.

Ez az attribútum a végzett munka jellegét határozza meg. A különböző típusú munkatételek gyakran eltérő folyamatokon mennek végig, és más teljesítményelvárások vonatkoznak rájuk. Egy Bug például gyors javítást igényelhet, míg egy Feature a szokásos fejlesztési és tesztelési ciklust követi.

Az elemzők ezzel az attribútummal összehasonlíthatják a különböző munkatípusok folyamatait és teljesítményét. Így megválaszolható például, hogy „Gyorsabban javítjuk a hibákat, mint ahogy az új funkciókat fejlesztjük?” vagy „Több utómunkát igényelnek a technikai adósságot érintő tételek?”. Ez az attribútum alapvető szempont az adatok szegmentálásához, hogy részletesebb, konkrét intézkedéseket megalapozó elemzések készülhessenek.

Lehetővé teszi a különböző munkakategóriák folyamatainak és teljesítményének összehasonlítását, így feltárhatók az egyes fejlesztéstípusokra jellemző hatékonysági problémák.

A legtöbb fejlesztéskezelő rendszerben a munkatétel vagy a hibajegy adatlapjának alapértelmezett mezője.

Ez az attribútum azonosítja azt a személyt vagy csoportot, aki az aktuális lépésért vagy a teljes munkatételért felel. A felelős a tétel életciklusa során többször is változhat, például amikor a fejlesztők, a QA-tesztelők és az ellenőrök között gazdát cserél a munka.

A felelős attribútum elemzésével feltárható a csapatok leterheltsége, az átadások hatékonysága és az együttműködés mintázata. A folyamattérkép egy adott személy vagy csapat munkájára szűrhető, így azonosíthatók az egyes erőforrásokhoz köthető szűk keresztmetszetek. A felelősök közötti átadásokra épülő közösségi hálózatelemzés kommunikációs hiányosságokra vagy túl bonyolult együttműködési struktúrákra is rávilágíthat.

Segít elemezni az erőforrások leterheltségét, az átadások gyakoriságát és az együttműködés mintázatait, így hatékonyabbá tehető a csapat munkája.

A munkatétel vagy a hibajegy adatlapján található meg, gyakran az előzményekben vagy az auditnaplóban rögzítik.

A projekt neve megadja a kontextust, és csoportosítja az adott termékhez, kezdeményezéshez vagy kódbázishoz tartozó munkatételeket. A fejlesztési gyakorlatok és az átfutási idők projektenként jelentősen eltérhetnek, például egy régi rendszer és egy új alkalmazás esetében.

Ez az attribútum lehetővé teszi a fejlesztési folyamatok magas szintű összesítését és összehasonlítását a szervezet különböző területein. A projekt szerinti szűréssel a vezetők felmérhetik az egyes fejlesztési feladatok állapotát és hatékonyságát. Az attribútum abban is segít megérteni, hogyan függ össze a folyamat teljesítménye a projekt sajátosságaival és műszaki környezetével.

Lehetővé teszi a folyamatok termék vagy kezdeményezés szerinti elemzését, és feltárja a projektkörnyezetből adódó teljesítménykülönbségeket.

A munkatétel vagy a hibajegy adatlapjának alapértelmezett mezője, illetve Githez hasonló rendszerekben a kódtár neve.

A súlyosság nem azonos a prioritással: a probléma műszaki hatását méri, míg a prioritás a javítás sürgősségét jelzi. Egy ritkán látogatott oldalon lévő elírás például alacsony súlyosságú és alacsony prioritású lehet, míg egy kritikus adatsérülési probléma magas súlyosságú és magas prioritású.

Ez az attribútum különösen hasznos a minőség elemzéséhez, főként a hibajavítási folyamatok vizsgálatakor. Segítségével a csapatok felmérhetik, hogy valóban a legsúlyosabb problémákat kezelik-e először. A különböző súlyossági szintek átfutási idejének elemzésével ellenőrizhető, hogy a kritikus rendszerhibákat gyorsan elhárítják-e, így mérsékelve az ügyfelekre gyakorolt hatást.

Lehetővé teszi annak elemzését, hogy a csapat mennyire hatékonyan kezeli a problémákat azok műszaki hatása alapján, és segít biztosítani a kritikus hibák gyors megoldását.

A fejlesztéskezelő rendszerekben általában alapmező, különösen a „Bug” vagy „Incident” típusú munkatételeknél.

A létrehozó attribútum azonosítja azt a személyt, aki elindította a munkatételt. Lehet például termékmenedzser, aki felhasználói történetet hoz létre, QA-tesztelő, aki hibát rögzít, vagy ügyfélszolgálati munkatárs, aki bejelent egy ügyfélproblémát.

A munkatételek létrehozójának elemzése megmutathatja, honnan érkezik a munka. Ha például a végfelhasználók sok hibát jelentenek, az a legutóbbi kiadások minőségi problémáira utalhat. A létrehozó és a későbbi utómunka vagy késések összefüggéseit vizsgálva a kezdeti követelmények egyértelműsége és minősége is elemezhető.

Segít azonosítani, ki kezdeményezi a munkát, így feltárhatók az igények, a hibák és a funkciókérések forrásai.

A munkatétel létrehozásakor rögzített alapmező, például a „Bejelentő” vagy a „Szerző”.

A tervezett kiadás attribútum egy adott kiadási ütemtervhez vagy verzióhoz kapcsolja a fejlesztési tételt. A kiadástervezés során gyakran használják a funkciók és javítások összehangolt telepítésre szánt csoportosítására.

A tervezett kiadás szerinti elemzés segít felmérni a kiadási folyamat kiszámíthatóságát és megbízhatóságát. A tervezett kiadás és a tényleges telepítési dátum összevetésével nyomon követhető a határidőre teljesített kiadások aránya. Az attribútum emellett segít a terjedelem kezelésében és az adott kiadásra szánt munka alakulásának megértésében, valamint rávilágít a szállítási ütemtervet veszélyeztető kockázatokra és késésekre.

A fejlesztési munkát a kiadási ütemtervhez kapcsolja, így elemezhető a határidőre teljesített kiadások aránya és a kiadási folyamat kiszámíthatósága.

Az agilis tervező- és fejlesztőeszközökben használt alapmező, például „Fix Version”, „Target Release” vagy „Iteration Path” néven.

Az utómunka jelzője egy levezetett logikai vagy kategóriás attribútum, amely megmutatja, hogy az esemény egy utómunka-ciklus része-e. Ezt jellemzően akkor állapítják meg, ha a folyamat visszalép, például a „QA Testing” állapotból visszatér a „Development in Progress” állapotba, vagy ha olyan konkrét utómunkát jelző tevékenység történik, mint a „Rework Identified in QA”.

Ez az attribútum különösen hasznos a minőség és a hatékonyság elemzéséhez. Közvetlenül kiszámítható vele az utómunka aránya, és azonosíthatók a folyamat azon részei, amelyek a legtöbb utómunkát okozzák. Az utómunkát jelző tevékenységekre szűrve a csapatok feltárhatják, miért nem derülnek ki korábban a minőségi problémák. Az utómunka csökkentése egyszerre javíthatja a fejlesztés sebességét és a termék minőségét.

Közvetlenül számszerűsíti az utómunkát, így a csapatok mérhetik annak gyakoriságát, elemezhetik az okait, és nyomon követhetik a minőség időbeli javulását.

Általában az adatátalakítás során vezetik le a folyamatban lévő visszalépések vagy a konkrét hibára utaló tevékenységnevek azonosításával.