Inspections may or may not involve the author of the work product.

While classic, formal inspection processes, such as those defined by Fagan or in IEEE Std 1028, specify the author as a required participant, variations in practice exist. The author's primary role is to provide clarification on the work product, not to defend it. However, some organizations conduct inspections without the author present in the defect-logging meeting. This approach is taken to foster a more open critique, prevent author defensiveness, and test if the work product can be understood on its own merits. In these cases, the author is still involved in the overall process (e.g., preparation and subsequent rework), but not in the meeting itself. Therefore, the statement that inspections "may or may not" involve the author is correct.

B. False: This is incorrect because it implies the author's presence is always mandatory in every type of inspection. Authoritative software engineering literature and practical process variations acknowledge scenarios where inspections are intentionally conducted without the author present in the meeting.

1. Wiegers, K. E. (2002). Peer Reviews in Software: A Practical Guide. Addison-Wesley Professional.

Reference: In Chapter 5, "The Players," Wiegers discusses the roles in a review. In the section "Review Without the Author" (p. 83), he explicitly states, "Some organizations hold review meetings without the author present... The theory is that the other reviewers will feel more comfortable pointing out defects if the author isn't there to get defensive." This directly supports the idea that author involvement is not always mandatory.

2. IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits.

Reference: Section 5.2.3.1, "Roles and responsibilities," states, "The author of the work product shall be a member of the inspection team." While this standard mandates the author be on the team, the existence of process tailoring and alternative methodologies (as discussed by Wiegers and others) means this standard is not universally and rigidly applied in all contexts, allowing for variations where the author might not attend the meeting.

3. Laitenberger, O., & DeBaud, J. M. (2000). An encompassing life-cycle and framework for software inspections. Journal of Systems and Software, 50(1), 5–31.

Reference: This paper discusses various frameworks and life cycles for software inspections, highlighting that the process is not monolithic. The discussion of different "reading techniques" and process models (Section 3) implies that variations in roles and procedures, including the specific level of author involvement, are part of the evolution and adaptation of the inspection process. DOI: https://doi.org/10.1016/S0164-1212(99)00083-900083-9)