Software review

Last updated

A software review is "a process or meeting during which a software product is examined by a project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval". [1]

Contents

In this context, the term "software product" means "any technical document or partial document, produced as a deliverable of a software development activity", and may include documents such as contracts, project plans and budgets, requirements documents, specifications, designs, source code, user documentation, support and maintenance documentation, test plans, test specifications, standards, and any other type of specialist work product.

Varieties of software review

Software reviews may be divided into three categories:

Different types of peer reviews

Formal versus informal reviews

"Formality" identifies the degree to which an activity is governed by agreed (written) rules. Software review processes exist across a spectrum of formality, with relatively unstructured activities such as "buddy checking" towards one end of the spectrum, and more formal approaches such as walkthroughs, technical reviews, and software inspections, at the other. IEEE Std. 1028-1997 defines formal structures, roles and processes for each of the last three ("formal peer reviews"), together with software audits. [1] IEEE 1028-1997 was succeeded by IEEE 1028-2008. [3]

Research studies[ who? ] tend to support the conclusion that formal reviews greatly outperform informal reviews in cost-effectiveness. Informal reviews may often be unnecessarily expensive (because of time-wasting through lack of focus) and frequently provide a sense of security which is quite unjustified by the relatively small number of real defects found and repaired.

IEEE 1028 generic process for formal reviews

IEEE 1028 defines a common set of activities for "formal" reviews (with some variations, especially for software audit). This standard applies distinctions between management review, technical review, inspection, walk-through, audit, etc.

The stipulated sequence of standard activities is largely based on the software inspection process originally developed at IBM by Michael Fagan. [4] Differing types of review may apply this structure with varying degrees of rigour, but all activities are mandatory for inspection:

Value of reviews

The most obvious value of software reviews (especially formal reviews) is that they can identify issues earlier and more cheaply than they would be identified by testing or by field use (the "defect detection process")[ citation needed ]. The cost to find and fix a defect by a well-conducted review may be one or two orders of magnitude less than when the same defect is found by test execution or in the field.[ citation needed ]

A second, but ultimately more important, value of software reviews is that they can be used to train technical authors in the development of extremely low-defect documents, and also to identify and remove process inadequacies that encourage defects (the "defect prevention process").

This is particularly the case for peer reviews if they are conducted early and often, on samples of work, rather than waiting until the work has been completed. Early and frequent reviews of small work samples can identify systematic errors in the author's work processes, which can be corrected before further faulty work is done. This improvement in author skills can dramatically reduce the time it takes to develop a high-quality technical document and dramatically decrease the error-rate in using the document in downstream processes.

As a general principle, the earlier a technical document is produced, the greater will be the impact of its defects on any downstream activities and their work products. Accordingly, greatest value will accrue from early reviews of documents such as marketing plans, contracts, project plans and schedules and requirements specifications. Researchers and practitioners have shown the effectiveness of reviewing process in finding bugs and security issues. [5]

See also

Related Research Articles

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to:

<span class="mw-page-title-main">Configuration management</span> Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process. An inspection might also be referred to as a Fagan inspection after Michael Fagan, the creator of a very popular software inspection process.

<span class="mw-page-title-main">Inspection</span> Organized examination or formal evaluation exercise

An inspection is, most generally, an organized examination or formal evaluation exercise. In engineering activities inspection involves the measurements, tests, and gauges applied to certain characteristics in regard to an object or activity. The results are usually compared to specified requirements and standards for determining whether the item or activity is in line with these targets, often with a Standard Inspection Procedure in place to ensure consistent checking. Inspections are usually non-destructive.

Code review is a software quality assurance activity in which one or several people check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the persons must not be the code's author. The persons performing the checking, excluding the author, are called "reviewers".

A Fagan inspection is a process of trying to find defects in documents during various phases of the software development process. It is named after Michael Fagan, who is credited with the invention of formal software inspections.

Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

DOD-STD-2167A, titled "Defense Systems Software Development", was a United States defense standard, published on February 29, 1988, which updated the less well known DOD-STD-2167 published 4 June 1985. This document established "uniform requirements for the software development that are applicable throughout the system life cycle." This revision was written to allow the contractor more flexibility and was a significant reorganization and reduction of the previous revision; e.g.., where the previous revision prescribed pages of design and coding standards, this revision only gave one page of general requirements for the contractor's coding standards; while DOD-STD-2167 listed 11 quality factors to be addressed for each software component in the SRS, DOD-STD-2167A only tasked the contractor to address relevant quality factors in the SRS. Like DOD-STD-2167, it was designed to be used with DOD-STD-2168, "Defense System Software Quality Program".

A Software management review is a management study into a project's status and allocation of resources. It is different from both a software engineering peer review, which evaluates the technical quality of software products, and a software audit, which is an externally conducted audit into a project's compliance to specifications, contractual agreements, and other criteria.

In software development, peer review is a type of software review in which a work product is examined by author's colleagues, in order to evaluate the work product's technical content and quality.

In software engineering, a walkthrough or walk-through is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems". The reviews are also performed by assessors, specialists, etc. and are suggested or mandatory as required by norms and standards.

A software technical review is a form of peer review in which "a team of qualified personnel ... examines the suitability of the software product for its intended use and identifies discrepancies from specifications and standards. Technical reviews may also provide recommendations of alternatives and examination of various alternatives".

A software audit review, or software audit, is a type of software review in which one or more auditors who are not members of the software development organization conduct "An independent examination of a software product, software process, or set of software processes to assess compliance with specifications, standards, contractual agreements, or other criteria".

IEEE 1471 is a superseded IEEE standard for describing the architecture of a "software-intensive system", also known as software architecture.

<span class="mw-page-title-main">Software security assurance</span>

Software security assurance is a process that helps design and implement software that protects the data and resources contained in and controlled by that software. Software is itself a resource and thus must be afforded appropriate security.

Verification and validation are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. These are critical components of a quality management system such as ISO 9000. The words "verification" and "validation" are sometimes preceded with "independent", indicating that the verification and validation is to be performed by a disinterested third party. "Integration verification and validation" can be abbreviated as "IV&V".

A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.

In engineering, technical peer review is a well defined review process for finding and correcting defects conducted by a team of peers with assigned roles. Technical peer reviews are carried out by peers representing areas of life cycle affected by material being reviewed. Technical peer reviews are held within development phases, between milestone reviews, on completed products, or on completed portions of products. A technical peer review may also be called an engineering peer review, a product peer review, a peer review/inspection or an inspection.

Software construction is a software engineering discipline. It is the detailed creation of working meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. It is linked to all the other software engineering disciplines, most strongly to software design and software testing.

References

  1. 1 2 IEEE Std . 1028-1997, "IEEE Standard for Software Reviews", clause 3.5
  2. ↑ Wiegers, Karl E. (2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley. p. 14. ISBN   0201734850.
  3. ↑ "IEEE Standard for Software Reviews and Audits". IEEE STD 1028-2008: 1–53. 2008-08-15 [2008]. doi:10.1109/IEEESTD.2008.4601584. ISBN   978-0-7381-5768-9.
  4. ↑ Fagan, Michael E: "Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, Vol. 15, No. 3, 1976; "Inspecting Software Designs and Code", Datamation, October 1977; "Advances In Software Inspections", IEEE Transactions on Software Engineering, Vol. 12, No. 7, July 1986
  5. ↑ Charles P.Pfleeger, Shari Lawrence Pfleeger. Security in Computing. Fourth edition. ISBN   0-13-239077-9
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.