Misplaced Pages

#476523

59-1305: ReDigi launched its public beta site in October 2011. It was founded by John Ossenmacher, along with his daughter, who had the idea of creating an online drop box where people could donate their unwanted digital media. Ossenmacher hired a team of programmers, mathematicians, business professionals, and legal advisors to build the service. ReDigi filed voluntary petitions for Chapter 11 reorganization in United States bankruptcy court in August 2016. The company arranged multiple sources of funding to restructure its current debt and planned to exit its restructure in 2017. Services currently offered include cloud storage for verifiable music, ebooks and other digital goods that were legally purchased, cloud streaming for listening to stored music, reading books, and utilizing other digital media, and buying and selling of used digital goods such as music, ebooks, games, apps and other digital media directly from other users on ReDigi. In January 2012, Capitol Records sued ReDigi in New York Federal Court stating that Redigi

118-401: A boxed version of Apple 's Mac OS X Public Beta operating system was released. Between September 2005 and May 2006, Microsoft released community technology preview s ( CTP s) for Windows Vista . From 2009 to 2011, Minecraft was in public beta. In February 2005, ZDNet published an article about the phenomenon of a beta version often staying for years and being used as if it were at

177-537: A closed beta , or an open beta ; closed beta versions are released to a restricted group of individuals for a user test by invitation, while open beta testers are from a larger group, or anyone interested. Private beta could be suitable for the software that is capable of delivering value but is not ready to be used by everyone either due to scaling issues, lack of documentation or still missing vital features. The testers report any bugs that they find, and sometimes suggest additional features they think should be available in

236-438: A feature freeze , indicating that no more features will be added to the software. At this time, the software is said to be feature-complete . A beta test is carried out following acceptance testing at the supplier's site (the alpha test) and immediately before the general release of the software as a product. A feature-complete (FC) version of a piece of software has all of its planned or primary features implemented but

295-403: A preview , preview release , prototype , technical preview or technology preview ( TP ), or early access . Beta testers are people who actively report issues with beta software. They are usually customers or representatives of prospective customers of the organization that develops the software. Beta testers tend to volunteer their services free of charge but often receive versions of

354-467: A beta version to the users is called beta release and is typically the first time that the software is available outside of the organization that developed it. Software beta releases can be either open or closed , depending on whether they are openly available or only available to a limited audience. Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. Some developers refer to this stage as

413-399: A business outcome. Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define

472-474: A controlled environment, facilitated by a trained facilitator (Business Analyst), wherein stakeholders participate in discussions to elicit requirements, analyze their details, and uncover cross-functional implications. A dedicated scribe should be present to document the discussion, freeing up the Business Analyst to lead the discussion in a direction that generates appropriate requirements that meet

531-427: A level of detail sufficient for system design . Conceptually, requirements analysis includes three types of activities: Requirements analysis can be a long and tiring process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs, and ensure they understand

590-784: A limited interpretation of copyright protection. However, here, the Court cannot of its own accord condone the wholesale application of the first sale defense to the digital sphere, particularly when Congress itself has declined to take that step. On April 20, 2013, United States District Court, Southern District of New York has ruled that ReDigi is engaged in illegal activity. Judge Richard J. Sullivan wrote that "ReDigi has vicariously infringed" on copyrights and found ReDigi guilty of direct contributory infringement. The 2nd Circuit Court of Appeals heard ReDigi's appeal on August 22, 2017. The Library association and Twenty-Four significant, University Law Professors, back ReDigi at appeal. ReDigi's technology

649-418: A number of ways users can inhibit requirements gathering: This may lead to the situation where user requirements keep changing even when system or product development has been started. Possible problems caused by engineers and developers during requirements analysis are: One attempted solution to communications problems has been to employ specialists in business or system analysis. Techniques introduced in

SECTION 10

#1732787544477

708-547: A requirement for long-range or high speed may result in a design requirement for low weight. A requirement is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items. Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard . Steve McConnell, in his book Rapid Development , details

767-462: A software product is available for purchase, depending, however, on language, region, and electronic vs. media availability. Commercialization activities could include security and compliance tests, as well as localization and worldwide availability. The time between RTM and GA can take from days to months before a generally available release can be declared, due to the time needed to complete all commercialization activities required by GA. At this stage,

826-484: A system, usually involving software, whether that is new or being changed. Each use case provides a set of scenarios that convey how the system should interact with a human user or another system, to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert . Use cases are often co-authored by requirements engineers and stakeholders. Use cases are deceptively simple tools for describing

885-410: A variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have a graphic design applied to it. This helps to prevent confusion as to whether the prototype represents the final visual look and feel of the application. A use case is a structure for documenting the functional requirements for

944-412: Is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities. Beta testers, if privately selected, will often be credited for using the release candidate as though it were a finished product. Beta testing

1003-740: Is conducted in a client's or customer's location and to test the software from a user's perspective. Also called production release , the stable release is the last release candidate ( RC ) which has passed all stages of verification and tests. Any known remaining bugs are considered acceptable. This release goes to production . Some software products (e.g. Linux distributions like Debian ) also have long-term support ( LTS ) releases which are based on full releases that have already been tried and tested and receive only security updates. This allows developers to allocate more time toward product development instead of updating code or finding and fixing newly introduced bugs due to outdated assumptions about

1062-419: Is focused on reducing impacts on users and may include usability testing. After beta testing, the software may go through one or more release candidate phases, in which it is refined and tested further, before the final version is released. Some software, particularly in the internet and technology industries, is released in a perpetual beta state, meaning that it is continuously being updated and improved, and

1121-586: Is never considered to be a fully completed product. This approach allows for a more agile development process and enables the software to be released and used by users earlier in the development cycle. Pre-alpha refers to all activities performed during the software project before formal testing. These activities can include requirements analysis , software design , software development , and unit testing . In typical open source development, there are several types of pre-alpha versions. Milestone versions include specific sets of functions and are released as soon as

1180-452: Is not yet final due to bugs , performance or stability issues. This occurs at the end of alpha testing in development . Usually, feature-complete software still has to undergo beta testing and bug fixing , as well as performance or stability enhancement before it can go to release candidate , and finally gold status. Beta, named after the second letter of the Greek alphabet , is

1239-689: Is often associated with software system builds, purchases, cloud computing strategies, embedded software in products or devices, or other technologies. The broader definition of requirements specification includes or focuses on any solution strategy or component, such as training, documentation guides, personnel, marketing strategies, equipment, supplies, etc. Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management: Statements of business level goals, without reference to detailed functionality. These are usually high-level (software and/or hardware) capabilities that are needed to achieve

SECTION 20

#1732787544477

1298-458: Is patented, and has additional patents pending . Features of the ReDigi system include: Public beta The software release life cycle is the process of developing, testing, and distributing a software product (e.g., an operating system ). It typically consists of several stages, such as pre-alpha, alpha, beta, and release candidate, before the final version, or "gold", is released to

1357-446: Is sold as part of a bundle in a related computer hardware sale and typically where the software and related hardware is ultimately to be available and sold on mass/public basis at retail stores to indicate that the software has met a defined quality level and is ready for mass retail distribution. RTM could also mean in other contexts that the software has been delivered or released to a client or customer for installation or distribution to

1416-409: Is typically the final build of a piece of software in the beta stages for developers. Typically, for iOS , it is the final build before a major release, however, there have been a few exceptions. RTM is typically used in certain retail mass-production software contexts—as opposed to a specialized software production or project in a commercial or government production and distribution—where the software

1475-571: The 32-bit editions of Windows XP and two service packs for the 64-bit editions. Such service releases contain a collection of updates, fixes, and enhancements, delivered in the form of a single installable package. They may also implement new features. Some software is released with the expectation of regular support. Classes of software that generally involve protracted support as the norm include anti-virus suites and massively multiplayer online games . Continuing with this Windows XP example, Microsoft did offer paid updates for five more years after

1534-524: The Windows Insider Program launched in 2014 are termed "Insider Preview builds". "Beta" may also indicate something more like a release candidate , or as a form of time-limited demo, or marketing technique. Requirements analysis In systems engineering and software engineering , requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of

1593-425: The "alpha/beta" test terminology originated at IBM . Similar terminologies for IBM's software development were used by people involved with IBM from at least the 1950s (and probably earlier). "A" test was the verification of a new product before the public announcement. The "B" test was the verification before releasing the product to be manufactured. The "C" test was the final test before the general availability of

1652-515: The 1990s like prototyping , Unified Modeling Language (UML), use cases , and agile software development are also intended as solutions to problems encountered with previous methods. Also, a new class of application simulation or application definition tools has entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code

1711-552: The Copyright Act to reach its desired policy outcome. However, "[s]ound policy, as well as history, supports [the Court's] consistent deference to Congress when major technological innovations alter the market for copyrighted materials. Congress has the constitutional authority and the institutional ability to accommodate fully the varied permutations of competing interests that are inevitably implicated by such new technology. Sony, 464 U.S. at 431. Such deference often counsels for

1770-403: The analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. Requirements quality can be improved through these and other methods: See Stakeholder analysis for a discussion of people or organizations (legal entities such as companies, and standards bodies) that have a valid interest in

1829-442: The application can be seen and shared before the application is built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably. Prototypes can be flat diagrams (often referred to as wireframes ) or working applications using synthesized functionality. Wireframes are made in

ReDigi - Misplaced Pages Continue

1888-583: The assessment of these needs to determine, and specify, what is required to meet the needs within the solution scope in focus. Discovery, analysis, and specification move the understanding from a current as-is state to a future to-be state. Requirements specification can cover the full breadth and depth of the future state to be realized, or it could target specific gaps to fill, such as priority software system bugs to fix and enhancements to make. Given that any large business process almost always employs software and data systems and technology, requirements specification

1947-504: The basic need and, at a minimum, answer the questions posed in the following listing: Architectural requirements explain what has to be done by identifying the necessary systems architecture of a system . Behavioral requirements explain what has to be done by identifying the necessary behavior of a system. Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as

2006-466: The behavior of software or systems. A use case contains a textual description of how users are intended to work with the software or system. Use cases should not describe the internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task without sequential assumptions. Requirements specification is the synthesis of discovery findings regarding current state business needs and

2065-515: The composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before

2124-478: The court held ReDigi vicariously liable because it "exercised complete control over its website's content, user access, and sales," and financially benefited from every sale due to its transaction fee. On March 30, 2013, the judge granted in part a summary judgment motion in favor of Capitol Records . The court stated: ReDigi has vicariously infringed Capitol's copyrights" and found RediGi guilty of direct contributory infringement. ReDigi seeks judicial amendment of

2183-411: The degree of certainty in their estimate, the degree of criticality to the system success, and their relationship to other requirements. The "build to", "code to", and "buy to" requirements for products and "how to execute" requirements for processes are expressed in technical data packages and technical manuals. Requirements that are implied or transformed from higher-level requirements. For example,

2242-495: The end of extended support. This means that support ended on April 8, 2019. When software is no longer sold or supported, the product is said to have reached end-of-life, to be discontinued, retired, deprecated, abandoned, or obsolete, but user loyalty may continue its existence for some time, even long after its platform is obsolete—e.g., the Common Desktop Environment and Sinclair ZX Spectrum . After

2301-467: The end user to verify the integrity and authenticity of the software purchase. A copy of the RTM build known as the " gold master " or GM is sent for mass duplication or disc replication if applicable. The terminology is taken from the audio record-making industry, specifically the process of mastering . RTM precedes general availability (GA) when the product is released to the public. A golden master build (GM)

2360-422: The end-of-life date, the developer will usually not implement any new features, fix existing defects, bugs, or vulnerabilities (whether known before that date or not), or provide any support for the product. If the developer wishes, they may release the source code, so the platform will live again, and be maintained by volunteers, and if not, it may be reverse-engineered later when it becomes abandonware . Usage of

2419-464: The feature is complete. The alpha phase of the release life cycle is the first phase of software testing (alpha is the first letter of the Greek alphabet , used as the number 1). In this phase, developers generally test the software using white-box techniques . Additional validation is then performed using black-box or gray-box techniques, by another testing team. Moving to black-box testing inside

ReDigi - Misplaced Pages Continue

2478-611: The final version. Open betas serve the dual purpose of demonstrating a product to potential consumers, and testing among a wide user base is likely to bring to light obscure errors that a much smaller testing team might not find. A release candidate ( RC ), also known as gamma testing or "going silver", is a beta version with the potential to be a stable product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded, and tested through one or more beta cycles with no known showstopper-class bugs. A release

2537-587: The implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as user stories in agile methods ), the identification of use cases , the use of workplace observation or ethnography , holding interviews , or focus groups (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists. Prototyping may be used to develop an example system that can be demonstrated to stakeholders. Where necessary,

2596-542: The organization is known as alpha release . Alpha software is not thoroughly tested by the developer before it is released to customers. Alpha software may contain serious errors, and any resulting instability could cause crashes or data loss. Alpha software may not contain all of the features that are planned for the final version. In general, external availability of alpha software is uncommon for proprietary software , while open source software often has publicly available alpha versions. The alpha phase usually ends with

2655-412: The possibly conflicting requirements of the various stakeholders , analyzing, documenting, validating, and managing software or system requirements . Requirements analysis is critical to the success or failure of a systems or software project . The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to

2714-490: The product they test, discounts on the release version, or other incentives. Some software is kept in so-called perpetual beta , where new features are continually added to the software without establishing a final "stable" release. As the Internet has facilitated the rapid and inexpensive distribution of software, companies have begun to take a looser approach to the use of the word beta . Developers may release either

2773-552: The product. As software became a significant part of IBM's offerings, the alpha test terminology was used to denote the pre-announcement test and the beta test was used to show product readiness for general availability. Martin Belsky, a manager on some of IBM's earlier software projects claimed to have invented the terminology. IBM dropped the alpha/beta terminology during the 1960s, but by then it had received fairly wide notice. The usage of "beta test" to refer to testing done by customers

2832-519: The production level. It noted that Gmail and Google News , for example, had been in beta for a long time although widely used; Google News left beta in January 2006, followed by Google Apps (now named Google Workspace ), including Gmail, in July 2009. Since the introduction of Windows 8 , Microsoft has called pre-release software a preview rather than beta . All pre-release builds released through

2891-415: The project is half over. A prototype is a computer program that exhibits a part of the properties of another computer program, allowing users to visualize an application that has not yet been constructed. A popular form of prototype is a mockup , which helps future users and other stakeholders get an idea of what the system will look like. Prototypes make it easier to make design decisions because aspects of

2950-412: The public. Pre-alpha refers to the early stages of development, when the software is still being designed and built. Alpha testing is the first phase of formal testing, during which the software is tested internally using white-box techniques . Beta testing is the next phase, in which the software is tested by a larger group of users, typically outside of the organization that developed it. The beta phase

3009-474: The related hardware end user computers or machines. The term does not define the delivery mechanism or volume; it only states that the quality is sufficient for mass distribution. The deliverable from the engineering organization is frequently in the form of a golden master media used for duplication or to produce the image for the web. General availability ( GA ) is the marketing stage at which all necessary commercialization activities have been completed and

SECTION 50

#1732787544477

3068-837: The session objective. JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements. One traditional way of documenting requirements has been contract-style requirement lists. In a complex system such requirements lists can run hundreds of pages long. An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favor in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims ; but they are still seen to this day. As an alternative to requirement lists, Agile Software Development uses User stories to suggest requirements in everyday language. Best practices take

3127-459: The software development phase following alpha. A beta phase generally begins when the software is feature-complete but likely to contain several known or unknown bugs. Software in the beta phase will generally have many more bugs in it than completed software and speed or performance issues, and may still cause crashes or data loss. The focus of beta testing is reducing impacts on users, often incorporating usability testing . The process of delivering

3186-662: The software has "gone live". Release to the Web ( RTW ) or Web release is a means of software delivery that utilizes the Internet for distribution. No physical media are produced in this type of release mechanism by the manufacturer. Web releases have become more common as Internet usage grew. During its supported lifetime, the software is sometimes subjected to service releases, patches or service packs , sometimes also called "interim releases" or "maintenance releases" (MR). For example, Microsoft released three major service packs for

3245-552: The system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders . It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in

3304-575: The toplevel functions for functional analysis. Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. The extent to which a mission or function must be executed; is generally measured in terms of quantity, quality, coverage, timeliness, or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of

3363-418: The used system, language, or underlying libraries. Once released, the software is generally known as a "stable release". The formal term often depends on the method of release: physical media, online release, or a web application. The term "release to manufacturing" (RTM), also known as "going gold", is a term used when a software product is ready to be delivered. This build may be digitally signed, allowing

3422-441: Was liable for contributing to copyright infringement demanding that ReDigi remove Capitol-owned material and pay $ 150,000 per track. On February 6, 2012, U.S. District Judge Richard Sullivan denied the preliminary injunction. Vicarious liability for copyright infringement exists where the defendant "has the right and ability to supervise the infringing activity and also has a direct financial interest in such activities." In ReDigi ,

3481-579: Was not done in IBM. Rather, IBM used the term "field test". Major public betas developed afterward, with early customers having purchased a "pioneer edition" of the WordVision word processor for the IBM PC for $ 49.95. In 1984, Stephen Manes wrote that "in a brilliant marketing coup, Bruce and James Program Publishers managed to get people to pay for the privilege of testing the product." In September 2000,

#476523