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".[1] The reviews are also performed by assessors, specialists, etc. and are suggested or mandatory as required by norms and standards.[2]

"Software product" normally refers to some kind of technical document. As indicated by the IEEE definition, this might be a software design document or program source code, but use cases, business process definitions, test case specifications, and a variety of other technical documentation may also be walked through.

A walkthrough differs from software technical reviews in its openness of structure and its objective of familiarization. It differs from software inspection in its ability to suggest direct alterations to the product reviewed. It lacks of direct focus on training and process improvement, process and product measurement.

Process

A walkthrough may be quite informal, or may follow the process detailed in IEEE 1028 and outlined in the article on software reviews.

Objectives and participants

In general, a walkthrough has one or two broad objectives: to gain feedback about the technical quality or content of the document; and/or to familiarize the audience with the content.

A walkthrough is normally organized and directed by the author of the technical document. Any combination of interested or technically qualified personnel (from within or outside the project) may be included as seems appropriate.

IEEE 1028 recommends three specialist roles in a walkthrough:[1]

  • The author, who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items;
  • The walkthrough leader, who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author); and
  • The recorder, who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meetings.

Further reading

  • O'Regan, Gerard (2011). Introduction to Software Process Improvement. Undergraduate Topics in Computer Science. London: Springer London. doi:10.1007/978-0-85729-172-1. ISBN 978-0-85729-171-4. S2CID 9037690. Retrieved 2023-03-22.

See also

References

  1. 1 2 IEEE Standard for Software Reviews and Audits. 2008-08-15. pp. 1–53. doi:10.1109/IEEESTD.2008.4601584. ISBN 978-0-7381-5768-9.
  2. ↑ Pries, Kim H.; Quigley, Jon M. (2009). Project Management of Complex and Embedded Systems. Boca Raton, FL: CRC Press (Auerbach Publications). ISBN 978-0-429-11624-7. OCLC 297220015.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.