Konfigurasjonsstyring - Configuration management

Konfigurasjonsstyringsaktivitetsmodell på toppnivå

Configuration management ( CM ) er en systemteknisk prosess for å etablere og opprettholde konsistensen av produktets ytelse, funksjonelle og fysiske attributter med dets krav, design og driftsinformasjon gjennom hele livet. CM -prosessen er mye brukt av militære ingeniørorganisasjoner for å håndtere endringer gjennom systemets livssyklus for komplekse systemer , for eksempel våpensystemer , militære kjøretøyer og informasjonssystemer . Utenfor militæret brukes CM -prosessen også med IT -tjenestestyring som definert av ITIL , og med andre domenemodeller i anleggs- og andre industritekniske segmenter som veier, broer, kanaler , demninger og bygninger.

Introduksjon

CM brukt over livssyklusen til et system gir synlighet og kontroll over dets ytelse, funksjonelle og fysiske attributter. CM bekrefter at et system fungerer etter hensikten, og er identifisert og dokumentert i tilstrekkelig detalj for å støtte den forventede livssyklusen. CM -prosessen letter ordnet styring av systeminformasjon og systemendringer for slike fordelaktige formål som å revidere evnen; forbedre ytelse, pålitelighet eller vedlikeholdsevne; forlenge livet; redusere kostnadene; redusere risiko og ansvar; eller rette feil. De relativt minimale kostnadene ved å implementere CM returneres mangfoldig for å unngå kostnader. Mangelen på CM, eller dens ineffektive implementering, kan være veldig dyrt og noen ganger kan ha slike katastrofale konsekvenser som feil på utstyr eller tap av liv.

CM understreker det funksjonelle forholdet mellom deler, delsystemer og systemer for effektivt å kontrollere systemendringer. Det hjelper til med å bekrefte at foreslåtte endringer systematisk blir vurdert for å minimere bivirkninger. Endringer i systemet foreslås, evalueres og implementeres ved hjelp av en standardisert, systematisk tilnærming som sikrer konsistens, og foreslåtte endringer evalueres når det gjelder deres forventede innvirkning på hele systemet. CM bekrefter at endringer utføres som foreskrevet og at dokumentasjon av varer og systemer gjenspeiler deres sanne konfigurasjon. Et komplett CM -program inkluderer bestemmelser for lagring, sporing og oppdatering av all systeminformasjon på en komponent, delsystem og systembasis.

Et strukturert CM -program sikrer at dokumentasjon (f.eks. Krav, design, test og akseptdokumentasjon) for varer er nøyaktig og i samsvar med den faktiske fysiske utformingen av varen. I mange tilfeller, uten CM, eksisterer dokumentasjonen, men er ikke i samsvar med selve varen. Av denne grunn blir ingeniører, entreprenører og ledelse ofte tvunget til å utvikle dokumentasjon som gjenspeiler elementets faktiske status før de kan fortsette med en endring. Denne reverse engineering -prosessen er sløsing med hensyn til menneskelige og andre ressurser og kan minimeres eller elimineres ved hjelp av CM.

Historie

Configuration Management oppstod i USAs forsvarsdepartement på 1950 -tallet som en teknisk styringsdisiplin for maskinvaremateriell - og det er nå en standard praksis i praktisk talt alle bransjer. CM-prosessen ble sin egen tekniske disiplin en gang på slutten av 1960-tallet da DoD utviklet en serie militære standarder kalt "480-serien" (dvs. MIL-STD-480, MIL-STD-481 og MIL-STD-483) som ble deretter utgitt på 1970 -tallet. I 1991 ble "480-serien" konsolidert i en enkelt standard kjent som MIL-STD-973 som ble deretter erstattet av MIL-HDBK-61 i henhold til en generell DoD mål som redusert antall militære standarder i favør av bransjen teknisk standarder som støttes av standardutviklingsorganisasjoner (SDO). Dette markerte begynnelsen på det som nå har utviklet seg til den mest distribuerte og aksepterte standarden på CM, ANSI – EIA – 649 –1998. CM -disiplinens konsepter, som nå er vidt vedtatt av mange organisasjoner og byråer, inkluderer systemteknikk (SE), Integrated Logistics Support (ILS), Capability Maturity Model Integration (CMMI), ISO 9000 , Prince2 prosjektledelsesmetode, COBIT , ITIL , produktlivssyklusstyring og Application Lifecycle Management . Mange av disse funksjonene og modellene har redefinert CM fra sin tradisjonelle helhetlige tilnærming til teknisk ledelse. Noen behandler CM som en bibliotekaraktivitet, og bryter ut endringskontroll eller endringsledelse som en egen eller frittstående disiplin.

Oversikt

CM er praksisen med å håndtere endringer systematisk slik at et system opprettholder sin integritet over tid. CM implementerer retningslinjene, prosedyrene, teknikkene og verktøyene som administrerer, evaluerer foreslåtte endringer, sporer status for endringer og opprettholder en oversikt over system- og støttedokumenter etter hvert som systemet endres. CM -programmer og planer gir teknisk og administrativ retning for utvikling og implementering av prosedyrer, funksjoner, tjenester, verktøy, prosesser og ressurser som kreves for å utvikle og støtte et komplekst system. Under systemutvikling lar CM programledelse spore krav gjennom livssyklusen gjennom aksept og drift og vedlikehold. Ettersom endringer uunngåelig skjer i krav og design, må de godkjennes og dokumenteres, noe som skaper en nøyaktig oversikt over systemstatusen. Ideelt sett brukes CM -prosessen gjennom systemets livssyklus . De fleste fagfolk blander seg eller blir forvirret med Asset Management (AM, se også ISO/IEC 19770 ), der den lagerfører eiendelene. Den viktigste forskjellen mellom CM og AM er at førstnevnte ikke administrerer det økonomiske regnskapsaspektet, men på tjenesten som systemet støtter eller med andre ord, at den senere (AM) prøver å realisere verdi fra en IT -eiendel.

CM-prosessen for både maskinvare- og programvarekonfigurasjonselementer består av fem forskjellige disipliner som er etablert i MIL – HDBK – 61A og i ANSI/EIA-649. Disse disipliner utføres som retningslinjer og prosedyrer for å etablere grunnlinjer og for å utføre en standard endringshåndteringsprosess . Den IEEE 12207 prosessen IEEE 12207,2 har også disse aktivitetene og legger til "Slipp ledelse og levering". De fem disipliner er:

  1. CM Planning and Management: et formelt dokument og en plan for å veilede CM -programmet som inneholder elementer som:
    • Personale
    • Ansvar og ressurser
    • Treningskrav
    • Retningslinjer for administrativt møte, inkludert en definisjon av prosedyrer og verktøy
    • Baselineringsprosesser
    • Konfigurasjonskontroll og konfigurasjonsstatusregnskap
    • Navngivningskonvensjoner
    • Revisjoner og anmeldelser
    • Underleverandør/leverandør CM krav
  2. Configuration Identification (CI): består av å sette og vedlikeholde grunnlinjer, som definerer system- eller delsystemarkitekturen, komponenter og enhver utvikling når som helst. Det er grunnlaget for hvordan endringer i en hvilken som helst del av et system blir identifisert, dokumentert og senere sporet gjennom design, utvikling, testing og endelig levering. CI etablerer og opprettholder det endelige nåværende grunnlaget for konfigurasjonsstatusregnskap (CSA) for et system og dets konfigurasjonselementer (CI) gjennom hele livssyklusen (utvikling, produksjon, distribusjon og driftsstøtte) til avhending.
  3. Konfigurasjonskontroll: inkluderer evaluering av alle endringsforespørsler og endringsforslag, og deres påfølgende godkjenning eller avvisning. Den dekker prosessen med å kontrollere endringer i systemets design, maskinvare, fastvare, programvare og dokumentasjon.
  4. Konfigurasjonsstatusregnskap: inkluderer prosessen med å registrere og rapportere beskrivelser av konfigurasjonselementer (f.eks. Maskinvare, programvare, fastvare, etc.) og alle avvik fra grunnlinjen under design og produksjon. Ved mistanke om problemer kan verifisering av grunnlinjekonfigurasjon og godkjente modifikasjoner raskt bestemmes.
  5. Konfigurasjonskontroll og revisjon: en uavhengig gjennomgang av maskinvare og programvare med det formål å vurdere samsvar med etablerte ytelseskrav, kommersielle og passende militære standarder, og funksjonelle, tildelte og produktbaselinjer. Konfigurasjonsrevisjoner bekrefter at system- og undersystemets konfigurasjonsdokumentasjon er i samsvar med funksjonelle og fysiske ytelsesegenskaper før de godtas i en arkitektonisk grunnlinje.

Programvare

Programvarekonfigurasjonsstyringsprosessen (SCM) blir sett på av praktikere som den beste løsningen for å håndtere endringer i programvareprosjekter. Den identifiserer de funksjonelle og fysiske attributtene til programvare på forskjellige tidspunkter, og utfører systematisk kontroll av endringer i de identifiserte attributtene med det formål å opprettholde programvareintegritet og sporbarhet gjennom programvareutviklingens livssyklus.

SCM -prosessen definerer videre behovet for å spore endringer og muligheten til å bekrefte at den endelige leverte programvaren har alle de planlagte forbedringene som skal inkluderes i utgivelsen. Den identifiserer fire prosedyrer som må defineres for hvert programvareprosjekt for å sikre at en forsvarlig SCM -prosess er implementert. De er:

  1. Konfigurasjonsidentifikasjon
  2. Konfigurasjonskontroll
  3. Konfigurasjonsstatusregnskap
  4. Konfigurasjonsrevisjoner

Disse begrepene og definisjonene endres fra standard til standard, men er i hovedsak de samme.

  • Konfigurasjonsidentifikasjon er prosessen med å identifisere attributtene som definerer alle aspekter av et konfigurasjonselement. Et konfigurasjonselement er et produkt (maskinvare og/eller programvare) som har et sluttbrukerformål. Disse attributtene er registrert i konfigurasjonsdokumentasjon og baselined. Baselining av et attributt tvinger til at formelle konfigurasjonsendringskontrollprosesser utføres i tilfelle at disse attributtene endres.
  • Konfigurasjonsendringskontroll er et sett med prosesser og godkjenningstrinn som kreves for å endre attributtene til et konfigurasjonselement og for å baseline dem på nytt.
  • Konfigurasjonsstatusregnskap er muligheten til å registrere og rapportere om konfigurasjonsgrunnlinjene som er knyttet til hvert konfigurasjonselement når som helst.
  • Konfigurasjonsrevisjoner er delt inn i funksjonelle og fysiske konfigurasjonsrevisjoner . De skjer enten ved levering eller på tidspunktet for endringen. En funksjonell konfigurasjonsrevisjon sikrer at funksjonelle og ytelsesattributter for et konfigurasjonselement oppnås, mens en fysisk konfigurasjonsrevisjon sikrer at et konfigurasjonselement installeres i samsvar med kravene i den detaljerte designdokumentasjonen.

Konfigurasjonsstyringsdatabase

ITIL spesifiserer bruk av et konfigurasjonsstyringssystem (CMS) eller konfigurasjonsstyringsdatabase (CMDB) som et middel for å oppnå industriens beste praksis for konfigurasjonsstyring. CMDB brukes til å spore konfigurasjonselementer (CI) og avhengighetene mellom dem, der CI representerer tingene i et foretak som er verdt å spore og administrere, for eksempel, men ikke begrenset til, datamaskiner, programvare, programvarelisenser, stativer, nettverksenheter, lagring , og til og med komponentene i slike elementer.

Fordelene med et CMS/CMDB inkluderer å kunne utføre funksjoner som rotårsaksanalyse, konsekvensanalyse, endringshåndtering og nåværende tilstandsvurdering for fremtidig utvikling av statsstrategi. Eksempler på systemer som vanligvis identifiserer seg som ITSM -systemer (IT Service Management) , inkluderer FreshService, ServiceNow og Samanage.

Informasjonssikring

For informasjonssikring kan CM defineres som styring av sikkerhetsfunksjoner og forsikringer gjennom kontroll av endringer i maskinvare, programvare, fastvare, dokumentasjon, test, testarmaturer og testdokumentasjon gjennom et datasystems livssyklus. CM for informasjon forsikring, noen ganger referert til som S ecure C onfiguration M anagement, er avhengig av ytelse, funksjonelle og fysikalske attributter av IT-plattformer og produkter og deres miljø for å bestemme de riktige sikkerhetsfunksjoner og forsikringer som brukes til å måle en systemkonfigurasjon tilstand . Konfigurasjonskrav kan for eksempel være forskjellige for en nettverksbrannmur som fungerer som en del av en organisasjons internettgrense mot en som fungerer som en intern lokal nettverksbrannmur.

Vedlikeholdssystemer

Konfigurasjonsstyring brukes til å opprettholde en forståelse av statusen til komplekse eiendeler med sikte på å opprettholde det høyeste servicenivået til de laveste kostnadene. Spesielt har den til hensikt å sikre at driften ikke blir forstyrret på grunn av at eiendelen (eller deler av eiendelen) overskrider grenser for planlagt levetid eller under kvalitetsnivåer.

I militæret blir denne typen aktiviteter ofte klassifisert som "misjonsberedskap", og søker å definere hvilke eiendeler som er tilgjengelige og for hvilken type oppdrag; et klassisk eksempel er om fly om bord på et hangarskip er utstyrt med bomber for bakkestøtte eller missiler for forsvar.

Administrasjon av operativsystemkonfigurasjon

Konfigurasjonsbehandling kan brukes til å vedlikeholde OS -konfigurasjonsfiler. Eksempler på systemer inkluderer Ansible , Bcfg2 , CFEngine , Chef , Nix , Otter , Puppet , Quattor , SaltStack , Terraform , Pulumi og Vagrant . Mange av disse systemene bruker infrastruktur som kode for å definere og vedlikeholde konfigurasjon.

Den løftet teorien av konfigurasjon vedlikehold ble utviklet av Mark Burgess , med en praktisk implementering på nåværende dag datasystemer i programvaren cfengine i stand til å utføre sanntids reparasjon, så vel som forebyggende vedlikehold.

Forebyggende vedlikehold

Å forstå tilstanden til en eiendel og dens hovedkomponenter er "slik den er" er et vesentlig element i forebyggende vedlikehold som brukes i vedlikeholds-, reparasjons-, og overhalings- og foretaksstyringssystemer .

Komplekse eiendeler som fly, skip, industrimaskiner etc. er avhengige av at mange forskjellige komponenter kan brukes. Denne brukbarheten er ofte definert ut fra mengden bruk komponenten har hatt siden den var ny, siden den ble montert, siden den ble reparert, mengden bruk den har hatt i løpet av sin levetid og flere andre begrensende faktorer. Å forstå hvor nær hver levetid hver av disse komponentene har vært, har vært et stort arbeid med arbeidskrevende journalføring frem til den siste utviklingen innen programvare.

Forutsigbart vedlikehold

Mange typer komponenter bruker elektroniske sensorer til å fange data som gir overvåking av levende tilstand . Disse dataene analyseres om bord eller på et eksternt sted av datamaskinen for å evaluere nåværende brukbarhet og i økende grad dens sannsynlige fremtidige tilstand ved hjelp av algoritmer som forutsier potensielle fremtidige feil basert på tidligere eksempler på feil gjennom feltopplevelse og modellering. Dette er grunnlaget for "prediktivt vedlikehold".

Tilgjengelighet av nøyaktige og betimelige data er avgjørende for at CM skal gi driftsverdi, og mangel på dette kan ofte være en begrensende faktor. Å fange og spre driftsdata til de forskjellige støtteorganisasjonene blir en bransje i seg selv.

Forbrukerne av disse dataene har blitt flere og mer komplekse med veksten av programmer som tilbys av produsenter av originalutstyr (OEM). Disse er designet for å tilby operatører garantert tilgjengelighet og gjøre bildet mer komplekst med operatøren som administrerer eiendelen, men OEM påtar seg ansvaret for å sikre dets brukbarhet.

Standarder

En rekke standarder støtter eller inkluderer konfigurasjonsadministrasjon, inkludert:

  • ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
  • EIA-649-A 2004 National Consensus Standard for Configuration Management
  • ANSI EIA-649-C 2019 Configuration Management Standard
  • ISO 10007 Kvalitetsstyringssystemer - Retningslinjer for konfigurasjonsstyring
  • Federal Standard 1037C
  • GEIA Standard 836–2002 Datautveksling og interoperabilitet for konfigurasjonsadministrasjon
  • IEEE 829 Standard for programvaretestdokumentasjon
  • 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering . 2012. doi : 10.1109/IEEESTD.2012.6170935 . ISBN 978-0-7381-7232-3.
  • MIL-STD-973 Configuration Management (kansellert 20. september 2000)
  • NATO STANAG 4427 Configuration Management in Systems Life Cycle Management inkludert
  • NATO ACMP 2000 Policy on Configuration Management
  • NATO ACMP 2009 Veiledning om konfigurasjonsstyring
  • NATO ACMP 2100 Kontraktsmessige krav til konfigurasjonsstyring
  • CMMI CMMI for utvikling, versjon 1.2 Configuration Management
  • CMII-100E CMII Standard for Enterprise Configuration Management
  • Utvidet liste over konfigurasjonsadministrasjon og relaterte standarder
  • ITIL Service Asset and Configuration Management
  • ISO 20000: 1 2011 & 2018 Service Management System.
  • ECSS-M-ST-40C Rev.1 Konfigurasjon og informasjonshåndtering

Retningslinjer

  • IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering, publisert dato: 2012-03-16
  • ISO 10007: 2017 Kvalitetsstyring - Retningslinjer for konfigurasjonsstyring
  • NATO ACMP-2009-Veiledning om konfigurasjonsstyring
  • ANSI/EIA-632-1998 Prosesser for prosjektering av et system
  • ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
  • GEIA-HB-649-Implementeringsguide for konfigurasjonsstyring
  • EIA-836 konsensusstandard for datautveksling og interoperabilitet for konfigurasjonsstyring
  • MIL-HDBK-61B Konfigurasjonshåndteringsveiledning, 7. april 2020
  • MIL-STD-3046 Configuration Management, 6. mars 2013 og kansellert 1. juni 2015
  • Retningsbok for forsvarsanskaffelse, elementer av CM på 4.3.7 SE -prosesser, attributter for CM på 5.1.7 livssyklusstøtte
  • System Engineering Fundamentals, Chapter 10 Configuration Management
  • Configuration Management Plan United States Dept. of Defense Acquisition document

Konstruksjon

Nylig har konfigurasjonsstyring blitt brukt på store byggeprosjekter som ofte kan være svært komplekse og ha et stort antall detaljer og endringer som må dokumenteres. Bygningsbyråer som Federal Highway Administration har brukt konfigurasjonsstyring for sine infrastrukturprosjekter. Det er konstruksjonsbaserte konfigurasjonsstyringsverktøy som tar sikte på å dokumentere endringsordre og RFI-er for å sikre at et prosjekt forblir i rute og budsjett. Disse programmene kan også lagre informasjon for å hjelpe til med vedlikehold og endring av infrastrukturen når den er fullført. En slik applikasjon, ccsNet, ble testet i en casestudie finansiert av Federal Transportation Administration (FTA) der effekten av konfigurasjonsstyring ble målt ved å sammenligne den omtrent 80% komplette konstruksjonen av Los Angeles County Metropolitan Transit Agency (LACMTA) først og andre segmenter av Red Line, et jernbaneprosjekt på 5,3 milliarder dollar. Denne studien ga resultater som indikerer en fordel ved å bruke konfigurasjonsstyring på prosjekter av denne art.

Se også

Referanser