Development stage (software)

A development stage in software technology is the state of completion that a software product to be created has reached or should reach at a certain point in time. The relevant stages are determined in terms of time and content as part of project management . They are based on the process model chosen for the project , its activities and milestones or on specifications in manufacturer-specific method concepts and development environments.

In a narrower sense , the term development stage refers to executable software; H. on executable programs that are made available for testing or to their users as part of the release management processes of a project. Depending on the project situation , often in smaller maintenance projects, some stages are omitted, they are merged or the software is only provided as a single final version.

In a broader sense , there are different development stages for software in the entire course of the project, in which results also arise in conceptual project phases that are assigned to certain milestones ('development stages'). Example see. At the end of each stage, the defined project results are transferred to the subsequent processing stages.

After reaching the final software state, the development cycle begins i. d. Usually new with measures / projects to expand the application - with the aim of a new software version .

Purpose / differences

The objective for defining several development stages is generally to achieve fixed points with defined maturity levels in the course of the project in order to be able to process the subsequent activities more reliably. Often different stages of development z. B. practiced in software testing in order to be able to check functional details in subsequent test levels / test types that are based on functionalities that were already tested in the previous stage.

Differences between the individual software development stages for computer programs can be, for example, the following - to be used for the release purpose given as an example :

• Some functions are not yet implemented; to test individual functions in advance
• ... or are only implemented in a simple form (without special cases); also for first / early tests.
• In the previous stage, the software was only checked using certain types of tests (such as alpha tests); to carry out beta tests.
• The software also contains auxiliary routines (e.g. stubs or drivers); for testing subroutines .
• The application is made available for transfer to a special system or test environment and, if necessary, is adapted to the target system; to carry out production tests or load tests.
• The application contains auxiliary routines that support the testing and documentation of error cases; for public testers.
• Stage-related handovers contain either the entire application or only individual components for (subsequent) installation.
• The application is fully operational (final stage); for the final handover to the production environment .

Examples of stages of development

The number of development stages with their target levels of maturity and their names vary considerably. In the case of standard software in particular (including system software ), manufacturers often specify how they develop their software in stages, for whom and for what purposes they provide the respective software versions and how they name these stages. In the development of individual software, development stages / software releases are usually carried out on a company-specific basis; they are often not generally defined, but rather follow project-specific conditions.

Development stages and designations for software releases can be, for example:

pre-alpha → alpha → beta → release candidate → release .

In other cases, a manufacturer practices release designations such as the following:

CLOSED → FINAL STABLE → FINAL → CURRENT BUILD → SCHEDULED .

There are any number of interim software versions between such main stages in software development, for example from several rectification attempts (and test levels) in the case of reported program errors .

For software development in general, i. H. not only valid for executable programs, for example the following stages i. S. known from milestones:

Project definition , requirements analysis , specification , functional specification , code analysis , unit testing, system testing, project acceptance

Software stages for executable software

Software development stages

Pre-alpha version

In general, any stage of development before the first alpha version can be referred to as a pre-alpha version (from the Latin prae- 'prematurely' and from the first letter of the Greek alphabet alpha , also as α ' character for 1). Such a version is often used when a halfway finished module of the software is to be presented. Another name is the developer preview (of English preview developer , also abbreviated often DP ).

Alpha version

The first version of a computer program to be tested by strangers (not the actual developers) is often called the alpha version . Although the term is not precisely defined, an alpha version usually already contains the basic components of the software product - but it is almost essential that the range of functions is expanded in later versions.

In particular, alpha versions usually contain program errors of the magnitude or quantity that make them unsuitable for productive use.

Also alpha versions as developer previews, English Developer previews or developer releases are made available. This is usually done in an exclusive circle for third-party developers .

Beta version

Beta versions are often identified by simple logos, especially for Web 2.0 services.

A beta version is the first version of a computer program that is published by the manufacturer for test purposes. The term is not exactly defined, as a rule of thumb to differentiate a beta version from other versions, it is usually the case that all essential functions of the program have been implemented in it, but not yet fully tested. The program can or will therefore still contain many, possibly serious errors, which make productive use not recommended.

The benefits of beta testing in particular is that errors that typically occur (such as conflicts with other programs, problems with certain only in practice, hardware components , ambiguous implemented requirements or ambiguities in the user interface ), even before the final release ( english release ) of the program can be recognized and rectified or at least documented.

A beta tester is generally the first independent or anonymous third-party tester and user.

Beta versions of programs can usually be recognized by the 0 as the main version number - of course, this variant only applies to the beta versions before the first finished version (1.0) - or the beta suffix .

Beta versions are usually not distributed in the same way as release candidates or finished versions. The following options are used:

• Defined snapshots (current development states) are generated from the source code management system at (un) regular intervals and offered en bloc either in the source code or as a precompiled package. This can be done daily ( nightly build ), weekly, or at any other time the developers deem appropriate (e.g. after completion of a subsystem). Such a version can also contain an automatic bug tracking module (see e.g. Amarok ) to make it easier for beta testers to report bugs to developers. This is usually the norm for large projects with defined development goals and a fixed release schedule (e.g. with GNOME ).
• The beta version is in the source control system to a defined revision with a day provided (a mark), but not otherwise dealt with separately. Independent providers can then use this level of development as the basis for their precompiled packages . This is used for projects that change very quickly and that may work with no or only rarely fixed releases , but where there is still general interest in current versions (e.g. Dirac , Xine ).
• There is no fixed beta version, beta is the current HEAD , i.e. the constantly changing, actual development status. Beta testers have to download, configure and compile the current status themselves from the source code management system; this activity is normally done automatically by scripts provided by the project. This is the most common, but it can also be combined with either of the previous two methods (this is the rule).

Perpetual beta

A term that describes that in relation to the constant development of the Internet, websites and software are also continuously developing and are therefore never really finished. Thus, a permanent state of development has occurred, the “Perpetual Beta”. Originated as a catchphrase within the Web 2.0 concept, which takes into account the extreme programming concept of " Continuous Integration ".

See also : banana principle

Release Candidate / Prerelease

A release candidate (short RC , from English for release candidate ), sometimes also referred to as a prerelease (from English for "pre-release" or "pre-release version"), is a final test version of a software. All functions that the final version of the software should contain are already available in it (so-called feature complete ), and all known errors have been eliminated. The final version is created from the release candidate before publication in order to carry out a final product test or system test. The quality of the software is checked and any remaining program errors are searched for.

If even a minor change is made, another release candidate must be created and the tests repeated. The release candidates are therefore often numbered (RC1, RC2, etc.). No further changes and maintains a release candidate finally the required quality standards, so the suffix is RCx removed and thus the version and release (also English final release , final release or final version , final version) explained and published.

Versions that are significantly more stable than beta versions, but not yet tested as a release candidate , are referred to as gamma versions in some development projects .

For device drivers for Windows , there are sometimes the status WHQL Candidate (translated WHQL-candidate ). This is a driver version that corresponds to the RC and that the manufacturer has submitted for the WHQL test, but the corresponding certification has not yet taken place.

Release

The finished and published version of software is known as the release , sometimes also as the major version . This traditionally goes hand in hand with an increase in the version number . In the case of media-based distribution, this version is delivered to the press shop for production, where it is copied onto data carriers such as CD-ROMs or DVDs , i.e. manufactured as an actually tangible product.

Various designations have also been established for this status:

Release to Manufacturing / Web (RTM / RTW), also First Customer Shipment (FCS)

Ready for reproduction and publication on the net ( web )

Stable

for a stable version that is no longer changed

Final

for the final (final) version

General Availability (GA)

stands for general availability. The term makes it clear that the version has been released for practical use and has been distributed or is available via various media.

Gold , also Golden Master (GM)

The gold master is the version that finally goes to the press shop and is (physically) duplicated. In order to achieve the Golden Master, all errors must be ironed out and the end product completely complete and burned onto the final storage medium (the Goldmaster DVD). The name comes from the music industry. The Goldmaster DVD is produced at the very end, shortly before it is sent to the press shop. Since there were previously no updates or similar, several Golden Masters were created and extensively tested before the final version was sent to the press shop. The Gold Master is the final sales version that comes into the press shop as an original and copies of which are then made. In the music and film industry, the Golden Master is still used extensively (CD and DVD production), in the software industry it has been largely replaced by updates. There is usually only one track on the Goldmaster DVD.

Designations

The designations of software versions, releases, are generally not standardized and usually vary from project to project. Some manufacturers also specify the intended designations for (planned) published development statuses in a kind of roadmap . Instead of “Version” or “Release”, a. The following terms are common for published software:

Build

The result of compiling the source code . In the build process , the automatically managed build number is usually increased by one, especially when the entire source code is compiled. However, since the software often has to be compiled internally for testing, such a build usually has the same version number as the previous build . But even with previously published versions or releases are often for maintenance, such as for feature updates or bug fixes newer builds as update published.

Some programs append the build number to the version with a hyphen , e.g. B. 1.2.3-4567, where 1 is the major version number, 2.3 is the minor version and revision number and 4567 (after the hyphen) is the build number. See also version number .

version

A build that is given a unique version number is managed as a new version of a project. Is in the course of hotfixes or bug fixes z. If, for example, a maintenance version is published, it can have the same version number, but a higher build number or an addition to the name, such as " Service Release  1" or simply " Maintenance Release ."

Release

In general, a published version is referred to as a release . Internal versions that are not published are therefore not normally a release called, but such versions or builds can leak s and thus also reach the public.

The term beta version is also problematic, as it is not clearly defined and can therefore basically stand for any unfinished development status. So there is the same designation after the stages of development, on the one hand, related to the entire project, on the other hand, the designation can also only refer to recently added subcomponents (and the rest of the project is actually stable and therefore not a beta version).

The published software itself usually has different names. In addition to the so-called “release”, there is also the “final” or final version (in German: finished version or also final version). However, there is also the term “stable” , which means stable, often as a stable version . Here, too, it is clear that different names are quite common: instead of a version, a publication can also give the name: a final release of a development project is only the published final version .

The situation is no different for unfinished versions. Whether pre-alpha , alpha or beta version : the most common is “experimental” (experimental), “unstable” (unstable), “testing” as well as “preview” , each optionally again as “version” or as “release” ” , But also as a “ build ” . A build is the most unspecific, but is also often used in publications to illustrate the status of an unfinished software. However, stable and finished versions often have a build number.

A special feature is the naming as nightly build , translated: nightly build . A program with this name can be anything from completely stable to completely inoperable, because the process almost always runs automatically at night (hence the name) and is based on the current version of the source code on which the developers make their changes during the day. The source code may have become damaged by the recent changes ( english broken ) but still translated for the compiler remain so while successfully runs the build process, the program but still can not run. Therefore, the designation as nightly build says nothing about the development stage of the software project.

However, terms that are directed at a specific audience regardless of the level of development of a software project are also common. These mostly pursue the goal, which is advantageous for the developer, of carrying out an external beta test under certain conditions. The terms for more far-reaching "beta programs" are not standardized either and vary from project to project, but there are common keywords:

Internal build or private build

refers to an executable version of a project that is only tested internally.

Developer Build

is a trial version that specifically (for external developers english developer ) is intended. This is mostly used when many third-party providers are essential for the project to function, e.g. B. in an operating system on which many programs from other manufacturers can run (or remain compatible or should become).
Example: Rhapsody Developer Release or Mac OS X Developer Preview

Closed beta

denotes a beta version that is made available to an exclusive circle.
Example: Windows 10 as an Insider Build or Insider Preview , which was published for participants in an open (since only registrable) program by Microsoft called the Insider Program . The admission of testers was limited in time.

Public beta

refers to a beta version that is openly and unrestrictedly intended for early adopters .
Example: Mac OS X Public Beta , a beta version of Mac OS X 10.0 .

Early Access

refers to a client program that usually a fee-based access ( english access offers) to early testing and / or developer versions. This is particularly popular with computer games , because on the one hand it allows players to research certain elements of the gaming world long before a title is released and to help with stability tests on various hardware, and on the other hand it enables developers to make changes at an early stage based on feedback based on the player. Early access programs are also usually a good source of funding, as the development studio takes money in advance for developing the game through early access sales.

Another type of naming is the designation of the purpose or reason for which a particular version is issued. The “Maintenance Release” and “Service Release” , ie a release for the purpose of maintenance , are mainly used here . This is often translated as the maintenance version.

Post release bug fix

To fix errors in software that has already been released, software manufacturers release updates, hotfixes , patches and service packs . With many modern applications and operating systems , these can then be obtained manually or automatically via the Internet .

Firefox as an example

The web browser Mozilla Firefox appears every six weeks in four different versions: the experimental version Firefox Nightly (pre-alpha), the experimental version "Firefox Developer Edition", the mostly stable version Firefox Beta and the stable version Firefox , each in their Differentiate the version number, e.g. B. Firefox Aurora 11, Firefox Beta 10, Firefox 9. You can also download the "nocturnal" Nightly Build (current development status, only suitable for testing). In this way, on the one hand, the development process can be accelerated, and on the other hand, by using the Beta or Aurora versions, users can help test and assess future functions of the stable version and identify bugs and security gaps at an early stage, since Aurora version twelve and the Beta version will be made available to the public six weeks before the final stable release.

See also

• Code freeze

literature

• Manfred Precht, Nikolaus Meier, Dieter Tremel: Basic IT knowledge. Pearson Education, Munich 2004, ISBN 3-8273-2129-8 .
• Mike Gunderloy: Coder to Developer. Wiley_Default, 2004, ISBN 0-7821-4327-X .

Individual evidence

1. ↑ Ralf Ötinger User- friendly software development [1] Stages: Problem analysis, definition of requirements
2. ↑ es2000 software made for you Archived copy ( memento of the original from December 11, 2017 in the Internet Archive ) Info: The archive link has been inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. Support lifecycle 
3. ↑ Microsoft Announces General Availability of Windows Small Business Server 2008 and Windows Essential Business Server 2008 ( Memento from December 25, 2008 in the Internet Archive )
4. ↑ VMware Announces General Availability of VMware View 3, with Ground-Breaking Advances in Managing, Scaling and Personalizing Virtual Desktop Environments ( Memento from December 5, 2008 in the Internet Archive )
5. ↑ Release Phases & Criteria. (No longer available online.) In: cs.pomona.edu. Archived from the original on July 11, 2016 ; accessed on July 24, 2016 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  
6. ^ Johnathan Nightingale: Every Six Weeks. In: blog.mozilla.org. July 18, 2011, accessed July 24, 2016 . 
7. ↑ Jens Ihlenfeld: Firefox continues every 6 weeks, but with version number. golem.de , August 26, 2011, accessed on July 24, 2016 .