Controlul configurației … eliberați cătușele!

natura din ce în ce mai complexă, globală a tuturor afacerilor din industrii și sectoare verticale, cuplată cu modele de afaceri “Internet Time” cu foc rapid, pune un nou accent pe gestionarea schimbărilor. Abilitatea de a gestiona eficient Schimbarea apare ca o cheie de diferențiere între concurenți – permițând organizațiilor să evolueze modele de afaceri și linii de produse și să schimbe vitezele suficient de repede pentru a satisface oportunitățile economiei actuale – înaintea concurenței.

pe măsură ce organizațiile se luptă să gestioneze proiecte în acest mediu, managementul configurației (cm) a devenit o componentă din ce în ce mai critică, oferind un cadru pentru gestionarea schimbării.

disciplina CM constă din șase domenii de expertiză definite de EIA-649 (ANSI, 2004))

• planificarea și gestionarea CM (CMPM),
• identificarea configurației (CI),
• gestionarea modificărilor configurației (CCM),
• contabilitatea stării configurației (CSA),
• Verificarea configurației & audituri (CVA) și
• cm de date digitale.

cu toate acestea, ISO 10007 (ISO, 2003) grupează CM în patru clasificări:

• ci,
• controlul configurației (CC),
• CSA și
• revizuiri și audituri ale configurației (R&A).

(CCM și CC sunt identice pentru toate scopurile practice, la fel ca și CVA și R&A.)

rețineți că controlul configurației este discutat în acest articol. Gestionarea modificărilor configurației și controlul modificărilor sunt, de asemenea, termeni utilizați pentru a descrie același proces.

mulți manageri de proiect percep controlul configurației ca sisteme de restricționare și limitare concepute pentru a împiedica dezvoltarea produsului și care, de obicei, afectează programul proiectului într-un mod negativ. Din păcate, procesele CC prea des generice concepute pentru programe mari, complexe, cum ar fi armele sau dezvoltarea sistemelor medicale, sunt impuse altor tipuri de proiecte. Aceste procese nu sunt adaptate pentru a satisface nevoile, de exemplu, un efort de dezvoltare Web sau un nou produs roll-out. Acest lucru duce în cele din urmă la o frustrare intensă cu procesul CC și efectul de “încătușare” – unde procesele care nu sunt concepute pentru a satisface nevoile programului au un impact negativ asupra progresului.

managerii de proiect implementează controlul configurației pentru a controla și urmări modificările. Procesele sunt concepute pentru a se asigura că nivelul adecvat este utilizat pentru a aproba modificările și că aceste modificări se bazează pe cele mai bune informații disponibile. Procesele oferă un cadru pentru revizuirea schimbărilor. Acest lucru permite echipei să evalueze dacă implementarea schimbării este acceptabilă și să identifice problemele potențiale în timp util. Aceste procese permit calibrarea și, dacă este necesar, revizuirea ulterioară.

adevărata întrebare nu este dacă să pună în aplicare de control de configurare, dar ce nivel de control de configurare pentru a pune în aplicare. O organizație poate solicita un pachet de control al configurației “standard al companiei” pentru toate proiectele. Acest tip de sistem este adesea impus echipelor de proiect din cauza unei istorii a lipsei controlului configurației și a impactului financiar rezultat. Managerii de proiect, care recunosc că o abordare “unică” nu va funcționa, trebuie să demonstreze că există controale adecvate pentru a evita repetarea greșelilor din trecut.

controlul configurației în acțiune

proiectul tipic de dezvoltare nu necesită un proces de control al configurației la nivelul unui sistem major de arme. Este important să împuterniciți echipa cu un nivel adecvat de flexibilitate, asigurându-vă în același timp că există un sistem de control și echilibru. Cheia pentru orice sistem este efortul necesar în documentarea procesului, împreună cu documentația cerută de proces. Procesul CC eșantion descris mai jos este conceput pentru a satisface cerințele unui proiect de dezvoltare a aplicațiilor de dimensiuni mici până la medii.

echipa de proiect ar trebui să analizeze mai întâi rolul adecvat al controlului configurației asupra proiectului. Acest lucru, cel puțin pe un proiect software, ar implica o temă de documentare a tuturor fișierelor de cod intern și a unui anumit tip de documentație externă. Domeniile suplimentare de acoperit includ aprobarea Modificărilor și procesele de documentare a modificărilor. Consensul simplu al participanților implicați ar trebui să fie suficient. Desigur, un consiliu structurat convocat în mod regulat este mai bun.

acum să intrăm în diferitele aspecte ale procesului simplu de control al configurației.

documente

planul de gestionare a configurației (CMP) va defini procesul CC. În unele aplicații în care procesul CC este destul de detaliat, este dezvoltat un plan de control al configurației (CCP). În ambele cazuri, toate procesele și procedurile sunt acoperite pentru a efectua controlul configurației.

modificarea documentației în sine (detaliată mai târziu) trebuie să furnizeze suficiente informații care se explică de la sine până la punctul de a nu solicita informații suplimentare de la inițiator. Acest lucru este necesar datorită posibilității ca inițiatorul să nu fie disponibil până la implementarea modificării.

proces

procesul CC este simplu (proba 1). O persoană are o idee sau găsește o eroare în sistemul actual. Această persoană ar trebui să documenteze constatările lor pe o cerere de modificare a întreprinderii (ECR), un formular utilizat pentru a înregistra toate erorile, modificările sau îmbunătățirile pentru proiectul dat. Cererea de modificare este direcționată către colegi și supraveghetori pentru revizuire și apoi aprobată și implementată.

Exponatul 1 – proces simplu de control al configurației

modificare documentație

documentarea modificării este partea cea mai critică a unui sistem de control al configurației. Detaliile documentației nu sunt la fel de importante ca informațiile documentate. Cu toate acestea, informațiile documentate trebuie să descrie modificarea și să includă, cel puțin, următoarele informații. Cerințele minime pentru documentare sunt:

desigur, cu cât sunt mai multe informații conținute în documentație, cu atât este mai ușor să recreezi, să recuperezi, să analizezi și să corectezi. În plus, acest lucru va ajuta la documentația finală pentru livrarea produsului.

când o persoană descoperă o eroare sau o cerință în proiectul curent, el sau ea documentează modificarea necesară. O solicitare de modificare conține informații despre solicitare și descrie scenariul care a descoperit eroarea, cine a descoperit-o, când a fost descoperită și remedierile recomandate. Solicitarea ar trebui, de asemenea, să identifice elementele de configurare afectate, dacă este posibil, și să plaseze un fel de cod de severitate sau prioritate pentru a identifica când ar trebui să apară această modificare, dacă este aprobată.

aprobarea schimbării

aprobarea schimbării ar trebui să provină de la un supraveghetor de proiect desemnat cu vizualizarea “imagine de ansamblu” a impactului schimbării. O evaluare inter pares este un mijloc foarte eficient de a verifica toate aspectele schimbării și de a asigura abordarea tuturor domeniilor afectate de schimbare. Dacă Clientul este de acord cu schimbarea, ar fi benefic pentru îmbunătățiri. Cu toate acestea, în proiectele de dezvoltare mici, majoritatea modificărilor sunt de tip “bug fix”, iar clientul nu ar vedea impactul schimbării.

colectarea datelor

colectarea datelor este vitală în recuperarea informațiilor despre articole similare și descoperirea tendințelor și tendințelor. Aceste informații ar trebui să se afle electronic, ceea ce permite recuperarea ușoară a datelor și manipularea datelor pentru contabilitatea stării și valorile. Informațiile pot fi utilizate pentru a compila un raport “lecții învățate”, care este distribuit în întreaga organizație pentru îmbunătățirea tehnică.

Modificare Implementare.

odată ce toate aprobările corespunzătoare sunt primite, atunci începe sarcina de implementare. Testarea la fiecare pas al implementării verifică dacă impactul asupra altor aspecte ale programului este minim. Toate testele sunt finalizate și modificarea este implementată în întregul program.

proces în buclă închisă

un proces în buclă închisă în care inițiatorul schimbării va cunoaște rezultatul final al modificării înainte de a apărea în produsul final este o componentă cheie pentru succes. Acest lucru este valabil pentru toate tipurile de industrii, de la construcții la producție până la software.

acest proces în buclă închisă stabilește panouri de control cu roluri diferite în procesul de schimbare (Exponatul 2). Fiecare consiliu are obligația de a revizui o modificare în contextul complet al Cartei sale și de a lua o decizie definitivă pentru fiecare modificare. Desigur, Consiliul poate solicita informații suplimentare înainte de a putea lua această decizie, dar acest lucru ar trebui să fie minim.

Institutul pentru managementul configurației (ICMHQ) predă metodologia CMII (CMIIU) pentru gestionarea configurației și a dezvoltat această viziune a unui proces de schimbare în buclă închisă. Acest proces începe și se termină cu elementul final. Rețineți că administrarea schimbării configurației apare la trei niveluri diferite în buclă. Fiecare domeniu este definit diferit și are roluri și responsabilități specifice.

• revizuirea tehnică-asigură că toate evaluările detaliate și analiza de fezabilitate sunt complete.
• Comitetul de revizuire a modificărilor (CRB) – evaluează impactul schimbării asupra afacerii. Este această schimbare valabilă pentru mediul nostru de afaceri? Îndeplinește unul dintre obiectivele noastre strategice? Se încadrează în Declarația noastră de viziune? Cu o modificare aprobată, CRB poate indica sau nu un interval de timp pentru Modificare, în funcție de prognoza competitivă și de riscul de afaceri.
• Comitetul de implementare a modificărilor (CIB) – alocă finanțarea necesară și determină termenele de implementare a modificărilor. Aceasta include, de asemenea, atribuirea efectivității pentru Modificare, care specifică când modificarea este eficientă. Effectivity ar putea se referă la o dată, construi, numărul de serie, sau numărul lotului. Acest lucru depinde de elementul final.

opțiunea Fast Track a buclei este locul în care toată durerea CC este eliberată, iar proprietarii pot obține o modificare aprobată în câteva minute față de zile. Cheia acestui lucru este, desigur, un arbore de documentare adecvat pentru fiecare produs. Fiecare document trebuie să aibă un creator și un utilizator atribuit acestora. Dacă modificările afectează doar documentația de nivel scăzut, atunci pista rapidă este în ordine și schimbarea strigă prin procesul CC.

rezumat

cheia oricărui proces de control al configurației de succes este buy-in-ul întregii echipe de proiect. Membrii echipei nu ar trebui să li se ceară să renunțe la o judecată și un control solid de dragul unei infrastructuri de management care nu este concepută pentru a satisface cerințele proiectului la îndemână. Procesele de control al configurației sunt concepute pentru a reduce riscul de eșec și pentru a asigura îndeplinirea livrabilelor la timp și la buget. Dacă echipa de proiect participă la stabilirea cadrului inițial de control al configurației – participarea și acceptarea în cadrul echipei de proiect sunt accelerate, iar infrastructura stabilită va sprijini obiectivele de afaceri.