Konfigurationskontroll-släpp handbojorna!

den alltmer komplexa, globala karaktären hos alla företag inom branscher och vertikala sektorer, i kombination med snabbbrand, “Internet Time” affärsmodeller, Driver ny tonvikt på förändringshantering. Förmågan att effektivt hantera förändringar framträder som en differentierande nyckel bland konkurrenterna – vilket gör det möjligt för organisationer att utveckla affärsmodeller och produktlinjer och byta växlar tillräckligt snabbt för att möta möjligheterna i den nuvarande ekonomin – före tävlingen.

när organisationer kämpar för att hantera projekt i denna miljö har konfigurationshantering (CM) blivit en alltmer kritisk komponent och erbjuder ett ramverk för att hantera förändringar.

cm-disciplinen består av sex kompetensområden enligt definitionen i EIA-649 (ANSI, 2004))

• CM planering och hantering (CMPM),
• Konfigurationsidentifiering (CI),
• Konfigurationsbyteshantering (CCM),
• Konfigurationsstatusredovisning (CSA),
• Konfigurationsverifiering & revisioner (CVA) och
• CM av digitala Data.

ISO 10007 (ISO, 2003) grupperar emellertid CM i fyra klassificeringar:

• CI,
• Konfigurationskontroll (CC),
• CSA och
• Konfigurationsgranskningar och revisioner (R&a).

(CCM och CC är för alla praktiska ändamål identiska, liksom CVA och R&A.)

Observera att konfigurationskontroll diskuteras i den här artikeln. Configuration change management och change control är också termer som används för att beskriva samma process.

många projektledare uppfattar konfigurationskontroll som begränsande och begränsande system som är utformade för att hämma produktutveckling och som vanligtvis påverkar projektets schema på ett negativt sätt. Tyvärr läggs alltför ofta generiska CC-processer utformade för stora, komplexa program som vapen eller utveckling av medicinska system på andra typer av projekt. Dessa processer är inte skräddarsydda för att möta behoven hos till exempel en Webbutvecklingsinsats eller en ny produktutbyggnad. Detta leder i slutändan till intensiv frustration med CC-processen och” handbojningseffekten ” – där processer som inte är utformade för att möta programmets behov påverkar framstegen negativt.

Projektledare implementerar konfigurationskontroll för att styra och spåra ändringar. Processerna är utformade för att säkerställa att lämplig nivå används för att godkänna ändringar och att dessa ändringar baseras på bästa tillgängliga information. Processerna ger en ram för förändringsgranskning. Detta gör det möjligt för teamet att bedöma om genomförandet av förändringen är acceptabelt och att identifiera potentiella problem i tid. Dessa processer möjliggör kalibrering och vid behov ytterligare revision.

den verkliga frågan är inte om man ska implementera konfigurationskontroll, men vilken nivå av konfigurationskontroll som ska implementeras. En organisation kan kräva ett konfigurationskontrollpaket” företagsstandard ” på alla projekt. Denna typ av system åläggs ofta projektgrupper på grund av en historia av brist på konfigurationskontroll och den resulterande ekonomiska effekten. Projektledare, som inser att en” one-size-fits-all ” – strategi inte fungerar, måste visa att lämpliga kontroller finns på plats för att undvika att upprepa tidigare misstag.

Konfigurationskontroll i aktion

det typiska utvecklingsprojektet kräver ingen konfigurationskontrollprocess på nivån för ett större vapensystem. Det är viktigt att ge laget en lämplig nivå av flexibilitet samtidigt som man säkerställer att ett system med kontroller och saldon finns på plats. Nyckeln till alla system är den ansträngning som krävs för att dokumentera processen, tillsammans med den dokumentation som krävs av processen. Prov CC-processen som beskrivs nedan är utformad för att uppfylla kraven i ett litet till medelstort applikationsutvecklingsprojekt.

projektgruppen bör först analysera lämplig roll för konfigurationskontroll på projektet. Detta, åtminstone på ett mjukvaruprojekt, skulle innebära ett tema för att dokumentera alla kodfiler internt och någon typ av extern dokumentation. Ytterligare områden att täcka inkluderar ändringsgodkännande och förändringsdokumentationsprocesser. Enkel konsensus av de inblandade deltagarna borde räcka. Naturligtvis är en strukturerad styrelse som sammankallas regelbundet bättre.

låt oss nu komma in i de olika aspekterna av den enkla Konfigurationskontrollprocessen.

dokument

Konfigurationshanteringsplanen (CMP) definierar CC-processen. I vissa applikationer där CC-processen är ganska detaljerad utvecklas en Konfigurationskontrollplan (CCP). I båda fallen omfattas alla processer och procedurer för att utföra konfigurationskontroll.

ändra själva dokumentationen (detaljerad senare) måste ge tillräckligt med information som är självförklarande så att den inte kräver ytterligare information från upphovsmannen. Detta krävs på grund av möjligheten att upphovsmannen kanske inte är tillgänglig när ändringen genomförs.

Process

CC-processen är enkel (utställning 1). En individ har en uppfattning eller finner ett fel i det nuvarande systemet. Denna person bör dokumentera sina resultat på en Enterprise Change Request (ECR), ett formulär som används för att logga alla buggar, ändringar eller förbättringar för det givna projektet. Ändringsförfrågan dirigeras till kamrater och handledare för granskning och godkänns och implementeras sedan.

Exhibit 1 – Enkel Konfigurationskontrollprocess

ändra dokumentation

dokumentera förändring är den mest kritiska delen av ett konfigurationskontrollsystem. Dokumentationens detalj är inte lika viktig som informationen som dokumenteras. Den dokumenterade informationen måste dock beskriva ändringen och innehålla åtminstone följande information. Minimikrav för dokumentation är:

ju mer information som finns i dokumentationen desto lättare är det att återskapa, återställa, analysera och korrigera. Dessutom kommer detta att hjälpa till i slutdokumentationen för produktleverans.

när en individ upptäcker ett fel eller ett krav i det aktuella projektet dokumenterar han eller hon den ändring som krävs. En ändringsbegäran innehåller information om begäran och beskriver scenariot som upptäckte felet, som upptäckte det, när det upptäcktes och rekommenderade korrigeringar. Begäran bör också identifiera de konfigurationsobjekt som påverkas, om möjligt, och placera någon form av svårighetsgrad eller prioritetskod för att identifiera när denna ändring, om den godkänns, ska inträffa.

ändra godkännande

ändra godkännande bör komma från en utsedd projektledare med “big picture” syn på förändring inverkan. En peer review är ett mycket effektivt sätt att verifiera alla aspekter av förändringen och se till att alla områden som påverkas av förändringen behandlas. Att ha kunden överens med förändringen skulle vara fördelaktigt för förbättringar. Men i små utvecklingsprojekt är de flesta förändringar av en “bug fix” – typ och kunden skulle inte se effekten av förändringen.

datainsamling

datainsamling är avgörande för att återställa information om liknande objekt och upptäcka trender och tendenser. Denna information bör finnas elektroniskt, vilket möjliggör enkel återställning av data och datamanipulation för statusredovisning och mätvärden. Informationen kan användas för att sammanställa en “lessons learned” – rapport, som distribueras i en organisation för teknisk förbättring.

Ändra Genomförandet.

när alla lämpliga godkännanden har mottagits börjar implementeringsuppgiften. Testning vid varje implementeringssteg verifierar att effekterna på andra aspekter av programmet är minimala. All testning är klar och ändringen implementeras i hela programmet.

sluten slinga Process

en sluten slinga process där förändringen upphovsmannen vet det slutliga resultatet av förändringen innan den dyker upp i den slutliga produkten är en nyckelkomponent för framgång. Detta gäller för alla typer av industrier, från konstruktion till tillverkning till programvara.

denna slutna process sätter upp styrkort med olika roller i förändringsprocessen (utställning 2). Varje styrelse är skyldig att se över en ändring i sin stadgas fullständiga sammanhang och att fatta ett slutgiltigt beslut för varje ändring. Naturligtvis kan styrelsen kräva ytterligare information innan den kan fatta det beslutet, men det borde vara minimalt.

Institutet för konfigurationshantering (ICMHQ) lär ut cmii-metoden (CMIIU) för konfigurationshantering och har utvecklat denna syn på en förändringsprocess med sluten slinga. Denna process börjar och slutar med slutet. Observera att konfigurationsändringsadministration visas på tre olika nivåer i slingan. Varje område definieras annorlunda och har specifika roller och ansvarsområden.

• teknisk granskning-säkerställer att alla detaljerade utvärderingar och genomförbarhetsanalyser är fullständiga.
• change Review Board (CRB) – utvärderar förändringens affärseffekter. Är denna förändring giltig för vår affärsmiljö? Uppfyller det något av våra strategiska mål? Passar det in i vår vision? Med en godkänd förändring kan CRB ange en tidsram för förändringen, beroende på konkurrensprognoser och affärsrisk.
• styrelsen för Förändringsimplementering (CIB) – fördelar den finansiering som krävs och bestämmer tidsramar för förändringsimplementering. Detta inkluderar också att tilldela effektivitet för ändringen, som anger när ändringen är effektiv. Effektiviteten kan avse ett datum, bygga, serienummer, eller partinummer. Detta är beroende av slutposten.

snabbspåralternativet i slingan är där all smärta av CC släpps och ägarna kan få en ändrad godkänd på några minuter kontra dagar. Nyckeln till detta är naturligtvis ett korrekt dokumentationsträd för varje produkt. Varje dokument måste ha en skapare och användare tilldelad dem. Om ändringarna bara påverkar dokumentationen på låg nivå är Fast Track i ordning och ändringen skriker genom CC-processen.

sammanfattning

nyckeln till en lyckad Konfigurationskontroll är inköp från hela projektgruppen. Teammedlemmar bör inte uppmanas att avstå från sund bedömning och kontroll för en förvaltningsinfrastruktur som inte är utformad för att uppfylla kraven i det aktuella projektet. Konfigurationskontrollprocesser är utformade för att minska risken för fel och säkerställa att leveranser uppfylls i tid och på budget. Om projektgruppen deltar i upprättandet av det ursprungliga ramverket för Konfigurationskontroll-deltagande och acceptans i hela projektgruppen påskyndas och den etablerade infrastrukturen kommer att stödja affärsmålen.