Konfigurasjonskontroll-slipp håndjernene!

den stadig mer komplekse, globale naturen til all virksomhet på tvers av bransjer og vertikale sektorer, kombinert med raske brann, “Internet Time” forretningsmodeller, driver ny vekt på endringsledelse. Evnen til effektivt å håndtere endring fremstår som en differensierende nøkkel blant konkurrenter-slik at organisasjoner kan utvikle forretningsmodeller og produktlinjer, og skifte gir raskt nok til å møte mulighetene i dagens økonomi – foran konkurransen.

som organisasjoner sliter med å styre prosjekter i dette miljøet, Har Konfigurasjonsstyring (CM) blitt en stadig mer kritisk komponent, og tilbyr et rammeverk for å håndtere endring.

disiplinen CM består av seks kompetanseområder som definert AV EIA-649 (ANSI, 2004))

• CM Planning and Management (CMPM),
• Configuration Identification (CI),
• Configuration Change Management (CCM),
• Configuration Status Accounting (CSA),
• Configuration Verification & Revisjoner (CVA) og
• CM Av Digitale Data.

IMIDLERTID grupperer ISO 10007 (ISO, 2003) CM I fire klassifiseringer:

• CI,
• Konfigurasjonskontroll (CC),
• CSA og
• Konfigurasjonsgjennomganger Og-Revisjoner (R&A).

(CCM og CC er for alle praktiske formål identiske, som ER CVA Og R& A.)

Merk at konfigurasjonskontroll er omtalt i denne artikkelen. Configuration change management og change control er også begreper som brukes for å beskrive den samme prosessen.

mange prosjektledere oppfatter konfigurasjonskontroll som begrensende og begrensende systemer designet for å stunt produktutvikling og som vanligvis påvirker prosjektets tidsplan på en negativ måte. Dessverre, altfor ofte generiske CC prosesser designet for store, komplekse programmer som våpen eller medisinske systemer utvikling, er pålagt andre typer prosjekter. Disse prosessene er ikke skreddersydd for å møte behovene til For Eksempel En webutviklingsinnsats eller en ny produktutrulling. Dette fører til slutt til intens frustrasjon med CC-prosessen og” håndjern ” – effekten – hvor prosesser som ikke er utformet for å møte programmets behov, påvirker fremdriften negativt.

Prosjektledere implementerer konfigurasjonskontroll for å kontrollere og spore endringer. Prosessene er utformet for å sikre at riktig nivå brukes til å godkjenne endringer, og at disse endringene er basert på best tilgjengelig informasjon. Prosessene gir et rammeverk for endringsgjennomgang. Dette gjør det mulig for teamet å vurdere om implementeringen av endringen er akseptabel og å identifisere potensielle problemer i tide. Disse prosessene tillater kalibrering, og om nødvendig ytterligere revisjon.

det virkelige spørsmålet er ikke om man skal implementere konfigurasjonskontroll, men hvilket nivå av konfigurasjonskontroll som skal implementeres. En organisasjon kan kreve en” firmastandard ” konfigurasjonskontrollpakke på alle prosjekter. Denne typen system er ofte pålagt prosjektteam på grunn av en historie med mangel på konfigurasjonskontroll, og den resulterende økonomiske effekten. Prosjektledere, som erkjenner at en” one-size-fits-all ” tilnærming ikke vil fungere, må vise at nødvendige kontroller er på plass for å unngå å gjenta tidligere feil.

Konfigurasjonskontroll I Aksjon

det typiske utviklingsprosjektet krever ikke en konfigurasjonskontrollprosess på nivå med et større våpensystem. Det er viktig å styrke teamet med riktig nivå av fleksibilitet samtidig sikre at et system av sjekker og balanserer er på plass. Nøkkelen til ethvert system er innsatsen som kreves for å dokumentere prosessen, sammen med dokumentasjonen som kreves av prosessen. PRØVEN CC prosessen beskrevet nedenfor er utformet for å møte kravene i en liten til mellomstor programutviklingsprosjekt.

prosjektgruppen bør først analysere riktig rolle konfigurasjonskontroll på prosjektet. Dette, som et minimum på et programvareprosjekt, ville innebære et tema for å dokumentere alle kodefiler internt og noen form for ekstern dokumentasjon. Andre områder å dekke inkluderer endringsgodkjenning og endringsdokumentasjonsprosesser. Enkel konsensus av de involverte deltakerne bør være tilstrekkelig. Selvfølgelig er et strukturert styre innkalt regelmessig bedre.

la Oss nå komme inn i de ulike aspektene av den enkle Konfigurasjonskontrollprosessen.

Dokumenter

Configuration Management Plan (Cmp) vil definere CC-prosessen. I noen applikasjoner der CC-prosessen er ganske detaljert, utvikles En Konfigurasjonskontrollplan (Ccp). I begge tilfeller er alle prosesser og prosedyrer dekket for å utføre konfigurasjonskontroll.

Endre dokumentasjon selv (detaljert senere) må gi nok informasjon som er selvforklarende til at det ikke kreves ytterligere informasjon fra opphavsmannen. Dette er nødvendig på grunn av muligheten for at opphavsmannen kanskje ikke er tilgjengelig innen endringen er implementert.

Prosess

CC-prosessen er enkel (Utstilling 1). En person har en ide eller finner en feil i dagens system. Denne personen skal dokumentere sine funn på En Enterprise Change Request (ECR), et skjema som brukes til å logge alle feil, endringer eller forbedringer for det aktuelle prosjektet. Endringsforespørselen rutes til kolleger og veiledere for gjennomgang og deretter godkjent og implementert.

Utstilling 1-Enkel Konfigurasjonskontrollprosess

Endre Dokumentasjon

Dokumentere endring er den mest kritiske delen av et konfigurasjonskontrollsystem. Detalj av dokumentasjon er ikke like viktig som informasjonen som dokumenteres. Den dokumenterte informasjonen må imidlertid beskrive endringen og minst inneholde følgende informasjon. Minimale krav til dokumentasjon er:

Selvfølgelig, jo mer informasjon i dokumentasjonen, desto lettere er det å gjenskape, gjenopprette, analysere og korrigere. I tillegg vil dette hjelpe til med endelig dokumentasjon for produktlevering.

når en person oppdager en feil eller et krav i det aktuelle prosjektet, dokumenterer han eller hun endringen som kreves. En endringsforespørsel inneholder informasjon om forespørselen og beskriver scenariet som oppdaget feilen, som oppdaget den, da den ble oppdaget, og anbefalte reparasjoner. Forespørselen bør også identifisere konfigurasjonselementene som er berørt, om mulig, og plassere en slags alvorlighetsgrad eller prioritetskode for å identifisere når denne endringen, hvis godkjent, skulle skje.

Endre Godkjenning

endre godkjenning skal komme fra en utpekt prosjektleder med” big picture ” – visningen av endringspåvirkning. En peer review er et svært effektivt middel for å verifisere alle fasetter av endringen og sikre at alle områder som berøres av endringen, blir adressert. Å ha kunden enig med endringen ville være gunstig for forbedringer. Men i små utviklingsprosjekter er de fleste endringene av en “bug fix” type, og kunden vil ikke se effekten av endringen.

Datainnsamling

datainnsamling er viktig for å gjenopprette informasjon om lignende elementer og oppdage trender og tendenser. Denne informasjonen skal ligge elektronisk, noe som muliggjør enkel gjenoppretting av data og datamanipulering for statusregnskap og beregninger. Informasjonen kan brukes til å kompilere en” lessons learned ” – rapport, som distribueres gjennom en organisasjon for teknisk forbedring.

Endre Implementering.

når alle nødvendige godkjenninger er mottatt, begynner implementeringsoppgaven. Testing ved hvert trinn i implementeringen bekrefter at virkningen på andre aspekter av programmet er minimal. All testing er fullført og endringen er implementert i hele programmet.

Lukket Prosess

en lukket prosess der endringsopphavsmannen vil vite det endelige resultatet av endringen før den vises i sluttproduktet, er en nøkkelkomponent for suksess. Dette gjelder for alle typer bransjer, fra konstruksjon til produksjon til programvare.

denne lukkede prosessen setter opp kontrolltavler med ulike roller i endringsprosessen (Vedlegg 2). Hvert styre har plikt til å gjennomgå en endring i sin helhet og å komme til en endelig beslutning for hver endring. Selvfølgelig kan styret kreve ytterligere informasjon før det kan ta den avgjørelsen, men dette bør være minimal.

Institutt For Konfigurasjonsstyring (ICMHQ) lærer CMII (CMIIU) metodikk for konfigurasjonsstyring og har utviklet denne visningen av en lukket endringsprosess. Denne prosessen begynner og slutter med sluttelementet. Vær oppmerksom på at konfigurasjonsendringsadministrasjon vises på tre forskjellige nivåer i løkken. Hvert område er definert forskjellig og har spesifikke roller og ansvar.

• Teknisk Gjennomgang-Sikrer at alle detaljevalueringer og mulighetsanalyse er fullført.
• Change Review Board (CRB) – Evaluerer forretningseffekten av endringen. Er denne endringen gyldig for vårt forretningsmiljø? Oppfyller det et av våre strategiske mål? Passer det inn i vår visjon? MED en godkjent endring kan CRB angi en tidsramme for endringen, avhengig av konkurransedyktig prognose og forretningsrisiko.
• Change Implementation Board (CIB) – Tildeler nødvendige midler og bestemmer tidsrammer for endringsimplementering. Dette inkluderer også tildeling av effektivitet for endringen, som angir når endringen er effektiv. Effektiviteten kan gjelde en dato, bygge, serienummer, eller lot nummer. Dette er avhengig av sluttproduktet.

Fast Track-alternativet til loop er hvor all smerte AV CC er utgitt, og eierne kan få endret godkjent i minutter mot dager. Nøkkelen til dette er selvfølgelig et riktig dokumentasjonstre for hvert produkt. Hvert dokument må ha en skaper og bruker tildelt dem. Hvis endringene bare påvirker dokumentasjonen på lavt nivå, Er Fast Track i orden, og endringen skriker gjennom CC-Prosessen.

Sammendrag

nøkkelen til En Vellykket Konfigurasjonskontrollprosess er innkjøpet fra hele prosjektgruppen. Teammedlemmer bør ikke bli bedt om å avstå sunn dømmekraft og kontroll på grunn av en ledelsesinfrastruktur som ikke er utformet for å oppfylle kravene til prosjektet ved hånden. Konfigurasjonskontrollprosesser er utformet for å redusere risikoen for feil og sikre at leveransene oppfylles i tide og på budsjett. Hvis prosjektgruppen deltar i å etablere det opprinnelige Rammeverket For Konfigurasjonskontroll-vil deltakelse og aksept på tvers av prosjektgruppen akselereres, og infrastrukturen som etableres vil støtte forretningsmålene.