Ontwikkelingsfase (software)

Van Wikipedia, de gratis encyclopedie
Spring naar navigatie Spring naar zoeken

Een ontwikkelingsstadium in softwaretechnologie is de staat van voltooiing die een te maken softwareproduct op een bepaald moment heeft bereikt of zou moeten bereiken. De relevante fasen worden in het kader van projectmanagement naar tijd en inhoud gedefinieerd. Ze zijn gebaseerd op het door het project geselecteerde procesmodel , de activiteiten en mijlpalen of bepalingen in eigen methodeconcepten en ontwikkelomgevingen.

In engere zin heeft de term ontwikkelingsfase betrekking op uitvoerbare software, dat wil zeggen op uitvoerbare programma's die beschikbaar worden gesteld voor testen of aan hun gebruikers als onderdeel van de releasebeheerprocessen van een project. Afhankelijk van de projectsituatie, vaak bij kleinere onderhoudsprojecten , worden enkele fasen weggelaten, samengevoegd of wordt de software slechts als één definitieve versie geleverd.

In bredere zin zijn er in het gehele traject van het project verschillende ontwikkelingsstadia voor software, waarbij ook resultaten ontstaan ​​in conceptuele projectfasen die aan bepaalde mijlpalen ('ontwikkelingsstadia') worden toegekend. Voorbeeld zie. [1] Aan het einde van elke fase worden de gedefinieerde projectresultaten overgedragen naar de volgende verwerkingsfasen.

Nadat de software zijn definitieve staat heeft bereikt, begint de ontwikkelcyclus meestal opnieuw met maatregelen/projecten om de applicatie uit te breiden - met als doel een nieuwe softwareversie .

Doel / verschillen

Het doel voor het definiëren van meerdere ontwikkelingsstadia is in het algemeen het bereiken van vaste punten met gedefinieerde volwassenheidsniveaus in de loop van het project om de daaropvolgende activiteiten betrouwbaarder te kunnen verwerken. Vaak verschillende ontwikkelingsstadia z. B. geoefend in softwaretests om functionele details te kunnen controleren in volgende testniveaus / testtypes die gebaseerd zijn op functionaliteiten die al getest zijn in de vorige fase.

Verschillen tussen de afzonderlijke softwareontwikkelingsstadia voor computerprogramma's kunnen bijvoorbeeld de volgende zijn - te gebruiken voor het als voorbeeld gegeven releasedoel :

  • Sommige functies zijn nog niet geïmplementeerd; individuele functies vooraf testen
  • ... of alleen in een eenvoudige vorm (zonder speciale gevallen) worden uitgevoerd; ook voor eerste/vroege testen.
  • In de vorige fase werd de software alleen gecontroleerd met behulp van bepaalde soorten tests (zoals alfatests); bètatests uit te voeren.
  • De software bevat ook hulproutines (bijv. stubs of stuurprogramma's); voor het testen van subroutines .
  • De applicatie wordt beschikbaar gesteld voor overdracht naar een speciaal systeem of testomgeving en wordt zo nodig aangepast aan het doelsysteem; om productietesten of belastingtests uit te voeren.
  • De applicatie bevat hulproutines die het testen en documenteren van foutgevallen ondersteunen; voor openbare testers.
  • Stagegerelateerde overdrachten bevatten ofwel de gehele applicatie of alleen losse componenten voor (vervolg)installatie.
  • De applicatie is volledig operationeel (laatste fase); voor de definitieve oplevering aan de productieomgeving .

Voorbeelden van ontwikkelingsstadia

Het aantal ontwikkelingsstadia met hun beoogde volwassenheidsniveaus en hun namen lopen sterk uiteen. Vooral bij standaardsoftware (inclusief systeemsoftware ) specificeren fabrikanten vaak hoe ze hun software in fasen ontwikkelen, voor wie en voor welke doeleinden ze de respectievelijke softwareversies ter beschikking stellen en hoe ze deze fasen benoemen. Bij de ontwikkeling van individuele software worden ontwikkelingsstadia / software-releases meestal op bedrijfsspecifieke basis uitgevoerd; ze zijn vaak niet algemeen gedefinieerd, maar volgen projectspecifieke voorwaarden.

Ontwikkelingsstadia en aanduidingen voor softwarereleases kunnen bijvoorbeeld zijn:

pre-alphaalphabetarelease candidaterelease .

In andere gevallen oefent een fabrikant aanduidingen uit zoals de volgende:

GESLOTEN → FINAL STABIEL → FINAL → HUIDIGE BOUW → GEPLANDE . [2]

Tussen dergelijke hoofdfasen in de softwareontwikkeling zijn er een aantal tussentijdse softwareversies, bijvoorbeeld van meerdere rectificatiepogingen (en testniveaus) in het geval van gemelde programmafouten .

Voor softwareontwikkeling in het algemeen, dus niet alleen van toepassing op uitvoerbare programma's, zijn de volgende fasen i. S. bekend van mijlpalen:

Projectdefinitie , eisen analyse , vereiste specificaties , functionele specificatie , code analyse , module test, systeemtest, projectacceptatiecriteria

Softwarestadia voor uitvoerbare software

Stadia van softwareontwikkeling

Pre-alfaversie

Over het algemeen kan naar elk ontwikkelingsstadium vóór de eerste alfaversie worden verwezen als een pre-alpha-versie (van het Latijnse prae- 'voorbarig' en van de eerste letter van het Griekse alfabet alpha , ook als α ' -teken voor 1) . Een dergelijke versie wordt vaak gebruikt wanneer een half afgewerkte module van de software moet worden gepresenteerd. Een andere naam is de developer preview (van Engelse preview developer, ook wel vaak afgekort DP).

Alfa versie

De eerste versie van een computerprogramma die door vreemden (niet de eigenlijke ontwikkelaars) wordt getest, wordt vaak de alfaversie genoemd . Hoewel de term niet precies gedefinieerd is, bevat een alfaversie meestal al de basiscomponenten van het softwareproduct - maar het is bijna essentieel dat het scala aan functies in latere versies wordt uitgebreid.

Vooral alfaversies bevatten meestal programmafouten van de omvang of hoeveelheid die ze ongeschikt maken voor productief gebruik.

Ook alfaversies als ontwikkelaarsvoorbeelden, Engelse ontwikkelaarsvoorbeelden of ontwikkelaarsreleases worden beschikbaar gesteld. Dit gebeurt meestal in een exclusieve kring voor externe ontwikkelaars .

Beta versie

Bètaversies worden vaak geïdentificeerd door eenvoudige logo's, vooral voor Web 2.0- services.

Een bètaversie is de eerste versie van een computerprogramma die door de fabrikant voor testdoeleinden wordt gepubliceerd. De term is niet precies gedefinieerd, als vuistregel om een ​​bètaversie van andere versies te onderscheiden, is het meestal zo dat alle essentiële functies van het programma erin zijn geïmplementeerd, maar nog niet volledig zijn getest. Het programma kan of zal daarom nog veel, mogelijk ernstige fouten bevatten, waardoor productief gebruik niet wordt aanbevolen.

De voordelen van de beta-testen in het bijzonder is dat de fouten die typisch voorkomen (zoals conflicten met andere programma's, problemen met bepaalde alleen in de praktijk, hardware componenten , dubbelzinnig geïmplementeerd eisen of onduidelijkheden in de user interface ), nog voordat de definitieve versie ( Engels versie ) van het programma kan worden herkend en verholpen of in ieder geval gedocumenteerd.

Een bètatester is over het algemeen de eerste onafhankelijke of anonieme externe tester en gebruiker.

Bètaversies van programma's zijn meestal te herkennen aan de 0 als het hoofdversienummer - deze variant is natuurlijk alleen van toepassing op de bètaversies vóór de eerste voltooide versie (1.0) - of het bèta- achtervoegsel.

Bètaversies worden meestal niet op dezelfde manier gedistribueerd als releasekandidaten of voltooide versies. De volgende opties worden gebruikt:

  • Gedefinieerde snapshots (huidige ontwikkelingsstatus) worden met (on)regelmatige tussenpozen gegenereerd uit het broncodebeheersysteem en aangeboden en bloc ofwel in de broncode of als een voorgecompileerd pakket. Dit kan dagelijks ( nightly build ), wekelijks of op elk ander moment dat de ontwikkelaars geschikt achten (bijvoorbeeld na voltooiing van een subsysteem). Een dergelijke versie kan ook een automatische bevatten bug tracking module (zie bijvoorbeeld Amarok ) om het gemakkelijker maken voor beta maken testers om verslag bugs aan ontwikkelaars. Dit is meestal de norm voor grote projecten met gedefinieerde ontwikkelingsdoelen en een vast releaseschema (bijv. GNOME ).
  • De bètaversie wordt in het bronbeheersysteem aan een gedefinieerde revisie met een tag (een tag) geleverd, maar wordt verder niet apart behandeld. Onafhankelijke providers kunnen dit ontwikkelingsniveau vervolgens gebruiken als basis voor hun voorgecompileerde pakketten . Dit wordt gebruikt voor projecten die zeer snel veranderen en die misschien werken zonder of slechts zelden vaste releases , maar waar er nog steeds algemene interesse is in huidige versies (bijv. Dirac , Xine ).
  • Er is geen vaste bètaversie, bèta is de huidige HEAD , d.w.z. de constant veranderende, actuele ontwikkelingsstatus. Bètatesters moeten de huidige status zelf downloaden, configureren en compileren vanuit het broncodebeheersysteem; deze activiteit wordt meestal automatisch uitgevoerd door scripts die door het project worden geleverd. Dit is de meest voorkomende, maar het kan ook worden gecombineerd met een van de vorige twee methoden (dit is de regel).

Eeuwigdurende bèta

Een term die beschrijft dat in relatie tot de constante ontwikkeling van internet ook websites en software continu in ontwikkeling zijn en dus nooit echt af zijn. Zo heeft zich een permanente staat van ontwikkeling voorgedaan, de "Perpetual Beta". Ontstaan ​​als een slogan binnen het Web 2.0- concept, dat rekening houdt met het extreme programmeerconcept van " Continuous Integration ".

Vrijgavekandidaat / Prerelease

Een pre-release screenshot met waarschuwingen over het gebruik ervan

Een release candidate (afgekort RC , uit het Engels voor release candidate ), soms ook wel een prerelease genoemd (uit het Engels voor "pre-release" of "pre-release version"), is een definitieve testversie van software. Alle functies die de definitieve versie van de software zou moeten bevatten zijn al beschikbaar (zogenaamde feature complete ), en alle bekende fouten zijn geëlimineerd. De definitieve versie wordt vóór publicatie gemaakt op basis van de release-kandidaat om een ​​definitieve producttest of systeemtest uit te voeren. De kwaliteit van de software wordt gecontroleerd en eventuele resterende programmafouten worden opgezocht.

Als er zelfs maar een kleine wijziging wordt aangebracht, moet een andere release candidate worden gemaakt en moeten de tests worden herhaald. De releasekandidaten zijn daarom vaak genummerd (RC1, RC2, etc.). Geen verdere wijzigingen en eindelijk een release-kandidaat aan de vereiste kwaliteitsnormen houdend , wordt het achtervoegsel RCx verwijderd en daarmee de versie en release (ook Engelse definitieve release, definitieve release of definitieve versie, definitieve versie) uitgelegd en gepubliceerd.

Versies die aanzienlijk stabieler zijn dan bètaversies, maar die nog niet zijn getest als release-kandidaat, worden in sommige ontwikkelingsprojecten gammaversies genoemd .

Voor apparaatstuurprogramma's voor Windows is er soms de status WHQL- kandidaat (vertaald WHQL-kandidaat). Dit is een driverversie die overeenkomt met de RC, die de fabrikant heeft ingediend voor de WHQL-test, maar de bijbehorende certificering heeft nog niet plaatsgevonden.

Uitgave

De voltooide en gepubliceerde versie van software staat bekend als de release , soms ook als de hoofdversie . Dit gaat traditioneel hand in hand met een verhoging van het versienummer . In het geval van op media gebaseerde distributie wordt deze versie voor productie aan de pers geleverd, waar het wordt gekopieerd op gegevensdragers zoals cd-roms of dvd's , d.w.z. vervaardigd als een daadwerkelijk tastbaar product.

Ook voor deze status zijn verschillende aanduidingen vastgesteld:

Vrijgave aan Manufacturing / Web (RTM / RTW), ook First Customer Shipment (FCS)
Klaar voor reproductie en publicatie op het net ( web )
Stal
voor een stabiele versie die niet meer wordt gewijzigd
Laatste
voor de definitieve (definitieve) versie
Algemene beschikbaarheid (GA)
staat voor algemene beschikbaarheid. De term maakt duidelijk dat de versie is vrijgegeven voor praktisch gebruik en is verspreid of beschikbaar is via verschillende media. [3] [4] [5]
Goud , ook Gouden Meester (GM)
De gouden meester is de versie die uiteindelijk naar de perswinkel gaat en (fysiek) wordt gedupliceerd. Om de Golden Master te behalen, moeten alle fouten worden gladgestreken en moet het eindproduct volledig en volledig op het uiteindelijke opslagmedium (de Goldmaster-dvd) worden gebrand. De naam komt uit de muziekindustrie. De Goldmaster-dvd wordt helemaal aan het einde geproduceerd, kort voordat hij naar de perswinkel wordt gestuurd. Omdat er voorheen geen updates of iets dergelijks waren, zijn er verschillende Golden Masters gemaakt en uitgebreid getest voordat de definitieve versie naar de perswinkel werd gestuurd. De Gold Master is de definitieve verkoopversie die als origineel in de perswinkel komt en waarvan vervolgens kopieën worden gemaakt. De Gouden Meester wordt nog veel gebruikt in de muziek- en filmindustrie (cd- en dvd-productie); in de software-industrie is hij grotendeels vervangen door updates. Er is meestal maar één stuk van de Goldmaster-dvd.

Benamingen

De aanduidingen van softwareversies, releases, zijn over het algemeen niet gestandaardiseerd en verschillen meestal van project tot project. Sommige fabrikanten leggen ook de beoogde aanduidingen voor (geplande) gepubliceerde ontwikkelingsstatussen vast in een soort roadmap . In plaats van "Versie" of "Release" zijn de volgende namen gebruikelijk voor gepubliceerde software:

Bouwen
Het resultaat van het compileren van de broncode . In het bouwproces , het automatisch geregistreerd buildnummer wordt gewoonlijk met één verhoogd, vooral als de volledige broncode is gecompileerd. Omdat de software echter vaak intern moet worden gecompileerd om te testen, heeft zo'n build meestal hetzelfde versienummer als de vorige build . Maar zelfs met eerder gepubliceerde versies of releases worden vaak voor onderhoud, zoals voor feature-updates of bugfixes, nieuwere builds als update gepubliceerd.
Sommige programma's voegen het buildnummer aan de versie toe met een koppelteken , b.v. B. 1.2.3-4567, waarbij 1 het hoofdversienummer is, 2.3 het secundaire versie- en revisienummer en 4567 (na het koppelteken) het buildnummer is. Zie ook versienummer .
versie
Een build die een uniek versienummer krijgt, wordt beheerd als een nieuwe versie van een project. Is bezig met hotfixes of bugfixes z. Als er bijvoorbeeld een onderhoudsversie wordt gepubliceerd, kan deze hetzelfde versienummer hebben, maar een hoger buildnummer of een toevoeging aan de naam, zoals " Service Release 1" of simpelweg " Onderhoudsrelease ".
Uitgave
Over het algemeen wordt een gepubliceerde versie een release genoemd . Interne versies die niet worden gepubliceerd worden daarom meestal niet als releases aangeduid, maar dergelijke versies of builds kunnen lekken en dus ook openbaar worden.

De term bètaversie is ook problematisch, omdat deze niet duidelijk gedefinieerd is en daarom in principe kan staan ​​voor elke onvoltooide ontwikkelingsstatus. Er is dus dezelfde aanduiding na de ontwikkelingsstadia enerzijds gerelateerd aan het hele project, anderzijds kan de aanduiding ook alleen verwijzen naar recent toegevoegde subcomponenten (en de rest van het project is eigenlijk stabiel en daarom geen bètaversie).

De gepubliceerde software zelf heeft meestal verschillende namen. Naast de zogenaamde "Release" is er ook de "Final" of definitieve versie (in het Duits: voltooide versie of ook definitieve versie). Er is echter ook de term "stabiel" , wat stabiel betekent, vaak als een stabiele versie . Ook hier is duidelijk dat verschillende namen vrij vaak voorkomen: in plaats van een versie kan een publicatie ook de naam geven: een definitieve release van een ontwikkelproject is slechts de gepubliceerde definitieve versie .

De situatie is niet anders voor onvoltooide versies. Of het nu pre-alfa- , alfa- of bètaversie is : de meest voorkomende is "experimenteel" (experimenteel), "instabiel" (instabiel), "testen" en "preview" , elk naar keuze opnieuw als een "versie" of als een " release” ” , Maar ook als “ build ” . Een build is het meest onspecifiek, maar wordt ook vaak gebruikt in publicaties om de status van onvoltooide software te verduidelijken. Zelfs stabiele en voltooide versies hebben echter vaak een buildnummer .

Bijzonder is de naamgeving als nightly build , vertaald: nocturnal build . Een programma met deze naam kan van alles zijn, van volledig stabiel tot volledig onbruikbaar, omdat het proces bijna altijd 's nachts automatisch wordt uitgevoerd (vandaar de naam) en is gebaseerd op de huidige versie van de broncode waarop de ontwikkelaars overdag hun wijzigingen aanbrengen . De broncode kan beschadigd zijn geraakt door de recente wijzigingen ( engels gebroken) maar nog steeds vertaald voor de compiler blijft dat zo terwijl het bouwproces met succes wordt uitgevoerd, maar het programma kan nog steeds niet worden uitgevoerd. Daarom zegt de aanduiding als nightly build niets over de ontwikkelingsfase van het softwareproject.

Termen die op een specifiek publiek zijn gericht, ongeacht het ontwikkelingsniveau van een softwareproject, zijn echter ook gebruikelijk. Deze streven doorgaans het voor de ontwikkelaar voordelige doel na om onder bepaalde voorwaarden een externe bètatest uit te voeren . De termen voor verdergaande "bètaprogramma's" zijn ook niet gestandaardiseerd en verschillen van project tot project, maar er zijn gemeenschappelijke trefwoorden:

Intern gebouwd of privé gebouwd
verwijst naar een uitvoerbare versie van een project die alleen intern wordt getest.
Ontwikkelaar bouwen
is een proefversie die specifiek (voor externe ontwikkelaars engels ontwikkelaar) bedoeld is. Dit wordt meestal gebruikt wanneer veel externe providers essentieel zijn om het project te laten functioneren, b.v. B. in een besturingssysteem waarop veel programma's van andere fabrikanten kunnen draaien (of compatibel blijven of zouden moeten worden).
Voorbeeld: Rhapsody Developer Release of Mac OS X Developer Preview
Gesloten beta
geeft een bètaversie aan die beschikbaar wordt gesteld aan een exclusieve kring.
Voorbeeld: Windows 10 als Insider Build of Insider Preview , dat door Microsoft is gepubliceerd voor deelnemers aan een open (aangezien alleen te registreren) programma, het Insider-programma . De toelating van testers was beperkt in de tijd.
openbare bèta
verwijst naar een bètaversie die openlijk en onbeperkt bedoeld is voor early adopters .
Voorbeeld: Mac OS X Public Beta , een bètaversie van Mac OS X 10.0 .
Vroege toegang
verwijst naar een clientprogramma dat meestal tegen betaling toegang biedt ( Engels biedt toegang) tot vroege test- en/of ontwikkelaarsversies. Dit is vooral populair bij computerspellen , omdat het spelers enerzijds in staat stelt om bepaalde elementen van de gamewereld te onderzoeken lang voordat een titel wordt uitgebracht en helpt bij stabiliteitstests op verschillende hardware, anderzijds ontwikkelaars in staat stelt om vroegtijdig wijzigingen aan te brengen op gebaseerd op feedback op basis van de speler. Programma's voor vroege toegang zijn meestal ook een goede bron van financiering, aangezien de ontwikkelstudio vooraf geld aanneemt voor de ontwikkeling van het spel door middel van verkoop met vroege toegang .

Een ander type naamgeving is de aanduiding van het doel of de reden waarvoor een bepaalde versie wordt uitgegeven. Hier wordt voornamelijk gebruik gemaakt van de “Maintenance Release” en “Service Release” , oftewel een release ten behoeve van onderhoud. Dit wordt vaak vertaald als de onderhoudsversie.

Bugfix na release

Om bugs in software die al is uitgebracht op te lossen, brengen softwarefabrikanten updates, hotfixes , patches en servicepacks uit . Bij veel moderne applicaties en besturingssystemen kunnen deze vervolgens handmatig of automatisch via internet worden verkregen.

Firefox als voorbeeld

De webbrowser Mozilla Firefox verschijnt elke zes weken in vier verschillende versies: de experimentele versie Firefox Nightly (pre-alpha), de experimentele versie "Firefox Developer Edition", de grotendeels stabiele versie Firefox Beta en de stabiele versie Firefox , [6] [ 7] die elk verschillen in hun versienummer, e. B. Firefox Aurora 11, Firefox Beta 10, Firefox 9. U kunt ook de "nachtelijke" Nightly Build downloaden (huidige ontwikkelingsstatus, alleen geschikt om te testen). Op deze manier kan enerzijds het ontwikkelingsproces worden versneld, en anderzijds kunnen gebruikers door gebruik te maken van de Beta- of Aurora-versies helpen bij het testen en beoordelen van toekomstige functies van de stabiele versie en het identificeren van bugs en veiligheidshiaten op een in een vroeg stadium, aangezien Aurora-versie twaalf en de bètaversie zes weken voor de definitieve stabiele release voor het publiek beschikbaar zullen worden gemaakt.

Zie ook

literatuur

  • Manfred Precht, Nikolaus Meier, Dieter Tremel: basiskennis van IT. Pearson Education, München 2004, ISBN 3-8273-2129-8 .
  • Mike Gunderloy: programmeur tot ontwikkelaar. Wiley_Default, 2004, ISBN 0-7821-4327-X .

Individueel bewijs

  1. Ralf Ötinger Gebruiksvriendelijke softwareontwikkeling [1] Stadia: probleemanalyse, definitie van eisen
  2. es2000- software voor u gemaakt Gearchiveerde kopie ( aandenken aan het origineel van 11 december 2017 in het internetarchief ) Info: De archieflink is automatisch ingevoegd en is nog niet gecontroleerd. Controleer de originele en archieflink volgens de instructies en verwijder deze melding. @ 1 @ 2 Sjabloon: Webachiv / IABot / www.es2000.de Ondersteuningslevenscyclus
  3. Microsoft kondigt algemene beschikbaarheid aan van Windows Small Business Server 2008 en Windows Essential Business Server 2008 ( Memento van 25 december 2008 in het internetarchief )
  4. VMware kondigt algemene beschikbaarheid aan van VMware View 3, met baanbrekende vooruitgang in het beheren, schalen en personaliseren van virtuele desktopomgevingen ( Memento van 5 december 2008 in het internetarchief )
  5. Vrijgavefasen en -criteria. (Niet langer online beschikbaar.) In: cs.pomona.edu. Gearchiveerd van het origineel op 11 juli 2016 ; geraadpleegd op 24 juli 2016 . Info: De archieflink is automatisch ingevoegd en is nog niet gecontroleerd. Controleer de originele en archieflink volgens de instructies en verwijder deze melding. @ 1 @ 2 Sjabloon: Webachiv / IABot / www.cs.pomona.edu
  6. ^ Johnathan Nightingale: Elke zes weken. In: blog.mozilla.org. 18 juli 2011, geraadpleegd op 24 juli 2016 .
  7. Jens Ihlenfeld: Firefox gaat elke 6 weken door, maar met versienummer. golem.de , 26 augustus 2011, geraadpleegd op 24 juli 2016 .