Konfigurasjonsstyring In 140 Sommerville kap 29 Plan n

Konfigurasjonsstyring In 140 Sommerville kap 29

Plan n 28/4: Konfigurasjonsstyring. Styring av endringer. Versjonsproblematikk n 29/4: Brukermedvirkning n 5/5: Åpen kildekode som systemutviklingsmetode n 6/5: Oppsummering med eksamenstips

Mål Forstå hvorfor konfigurasjonsstyring er viktig n Bli kjent med fire grunnleggende aktiviteter i konfigurasjonsstyring n – – n konfigurasjonsplanlegging endringsadministrasjon versjon og utgavestyring systembygging Forstå hvordan CASE-verktøy kan brukes til å støtte konfigurasjonsstyring

Introduksjon n Kunsten å koordinere programvareutvikling for å unngå problemer med ulike versjoner kalles konfigurasjonsstyring n Konfigurasjonsstyring er kunsten å identifisere, organisere og kontrollere endringer i programvaren som er under bygging. n Målet er å oppnå best mulig produktivitet ved å redusere antall feil

Introduksjon n Dette skal administreres: – Endringsforslag, Feilrettinger, Tilpasning til maskinvare og operativsystemer – Mange versjoner kan være i bruk og utvikling samtidig – Hvordan endringer er implementert n Konfigurasjonsstyringsprosedyrer – Hvordan behandle og registrere endringsønsker – Hvordan knytte disse til systemkomponenter – Hvordan identifisere versjoner n Konfigurasjonsstyringsverktøy – Lagrer versjoner – Bygger systemer av dem – Holder styr på hva som er levert til hvilken kunde

Introduksjon n Konfigurasjonsstyring er ofte kombinert med kvalitetsstyring – Baseline: Spesifikasjon eller produkt som er blitt formelt vurdert og godkjent og som brukes som grunnlag for videre utvikling. Kan bare endres ved formell endringskontrollprosess n Hvorfor ulike konfigurasjoner? – Plattform – Kundespesifikke funksjoner – Markedshensyn Konfigurasjonsansvarlig n Konfigurasjonsstyringsprosessen n – Standarder finnes: • IEEE 828 -1983 konfigurasjonsstyringsplaner – Konfigurasjonsstyringshåndbok

System families

Introduksjon n CM ved Fossefallsmodellen – Komponentene leveres når de er testet – CM-teamet har ansvar for systemsammenbygging og testing – Feil som oppdages blir meldt til utviklerne som må levere en oppdatert komponent – Standardene forutsetter gjerne fossefallsmodell

Introduksjon n CM når fossefallsmodellen ikke blir anvendt dvs. inkrementell utvikling – – Hyppig systembygging Støtter samtidig utvikling og testing Tidsfrist for levering av komponenter (kan være skjelett) Ny versjon bygges av de leverte komponentene ved kompilering og linking – Systemet leveres til testteamet som kjører tester etter plan – Samtidig arbeider utviklerne videre med systemet – Feil som finnes meldes til utviklerne som må rette dem i senere versjoner. n Fordeler ved hyppig bygging – Finner integrasjonsproblemer mellom komponenter tidligere – Fremmer bedre enhetstesting før leveranse – Mindre tidsspill med problemer pga dårlig enhetstesting n Utfordringer ved daglig bygging – Holde styr på mange versjoner og feilmeldinger

CM-planlegging – Definere standarder og framgangsmåter for CM – Tilpasses prosjektet – CM-plan • Hva skal administreres og plan for hvordan hver del skal identifiseres. (SCI Software Configuration Item) • Hvem har ansvaret for CM og hvem skal levere SCI til CM • Hvordan skal endringsstyring og versjonsadministrasjon utføres • Hva skal registreres i forbindelse med CM-prosessen • Hvilke verktøy skal anvendes og hvordan går man fram når de skal brukes • Definisjon av konfigurasjonsdatabase. • Kan også dekke administrasjon av programvare levert utenfra og arbeide for å vurdere CM-prosessen. – Ansvarsplassering er viktig

Identifisering av SCI Alle dokumenter er ikke like nødvendige n Bestemme hva som er nødvendig - vanlig: n – Prosjektplaner, spesifikasjoner, designdokumenter, kildekode og testdatasett. – Alt som kan være nødvendig for framtidig vedlikehold bør være med. n Plan for navnsetting – – Unikt navn for alle SCI Hvordan vise sammenhenger – hierarkisk strukturering Ulempe: Knytter enheter til prosjekt og hindrer gjenbruk Ulempe: Dokumenter av samme type blir spredd

Konfigurasjonshierarki

Konfigurasjonsdatabase Hjelpemiddel ved konsekvensanalyse n Bør kunne svare på: n – Hvilke kunder har kjøpt versjon 3. 11 b 2 – Hva kreves av maskinvare og operativsystem for å kjøre versjon 3. 11 b 2 – Hvor mange versjoner er laget og når – Hvilke versjoner vil endres ved endring i en bestemt komponent – Hvor mange endringsønsker ligger i kø for versjon 3. 11 b 2 – Hvor mange rapporterte feil finnes det i versjon 3. 11 b 2 – Hva ble endret for å rette feilen som blokkerte rente-feltet Konfigurasjonsdatabasen bør være integrert med systemet for versjonsadministrasjon n System for versjonsadministrasjon kan n – referere til filer – inneholder filer.

Endringsadministrasjon Endringer er uunngåelige n Endringsadministrasjonsprosess n – Fastlagt og støttet av CASE – Sikrer registrering, gjennomføring og testing – Sikrer lønnsomhetsvurdering

Prosedyre for endringsadministrasjon

Prosedyre for administrasjon av endringer n Change Request Form – Hvem ønsker å endre hva – Validering (nb! Tilbakemelding ved avslag) – Konsekvensanalyse • Hvordan kan det gjennomføres • Hva koster det – Beslutning CRF bør registreres i konfigurasjonsdatabasen n CRF vurderes av endringskontrollorganet CCB (Change Control Board) n Mindre formell prosess ved inkrementell utvikling n – Normalt sendes endringsønsker direkte til modulutvikler – Modulutvikler avgjør selv, men må begrunne avslag – Hvis endringen involverer flere, gjøres en formell beslutning

Change request form

Endringshistorie (Derivation history) Bør beskrive hva som ble endret av hvem, når og hvorfor n Kan lages som kommentar i starten av hver komponent n Bør referere til CRF (Endringsanmodning) n Endringsrapporteringsverktøy n

Informasjon i starten av en komponent

Versjon og Release-administrasjon Framgangsmåte for å identifisere og holde styr på versjoner og releaser n Versjonsadministratorer planlegger hvordan versjoner kan hentes fram og hindrer endring av feil versjon n Nye versjoner skal framstilles av CM-teamet n Versjon n – En utgave av systemet som skiller seg fra andre utgaver n Variant – Hvis forskjellen liten, kan det kalles en variant n Release – En versjon som leveres til kunder n Versjonsadministrasjon støttes av CASE – Versjon kvitteres ut for endring – Leveres inn igjen og får nytt versjonsnummer.

Versjonsidentifikasjon Mange komponenter i mange versjoner n Tre teknikker for komponentidentifikasjon n – Versjonsnummerering – Attributtbasert identifikasjon – Endrings-orientert identifisering

Versjonsnummerering n Navn + Versjonsnummer – Word 9. 0 Release. Nr. Versjons. Nr n Forutsetter lineær prosess n Prosessen kan være ulineær n Må holde styr på n – Forskjell mellom versjoner – Sammenheng versjon og CRF – Sammenheng mellom systemversjon og komponentversjon

Version derivation structure

Attributtbasert identifikasjon n Inneholder mer informasjon enn versjonsnummerering – – – Kunde Programmeringsspråk Utviklingsstatus Plattform Dato Lettere å finne ønsket versjon n Database for å holde greie på sammenhengen mellom attributter og fil. n

Endringsorientert identifikasjon Endringsadministrasjonssystemet lagrer endringene (For hver modul som er endret) n Kan lage nye versjoner ved å bruke et sett endringer n Problematisk i praksis – En endring kan bygge på en annen endring, slik at du ikke kan bruke den ene uten den andre n

Release-administrasjon En release er en versjon som distribueres til kunder n En release-administrator har ansvar for å n – bestemme når en release er klar – Administrere produksjonen av releasen med distribusjonsmedia – Dokumentere hvordan releasen kan framstilles n En release er mer enn eksekverbar kode – – – n Konfigurasjonsfiler Datafiler Intallasjonsprogram Dokumentasjon i bok og elektronisk Pakkemateriale og tilhørende reklame Du kan ikke forutsette at forrige versjon er installert

Release-beslutninger En ny release er kostbart (særlig ved massedistribusjon) n Balanse mellom hyppige releaser med lite nytt og få releaser med mye nytt n Faktorer som innvirker: n – Systemets tekniske kvalitet (Feilrettingsrelease vs. Patch over www) – Konkurransesituasjonen. – Markedsførings – krav. – Endringsforslag fra kunder.

Å lage en ny release n Det er å lage en komplett samling av filer og dokumentasjonen – – n Både programkode og datafiler Konfigurasjonsbeskrivelser forskjellige miljø Elektroniske kopier av dokumentasjonen Skript for installasjonsprogrammet Når alt er klart – lage master-disk – CD-Rom 640 MByte – Distribusjon over internett.

Release-dokumentasjon Dokumenterer hvordan releasen kan lages n Spesielt viktig for systemer med lang levetid n Registrere n – Versjon av kildekomponentene – Versjon av operativsystem, biblioteker, kompilatorer n Ta vare på kopier av kildekode og eksekverbar kode, med alle tilhørende filer

Systembygging Innebærer kompilering og lenking n Dette må du sikre deg: n – – At alle komponenter er med i byggeinstruksjonen At riktig versjon av hver komponent blir brukt At alle nødvendige datafiler er til stede Blir datafilene tilgjengelige med samme navn/plassering på systemet du bygger for – Er korrekt versjon av kompilator og andre verktøy til stede? CM-verktøy sikrer korrekt skript til systembyggeprosessen. n Systembyggeskript styrer systembyggesystemet. n – Viser hvordan filer avhenger av hverandre. – Rekompilering bare hvis nødvendig – Hva med flere versjoner av kildefiler?

Systembygging

konfigurasjonsadministrasjon og CASE n Konfigurasjonsadministrasjon: – Store datamengder og store krav – En feil er nok til at det ikke virker n Mange CASE-verktøy i bruk – 1. Generasjon: Revisjonskontroll og Make – 2. Generasjon delvis integrert CM – 3. Generasjon full integrert CM • • n Planlegging Endringsadministrasjon Versjonsadministrasjon Systembygging 3. Generasjonsverktøy er komplekst og dyrt

Støtte for endringsadministrasjon Skjemaeditor n Arbeidsfordelingssystem n – Sender skjema til riktig person – E-postbasert informasjon om saksframgang n Endringsdatabase – Kan kobles til versjonsadministrasjon

Støtte for versjonsadministrasjon Store informasjonsmengder n Systemendringer må registreres og kontrolleres n Depository for SCI n – En SCI kan ikke endres – En SCI kan sjekkes ut, endres og lagres som SCI med nytt versjonsnummer. n Andre egenskaper – – Versjonsidentifikasjon Lagringsadministrasjon (Deltalagring) Endringshistorie Uavhengig utvikling

Støtte for systembygging n Kompilering og lenking av større systemer involverer hundrevis av filer og kan ta mange timer – En feil er nok til å vrake prosessen Systembyggingsverktøy automatiserer prosessen n Stand alone: Make eller Integrert med CASE n Består av n – – Avhengighetsspesifikasjonsspråk og interpreter Verktøyvalgsstøtte Distribuert kompilering Håndtering av deriverte objekter

Komponenter som avhenger av hverandre

Hovedpunkter Konfigurasjonsadministrasjon er administrasjon av systemendringer n I store prosjekter bør vi lage en plan for å sette navn på dokumenter n CM-teamet bør støtte seg på en konfigurasjonsdatabase over systemendringer og endringsønsker n Planlegg en versjonsidentifiseringsmetode bygd på versjonsnummer, attributter eller endringer de implementerer n

Hovedpunkter En release inneholder eksekverbar kode, datafiler, konfigurasjonsfiler og dokumentasjon. Releasadministrasjon innebærer å beslutte når og å lage istand og dokumentere en release n Systembygging er å sette sammen komponentene til et eksekverbart program n Det finnes CASE-verktøy som støtter CM n CASE-verktøy kan være stand-alone eller integrerte. n