A Glossary of Life Cycle Terms

Definitions in this glossary are taken from IEEE Standards 729-1983, ANSI, ISO, the software engineering literature, and common usage. This glossary is not intended to contain definitions for every term you might possibly encounter, but is instead a list of terms and concepts used to understand the Product Life Cycle. In several cases, there are different, but useful definitions for a word than the published standards, in such cases both definitions are included. Terms whose definition are special to this PLC are marked (PLC).

acceptance criteria	The criteria a software product must meet to successfully complete a test phase or meet delivery requirements.
acceptance testing	Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.
accuracy	A quality of that which is free of error. Contrast with precision.
algorithm	A finite set of well-defined rules for the solution of a problem in a finite number of steps; for example, a complete specification of a sequence of arithmetic operations for evaluating sin x to a given precision. A finite set of well-defined rules that gives a sequence of operations for performing a specific task.
algorithm analysis	The examination of an algorithm to determine its correctness with respect to its intended use, to determine its operational characteristics, or to understand it more fully in order to modify, simplify, or improve it.
Alpha (PLC)	A development milestone at which the feature set is frozen and the product is fully functional and documented.
analysis phase	Same as requirements phase.
ANSI	American National Standards Institute
API	Application Programmer's Interface. This is the documentation as to how to use (make calls or pass data) to an externally supplied module or component.
architectural design	The process of defining a collection of hardware and software components and their interfaces to establish a framework for the development of a computer system. The result of the architectural design process.
architecture	See program architecture.
audit	An independent review for the purpose of assessing compliance with software requirements, specifications, baselines, standards, procedures, instructions, codes, and contractual and licensing requirements. See also code audit.
baseline	A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.
Beta (PLC)	A development milestone where the User Interface is frozen and the product is highly stable.
bottom-up	Pertaining to an approach that starts with the lowest level software components of a hierarchy and proceeds through progressively higher levels to the top level component; for example, bottom-up design, bottom-up programming, bottom-up testing. Contrast with top-down.
bottom-up design	The design of a system starting with the most basic or primitive components and proceeding to higher level components that use the lower level ones. Contrast with top-down design.
bug	The basic unit of problem detection and reporting for a product. A bug comes into existence when a person reports a problem with a product currently being developed. Bugs are rated according to severity and likelihood of occurrence. See fault.
build	An operational version of a software product incorporating a specific subset of the capabilities that the final product will include.
build (PLC)	A compiling and linking of the product.
change control	The process by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked.
class	In an object oriented methodology, a set of objects that share a common structure and a common behavior.
class diagram	Part of the notation of object-oriented design, used to show the existence of classes and their relationships in the logical design of a system. A class diagram may represent all or part of the class structure of a system.
code	A set of unambiguous rules specifying what the computer can do. See also source code.
code audit	An independent review of source code by a person, team, or tool to verify compliance with software design documentation and programming standards. Correctness and efficiency may also be evaluated. See also audit, static analysis, inspection, walk-through.
Code Freeze (PLC)	A development milestone where the product is ready for final testing before Engineering Release.
code inspection	See inspection.
code walk-through	See walk-through.
cohesion	The degree to which the tasks performed by a single program module are functionally related. Contrast with coupling.
compile	To translate a high order language program(source code) into its relocatable or absolute machine code equivalent(object code).
complexity	The degree of complication of a system or system component, determined by such factors as the number and intricacy of interfaces, the number and intricacy of conditional branches, the degree of nesting, the types of data structures, and other system characteristics.
component	A basic part of a system or program. A chunk of reusable code.
Component (PLC)	Source code that has been compiled by a different team and made available as a self contained sub-system to the product team. Examples are Core Code, Install, and Filters.
Concept Approval (PLC)	The Concept Approval milestone is when decision makers review product concepts and determine funding levels to Project Approval.
configuration	The requirements, design, and implementation that define a particular version of a system or system component. The arrangement of a computer system or network as defined by the nature, number, and chief characteristics of its functional units. More specifically, the term configuration may refer to a hardware configuration or a software configuration.
configuration audit	The process of verifying that all required configuration items have been produced, that the current version agrees with specified requirements, that the technical documentation completely and accurately describes the configuration items, and that all change requests have been resolved.
configuration control	The process of evaluating, approving or disapproving, and coordinating changes to configuration items after formal establishment of their configuration identification.
configuration item	A collection of hardware or software elements treated as a unit for the purpose of configuration management.
configuration management	The process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the system life cycle, recording and reporting the status of configuration items and change requests, and verifying the completeness and correctness of configuration items.
correctness	The extent to which software is free from design defects and from coding defects; that is, fault free. The extent to which the software meets its specified requirements. The extent to which the software meets user expectations.
coupling	A measure of the interdependence among modules in a computer program. Contrast with cohesion.
critical piece first	Pertaining to an approach to software development that focuses on implementing the most critical aspects of a software system first. The critical piece may be defined in terms of services provided, degree of risk, difficulty, or some other criterion.
customer (PLC)	The person who authorizes the purchase of or buys, (or for internal products commits their team to use) the product. See also user.
data dictionary	In database design, a collection of the names of all data items used in a software system, together with relevant properties of those items; for example, length of data item, representation, etc. In structured programming, a set of definitions of data flows, data elements, files, databases, and processes referred to in a data flow diagram set.
data flow diagram	In structured programming, a graphic representation of a system. Synonymous with data flow graph, data flow chart.
debugging	The process of locating, analyzing, and correcting suspected bugs. Contrast with testing.
defect	See bug and fault.
Defect Prediction Model (PLC)	A chart used to predict the number of bugs (or defects) that will be found before a product is released.
defect tracking (PLC)	The procedure used to log defects or bugs along with their status and resolutions.
definition phase	See requirements phase.
deliverable (PLC)	An item or feature which is due at an assigned milestone.
delivery	The point in the software development cycle at which a product is released for operational use.
delivery (PLC)	The point at which a work product is turned over to another group; such as, the Octagon A4 build is given to SQA.
design	The process of defining the software architecture, components, modules, interfaces, test approaches, and data for a software system to satisfy the requirements. The result of the design process.
design analysis	The evaluation of a design to determine correctness with respect to stated requirements, conformance to design standards, system efficiency, and other criteria. The evaluation of alternative design approaches. See also preliminary design.
design inspection	See inspection.
design language	A language with special constructs and, sometimes, verification protocols used to develop, analyze, and document a design.
design methodology	A systematic approach to creating a design, consisting of the ordered application of a specific collection of tools, techniques, and guidelines.
design phase	The period of time in the software life cycle during which the designs for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements.
design requirement	Any requirement that impacts or constrains the design of a software system or software system component; for example, functional requirements, physical requirements, performance requirements, software development standards, software quality assurance standards. See also requirements specification.
design review	A formal review of an existing or proposed design for the purpose of detection and remedy of problems that could affect fitness-for-use and environmental aspects of the product, process or service, and/or for identification of potential improvements of performance, safety and economic aspects.
design specification	A specification that documents the design of a system or system component; for example, a software configuration item. Typical contents include system or component algorithms, control logic, data structures, data set-use information, input/output formats and interface descriptions. See requirements specifications.
detailed design	The process of refining and expanding the preliminary design to contain more detailed descriptions of the processing logic, data structures, and data definitions, to the extent that the design is sufficiently complete to be implemented. The result of the detailed design process.
development life cycle	See software development cycle.
development methodology	A systematic approach to the creation of software that defines development phases and specifies the activities, products, verification procedures, and completion criteria for each phase.
distribution media (PLC)	The media used to distribute the product; for example 3.5 inch floppy disks and CD-ROM are two such media.
document	A data medium and the data recorded on it, that generally has permanence and that can be read by man or machine. Often used to describe human readable items only, for example, technical documents, design documents version description documents. To create a document.
dynamic analysis	The process of evaluating a program by executing the program and observing the results. Contrast with static analysis.
Engineering Release (ER) (PLC)	A development milestone where the product is complete and ready to be sent to customers and users.
error	A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. Contrast with failure, fault.
failure	The inability of a system to perform a required function within specified limits. A failure may be produced when a fault is encountered. A departure of program operation from program requirements. The termination of the ability of a functional unit to perform its required function.
fault	A manifestation of an error in software. A fault, if encountered, may cause a failure. An accidental condition that causes a functional unit to fail to perform its required function
formal specification	A specification written and approved in accordance with established standards.
formal testing	The process of conducting testing activities and reporting results in accordance with an approved test plan.
functional decomposition	A method of designing a system by breaking it down into its components in such a way that the components correspond directly to system functions and sub-functions.
functional design	The specification of the working relationships among the parts of a data processing system. See preliminary design.
functional specification	A specification that defines the functions that a system or system component must perform.
IEEE	Institute of Electrical and Electronic Engineers
implement	The process of turning a design into a product. In the case of a software product, this would be writing and debugging the code.
inspection	A formal evaluation technique in which software requirements, design, or code are examined in detail by a person or group with the author to detect problems. Contrast with walk-through. See also code audit.
Install Set (PLC)	The files that will be copied to distribution media for product distribution.
integration	The process of combining software elements, hardware elements, or both into an overall system.
integration test	An orderly progression of testing in which software elements, hardware elements or both are combined and tested until the entire system has been integrated.
interface	A shared boundary. To interact or communicate with another system component.
interface (PLC)	See API and User Interface.
interface requirement	A requirement that specifies a hardware, software, or database element with which a system or system component must interface, or that sets forth constraints on formats, timing, or other factors caused by such an interface.
interface specification	A specification that sets forth the interface requirements for a system of or system component.
interface testing	Testing conducted to ensure that program or system components pass information or pass control correctly to one another.
ISO	International Standards Organization
librarian	See software librarian.
life cycle	See software life cycle, development life cycle, and product life cycle.
life cycle model (PLC)	The theoretical basis used to plan the strategy for developing a product; two examples, the waterfall model and the spiral model.
maintain	To repair, change, or add to a software product.
maintainability	The ease with which software can be changed and updated.
milestone	A scheduled event for which some project member or manager is held accountable and that is used to measure progress; for example, a formal review, issuance of a specification, product delivery.
milestone (PLC)	See IEEE definition (except multiple owners). a build which has met predefined levels of completeness and is ready to be given to SQA for testing; for example the A4 milestone in Octagon. An event which marks the end of a phase.
modification	A change made to the software. The process of changing software.
modular decomposition	A method of designing a system by breaking it down into modules.
modularity	The extent to which software is composed of discrete components such that a change to one component has minimal impact on other components.
module	A logically separate part of a program. A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading; for example, the input to, or output from an assembler, compiler, linkage editor, or executive routine.
MTBF	Mean Time Between Failure.
object	An object is a software "package" that contains a collection of related procedures and data.
object code	Machine readable instructions derived by compiling source code.
object diagram	Part of the notation of object-oriented design, used to show the existence of objects and their relationships in the logical design of a system.
object-oriented analysis	A method of analysis in which requirements are examined from the perspective of objects found in the problem.
object-oriented design	A method of design encompassing the process of object-oriented decomposition; specifically, this notation includes class diagrams, object diagrams, and process diagrams.
object-oriented programming	A method of implementation in which programs are organized as cooperative collections of objects.
performance	A measure of the ability of a computer system or subsystem to perform its functions; for example, response time, throughput, number of transactions.
performance requirement	A requirement that specifies a performance characteristic that a system or system component must possess; for example speed, accuracy, frequency.
performance specification	A specification which sets forth the performance requirements for a system or system component.
precision	The degree of discrimination with which a quantity is stated; for example, a three-digit numeral discriminates among 1000 possibilities. Contrast with accuracy.
preliminary design	The process of analyzing design alternatives and defining the software architecture. Preliminary design typically includes definition and structuring of computer program components and data definitions of the interfaces, and preparation of timing and sizing estimates. The result of the preliminary design process. See also design analysis, functional design.
process	In a computer system, a unique, finite course of events defined by its purpose or by its effect, achieved under given conditions.
Product (PLC)	A product is the tangible result of any process or work group. This includes, but is not limited to, shrink-wrapped or other software products, software components, support services, and task force deliverables.
product life cycle	A process which defines the phases of the development and deployment of a product.
Product Team (PLC)	A group of people representing different disciplines who manage a project.
productivity	A measure of effort per unit of time.
program	A computer program. A single executable. A schedule or plan that specifies actions to be taken. To design, write, and test computer programs.
program architecture	The structure and relationships among the components and/or modules of a computer program. The program architecture may also include the program's interface with its operating environment.
Project (PLC)	A group of people and other resources organized to complete a task.
Project Approval (PLC)	A formal approval by upper management for the continuation and funding for a project.
project folder (PLC)	A central repository of written material such as memos, plans, technical reports, etc., pertaining to a project. See the Project Completion Milestone Checklist in the PLC for a complete list of items required in the project folder. Synonymous with project file, project notebook.
project plan	A management document describing the approach that will be taken for a project. The plan typically describes the work to be done, the resources required, the methods to be used, the configuration management and quality assurance procedures to be followed, the schedules to be met, the project organization, etc.
prototyping	A method for determining the user's requirements. A quick and dirty product, created specifically to test ideas out and get feedback quickly, used to refine requirements and then be discarded.
pseudo code	A combination of programming language and natural language used for computer program design.
quality	The totality of features and characteristics of a product or service that bears on its ability to satisfy given needs. See software quality.
quality (PLC)	Quality means continually improving our processes by applying optimum quality practices. Quality is a process that involves looking for, identifying, and removing the causes of defects from the product.
release (PLC)	A set of distribution media that is ready to be duplicated.
reliability	The ability of an item to perform a specific function under stated conditions for a stated period of time.
requirement	A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component. See also requirements analysis, requirements phase, requirements specification.
requirement analysis	The process of studying user needs to arrive at a definition of system or software requirements. The verification of system or software requirements.
requirements phase	The period of time in the software life cycle during which the requirements for a software product, such as the functional and performance capabilities, are defined and documented.
requirements specifications	A specification that sets forth the requirements for a system or system component; for example, a software configuration item. Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards.
review	The process of examining a design, code, or other work products with the intent of finding defects..
risk analysis	The process of identifying potential problems and the associated likelihood of those problems.
root cause analysis (PLC)	The process of determining the underlying reasons an error, fault, failure, or bug occurred. The concern is not how to fix the problem but to discover why it occurred and prevent this type of problem from occurring in the future.
software	Computer programs, procedures, rules, and possible associated documentation and data pertaining to the operation of a computer system.
software development cycle	The period of time that begins with the decision to develop a software product and ends when the product is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Contrast with software life cycle.
software librarian	A person responsible for establishing, controlling, and maintaining a software library.
software library	A controlled collection of software and related documentation designed to aid in software development, use, or maintenance. Library material includes reusable software components, architectures, specifications, standards documents, and software utilities.
software life cycle	The period of time that starts when a software product is conceived and ends when the product is no longer supported. The software life cycle typically includes a requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Contrast with software development cycle.
software quality	The totality of features and characteristics of a software product that bear on its ability to satisfy given needs; for example, conform to specifications. The degree to which software possesses a desired combination of attributes. The degree to which a customer or user perceives that software meets his or her composite expectations. The composite characteristics of software that determine the degree to which the software in use will meet the expectations of the customer.
source code (PLC)	Programming statements required for a product. This is a subset of the source files. Source code does not include make files, install scripts resource files, or batch files. Source code is translated into executable code.
source file (PLC)	All files containing programming statements required for a product. These include header files, install scripts, make files, icons, bitmaps, resource files, and batch files.
specification	A document that prescribes, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or system component. See also design specification, formal specification, functional specification, interface specification, performance specification, requirements specification. The process of developing a specification.
SQA	Software Quality Assurance.
static analysis	The process of evaluating a program without executing the program. Contrast with dynamic analysis.
structured design	A disciplined approach to software design that adheres to a specified set of rules based on principles such as top-down design, stepwise refinement, and data flow analysis.
structured programming	A well-defined software development technique that incorporates top-down design and implementation and strict use of structured program control constructs. Loosely, any technique for organizing and coding programs that reduces complexity, improves clarity, and facilitates debugging and modification.
stub	A dummy program module used during the development and testing of a program.
system	An integrated whole that is composed of diverse, interacting, specialized structures and sub functions. A collection of people, machines, and methods organized to accomplish a set of specific functions.
task	Something which must be done. Usually, the smallest unit of work which can be scheduled or defined.
test phase	The period of time in the software life cycle during which the components of a software product are evaluated and integrated, and the software product is evaluated to determine whether or not requirements have been satisfied.
test plan	A document prescribing the approach to be taken for intended testing activities. The plan typically identifies the items to be tested, the testing to be performed, test schedules, personnel requirements, reporting requirements, evaluation criteria, and any risk requiring contingency planning.
test procedure	Detailed instructions for the setup, operation, and evaluation of results for a given test. A set of associated procedures is often combined to form a test procedures document.
testing	The process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements or to identify differences between expected and actual results. Compare with debugging.
testware (PLC)	Testware includes test strategies, procedures, test cases, test drivers, scripts, and files.
top-down	Pertaining to an approach that starts with the highest level component of a hierarchy and proceeds through progressively lower levels; for example, top-down design, top-down programming, top-down testing. Contrast with bottom-up.
top-down design	The process of designing a system by identifying its major components, decomposing them into their lower level components, and iterating until the desired level of detail is achieved. Contrast with bottom-up design.
unit test	The testing of a module.
user (PLC)	The person who actually uses the product. Contrast with customer.
User Interface (UI) (PLC)	That portion of the external interface which specifies how the program will respond to human inputs. The "look and feel" of the program.
validation	The process of evaluating software at the end of the software development process to ensure compliance with software requirements.
verification	The process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements of that phase. See also validation.
Version (PLC)	A shippable product. A milestone of a product or component while still in the development phase, usually given to SQA for testing; for example, the A4 version of Octagon. Any build of a product; for example, the nightly build of Octagon.
walk-through	A review process in which a designer or programmer leads one or more people through a segment of design or code that he or she has written, while the other members ask questions and make comments about technique, style, possible errors, violations of development standards, and other problems. Contrast with inspections.
waterfall model	A simple model for implementing a software life cycle.