to help ensure that:
- Errors are detected and corrected as early as possible in the software life cycle.
- Project risk, cost, and schedule effects are lessened./li>
- Software quality and reliability are enhanced.
- Management visibility into the software process is improved.
- Proposed changes and their consequences can be quickly assessed.
Lifecycle frameworks are definitely a step in the right direction, extending V&V out of testing, and ushering it right into the beginning of software lifecycles. However, like exhaustive testing frameworks, encyclopedic lifecycle frameworks are perceived as overly bureaucratic, unnecessary, and unaffordable. If most software projects won't employ highly structured testing, they certainly will not consider even more extensive lifecycle frameworks. The next few sections will introduce streamlined and more effective approaches to inundating lifecycle frameworks, as well as late and ineffective testing.
Lifecycle Methodologies (In Process)
Lifecycle methodologies, like lifecycle frameworks, address V&V across all software lifecycle stages, eliminating defects from software artifacts . That’s where the similarities end. Lifecycle methodologies are streamlined to include only the most effective and bare minimum software defect elimination techniques recommended by lifecycle frameworks. Lifecycle methodologies go on to add holistic and integrated step-by-step metrics and measurement approaches, thus earning the term methodology . Lifecycle methodologies also add predictive statistical parametric models, for accurately estimating software lifecycle resources, software defects, and software defect elimination effectiveness . Lifecycle methodologies are much more desirable than lifecycle frameworks, and are literally, orders of magnitude more desirable than testing. Lifecycle methodologies enable quality to focus on ensuring that processes are followed (not being reduced to testing), and are more effective and cost-efficient than lifecycle frameworks, testing, and even IV&V.
Basis for Lifecycle Methodology
The quantitative basis for lifecycle methodologies is predictive statistical parametric Rayleigh models . Rayleigh models are a special case of the Weibull distribution probability density curve or function [9, 10, 11]. Rayleigh models are used to predict defect populations of the total set of software life cycle artifacts before software lifecycles begin.
If true, which ample quantitative empirical results display , then lifecycle methodologies enable what no other reliability model claims to do. That is, accurately predict the number of software defects, and allocate the exact number of resources necessary to eliminate software defects, on a schedule, no less. In addition accurately portrayed defect populations, statistically correlated to other management indicators, such as cost, effort, and schedule, serve as the basis for accurately determining required software project resources, before software lifecycles begin [9, 11].
The news keeps on getting better, experience with lifecycle methodologies indicates that, not only can software defects be largely eliminated before testing begins, but that dependency on late and ineffective testing can be minimized [8, 9, 10, 11]. Contrary to the opinion of some practitioners, Rayleigh models can be successfully managed to become asymptotic before software lifecycles end [8, 9, 10, 11]. That is software defects may be completely eliminated before software is actually delivered to customers or users [9, 11].
However, there still must be an underlying process for eliminating and counting defects, in order to manage software lifecycles using lifecycle methodologies. These processes will be described in the next two sections.
Software Inspection Process
Inspections are a highly structured and measured, early lifecycle, in process multiple person review of software artifacts for the exclusive purpose of identifying software defects for elimination [11, 12, 13, 14, 15]. Inspections were invented by Michael E. Fagan of IBM in 1972, and first made public in a seminal paper in a 1976 issue of the IBM Systems Journal . Inspections may be used to identify defects in all software lifecycle artifacts throughout software lifecycles.