MIL-HDBK-61a: Konfigurasjonskontroll

< Forrige |Innhold |Neste >

6.1 Konfigurasjonskontrollaktivitet

Konfigurasjonskontroll er kanskje det mest synlige elementet i konfigurasjonsstyring. Det er prosessen som brukes av entreprenører og Regjeringsprogramkontorer for å administrere forberedelse, begrunnelse, evaluering, koordinering, disposisjon og implementering av foreslåtte tekniske endringer og avvik til utførte Konfigurasjonselementer (CIs) og baselined konfigurasjonsdokumentasjon.

hovedmålet med konfigurasjonskontrollen er å etablere og opprettholde en systematisk endringsprosessprosess som regulerer livssykluskostnader, og:

• Tillater optimal design og utvikling breddegrad med riktig grad, og dybden av konfigurasjonsendringskontrollprosedyrer under livssyklusen til et system / CI.

• Gir effektiv behandling og implementering av konfigurasjonsendringer som opprettholder eller forbedrer operasjonell beredskap, støttbarhet, utskiftbarhet og interoperabilitet

• Sikrer komplette, nøyaktige og rettidige endringer i konfigurasjonsdokumentasjonen som vedlikeholdes under passende konfigurasjonskontrollmyndighet

• Eliminerer unødvendig endring spredning

span Av Konfigurasjonskontroll begynner For Regjeringen når det første konfigurasjonsdokumentet er godkjent og baselined. Dette skjer vanligvis når grunnlinjen for funksjonell konfigurasjon (referert til som grunnlinjen for KRAV I EIA/IS-649) er etablert for et system eller konfigurasjonselement. På dette punktet, komplementære Regjeringen og entreprenør endringsledelse prosedyrer er ansatt for å systematisk evaluere hver foreslåtte engineering endring eller forespurt avvik til baselined dokumentasjon, for å vurdere den totale endringen innvirkning (inkludert kostnader) gjennom koordinering med berørte funksjonelle aktiviteter, å disponere endring eller avvik og gi rettidig godkjenning eller misbilligelse, og for å sikre rettidig gjennomføring av godkjente endringer av begge parter. Konfigurasjonskontroll er en viktig disiplin gjennom hele programmets livssyklus. Figur 6-1 illustrerer en toppnivåaktivitetsmodell av konfigurasjonskontrollprosessen. Det viser konfigurasjonskontrollprosessen delt inn i tre segmenter, som er detaljert i Figurene 6-2, 6-3 og 6-4, henholdsvis.

Det første segmentet, Government Configuration Control-Initiation, gjenspeiler den delen av prosessen før Regjeringen ber Om et forslag til entrepreneur Engineering Change Proposal (ECP). Denne aktiviteten skjer:

• når behovet for en endring stammer Fra En Statlig aktivitet (inkludert felt-og driftsaktiviteter)

• som et resultat av innspill fra entreprenøren at En Klasse Jeg Endre Til En Regjering kontrollert baseline er nødvendig

• etter konfigurasjonsdokumentasjon som vil bli påvirket av den foreslåtte endringen, er godkjent og innlemmet i dagens grunnlinje kontrollert av Regjeringen

Endringer kan være nødvendig for en rekke årsaker, for eksempel for å motvirke ny trussel, sette inn ny teknologi, og svare på tekniske og operasjonelle tester og evalueringer, eller rette opp problemer. Som vist i Figur 6-2, Bekrefter Den offentlige aktiviteten som er ansvarlig for konfigurasjonskontroll behovet for endring, setter terskler for ytelse, kostnad og tidsplan for den foreslåtte endringen, bestemmer at endringen er teknisk oppnåelig og rimelig (basert på gjeldende informasjon og kontraktsinterface, der det er hensiktsmessig), og forbereder en forespørsel om entreprenøren(e) å utarbeide EN ECP. En av de viktigste bidragsyterne til effektivitet og effektivitet for konfigurasjonskontroll er klar og konsis kommunikasjon mellom Regjeringen og entreprenøren før den formelle forespørselen OM ECP. Ideelt sett skjer dette i et integrert produktteammiljø.

Figur 6-3, som reflekterer Det andre segmentet I Figur 6-1, modellerer entreprenørens konfigurasjonskontrollprosess. Contractor configuration control påberopes som entreprenøren utgivelser hvert element av konfigurasjonsdokumentasjon. Til syvende og sist brukes contractor configuration control på det komplette settet med konfigurasjonsdokumentasjon, inkludert Statlig baselined konfigurasjonsdokumentasjon på ytelsesnivå eller detaljert spesifikasjonsnivå, som aktuelt, og designløsningen i tekniske modeller og tegninger. Entreprenøren svarer På MYNDIGHETENES ECP-forespørsler og på internt genererte forespørsler om designendringer eller avvik (RFD). Entreprenøren evaluerer hver foreslått endrings-eller avviksforespørsel og dokumenterer dens innvirkning på UTVIKLINGEN og støttbarheten TIL CI, bestemmer det gjeldende nivået for gjennomgang og godkjenning som kreves, og sikrer at en bestemt beslutning om levedyktigheten av endringen er gjort av gjeldende konfigurasjonskontrollmyndighet før den implementeres. Ecp-er og Rfd-er som krever Statlig gjennomgang og / eller godkjenning, sendes i samsvar med kontraktsmessige krav. Endringen godkjennes av Regjeringen når:

• endringen er et krav om et planlagt konfigurasjonsdokument på ytelsesnivå som kontrolleres av Myndighetene, eller

• en endring i et konfigurasjonsdokument kontrollert av entreprenøren har innvirkning på spesifisert ytelse, støttbarhet og andre kontraktsspesifiserte krav knyttet til CI og dokumentasjon kontrollert av Regjeringen.

leverandøren tar avgjørelsen når endringen er til elementer / konfigurasjonsdokumentasjon som det er konfigurasjonskontrollmyndigheten for, forutsatt at disse endringene ikke påvirker Regjeringens grunnlinjer.

Figur 6-4 modeller det tredje segmentet Av Figur 6-1, som dekker den delen av prosessen som gjelder Statlig gjennomgang og disponering av entreprenørens innsendte Ecp-er og Rfd-er. Det illustrerer kommunal representativ gjennomgang og samsvar med klasse ii-endringer og mindre avvik (der slike tiltak er kontraktsmessig påkrevd) og dets godkjenning (eller ikke-godkjenning) av klasse i-endringer og store/kritiske avvik. Regjeringens konfigurasjonskontrollaktivitet (vanligvis et sekretariat) forbereder konfigurasjonskontrollstyret ved å koordinere den foreslåtte endringen med alle berørte parter, motta teknisk samstemmighet og kostnads-og planleggingsforpliktelser, og ved å plassere endringen / avviket på CCB-kalenderen (i samspill med sin beredskap og det haster med endringen). CCB vurderer deretter forslaget og gjennomføringsforpliktelsene og godkjenner eller misliker dem i samsvar med anskaffelsesaktivitetens policy. SOM et resultat AV CCB-beslutningen er implementeringsretning gitt, typisk i form AV ET CCB-direktiv. Handlinger rettet AV CCB inkluderer både kontraktsmessige handlinger og oppdragsordre for Statlige aktiviteter, som aktuelt. Som svar PÅ ET CCB-Direktiv forbereder Og forhandler regjeringen en kontraktsendring for å autorisere entreprenøren til å fortsette med implementeringen av den godkjente KLASSE I ECP eller major / critical avvik.

en effektiv, veldefinert konfigurasjonskontrollprosess sikrer regjeringsprogrammets kontor at alle endringer i regjeringskontrollerte grunnlinjer, uansett hvor små eller tilsynelatende ubetydelige, blir gjennomgått av gjeldende konfigurasjonskontrollmyndighet. Uten en effektiv konfigurasjonskontrollprosess risikerer programmet office å levere CIs med konfigurasjoner som:

• er teknisk utilstrekkelig og ikke oppfyller spesifiserte ytelseskrav

• er ikke logistisk støttbare

• Kan være utrygt

• det fører til bortkastede ressurser, og

• ikke gi en nøyaktig historisk rekord som grunnlag for fremtidig endring.

som beskrevet i 6.1, konfigurasjonskontroll av baselined konfigurasjonsdokumentasjon er en integrert endringsledelsesprosess, inkludert både å utføre aktivitet (generelt en entreprenør) og oppgaveaktivitet (generelt regjeringen) ansvar for endringsforberedelse, begrunnelse, evaluering, koordinering, disposisjon og implementering. Gjennom konfigurasjonskontrollprosessen identifiseres og regnskapsføres den fulle effekten av foreslåtte tekniske endringer og avvik i implementeringen.

konfigurasjonskontrollprosessen utvikler seg fra en mindre formell prosess i de tidlige fasene av et program til en svært disiplinert og formell prosess under systemutvikling og Demonstrasjon, Produksjon Og Distribusjon, Samt Drift og Støttefaser . I konseptutforskningsfasen benyttes konfigurasjonskontrollprosessen til støtte for systemteknikk for å sikre at riktig versjon av dokumenter, som kommuniserer tekniske beslutninger eller definisjon av relevante studieparametere, formidles og brukes av alt personell. I tillegg gjør prosessen berørte parter oppmerksomme på at en endring er under utvikling og gjør dem i stand til å gi relevante innspill.

i Konsept-Og Teknologiutviklingsfasen (hvis aktuelt), når programdefinisjonsdokumentene utvikles, er konfigurasjonskontrollprosessen også mindre formell. Som en del av systems engineering kontrollprosessen i denne fasen, kan det være flere krav definisjon grunnlinjer etablert for enkelhets skyld i å sikre at alle deltakerne er ” på samme side.”En konfigurasjonskontrollprosedyre er nyttig i denne fasen for gjennomgang og koordinering av endringer i de utviklende systemnivåspesifikasjonene. Det kan også tjene til å opprettholde Regjeringen / Entreprenør informasjonsutveksling effektiv og håndterlig ved å gi:

• identifisering, dokumentasjon, formidling og gjennomgang av endringer

• Korrekt versjonering av filer og revisjon av dokumenter

• en utgivelsesprosess for å sikre at hver revisjon / versjon gjenspeiler de gjeldende endringene

Under Systemutvikling og Demonstrasjon, Produksjon og Distribusjon, Samt Drift og Støttefaser, er en formell konfigurasjonskontrollprosess avgjørende. Den uformelle dokumentendringskontrollen som ble praktisert under konseptutforskning, er utilstrekkelig for systemoppkjøp og opprettholdelse. Som produktet blir utviklet og produsert configuration control fokuserer på dokumentasjon som definerer ytelse, fysiske og funksjonelle egenskaper og konfigurasjonen av produktet. Konfigurasjonskontroll er en styringsprosess som bruker kontraktsmessige (Offentlige) og interne (entreprenør) konfigurasjonslinjene som referanser for å håndtere endring. Innenfor denne konteksten er det imidlertid flere konfigurasjonskontrollkompleksitetsnivåer. Når det ses på makronivå, beskrevet av aktivitetsmodellene (Figur 6-1 til 6-4), er prosessen:

• Adresserer grunnlinjedokumentasjonen

• Avgjør hvilke dokumenter som rammes

• Foreslår en endring som dekker konsekvensene for alle berørte elementer, og

• Angir når, hvor og av hvem dokumentasjonen vil bli oppdatert og endringen vil bli innlemmet i produktet og i alle støtteelementer.

selv om denne makrovisningen på toppnivå virker enkel og rett frem, kan en mikronivåvisning av konfigurasjonskontrollprosessen være betydelig mer kompleks. Mikrovisningen avslører prosesslaget som omhandler hva som må gjøres for å endre hvert berørt element, og dermed med et bredt spekter av hensyn som datarettigheter; godkjenningsmyndighet, dokumentforvaltere; design, utgivelse, produksjon, installasjon og testing organisasjoner; kontrakts-og grensesnittforhold.

for å endre et produkt, er det første trinnet å revidere dokumentene som definerer produktet. Konseptene som er omtalt nedenfor, letter å utføre dette trinnet ved hjelp av automatiserte verktøy som EN CM AIS. Denne håndboken ser disse begrepene fra både programstyring (makro) synspunkt og dokumentkontroll (mikro) synspunkt.

6.1.1.1 Nåværende Myndighet.

på mikronivå, hvis EN ECP som foreslår en endring av et produkt påvirker flere dokumenter, må endringsforslaget, evalueringen og gjennomføringen vurdere:

• Hvem er den kontraktsmessige myndigheten til å godkjenne EN ECP? Dette er produktkonfigurasjonskontrollmyndigheten

• Hvem har rett til å godkjenne revisjon av hvert dokument berørt AV EN ECP? Dette er gjeldende dokument endringsmyndighet.

• kreves det EN relatert ECP fra en organisasjon for dokumentendring før konfigurasjonskontrollmyndigheten for produktet kan godkjenne EN ECP for produktet?

• er Det Andre Offentlige eller industrielle aktiviteter involvert fordi produktet har flere brukere? Dette er applikasjonsaktiviteter. Er en utpekt ledelsen søknad aktivitet?

A. Konfigurasjon Kontroll Myndighet.

contractual configuration control authority som godkjenner implementering av en endring av et produkt (system/CI), kan i utgangspunktet bo hos en entreprenør eller Hos Regjeringen. Det kan overføre fra entreprenøren Til Regjeringen, eller kan fortsette å ligge hos entreprenøren gjennom HELE LIVSSYKLUSEN TIL CI. Denne myndigheten er teknisk ansvarlig for produktets ytelse samt finansielt ansvarlig for å finansiere endringer i produktet.

Nivået På regjeringskonfigurasjonskontroll bestemmes vanligvis som en del AV CI-utvalget. Under et oppkjøpsprogram er Det nivåene Som Regjeringen spesifiserer, kontrakter for, aksepterer og planlegger å logistisk støtte de enkelte komponentene i et system eller CIs. Government configuration control adresserer alltid den funksjonelle grunnlinjen og de tildelte grunnlinjene som er etablert for Lavere Nivå CIs, hvis spesifikasjoner er utstedt av Eller godkjent av Regjeringen . Lignende og relaterte entreprenør konfigurasjon kontroll praksis gjelder Også For CIs og komponenter under Nivået Av Regjeringen konfigurasjonskontroll.

contractual configuration control authority adresserer det totale settet med dokumenter som er baselined for produktet som kontrolleres av denne myndigheten for en bestemt kontrakt. Denne myndigheten kan være Gjeldende Dokumentendringsinstans (Cdca), beskrevet i b. nedenfor, for individuelle dokumenter som krever endring (f.eks. et system eller CI-ytelsesspesifikasjon). HVIS DET IKKE ER CDCA for et gitt dokument, har DET ikke myndighet til å godkjenne en foreslått endring av dette dokumentet, og må derfor be OM ECP-godkjenning fra gjeldende CDCA, eller velge en alternativ utforming.

B. Gjeldende Dokument Endre Myndighet.

begrepet gjeldende dokumentendringsautoritet (CDCA er et uttrykk for et forhold som alltid har eksistert. Før behovet for å administrere konfigurasjonsdokumentasjon med et automatisert informasjonssystem ble dette konseptet ikke klart formulert, men ble legemliggjort i uttrykkene ” Opprinnelig Designaktivitet “og” Nåværende Designaktivitet.”Definisjonen av disse begrepene refererer imidlertid spesifikt til designdokumenter, for eksempel tekniske tegninger, i motsetning til all dokumentasjon, og de inkluderer også frihetsberøvelse samt designansvar.

CDCA derimot, gjelder spesifikasjoner eller annen type dokument og er uavhengig av organisasjonen som fysisk vedlikeholder og lagrer dokumentet. CDCA er organisasjonen som har beslutningsmyndigheten over innholdet i dokumentet, som reflekterer proprietære eller datarettigheter til informasjonen som dokumentet inneholder. CDCA kan være En Statlig aktivitet eller en entreprenør, og myndigheten kan overføres. MEN DET er bare EN CDCA for et dokument om gangen.

scenariene i boksen illustrerer LOGIKKEN TIL CDCA-betegnelsen:

c. Søknadsaktivitet.

det kan være flere konfigurasjonskontrollmyndigheter for et produkt med mer enn en bruker; hver er en konfigurasjonskontrollmyndighet for en gitt kontrakt. Hvis konfigurasjonskontrollmyndigheten for en kontrakt ER CDCA for system / CI-Ytelsesspesifikasjonen for produktet, anses de andre konfigurasjonskontrollmyndighetene for applikasjonsaktiviteter fordi deres autoritet bare gjelder bruk av produktet og dets dokumentasjon. De kan ikke godkjenne endring til enten, men de kan delta i endringskontrollprosessen hvis de blir bedt om innspill fra enten konfigurasjonskontrollmyndigheten SOM ER CDCA, eller Av Regjeringens ledelsesprogramaktivitet.

det har alltid vært ønskelig for entreprenøren for en vare å håndtere gjennom et Enkelt regjeringskontor for koordinering av endringer. Ofte har dette ikke vært tilfelle. Hver Regjeringsaktivitet betraktet vanligvis sin autoritet som viktig og anerkjente ikke alltid at det var flere søknadsmyndigheter. Som flere bruk av elementer fortsetter å spre seg, må det være en enkel logisk metode for å skille kontroll myndighet fra bruk myndighet, og for å kommunisere og koordinere endringer som kan ha flere bruk innvirkning. Følgende Applikasjonsaktivitetsbetegnelser brukes til dette formålet:

• Application activity (AA) – en bruker av et dokument som ikke ER DENS CDCA

• Government lead application authority (GLAA) – regjeringens oppkjøpsaktivitet som er utpekt som ledelsen for oppkjøpet av varen. NÅR du antar denne rollen, konsoliderer GLAA anbefalinger fra Alle Regjeringens søknadsaktiviteter og er det eneste kontaktpunktet i Regjeringen for koordinering Med REGJERINGEN / Entreprenøren CDCA.

6.1.1.2. Endre Klassifisering.

Endringsklassifisering Er en forkortelse for endringsprosessering og / eller godkjenningsmetode. ECPs som kreves for Å bli sendt Til Regjeringen, er klassifisert som enten klasse i eller KLASSE II. En KLASSE I ECP er godkjent av Regjeringens Konfigurasjon Control Board og autorisert med en kontrakt modifikasjon. En klasse II-endring, derimot, blir vanligvis vurdert for sammenfall i klassifisering av kommunalrepresentanten, med mindre annet er angitt i kontrakten. Med mindre en regjeringsrepresentant er identifisert i kontrakten (normalt en person fra anskaffelsesaktiviteten), Er Entreprenøren (ELLER ECP-opphavsmannen) ansvarlig for å tildele endringsklassifisering. Tilsvarende kriterier for endringsklassifisering finnes I ANSI / EIA-649 der endringsklassifiseringene omtales som” Store “og” Mindre ” endringer..

i ytelsesbasert anskaffelse er definisjonen av både klasse I-og KLASSE II-endringer endret for å gjenspeile programmet bare for endringer som påvirker Konfigurasjonsdokumentasjonen Godkjent Av Myndighetene (basert). Endringer i entreprenørbasert dokumentasjon må alle gjennomgås av entreprenøren for å avgjøre om de også påvirker regjeringens ytelseskrav og støtteaktiviteter.

klassifiseringsfaktorene gjelder bare for tekniske endringer som foreslås for godkjent konfigurasjonsdokumentasjon. Selv om det å legge til en arbeidsoppgaveoppgave (for eksempel en miljøpåvirkningsanalyse) kan kreve en kontraktsendring og kan føre til økte kostnader for regjeringen, anses det ikke som en klasse i-ingeniørendring fordi verken design eller konfigurasjonsdokumentasjon påvirkes.

i klassifisere en endring, må det tas hensyn til mer enn form, passform, funksjon eller grensesnitt egenskapene TIL CI selv. Alle ECP-klassifiseringsfaktorer må vurderes før klassifisering AV EN ECP. Faktorene inkluderer mange støtte, operasjonelle og opplæringshensyn. For eksempel, hvis entreprenøren ER CDCA for kortets dokumentasjon, ville en foreslått designendring til et elektronisk kretskort ikke være en klasse jeg endrer seg selv.. Men hvis redesignet krever en endring i automatisk testutstyr eller støtteprogramvare Som Regjeringen er ansvarlig for, må endringen klassifiseres som EN KLASSE I ECP og behandles tilsvarende. Det skal bemerkes at klasse i-endringer av denne typen som feilaktig klassifiseres som klasse II eller vurderes innenfor entreprenørens CDCA-ansvar, kan føre til betydelige driftsmessige problemer og / eller logistikkstøtteproblemer og økte kostnader For Regjeringen.

Alle anvendelser av DET BERØRTE KI må vurderes ved klassifisering av en endring, f. eks. Ecp-er initiert mot ET KI som blir produsert av mer enn en entreprenør, et KI som har flere anvendelser eller brukes av mer enn en oppgaveaktivitet. Klassifiseringskriteriene må anvendes på ALLE CI-søknadene via samordning mellom de berørte aktivitetene.

6.1.1.3 Konfigurasjon Kontrollkort (CCB).

Regjeringen CCBs er etablert for store oppkjøp programmer. (Entreprenører bruker også en lignende prosess for deres interne konfigurasjonskontroll. CCBs består vanligvis av joint command eller agency organ chartret til å handle på Klasse I ECPs og forespørsler om store eller kritiske avvik. Programleder er normalt leder AV CCB og tar beslutninger om alle endringer brakt FØR CCB. CCB ER en programstyringsprosess som brukes av programlederen for å fastslå alle fordelene og konsekvensene av endringen før beslutningen fattes. NÅR EN beslutning er gjort, GODKJENNER CCB-lederen ET CCB-direktiv, eller tilsvarende brev/ memorandum, som styrer de nødvendige gjennomføringstiltakene som skal fullføres.

EN. CCB Myndighet.

HVER CCB har begrenset myndighet til å godkjenne endringer basert på følgende faktorer:

• Myndighet kan begrenses av ET HØYERE NIVÅ CCB, der Det er et Hierarki Av CCBs på et komplekst prosjekt

• EN CCB, i en organisasjon som IKKE ER CDCA for et dokument, har ikke myndighet til å godkjenne en endring i dette dokumentet.

• HVIS CDCA er organisasjonen som foreslo endringen TIL CCB, GODKJENNER CCB finansieringen og inkorporeringen av endringen til produktet, MENS CDCA godkjenner endringen i dokumentet. HVIS en organisasjon som ikke ER CDCA for et dokument, foreslår en endring til EN CCB-organisasjon som heller ikke ER CDCA for dokumentet (dvs. EN AA CCB), HAR AA CCB ikke myndighet til å godkjenne endringen.

• AA CCBs kan gjennomgå foreslåtte endringer og gi anbefalinger TIL CDCA. AA CCB kan bare bestemme seg for å vedta (eller ikke vedta) en endring som er godkjent AV CDCA.

• CCB-godkjenning av EN ECP må noen GANGER holdes tilbake i påvente av godkjenning av bestemte dokumentendringer Av CDCAs for disse dokumentene

• CCB-godkjenning kan noen ganger holdes tilbake i påvente av mottak av brukerstillinger fra Alle Myndigheter Som indikerer at de vil vedta endringen. Som nevnt i 6.1.1.1.c, flere AA-stillinger skal koordineres av EN GLAA.

B. CCB Medlemskap.

medlemskapet i CCB består normalt av sentrale funksjons-eller sakseksperter fra regjeringsorganisasjonen, f. eks. Integrert Program Team (ipt). Medlemmene er ansvarlige FOR Å gi RÅD TIL CCB-lederen. Annet funksjonelt personell kan inkluderes, som kan dikteres av endrings-og / eller programkravene, inkludert representanter fra andre DoD-tjenester (for felles tjenesteprogrammer) og andre land (for multinasjonale programmer). CCB medlemskap bør bestå av, men ikke være begrenset til representanter fra logistikk, opplæring, engineering, produksjonsstyring, kontrahering, konfigurasjonsstyring og andre programrelaterte funksjonelle disipliner. CCB medlemskap opprettholdes AV CCB charter.

c. CCB Charter.

CCB charter er normalt godkjent gjennom regjeringen skaffe aktivitet offisielle administrative kanaler. ALLE CCB-medlemmer må være til stede på HVERT CCB-møte og bør være kjent, fra deres funksjonelle perspektiv, med endringene som vurderes. CCB-medlemmer er forpliktet til å gjøre sin stilling(er) kjent for lederen; og til slutt å godkjenne CCB-direktivet/ordren (når det er nødvendig) som noterer seg deres avtale eller uenighet med vedtaket. FOR å godkjenne CCB-Direktivet (CCBD) må en person være det primære (eller alternative) CCB-medlemmet utpekt AV CCB-charteret.

D. CCB Driftsprosedyrer.

anskaffelsesaktivitetens CM-kontor skal publisere prosedyrer for CCB-drift slik at alle medlemmer forstår dens betydning for oppkjøpsprosessen. ET CCB-sekretariat planlegger møter, distribuerer agendaer, registrerer CCB-beslutninger, og distribuerer minutter og direktiver til parter som er tildelt implementerende tiltak eller har behov for å vite. CCBS driftsprosedyrer bør også definere målbehandlingstider For Ecp-Er for å sikre rettidig bemanning, godkjenning og implementering.

6.1.1.4 Effektivitet.

effektiviteten til EN ECP identifiserer mengden Eller rekkevidden Av CIs som skal endres, inkludert både produksjons-inkorporering og ettermontering av leverte CIs. Etablering AV ECP-effektivitet krever at anskaffelsesaktiviteten tar hensyn til faktorer som følgende:

• Haster-Korrigere en mangel som involverer personell sikkerhet kan være betydelig nok til å overstyre alle andre hensyn, selv samtidig støtte. Hvis driftsbegrensninger er plassert på utstyr i påvente av løsning av et sikkerhetsproblem, kan operativ effektivitet være sterkt begrenset

• Konfigurasjoner – Et av de viktigste konfigurasjonsmålene er å minimere antall FORSKJELLIGE CI-konfigurasjoner som må støttes samtidig, spesielt hvis DE forskjellige CI-konfigurasjonene krever forskjellig eller oppdatert operativ programvare, støtteutstyr, støtteprogramvare, reservedeler, opplæring eller publikasjoner. Siden alle EKSISTERENDE CI-konfigurasjoner ikke ofte kan oppdateres samtidig, må det vurderes nøye å enten forsinke eller akselerere inkorporeringen av endringen for å minimere virkningen. Innstilling av effektivitet til en fremtidig definert blokk Av CIs kan være en løsning. Kombinere eller pakke en rekke programvareendringer i neste versjon kan være en annen, etc.

• Ledetid – det er mange ledetider å vurdere når du identifiserer effektiviteten for en endring. Produksjons – / anskaffelsestider som er nødvendige for å fullføre engangskonstruksjon, anskaffe deler og materialer og innlemme endringen både i produksjon og/eller ettermontering må vurderes. Den administrative ledetiden som kreves for å behandle endringen for godkjenning, er også viktig. Regjeringen og entreprenøren har et ansvar for å unngå forsinkelse i endringsbehandling, spesielt når det er store mengder AV KI i produksjon og i operasjonell beholdning som må ettermonteres. Kostnaden ved å forsinke en beslutning kan føre til at flere foreldede konfigurasjoner blir levert som må ettermonteres. Ofte er de gjentatte kostnadene ved å erstatte komponenter i produksjonen bare erstatning av en montering av lik eller lavere kostnad for en annen; mens ettermontering av samme endring innebærer kostnaden for begge aggregater, samt tilleggskostnaden for demontering og utskifting.

• Timing-effektiviteten må kanskje velges slik at en gitt operativ evne vil være tilgjengelig på et gitt tidspunkt eller for en bestemt hendelse, for eksempel en planlagt utplassering av styrker eller en øvelse.

Tabell 6-1 gir en aktivitetsguide for evaluering av en konfigurasjonskontrollprosess.

Tabell 6-1. Aktivitetsguide: Sjekkliste for konfigurasjonskontroll For Prosessevaluering

klasse II-samhørighetsmyndighet har i mange tilfeller blitt delegert til entreprenører som følge av SPI-forslag (single process initiative). Klasse ii godkjenningsmyndighet kan imidlertid bare delegeres til entreprenører for dokumenter SOM DE ER CDCA

for korrekt anvendelse av denne informasjonen, se MERKNAD på Innholdssiden