Section Contents:- A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist.(More...)
A release is called feature complete when the product team agrees that functional requirements of the system are met and no new features will be put into the release, but significant software bugs may still exist. Companies with a formal software process will tend to enter the beta period with a list of known bugs that must be fixed to exit the beta period, and some companies make this list available to customers and testers.
[1] As the Internet has allowed for rapid and inexpensive distribution of software, companies have begun to take a more flexible approach to use of the word "beta". Netscape Communications was infamous for releasing alpha level versions of its Netscape web browser to the public and calling them "beta" releases.
[1] The term unstable does not necessarily mean that there are problems - rather, that enhancements or changes have been made to the software that have not undergone rigorous testing and that more changes are expected to be imminent. Users of such software are advised to use the stable version if it meets their needs, and to only use the unstable version if the new functionality is of interest that exceeds the risk that something might simply not work right.
[1] The term stable refers to a version of software that is substantially identical to a version that has been through enough real-world testing to reasonably assume there are no showstopper problems, or at least that any problems are known and documented.
[1] In the first phase of testing, developers generally test the software using white box techniques.
[1] Beta tests were conducted by people or groups other than the developers. As other companies began developing software for their own use, and for distribution to others, the terminology stuck and now is part of our common vocabulary.
[1] Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
[1] In the context of Web 2.0, people even talk of perpetual betas to signify that some software is meant to stay in beta state. "beta" is sometimes used to indicate something more like a release candidate such as the Halo 3 public beta.
[1] Beta version software is likely to be useful for internal demonstrations and previews to select customers, but unstable and not yet ready for release. Some developers refer to this stage as a preview, a prototype, a technical preview (TP) or as an early access.
[1] The expression that a software product "has gone gold" means that the code has been completed and "is being mass-produced and will be for sale soon." Other terms for the version include gold master, golden master, "GM", gold release, or gold build.
[1] Microsoft and others use the term "release to manufacturing" (RTM) to refer to this version (for commercial products, like Windows XP, as in, "Build 2600 is the Windows XP RTM release"), and "release to Web" (RTW) for freely downloadable products.
[1] As the second major stage in the release lifecycle, following the alpha stage, it is named after the Greek letter beta, the second letter in the Greek alphabet. Often this stage begins when the developers announce a feature freeze on the product, indicating that no more feature requirements will be accepted for this version of the product.
[1] Conventionally, code names are often used by many companies for versions prior to the release of the product, though the actual product and features are rarely secret.
[1] The term release candidate refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage, the product features all designed functionalities and no known showstopper -class bugs. At this phase the product is usually code complete.
[1] The gold or general availability release version is the final version of a particular product. It is typically almost identical to the final release candidate, with only last-minute bugs fixed.
[1] Often, beta testers, if privately selected, will be billed for using the release candidate as though it were a finished product. A release is called code complete when the development team agrees that no entirely new source code will be added to this release.
[1] The stage comes between the Beta and Release Candidate stages of software development because the software product is still not ready to be a potential final product but libraries of the software are release quality.
[1] The discussion took place between the two presenters of the show and Aaron Seigo via Skype. It was finally agreed that the release candidate had been termed as such because it was beyond beta quality as the libraries were of release candidate quality. At this point one of the presenters said that they should rename the stage KDE 4 had reached, the name they choose was the Seigo Stage.
[1] The term Seigo Stage was invented after a heated discussion on The Linux Action Show! podcast regarding the naming of the KDE 4 second release candidate not being up to the standard of what a release candidate should be.
[1] A box copy is the final product, printed on a disc that is included in the actual release, complete with disc graphic art. This term is used mostly by reviewers to differentiate from gold master discs.
[1] Developers release either a closed beta or an open beta ; closed beta versions are released to a select group of individuals for a user test, while open betas are to a larger community group, usually the general public. The testers report any bugs that they found and sometimes minor features they would like to see in the final version.
[1] The process of delivering a beta version to the users is called beta release.
[1] Sometimes a build known as pre-alpha is issued, before the release of an alpha or beta.
[1] Moving to black box testing inside the organization is known as alpha release.
[1] A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing.
[1] The users of a beta version are called beta testers. They are usually customers or prospective customers of the organization that develops the software. They receive the software for free or for a reduced price, but act as free testers.
[1] The alpha build of the software is the build delivered to the software testers, that is persons different from the software engineers, but usually internal to the organization or community that develops the software. In a rush to market, more and more companies are engaging external customers or value-chain partners in their alpha testing phase. This allows more extensive usability testing during the alpha phase.
[1] With the advent of programmable computers and the first shareable software programs, IBM used the same terminology for testing software.
[1] When it is used, it refers to all activities performed during the software project prior to software testing. These activities can include requirements analysis, software design, software development and unit testing.
[1] The Seigo Stage is the stage in software development when the libraries for the product are ready (or very close to being ready) but the rest of the product is still in need of polishing up.
[1] Each time a software program or system is changed, the software engineers and company doing the work decide on how to distribute the program or system, or changes to that program or system.
[1] The feedback is driven by regular tests and releases of the evolving software. Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability.
[4] Maintenance Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software.
[4] People are occasionally resistant to change and avoid venturing into an unfamiliar area so, as a part of the deployment phase, it is very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software.
[4] The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality. Critics of iterative development approaches point out that these processes place what may be an unreasonable expectation upon the recipient of the software: that they must possess the skills and experience of a seasoned software developer.
[4] The Capability Maturity Model (CMM) is one of the leading models. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced.
[4] A growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on ' process models ' to obtain contracts.
[4] Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels.
[4] Domain Analysis Often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system, is, what is generally referred to as "Domain Analysis".
[4] Implementation Converting a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.
[4] Documentation An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement.
[4] Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About " of all software engineering work is maintenance, but this statistic can be misleading.
[4] Testing Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.
[4] Software Elements Analysis The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers.
[4] Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.
[4] Software Training and Support A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it.
[4] Users will have lots of questions and software problems which leads to the next phase of software.
[4] Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed.
[4] The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.
[4] Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism.
[4] The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management." Studies of the failure rate of the DOD-STD-2167 specification, which enforced waterfall, have shown that the more closely a project follows its process, specifically in up-front requirements gathering, the more likely the project is to release features that are not used in their current form.
[4] If market conditions change for the client, changes can be incorporated in the next iterative release, allowing the software to be much more nimble.
[2] Full installation routines are to be used for each iterative release as it would be done in production.
[2] The Design phase goes much faster, as designs are only done on the items in the current release (Release 1.0 for example).
[2] With the Waterfall method, all software requirements are gathered up front, designs are done for each requirement, and each feature is coded and tested before migrating to production.
[2] With over 20 years of experience, Steve has extensive knowledge in project management, software architecture and test design.
[2] Software Planner tracks customer requirements, test cases, defects, support tickets, appointments and to-do lists, and allows you to share documents and hold threaded discussions.
[2] Best Practices for Software Projects - Iterative Development This year's newsletters will focus on best practices for software development projects.
[2] Each month will cover a different best practice technique. This month focuses on improving software development by Iterative Development.
[2] Date: 10 Oct 1998 Archive file: spiral (1) Barry Boehm, "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, August 1986. (2) Barry Boehm "A Spiral Model of Software Development and Enhancement" IEEE Computer, vol.21, #5, May 1988, pp 61-72. Basically, the idea is evolutionary development, using the waterfall model for each step; it's intended to help manage risks.
[5] One variant involves so called "binary" software implementation model using a scripting language plus statically typed language. In this case system first is coded in a scripting language and then gradually critical components are rewritten in the lower language. This new development paradigm was pioneered by Ousterhout with TCL but also possible with Python, various scripting language that use JVM (Jython +Java, etc) or Microsoft.NET framework (for example Iron Python + C++).
[5] The team releases running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users (highly recommended).
[5] The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible. XP teams release to their end users frequently as well.
[5] Too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. These tests provide invaluable support as the software design is improved.
[5] All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code. It may seem inefficient to have two programmers doing "one programmer's job", but the reverse is true.
[5] XP teams build software to a simple design. They start simple, and through programmer testing programmer testing and design improvement design improvement, they keep it that way.
[5] The result is that XP teams start with a good, simple design, and always have a good, simple design for the software. This lets them sustain their development speed, and in fact generally increase speed as the project goes forward.
[5] Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. They work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software.
[5] Extreme Programming focuses on delivering business value in every iteration. To accomplish this over the course of the whole project, the software must be well-designed.
[5] In the last few years, a paradigm known as eXtreme Programming has emerged that emphasizes reducing the cost of software changes, developing test cases before coding, developing code using pairs of programmers, and putting most of the documentation into the code.
[5] Higher-order programming languages avoid a substantial set of error sources (through advanced data typing, interface separation, and packaging and programming constructs) and permit the software solution to be "programmed" in fewer lines of human-generated code.
[5] XP teams build software in two-week "iterations", delivering running useful software at the end of each iteration.
[5] Extreme programming Extreme programming (XP) is the latest incarnation of Waterfall model and is the most recent software fad.
[5] Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing.
[5] The target audience is all personnel involved in software development for the DoD. No attempt has been made to cover methodologies that are most applicable to smaller projects that can be accomplished by five or fewer software engineers. You may learn about several of these in. Since the intended readers should consider government software standards in their use of methodologies, background on these standards is included.
[5] There are simple versions of the model and much more complex ones. Generally, all of the relationships used to predict these relationships are statistical in nature: Dr. Boehm and other workers in software project cost estimation build a database of project schedules and costs and then regress those against SLOC estimates.
[5] In each stage, new functionality is added. This type of development allows the user to see a functional product very quickly and allows the user to impact what changes are included in subsequent releases.
[5] Once artifacts get into the coded stage, rigorous configuration management is necessary to maintain baseline control of formal releases in the test process, and to transition the product to a zero-defect state suitable for release.
[5] With the costs estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, we won't know just how fast they will go.
[5] The emphasis is on steering the project -- which is quite straightforward -- rather than on exact prediction of what will be needed and how long it will take -- which is quite difficult. Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty.
[5] During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning).
[5] There are design steps in release planning and iteration planning, plus teams engage in quick design sessions and design revisions through refactoring, through the course of the entire project.
[5] Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work.
[5] At some time a baseline branch of the development project(s) can be used for a release, with promotion levels reflecting the release cycle.
[6] A line can be pulled out of retirement simply by using it again. An important feature of the Perforce model is that the relevance of a file is encoded in its name: //depot/release/3.5/01/db/dbhdr.h is a file that is part of a release, and clearly not the place for miscellaneous enhancements.
[6] Creating a maintenance line is somewhat analogous to promoting the files from "development" to "QA". The line is named after its intended use rather than its current user, and its name includes the release number. By including the release number we make it clear that this line is not to be reused for other releases.
[6] The database development group might branch the files under //depot/main/db into //depot/dev/fast-db/db for a performance enhancement project. Not all products need both maintenance lines and release lines.
[6] The policy of the development line (that it can accept new functionality) is usually incompatible with making stable releases, and so release lines should be branched from the development lines.
[6] The new line is called a maintenance line and given a name that reflects the release name.
[6] If a file was promoted to "released" last year and now a new revision is up for a new release, either a different promotion attribute must be created or the promotion level of the previous release will be lost.
[6] Promotion history is often not versioned as well as regular file history. If a file is promoted and then demoted, it may not be possible to reproduce a release made when the file was in its promoted level.
[6] Unfortunately, multiple active releases off of multiple active maintenance lines are realities with large software products.
[6] The work on each project must be integrated successfully into a coherent working software system with appropriate testing and documentation.
[3] By branching whole code lines and using the file name space to denote branches, Perforce provides plain, understandable software life-cycle support.
[6] While newer code may be being developed off in special development branches, the mainline is the ultimate destination for all software development.
[6] During the course of testing, the maintenance line will be found to be ready for release.
[6] The trunk may remain the main line of development, with promotion levels reflecting the development cycle.
[6] 
