| < Day Day Up > |
|
In a RAD work pattern, the Requirements Definition and Design phases are iteratively conducted; in this process, a rough set of requirements is used to create an initial version of the system, giving users visibility into the look, feel, and system capabilities. User evaluation and feedback provide revisions to the requirements, and the process is repeated until the requirements are considered to be complete.
The formal set of system records (e.g., files, data) that must be retained during the Disposition phase; the plan for collecting and storing these records.
The ability of a software system to continue operating despite the presence of errors.
Rebuilding a process to suit some new purpose (e.g., a new business process).
In software maintenance, the rerunning of test cases that previously executed correctly in order to detect errors introduced by the maintenance activity.
A configuration management activity wherein a specific version of software is made available for use.
The ability of a system (or system component) to perform its required functions under stated conditions for a specified period of time.
A capability needed by a user; 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 period of time in the SEP during which the requirements for a software product are formally defined, documented, and analyzed.
Establishes and controls the scope of system development efforts and facilitates a common understanding of system capabilities between the system proponent, developers, and future users.
Provides a method for tracking the functional requirements and their implementation through the development process.
In management, the time, staff, capital, or money available to perform a service or build a product; also, an asset needed for a process step to be performed.
A software engineering approach that derives the design and requirements of a system from its code; often used during the Maintenance phase of a system with no formal documentation.
A formal process at which an activity or product (e.g., code, document) is presented for comment and approval; reviews are conducted for different purposes, such as peer reviews, user reviews, management reviews (usually for approval), or done at a specific milestone, such as phase reviews (usually to report progress).
A formal document that records the results of a review.
A potential occurrence that would be detrimental to the project; risk is both the likelihood of the occurrence and the consequence of the occurrence.
The process of identifying areas of risk; the probability of the risk occurring, and the seriousness of its occurrence; also called risk analysis.
The integration of risk assessment and risk reduction in order to optimize the probability of success (i.e., minimize the risk).
A formal document that identifies project risks and specifies the plans to reduce these risks.
A defined responsibility (usually task) to be carried out by one or more individuals.
| < Day Day Up > |
|