Vianratkaisun kesto

Kysymys: Kuinka kauan projektissa menee vikojen korjaamiseen, kun ne on raportoitu ja kirjattu?

Synonyymit: Virheenratkaisun kesto

Kuvaus

Mikä on mediaaniaika projektille tehdystä viasta ilmoittamisen (käyttämällä projektin vikailmoitusmekanismia) ja sen hetken välillä, jolloin projekti korjaa vian? Huomaa, että ratkaisu voi olla päivityksen käsitteleminen (ratkaiseminen ja yhdistäminen) ja päivityksen saattaminen käyttäjien saataville tai nimenomainen valinta olla käsittelemättä (hylätä).

Huomautus:

  1. Tämä määritelmä määrittelee päättymisajan, jolloin korjaus hyväksytään (yhdistetään julkiseen pääkonttoriin tai julkaistaan) tai hylätään verrattuna siihen, milloin ohjelmistolle tehdään uusi virallinen julkaisu (tämä mahdollistaa vian ratkaisemisen, jossa vain muutama käyttäjä välitä sen kiinnittämisestä). Esimerkiksi, jos vika katsotaan korjatuksi, siihen liittyvän raportin sulkeminen (esim. ongelma) on linkitettävä yhdistettyyn muutospyyntöön tai muuhun koodin muutokseen, mukaan lukien koontiohjeet (kääntäjän liput tai muut rakennusaikaiset kokoonpanokohteet).
  2. Kaikki raportit/ongelmat eivät ole tarkkoja, ja monet tarkat raportit/ongelmat eivät ole vikoja (esim. ominaisuuspyynnöt ja asiakastukipyynnöt).
  3. Projektilla voi näyttää olevan nopea vasteaika, koska se hylkää nopeasti kaikki vikailmoitukset ikään kuin raportit eivät kuvaisi vikoja. Lisäksi haitalliset toimittajat voivat luoda suuren määrän virheellisiä vikailmoituksia. Tämä mittari ei yritä vangita näitä tilanteita. mittareiden käyttäjien pitäisi sen sijaan katsoa, ​​onko tällaisia ​​käytäntöjä koskevia indikaattoreita.
  4. Vian ilmaisemiseen käytetyt tunnisteet vaihtelevat, ja vianratkaisuanalyysissä on otettava huomioon tutkittavien projektien kokoelmassa käytetyt tarrat.
  5. Tarkoitus ei ole käsitellä tätä mittaria palvelutasosopimuksena (SLA), koska avoimen lähdekoodin projekteja ylläpitävät vapaaehtoiset ja ratkaisuaika vaihtelee projekteittain aktiivisten ylläpitäjien mukaan.

Viat sisältävät kaiken ohjelmiston, joka ei toimi oikein (esim. määritetyllä tavalla). Kehitystoiminnan virheistä johtuvia käyttöönottoongelmia ei pidetä ohjelmistovirheinä.

Tavoitteet

  1. Ymmärtää, kuinka kauan kuluu vikailmoituksen vastaanottamisen ja sen ratkaisun saamisen välillä ohjelmiston käyttäjien saataville.
  2. Ymmärtää avoimen lähdekoodin projektien vianratkaisuajan keskiarvoa, mediaania tai muita tilastollisia mittareita projektille, tietovarastolle tai portfoliolle.
    1. Vikailmoituksissa on usein poikkeavuuksia, esim. vähämerkityksistä vikaa voi olla vaikea ilmoittaa, ja siksi sen korjaaminen kestää hyvin kauan. Tästä syystä olemme suositelleet mediaania ensisijaiseksi mittariksi.
    2. Vianratkaisun ymmärtäminen kokoelmassa toisiinsa liittyviä tietovarastoja, organisaatioita tai projekteja.

Täytäntöönpano

Terveysmittareiden käyttö ja levittäminen voi johtaa yksityisyyden loukkauksiin. Organisaatiot voivat altistua riskeille. Nämä riskit voivat johtua GDPR-asetuksen noudattamisesta EU:ssa, Yhdysvaltain osavaltion lain tai muun lainsäädännön noudattamisesta. Tietojen tarjoajien, kuten GitHubin ja GitLabin, palveluehdoista voi myös aiheutua sopimusriskejä. Mittareiden käyttöä on tutkittava riskien ja mahdollisten dataeettisten ongelmien varalta. Ole hyvä ja katso CHAOSS Data Ethics -asiakirja lisäohjeita varten.

Useimmissa suurissa Git-alustoissa on "ongelmien seuranta", joissa ominaisuuspyyntöjä, vikoja ja käyttöönottotukikysymyksiä ei eroteta automaattisesti toisistaan. Ongelmiin, ongelmatunnisteisiin ja muihin metatietoihin käytetään suodattimia, jotta ne erottavat viat ja muun tyyppiset ongelmat.

Suodattimet

Sisällytä suodatin

  • Vianratkaisu sidottu koodin muutokseen tai muutospyynnöt
  • Vianratkaisun nopeus mittaa yhteenlaskettua (keskimääräistä, keskiarvoa, mediaani) aikaa, joka kuluu vian tunnistamisen ja sen sulkemisen välillä yhdistämällä muutospyynnöt.
  • Mikä tahansa ongelma, joka on merkitty vian ratkaisuksi, kun koodi yhdistetään käyttäjien saatavilla olevaan versioon (tunnisteet vaihtelevat arkiston mukaan).
  • GitHubissa, GitLabissa, Bugzillassa, SourceForgessa tai missä tahansa muussa ongelmanseurantajärjestelmässä olevat tarrat, jotka osoittavat, että "ongelma" edustaa ohjelmistovirhettä.
  • Linkitetty ongelma muutospyynnöt, tai osoitus siitä, että ongelma ei liity johonkin prosenttiosuuteen muutospyynnöt.

visualisointeja

Four Keys -projektia voidaan muokata niin, että se keskittyy vikojen ratkaisuun ja vaikutuksiin.

Neljä avainprojektia

Lähde: Tämä kuva on peräisin [Four Keys -projektista] (https://github.com/GoogleCloudPlatform/fourkeys)

lupaavat

Augurin visualisointisovellusliittymää voidaan käyttää suodattimella vikatunnisteisiin.

Lähde: Tämä kuva on peräisin lupaavat ja http://new.augurlabs.io

Grimoirelab

Grimoirelab voi käyttää virheisiin liittyviä suodattimia muuttaakseen pyyntötietoja.

Lähde: Tämä kuva on peräisin GrimoireLab

Mittarin antavat työkalut

Tiedonkeruustrategiat

Ongelmien kerääminen ongelmanseurantaohjelmasta vastaavien tunnisteiden kanssa ja alustavan arvion tekeminen siitä, heijastaako raportti ongelmaa.

Viitteet

  1. Ongelmiin reagointikyky
  2. Aika sulkea
  3. https://ieeexplore.ieee.org/document/8285884

Osallistujat

  • Duane O'Brian
  • David Wheeler
  • Kate stewart
  • Renisha Nellums
  • Vinod Ahuja
  • Sean Goggins
  • Sofia Vargas

Tämä mittari tarkistettiin viimeksi 24. helmikuuta 2022 osana 1. maaliskuuta 2022 julkaistun CHAOSS Metrics -julkaisun tarkistusjaksoa.