Menu

Vejledning til rodårsagsanalyse - trin, teknikker og eksempler

  • Vigtigste
  • Andet
  • Vejledning til rodårsagsanalyse - trin, teknikker og eksempler

guide root cause analysis steps

Prøv Vores Instrument Til At Fjerne Problemer

Denne vejledning forklarer, hvad der er rodårsagsanalyse og forskellige teknikker til rodårsagsanalyse som fiskebenanalyse og 5 hvorfors teknik:

RCA (rodårsagsanalyse) er en struktureret og effektiv proces til at finde årsagen til problemer i et Software Project-team. Hvis det udføres systematisk, kan det forbedre ydelsen og kvaliteten af ​​leverancerne og processerne, ikke kun på teamniveau, men også på tværs af organisationen.

Denne tutorial hjælper dig med at definere og strømline Root Cause Analysis-processen i dit team eller din organisation.

Grundårsagsanalyse

Denne tutorial er beregnet til Delivery Managers, Scrum Masters, Project Managers, Quality Managers, Development Team, Test Team, Information Management Team, Quality Team, Support Team osv. For at forstå det grundlæggende i Root Cause Analysis og giver skabeloner og eksempler på det .

Hvad du lærer:

Hvad er rodårsagsanalyse?

RCA (rodårsagsanalyse) er en mekanisme til analyse af defekterne for at identificere årsagen. Vi brainstormer, læser og graver defekten for at identificere, om manglen skyldtes “ test miss ',' udvikling miss ”Eller var en“ krav eller design savner ”.

Når RCA udføres nøjagtigt, hjælper det med at forhindre defekter i de senere udgivelser eller faser. Hvis vi finder ud af, at en mangel skyldtes design miss , kan vi gennemse designdokumenterne og træffe passende foranstaltninger. Tilsvarende, hvis vi finder ud af, at en mangel skyldtes test miss , kan vi gennemgå vores testtilfælde eller metrics og opdatere det i overensstemmelse hermed.

RCA bør ikke kun være begrænset til at teste manglerne. Vi kan også lave RCA på produktionsfejl. Baseret på RCA's beslutning kan vi forbedre vores Test seng og inkludere disse produktionsbilletter som Regression Test-sager. Dette vil sikre, at defekten eller lignende mangler ikke gentages.

Rødårsag Analyseproces

Introduktion

RCA bruges ikke kun til defekter rapporteret fra et kundeside, men også til UAT-defekter, Unit Testing defects, Business og operationelle procesniveauproblemer, daglige livsproblemer osv. Derfor bruges det i flere brancher som Softwaresektor, fremstilling, sundhed, banksektor osv.

Gennemførelse af rodårsagsanalyse svarer til arbejdet hos den læge, der behandler en patient. Lægen vil først forstå symptomerne. Derefter henviser han til laboratorietest for at analysere årsagen til sygdommen.

Hvis grundårsagen til sygdommen stadig er ukendt, vil lægen henvise til scanningstest for at forstå yderligere. Han vil fortsætte diagnosen og studere, indtil han indsnævrer til årsagen til patientens sygdom. Den samme logik gælder for rodårsagsanalyse udført i enhver branche.

Så RCA er rettet mod at finde årsagen og ikke behandle symptomet ved at følge et specifikt sæt trin og tilhørende værktøjer. Det adskiller sig fra fejlanalyse, fejlfinding og andre metoder til problemløsning, da disse metoder forsøger at finde løsningen til det specifikke problem, men RCA forsøger at finde den bagvedliggende årsag.

Oprindelsen af ​​navnet Root Cause Analysis:

Oprindelsen af ​​navnet Root Cause Analysis

(billede kilde )

Blade, stamme og rødder er de vigtigste dele af et træ. Blade (Symptom) og bagagerum (Problem), der er over jorden, er synlige, men rødder (Årsag), der er under jorden, er ikke synlige, og rødderne vokser dybere og kan sprede sig mere, end vi forventer. Derfor kaldes processen med at grave til bunden af ​​problemet Root Cause Analysis.

Fordele ved rodårsagsanalyse

Nedenfor er nogle af de fordele, du får:

  • Undgå gentagelse af det samme problem i fremtiden.
  • Til sidst reducer antallet af rapporterede mangler over tid.
  • Reducerer udviklingsomkostninger og sparer tid.
  • Forbedre softwareudviklingsprocessen og dermed hjælpe hurtig levering til markedet.
  • Forbedrer kundetilfredshed.
  • Øg produktiviteten.
  • Find skjulte problemer i systemet.
  • Hjælper med kontinuerlig forbedring.

Typer af rodårsager

# 1) Menneskelig årsag: Menneskeskabte fejl.

Eksempler:

  • Under dygtige.
  • Instruktioner, der ikke følges behørigt.
  • Udførte en unødvendig operation.

# 2) Organisatorisk årsag: En proces, som folk bruger til at træffe beslutninger, der ikke var korrekte.

Eksempler:

  • Vage instruktioner blev givet fra Team Lead til teammedlemmer.
  • Valg af den forkerte person til en opgave.
  • Overvågningsværktøjer, der ikke er på plads for at vurdere kvaliteten.

# 3) Fysisk årsag: Enhver fysisk genstand mislykkedes på en eller anden måde.

Eksempler:

  • Computeren genstarter.
  • Serveren starter ikke op.
  • Mærkelige eller kraftige lyde i systemet.

Skridt til at udføre analyse af rodårsager

En struktureret og logisk tilgang er påkrævet for en effektiv rodårsagsanalyse. Derfor er det nødvendigt at følge en række trin.

Trin til at udføre analyse af rodårsager

# 1) Form RCA Team

Hvert hold skal have en dedikeret Root Cause Analysis Manager (RCA Manager) der indsamler detaljerne fra supportteamet og indleder startprocessen for RCA. Han koordinerer og tildeler ressourcer, der har brug for at deltage i RCA-møder afhængigt af det angivne problem.

Hold, der deltager i mødet, skal have personale fra hvert hold (Krav, design, test, dokumentation, kvalitet, support og vedligeholdelse), der er mest fortrolige med problemet. Holdet skal også have folk, der også er direkte knyttet til manglen. For eksempel, Supportingeniøren, der gav en øjeblikkelig løsning til kunden.

Del problemoplysningerne med holdet, inden du deltager i mødet, så de kan foretage en indledende analyse og være forberedt. Teammedlemmer indsamler også information relateret til manglen. Afhængigt af hændelsesrapporten vil hvert hold spore, hvad der gik galt w.r.t til dette scenario i deres respektive faser. At være forberedt vil øge effektiviteten af ​​den kommende diskussion.

# 2) Definer problemet

Saml detaljerne i problemet som hændelsesrapporter, problembevis (skærmbillede, logfiler, rapporter osv.), Og studer / analyser derefter problemet ved at stille nedenstående spørgsmål:

  • Hvad er problemet?
  • Hvad er rækkefølgen af ​​begivenheder, der førte til problemet?
  • Hvilke systemer var involveret?
  • Hvor længe problemet eksisterede?
  • Hvad er virkningen af ​​problemet?
  • Hvem var involveret og fastslå, hvem der skulle interviewes?

Brug 'SMART' regler til at definere dit problem:

  • S SPECIFIK
  • M NEMLIG
  • TIL CTION-ORIENTERET
  • R ELSKENDE
  • T NAVN-BUNDET

John Dewey citat

# 3) Identificer rodårsagen

Udfør BRAINSTORMING session inden for RCA-teamet, der blev dannet for at identificere årsagerne. Brug Fishbone diagram eller 5 Hvorfor analyse metode eller begge for at nå frem til grundårsagen / -erne.

RCA-leder bør moderere mødet og indstille reglerne for Brainstorming-sessionen. For eksempel kan reglerne være:

  1. Kritik / skylden på andre bør ikke være tilladt.
  2. Bedøm ikke andres ideer. Ingen ideer er dårlige, de tilskynder vilde ideer.
  3. Byg videre på ideerne om andre. Tænk over, hvordan du kan bygge videre på andres ideer og gøre det bedre.
  4. Giv hver deltager god tid til at dele deres synspunkter.
  5. Tilskynd tænkning uden for boksen.
  6. Forbliv fokuseret.

Alle ideer skal registreres. RCA-manager skal tildele et medlem til at registrere referatet af mødet og opdatere RCA-skabeloner.

# 4) Implementere rodårsag korrigerende handling (RCCA)

Korrektionshandling indebærer, at løsningen løses ved at identificere den virkelige grundårsag. For at lette dette skal en leveringschef være til stede, der kan beslutte, i hvilke alle versioner rettelsen skal implementeres, og hvad der skal være leveringsdatoen.

RCCA skal implementeres på en sådan måde, at denne grundårsag ikke vil forekomme igen i fremtiden. Rettelse fra supportteamet vil være midlertidig for det kundeside, hvor problemet rapporteres. Når denne rettelse flettes til en løbende version, skal du foretage korrekt indvirkningsanalyse for at sikre, at ingen eksisterende funktion brydes.

Giv trinnene for at validere rettelsen og overvåg den implementerede løsning for at kontrollere, om løsningen er effektiv.

# 5) Implementere rodårsag forebyggende handling (RCPA)

Holdet skal komme med en plan for, hvordan et sådant lignende problem kan forhindres i fremtiden. For eksempel, Opdater instruktionsmanual, forbedr færdighedssættet, opdater teamlistevurderingslisten osv. Følg korrekte dokumenter om forebyggende handlinger, og overvåg, om holdet overholder de udførte forebyggende handlinger.

Se dette forskningsartikel om 'Fejlanalyse og forebyggelse af forbedring af softwareprocessens kvalitet' offentliggjort i International Journal of Software Engineering & Applications for at få en idé om, hvilke typer fejl der er rapporteret i hver softwarefase og foreslået forebyggende handlinger for dem.

Oplysningerne fra RCA kan gå som input til Fejltilstand og effektanalyse (FMEA ) for at identificere punkter, hvor løsningen kan mislykkes.

Implementere Pareto-analyse med årsagerne identificeret under RCA over en periode, sig halvårligt eller kvartalsvis, hvilket vil hjælpe med at identificere de største årsager, der bidrager til manglerne og fokusere på forebyggende handling for dem.

Duke Ellington citat

Root Cause Analysis Techniques

# 1) Fiskebenanalyse

Fishbone diagram er et visuelt rodårsagsanalyseværktøj til at identificere de mulige årsager til de identificerede problemer, og derfor kaldes det også Cause and Effect diagram. Det giver dig mulighed for at komme ned til den virkelige grundårsag til problemet i stedet for at løse dets symptom.

Det kaldes også Ishikawa-diagrammet, som det blev oprettet af Dr. Kaoru Ishikawa (en japansk statistik over kvalitetskontrol). Det er også kendt som sildben eller Fishikawa-diagram.

Fishbone analyse bruges i analysefasen af seks sigma's DMAIC tilgang til problemløsning. Det er en af ​​de 7 grundlæggende værktøjer til kvalitetskontrol .

Trin til at oprette et Fishbone Diagram:

Fishbone-diagram ligner skelettet på en fisk med problemet, der danner fiskens hoved og forårsager dannelse af rygsøjlen og knoglerne på fisken.

Følg nedenstående trin for at oprette et fiskebensdiagram:

  1. Skriv problem ved fiskens hoved .
  2. Identificer kategori af årsager og skriv kl slutningen af ​​hver knogle (årsagskategori 1, årsagskategori 2 …… årsagskategori N)
  3. Identificer primære årsager under hver kategori og marker det som primær årsag 1, primær årsag 2, primær årsag N.
  4. Udvid årsagerne til sekundære, tertiære og flere niveauer alt efter hvad der er relevant.

FIshbone_template

Et eksempel på, hvordan et fishbone-diagram anvendes på en softwarefejl (se nedenfor).

FIshbone_softwareDefect

Der er mange gratis såvel som betalte værktøjer til rådighed til oprettelse af et fishbone-diagram. Fishbone-diagrammet i denne vejledning blev oprettet ved hjælp af ' Kreativt ' online værktøj . Flere detaljer om fiskebenskabeloner og -værktøjer vil blive forklaret i vores næste vejledning.

# 2) 5 Whys-teknikken

5 Hvorfor teknik blev udviklet af Sakichi Toyoda og blev brugt hos Toyota i deres fremstillingsindustri. Denne teknik henviser til en række spørgsmål, hvor hvert svar besvares med et hvorfor-spørgsmål. Det kan relateres til, hvordan et barn vil stille spørgsmål til voksne. Baseret på det svar, som voksne giver, vil de stille ”hvorfor” spørgsmål igen og igen, indtil de er tilfredse.

5 Hvorfor teknik bruges uafhængigt eller som en del af fiskebenanalyse til at bore ned til årsagen til problemet. Antallet af trin er ikke begrænset til 5. Det kan være mindre eller mere end 5, indtil diagnosen af ​​problemet er ankommet. 5 Hvorfor er relativt en enklere teknik og hurtigere måde at nå frem til grundårsagerne. Det letter hurtig diagnose for at udelukke symptomerne og nå frem til grundårsagen.

Teknikens succes afhænger af personens viden. Der kan være forskellige svar på det samme hvorfor-spørgsmål. Så det er vigtigt at vælge den rigtige retning og fokus i mødet.

Trin til at oprette 5 Whys diagram

Start brainstorming-diskussionen ved at definere problemet. Følg derefter med efterfølgende hvorfor og deres svar.

5Hvorfor_skabelon

Et eksempel på, hvordan 5 Whys-diagram anvendes på en softwarefejl:

5Why_Software_Defect Eksempel

5 Hvorfor tegnes skabeloner og billeder ved hjælp af Creately online-software.

Faktorer, der forårsager defekter

Der er mange faktorer, der provokerer manglerne:

  • Uklare / manglende / forkerte krav
  • Forkert design
  • Forkert kodning
  • Utilstrækkelig testning
  • Miljøproblemer (hardware, software eller konfigurationer)

Disse faktorer skal altid holdes for øje, når du udfører RCA-processen.

RCA starter og fortsætter med brainstorming om defekten. Det eneste spørgsmål, som vi stiller os selv, mens vi laver RCA, er 'HVORFOR?' og hvad?' Vi kan grave i hver fase af livscyklussen for at spore, hvor manglen vedvarer.

Lad os starte med 'HVORFOR?' spørgsmål (listen er ikke begrænset). Du kan starte fra den ydre fase og bevæge dig mod den indre fase af SDLC.

forskel mellem port forwarding og triggering
  • 'HVORFOR' blev fejlen ikke fanget i løbet af Sanity Test i produktion?
  • “HVORFOR” blev fejlen ikke fanget under testen?
  • “HVORFOR” blev fejlen ikke fanget under gennemgangen af ​​testsagen?
  • ”HVORFOR” blev fejlen ikke fanget Enhedstest ?
  • “HVORFOR” blev fejlen ikke fanget under “Design Review”?
  • “HVORFOR” blev fejlen ikke fanget i kravfasen?

Svaret på dette spørgsmål giver dig den nøjagtige fase, hvor manglen findes. Når du først har identificeret fasen og årsagen, så kommer “HVAD” -delen.

”HVAD vil du gøre for at undgå dette i fremtiden?

Svaret på dette 'HVAD' -spørgsmål, hvis det implementeres og behandles, vil forhindre, at den samme defekt eller den slags defekt opstår igen. Tag passende forholdsregler for at forbedre den identificerede proces, så manglen eller årsagen til manglen ikke gentages.

Baseret på resultaterne af RCA kan du bestemme, hvilken fase der har problemområder.

For eksempel, hvis du finder ud af, at de fleste af RCA-fejlene skyldes krav frøken , så kan du forbedre kravindsamlings- / forståelsesfasen ved at indføre flere anmeldelser eller gennemgangssessioner.

Tilsvarende, hvis du finder ud af, at de fleste mangler skyldes test miss , skal du forbedre testprocessen. Du kan introducere metrics som Krav Sporbarhedsmålinger , Test dækningsmålinger eller kan kontrollere kontrolprocessen eller ethvert andet trin, som du mener vil forbedre testens effektivitet.

Konklusion

Det er hele teamets ansvar at sidde og analysere manglerne og bidrage til produkt- og procesforbedring.

I denne vejledning har du en grundlæggende forståelse af RCA, trin, der skal følges for at udføre en effektiv RCA og forskellige værktøjer, der skal bruges, såsom Fishbone-analyse og 5 Why Technique. I de kommende tutorials vil der blive dækket forskellige RCA-skabeloner, eksempler og brugssager om, hvordan de implementeres.

Anbefalet læsning

^