Utviklingstrinn (programvare)

Et utviklingstrinn innen programvareteknologi er ferdigstillelsen som et programvareprodukt som skal opprettes har nådd eller bør nå på et bestemt tidspunkt. De relevante stadiene er definert når det gjelder tid og innhold som en del av prosjektledelsen . De er basert på den prosjektvalgte prosessmodellen , dens aktiviteter og milepæler eller bestemmelser i proprietære metodekonsepter og utviklingsmiljøer.

I en smalere forstand gjelder begrepet utviklingsstadium kjørbar programvare, det vil si kjørbare programmer som er gjort tilgjengelig for testing eller for brukerne som en del av prosessene for administrering av utgivelser . Avhengig av prosjektsituasjonen, ofte i mindre vedlikeholdsprosjekter , blir noen stadier utelatt, de er slått sammen eller programvaren leveres bare som en enkelt endelig versjon.

I en bredere forstand er det forskjellige utviklingsstadier for programvare i hele prosjektets forløp, der resultater også oppstår i konseptuelle prosjektfaser som er tilordnet visse milepæler ('utviklingstrinn'). Eksempel se. ^[1] På slutten av hvert trinn overføres de definerte prosjektresultatene til de påfølgende behandlingstrinnene.

Etter at programvaren har nådd sin endelige tilstand, starter utviklingssyklusen vanligvis igjen med tiltak / prosjekter for å utvide applikasjonen - med sikte på en ny programvareversjon .

Formål / forskjeller

Målet for å definere flere utviklingstrinn er generelt å oppnå faste punkter med definerte modenhetsnivåer i løpet av prosjektet for å kunne behandle de påfølgende aktivitetene mer pålitelig. Ofte forskjellige utviklingsstadier z. B. praktisert i programvaretester for å kunne kontrollere funksjonsdetaljer i påfølgende testnivåer / testtyper som er basert på funksjonaliteter som allerede er testet i forrige trinn.

Forskjellene mellom de enkelte trinnene for programvareutvikling for dataprogrammer kan for eksempel være følgende - som skal brukes til utgivelsesformålet gitt som et eksempel:

• Noen funksjoner er ennå ikke implementert; å teste individuelle funksjoner på forhånd
• ... eller bare implementeres i en enkel form (uten spesielle tilfeller); også for første / tidlige tester.
• I forrige trinn ble programvaren bare sjekket ved bruk av visse typer tester (for eksempel alfatester); å utføre betatester.
• Programvaren inneholder også tilleggsrutiner (f.eks. Stubber eller drivere); for å teste subrutiner .
• Søknaden blir gjort tilgjengelig for overføring til et spesielt system eller testmiljø og er om nødvendig tilpasset målsystemet; å utføre produksjonstester eller lasttester.
• Programmet inneholder tilleggsrutiner som støtter testing og dokumentasjon av feiltilfeller; for offentlige testere.
• Etapprelaterte overleveringer inneholder enten hele applikasjonen eller bare individuelle komponenter for (påfølgende) installasjon.
• Søknaden er fullt operativ (siste fase); for den siste overleveringen til produksjonsmiljøet .

Eksempler på utviklingsstadier

Antall utviklingstrinn med sine målnivåer av modenhet og navn varierer betydelig. Spesielt når det gjelder standardprogramvare (inkludert systemprogramvare ), angir produsenter ofte hvordan de utvikler programvaren sin i etapper, for hvem og til hvilke formål de tilbyr de respektive programvareversjonene og hvordan de navngir disse stadiene. I utviklingen av individuell programvare utføres utviklingsstadier / programvareutgivelser vanligvis på et bedriftsspesifikt grunnlag; de er ofte ikke generelt definert, men følger prosjektspesifikke forhold.

Utviklingsstadier og betegnelser for programvareutgivelser kan for eksempel være:

pre-alfa → alfa → beta → utgivelseskandidat → utgivelse .

I andre tilfeller praktiserer en produsent utgivelsesbetegnelser som følgende:

STENGT → SLUTTSTABIL → FINAL → AKTUELL BYGG → TIDSPLAN . ^[2]

Det er et hvilket som helst antall midlertidige programvareversjoner mellom slike hovedstadier i programvareutvikling, for eksempel fra flere utbedringsforsøk (og testnivåer) ved rapporterte programfeil .

For programvareutvikling generelt, dvs. ikke bare gjeldende for kjørbare programmer, de følgende trinnene i. S. kjent fra milepæler:

Prosjekt definisjon , krav analyse , krav spesifikasjon , funksjonell spesifikasjon , kodeanalyse , modul test, systemtest, prosjekt aksept

Programvaretrinn for kjørbar programvare

Pre-alfa-versjon

Generelt kan ethvert utviklingsstadium før den første alfa-versjonen omtales som en pre-alfa-versjon (fra latin prae- 'for tidlig' og fra den første bokstaven i det greske alfabetet alfa , også som α'- tegn for 1) . En slik versjon brukes ofte når en halvveis ferdig modul av programvaren skal presenteres. Et annet navn er utviklerforhåndsvisningen (av engelsk forhåndsutvikler, også forkortet ofte DP).

Alpha -versjon

Den første versjonen av et dataprogram som blir testet av fremmede (ikke de faktiske utviklerne) kalles ofte alfa -versjonen . Selv om begrepet ikke er nøyaktig definert, inneholder en alfa -versjon vanligvis allerede de grunnleggende komponentene i programvareproduktet - men det er nesten avgjørende at funksjonsområdet utvides i senere versjoner.

Spesielt inneholder alfa -versjoner stort sett programfeil av størrelsen eller mengden som gjør dem uegnet for produktiv bruk.

Også alfa -versjoner som forhåndsvisning av utviklere, forhåndsvisning av engelske utviklere eller utviklerutgivelser blir gjort tilgjengelige. Dette gjøres vanligvis i en eksklusiv krets for tredjepartsutviklere .

Beta versjon

En betaversjon er den første versjonen av et dataprogram som er publisert av produsenten for testformål. Begrepet er ikke nøyaktig definert, som en tommelfingerregel for å skille en betaversjon fra andre versjoner, er det vanligvis slik at alle viktige funksjoner i programmet er implementert i det, men ennå ikke fullt ut testet. Programmet kan eller vil derfor fortsatt inneholde mange, muligens alvorlige feil, som gjør at produktiv bruk ikke anbefales.

Fordelene med betatesting er spesielt at feil som vanligvis oppstår (for eksempel konflikter med andre programmer, problemer med visse bare i praksis, maskinvarekomponenter , tvetydige implementerte krav eller uklarheter i brukergrensesnittet ), selv før den endelige utgivelsen ( engelsk utgave ) av programmet kan gjenkjennes og utbedres eller i det minste dokumenteres.

En betatester er vanligvis den første uavhengige eller anonyme tredjepartstesteren og brukeren.

Betaversjoner av programmer kan vanligvis gjenkjennes av 0 som hovedversjonsnummeret - selvfølgelig gjelder denne varianten bare betaversjonene før den første ferdige versjonen (1.0) - eller beta -suffikset.

Betaversjoner distribueres vanligvis ikke på samme måte som utgivelseskandidater eller ferdige versjoner. Følgende alternativer brukes:

• Definerteøyeblikksbilder (nåværende utviklingsstatus) genereres fra kildekodestyringssystemet med (u) jevne mellomrom og tilbys en bloc enten i kildekoden eller som en forhåndskompilert pakke. Dette kan gjøres daglig ( nattlig bygging ), ukentlig eller når som helst som utviklerne finner passende (f.eks. Etter fullføring av et delsystem). En slik versjon kan også inneholde en automatisk bug tracking modulen (se f.eks Amarok ) for å gjøre det enklere for betatestere for å rapportere bugs til utviklere. Dette er vanligvis normen for store prosjekter med definerte utviklingsmål og en fast utgivelsesplan (f.eks. GNOME ).
• Beta -versjonen leveres i kildekontrollsystemet til en definert revisjon med en tag (en tag), men behandles ellers ikke separat. Uavhengige tilbydere kan deretter bruke dette utviklingsnivået som grunnlag for sine forhåndskompilerte pakker . Dette brukes til prosjekter som endres veldig raskt og som kan fungere uten eller bare sjelden faste utgivelser , men hvor det fortsatt er generell interesse for nåværende versjoner (f.eks. Dirac , Xine ).
• Det er ingen fast betaversjon, beta er nåværende HEAD , det vil si den stadig skiftende, faktiske utviklingsstatusen. Betatestere må laste ned, konfigurere og kompilere gjeldende status selv fra kildekodestyringssystemet; denne aktiviteten utføres vanligvis automatisk av skript levert av prosjektet. Dette er den vanligste, men den kan også kombineres med en av de to foregående metodene (dette er regelen).

Evig beta

Et begrep som beskriver at i forhold til internettets konstante utvikling, utvikles også nettsteder og programvare kontinuerlig og blir derfor aldri ferdig. Dermed har det oppstått en permanent utviklingstilstand, "Perpetual Beta". Oppsto som et slagord i Web 2.0 -konseptet, som tar hensyn til det ekstreme programmeringskonseptet " Kontinuerlig integrasjon ".

Utgivelseskandidat / forhåndsutgivelse

En utgivelseskandidat ( RC for kort, fra engelsk for utgivelseskandidat ), noen ganger også referert til som en forhåndsutgivelse (fra engelsk for "forhåndsutgivelse" eller "forhåndsversjon"), er en siste testversjon av programvare. Alle funksjoner som den endelige versjonen av programvaren skal inneholde, er allerede tilgjengelige (såkalt funksjon fullført ), og alle kjente feil er eliminert. Den endelige versjonen opprettes fra utgivelseskandidaten før publisering for å utføre en siste produkttest eller systemtest . Kvaliteten på programvaren sjekkes og eventuelle gjenværende programfeil blir søkt etter.

Hvis det gjøres en liten endring, må en annen utgivelseskandidat opprettes og testene gjentas. Utgivelseskandidatene er derfor ofte nummerert (RC1, RC2, etc.). Ingen ytterligere endringer og endelig holde en utgivelseskandidat de nødvendige kvalitetsstandardene, suffikset RCx fjernes og dermed versjonen og utgivelsen (også engelsk endelig utgivelse, endelig utgivelse eller endelig versjon, endelig versjon) forklart og publisert.

Versjoner som er betydelig mer stabile enn beta -versjoner, men som ennå ikke er testet som en utgivelseskandidat , kalles gamma -versjoner i noen utviklingsprosjekter.

For enhetsdrivere for Windows er det noen ganger status WHQL Candidate (oversatt WHQL-kandidat). Dette er en driverversjon som tilsvarer RC, som produsenten har sendt inn for WHQL -testen, men den tilsvarende sertifiseringen har ennå ikke funnet sted.

Utgivelse

Den ferdige og publiserte versjonen av programvaren er kjent som utgivelsen , noen ganger også som hovedversjonen . Dette går tradisjonelt hånd i hånd med en økning i versjonsnummeret . Når det gjelder mediebasert distribusjon, leveres denne versjonen til pressebutikken for produksjon, hvor den kopieres til databærere som CD-ROMer eller DVDer , dvs. produsert som et faktisk håndfast produkt.

Det er også etablert forskjellige betegnelser for denne statusen:

Utgivelse til produksjon / web (RTM / RTW), også første kundesending (FCS)

Klar for reproduksjon og publisering på nettet ( web )

Stabil

for en stabil versjon som ikke lenger endres

Endelig

for den siste (siste) versjonen

Generell tilgjengelighet (GA)

står for generell tilgjengelighet. Begrepet gjør det klart at versjonen er utgitt for praktisk bruk og har blitt distribuert eller er tilgjengelig via forskjellige medier. ^{[3] [4] [5]}

Gull , også Golden Master (GM)

Gullmesteren er versjonen som endelig går til pressebutikken og (fysisk) dupliseres. For å oppnå Golden Master må alle feil strykes og sluttproduktet brenne helt og fullstendig på det endelige lagringsmediet (Goldmaster DVD). Navnet kommer fra musikkbransjen. Goldmaster DVD -en produseres helt på slutten, kort tid før den sendes til pressebutikken. Siden det tidligere ikke var noen oppdateringer eller lignende, ble flere Golden Masters opprettet og grundig testet før den endelige versjonen ble sendt til pressebutikken. The Gold Master er den endelige salgsversjonen som kommer inn i pressebutikken som en original og kopier av disse blir deretter laget. Golden Master brukes fortsatt mye i musikk- og filmindustrien (CD- og DVD -produksjon); i programvareindustrien har den i stor grad blitt erstattet av oppdateringer. Det er vanligvis bare ett stykke av Goldmaster DVD.

Betegnelser

Betegnelsene på programvareversjoner, utgivelser er vanligvis ikke standardiserte og varierer vanligvis fra prosjekt til prosjekt. Noen produsenter angir også de tiltenkte betegnelsene for (planlagte) publiserte utviklingsstatuser i et slags veikart . I stedet for "Versjon" eller "Utgivelse" er følgende navn vanlige for publisert programvare:

Bygge

Resultatet av kompilering av kildekoden . I byggeprosessen , den registreres automatisk build-nummeret er vanligvis økt med en, spesielt når hele kildekoden kompileres. Siden programvaren ofte må kompileres internt for testing, har imidlertid en slik build vanligvis samme versjonsnummer som den forrige builden . Men selv med tidligere publiserte versjoner eller utgivelser er ofte for vedlikehold, for eksempel for funksjonsoppdateringer eller feilrettinger, nyere versjoner , som oppdatering publisert.

Noen programmer legge versjonsnummeret til den versjonen med en bindestrek , f.eks B. 1.2.3-4567, hvor 1 er hovedversjonsnummeret, 2.3 er det mindre versjon og revisjonsnummer og 4567 (etter bindestreken) er byggnummeret. Se også versjonsnummer .

versjon

En build som får et unikt versjonsnummer, administreres som en ny versjon av et prosjekt. Er i løpet av hurtigreparasjoner eller feilrettinger z. Hvis for eksempel en vedlikeholdsversjon er publisert, kan den ha samme versjonsnummer, men et høyere build -nummer eller et tillegg til navnet, for eksempel " Service Release 1" eller ganske enkelt " Maintenance Release ".

Utgivelse

Generelt blir en publisert versjon referert til som en utgivelse . Interne versjoner som ikke publiseres blir derfor vanligvis ikke referert til som utgivelser , men slike versjoner eller bygninger kan lekke og dermed også bli offentlige.

Begrepet beta -versjon er også problematisk, ettersom det ikke er klart definert og derfor i utgangspunktet kan stå for en uferdig utviklingsstatus. Så det er den samme betegnelsen etter utviklingstrinnene, på den ene siden, knyttet til hele prosjektet, på den andre siden kan betegnelsen også bare referere til nylig lagt til delkomponenter (og resten av prosjektet er faktisk stabilt og derfor ikke en betaversjon).

Selve den publiserte programvaren har vanligvis forskjellige navn. I tillegg til den såkalte "Release", er det også "Final" eller siste versjon (på tysk: ferdig versjon eller også endelig versjon). Imidlertid er det også begrepet "stabil" , som betyr stabil, ofte som en stabil versjon . Også her er det klart at forskjellige navn er ganske vanlige: i stedet for en versjon kan en publikasjon også gi navnet: en endelig utgivelse av et utviklingsprosjekt er bare den publiserte endelige versjonen .

Situasjonen er ikke annerledes for uferdige versjoner. Enten pre-alfa , alfa eller beta-versjon : den vanligste er "eksperimentell" (eksperimentell), "ustabil" (ustabil), "testing" så vel som "forhåndsvisning" , hver valgfritt igjen som en "versjon" eller som en " release ”” , men også som en ”build” . En build er den mest uspesifikke, men brukes også ofte i publikasjoner for å avklare statusen til uferdig programvare. Imidlertid har selv stabile og ferdige versjoner ofte et build -nummer.

En spesiell funksjon er navngivningen som nattlig bygning , oversatt: nattlig bygg . Et program med dette navnet kan være alt fra helt stabilt til helt ubrukelig, fordi prosessen nesten alltid kjører automatisk om natten (derav navnet) og er basert på den nåværende versjonen av kildekoden som utviklerne gjør sine endringer på i løpet av dagen . Kildekoden kan ha blitt skadet av de siste endringene ( engelsk ødelagt), men fortsatt oversatt for kompilatoren forblir slik mens byggeprosessen kjøres, men programmet kan fortsatt ikke kjøres. Derfor sier betegnelsen som nattlig bygning ingenting om utviklingsstadiet av programvareprosjektet.

Imidlertid er begreper som er rettet mot et bestemt publikum uavhengig av utviklingsnivået for et programvareprosjekt også vanlige. Disse forfølger vanligvis målet, som er fordelaktig for utvikleren, å utføre en ekstern betatest under visse forhold. Vilkårene for mer vidtrekkende "betaprogrammer" er heller ikke standardiserte og er forskjellige fra prosjekt til prosjekt, men det er vanlige søkeord:

Intern bygg eller privat bygg

refererer til en kjørbar versjon av et prosjekt som bare testes internt.

Utvikler Build

er en prøveversjon som spesielt (for eksterne utviklere engelsk utvikler) er beregnet. Dette brukes mest når mange tredjepartsleverandører er avgjørende for at prosjektet skal fungere, f.eks. B. i et operativsystem som mange programmer fra andre produsenter kan kjøre (eller forbli kompatible eller burde bli).
Eksempel: Rhapsody Developer Release eller Mac OS X Developer Preview

Lukket betaversjon

betegner en betaversjon som er tilgjengelig for en eksklusiv krets.
Eksempel: Windows 10 som Insider Build eller Insider Preview , som ble publisert for deltakere i et åpent (siden bare registrerbart) program av Microsoft kalt Insider Program . Opptak av testere var tidsbegrenset.

Offentlig beta

refererer til en betaversjon som er åpent og ubegrenset beregnet for tidlige brukere .
Eksempel: Mac OS X Public Beta , en betaversjon av Mac OS X 10.0 .

Tidlig tilgang

refererer til et klientprogram som vanligvis en gebyrbasert tilgang ( engelsk gir tilgang) til tidlig testing og / eller utviklerversjoner. Dette er spesielt populært blant dataspill , ettersom det på den ene siden tillater spillere å forske på visse elementer i spillverdenen lenge før en tittel slippes og hjelper med stabilitetstester på forskjellig maskinvare, på den annen side gjør det det mulig for utviklere å gjøre endringer tidlig basert på tilbakemelding basert på spilleren. Tidlig tilgangsprogrammer er vanligvis også en god finansieringskilde, ettersom utviklingsstudioet tar penger på forhånd for utvikling av spillet gjennom salg av tidlig tilgang .

En annen type navn er betegnelsen på formålet eller årsaken til at en bestemt versjon utstedes. "Vedlikeholdsutgivelsen" og "Serviceutgivelsen" , dvs. en utgivelse for vedlikehold, brukes hovedsakelig her. Dette blir ofte oversatt som vedlikeholdsversjonen.

Feilrettelse etter utgivelse

For å fikse feil i programvare som allerede er utgitt, lanserer programvareprodusenter oppdateringer, hurtigreparasjoner , oppdateringer og servicepakker . Med mange moderne applikasjoner og operativsystemer kan disse deretter hentes manuelt eller automatisk via Internett .

Firefox som et eksempel

Nettleseren Mozilla Firefox vises hver sjette uke i fire forskjellige versjoner: den eksperimentelle versjonen Firefox Nightly (pre-alfa), den eksperimentelle versjonen "Firefox Developer Edition", den for det meste stabile versjonen Firefox Beta og den stabile versjonen Firefox , ^{[6] [ 7]} som hver er forskjellige i sitt versjonsnummer, f.eks. B. Firefox Aurora 11, Firefox Beta 10, Firefox 9. Du kan også laste ned den "nattlige" Nightly Build (nåværende utviklingsstatus, bare egnet for testing). På denne måten kan utviklingsprosessen på den ene siden fremskyndes, og på den andre siden kan brukerne hjelpe med å teste og vurdere fremtidige funksjoner i den stabile versjonen ved å bruke beta- eller Aurora -versjonene og identifisere feil og sikkerhetshull ved en tidlig, da Aurora versjon tolv og Beta -versjonen vil bli gjort tilgjengelig for publikum seks uker før den endelige stabile utgivelsen.

Se også

• Kodefrysing

litteratur

• Manfred Precht, Nikolaus Meier, Dieter Tremel: Grunnleggende IT -kunnskap . Pearson Education, München 2004, ISBN 3-8273-2129-8 .
• Mike Gunderloy: Koder til utvikler. Wiley_Default, 2004, ISBN 0-7821-4327-X .

Individuelle bevis

1. ↑ Ralf Ötinger Bruker- vennlig utvikling av programvare [1] Trinn: problem analyse, krav definisjon
2. ↑ es2000 programvare laget for deg arkivert kopi ( Memento av den opprinnelige fra 11 desember 2017 i Internet Archive ) Info: Arkivkoblingen ble satt inn automatisk og er ikke kontrollert ennå. Vennligst sjekk den originale og arkivkoblingen i henhold til instruksjonene, og fjern deretter denne merknaden. @ 1 @ 2 Mal: Webachiv / IABot / www.es2000.de Support Lifecycle
3. ^ Microsoft kunngjør generell tilgjengelighet for Windows Small Business Server 2008 og Windows Essential Business Server 2008 ( Memento fra 25. desember 2008 i Internettarkivet )
4. ^ VMware kunngjør generell tilgjengelighet av VMware View 3, med banebrytende fremskritt innen administrasjon, skalering og tilpassing av virtuelle skrivebordsmiljøer ( Memento fra 5. desember 2008 i Internettarkivet )
5. ↑ Utgivelsesfaser og kriterier. (Ikke lenger tilgjengelig online.) I: cs.pomona.edu. Arkivert fra originalen 11. juli 2016 ; åpnet 24. juli 2016 . Info: Arkivkoblingen ble satt inn automatisk og er ikke kontrollert ennå. Vennligst sjekk den originale og arkivkoblingen i henhold til instruksjonene, og fjern deretter denne merknaden. @ 1 @ 2 Mal: Webachiv / IABot / www.cs.pomona.edu  
6. ^ Johnathan Nightingale: Hver sjette uke. I: blog.mozilla.org. 18. juli 2011, åpnet 24. juli 2016 .  
7. ↑ Jens Ihlenfeld: Firefox fortsetter hver 6. uke, men med versjonsnummer. golem.de , 26. august 2011, åpnet 24. juli 2016 .