Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Konfigurasjonsstyring In 140 Sommerville kap 29. Mål Forstå hvorfor konfigurasjonsstyring er viktig Bli kjent med fire grunnleggende aktiviteter i konfigurasjonsstyring.

Liknende presentasjoner


Presentasjon om: "Konfigurasjonsstyring In 140 Sommerville kap 29. Mål Forstå hvorfor konfigurasjonsstyring er viktig Bli kjent med fire grunnleggende aktiviteter i konfigurasjonsstyring."— Utskrift av presentasjonen:

1 Konfigurasjonsstyring In 140 Sommerville kap 29

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

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

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

5 Introduksjon 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 Hvorfor ulike konfigurasjoner? –Plattform –Kundespesifikke funksjoner –Markedshensyn Konfigurasjonsansvarlig Konfigurasjonsstyringsprosessen –Standarder finnes: IEEE konfigurasjonsstyringsplaner –Konfigurasjonsstyringshåndbok

6 System families

7 Introduksjon 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

8 Introduksjon 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. Fordeler ved hyppig bygging –Finner integrasjonsproblemer mellom komponenter tidligere –Fremmer bedre enhetstesting før leveranse –Mindre tidsspill med problemer pga dårlig enhetstesting Utfordringer ved daglig bygging –Holde styr på mange versjoner og feilmeldinger –

9 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

10 Identifisering av SCI Alle dokumenter er ikke like nødvendige Bestemme hva som er nødvendig - vanlig: –Prosjektplaner, spesifikasjoner, designdokumenter, kildekode og testdatasett. –Alt som kan være nødvendig for framtidig vedlikehold bør være med. 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

11 Konfigurasjonshierarki

12 Konfigurasjonsdatabase Hjelpemiddel ved konsekvensanalyse Bør kunne svare på: –Hvilke kunder har kjøpt versjon 3.11 b2 –Hva kreves av maskinvare og operativsystem for å kjøre versjon 3.11 b2 –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 b2 –Hvor mange rapporterte feil finnes det i versjon 3.11 b2 –Hva ble endret for å rette feilen som blokkerte rente-feltet Konfigurasjonsdatabasen bør være integrert med systemet for versjonsadministrasjon System for versjonsadministrasjon kan –referere til filer –inneholder filer

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

14 Prosedyre for endringsadministrasjon

15 Prosedyre for administrasjon av endringer 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 CRF vurderes av endringskontrollorganet CCB (Change Control Board) Mindre formell prosess ved inkrementell utvikling –Normalt sendes endringsønsker direkte til modulutvikler –Modulutvikler avgjør selv, men må begrunne avslag –Hvis endringen involverer flere, gjøres en formell beslutning

16 Change request form

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

18 Informasjon i starten av en komponent

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

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

21 Versjonsnummerering Navn + Versjonsnummer –Word 9.0 ReleaseNr.VersjonsNr Forutsetter lineær prosess Prosessen kan være ulineær Må holde styr på –Forskjell mellom versjoner –Sammenheng versjon og CRF –Sammenheng mellom systemversjon og komponentversjon

22 Version derivation structure

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

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

25 Utgaveadministrasjon En utgave er en versjon som distribueres til kunder En utgaveadministrator har ansvar for å –bestemme når en utgave er klar –Administrere produksjonen av utgaven med distribusjonsmedia –Dokumentere hvordan utgaven kan framstilles En utgave er mer enn eksekverbar kode –Konfigurasjonsfiler –Datafiler –Installasjonsprogram –Dokumentasjon i bok og elektronisk –Pakkemateriale og tilhørende reklame Du kan ikke forutsette at forrige versjon er installert

26 Utgavebeslutninger En ny utgave er kostbart (særlig ved massedistribusjon) Balanse mellom hyppige utgaver med lite nytt og få utgaver med mye nytt Faktorer som innvirker: –Systemets tekniske kvalitet (Feilrettingsutgave vs. Patch over www) –Konkurransesituasjonen. –Markedsførings – krav. –Endringsforslag fra kunder.

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

28 Utgavedokumentasjon Dokumenterer hvordan utgaven kan lages Spesielt viktig for systemer med lang levetid Registrere –Versjon av kildekodekomponentene –Versjon av operativsystem, biblioteker, kompilatorer Ta vare på kopier av kildekode og eksekverbar kode, med alle tilhørende filer

29 Systembygging Innebærer kompilering og lenking Dette må du sikre deg: –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. Systembyggeskript styrer systembyggesystemet. –Viser hvordan filer avhenger av hverandre. –Rekompilering bare hvis nødvendig –Hva med flere versjoner av kildefiler?

30 Systembygging

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

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

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

34 Støtte for systembygging 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 Stand-alone make eller integrert med CASE Består av –Avhengighetsspesifikasjonsspråk og interpreter –Verktøyvalgsstøtte –Distribuert kompilering –Håndtering av deriverte objekter

35 Komponenter som avhenger av hverandre

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

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


Laste ned ppt "Konfigurasjonsstyring In 140 Sommerville kap 29. Mål Forstå hvorfor konfigurasjonsstyring er viktig Bli kjent med fire grunnleggende aktiviteter i konfigurasjonsstyring."

Liknende presentasjoner


Annonser fra Google