Efficient management of inspections in software development projects
Introduction
Since the first published description of the inspection process by Michael Fagan [4] software inspections are gaining increased acceptance by both software developers and project managers. The reasons for this increasing practice of inspections, which, however, has not yet led to widespread usage according to the Software Engineering Institute [10], are not limited to their usefulness in improving quality by preventing defect leakage from one life cycle activity to the other. Industry experience shows also that through inspections, cycle time is reduced, costs are lowered, process visibility is increased and also programmers' capability is improved [4], [6], [20].
Inspections form an integral part in all phases of software development and apart from code reviews, cover all software artifacts, such as requirements, specifications, architectures, design, and test plans [11], [12]. Although inspection details vary according to the employed methodology and the target project, a set of common elements can be identified. These include a number of well-defined inspections steps (e.g. preparation, meeting, rework), well-defined inspection roles (e.g. moderator, author, inspector), formal collection of inspection data and a supporting infrastructure [1].
In almost every study dealing with inspections [1], [2], [10], [20] planning of inspections is identified as the initial stage of the inspection process. However, the purpose of planning in the above sense is to define the goals, the objectives and the methodology of the inspection [6] rather than to coordinate the inspection process with other project activities. Even though the importance of scheduling inspections in time has been addressed in Ref. [7] and [22], the arrangement of staff, people and time for the inspection is performed in short term before the inspection and definitely not earlier than the time when the item for the inspection has been prepared and checked to see whether it meets certain entry criteria [4], [5], [6]. In other words, the planning of the inspections is not performed well ahead the project initiation as it is done for all other project activities and it is not related to the project master plan.
Approaching inspection activities only in a procedural manner and not by taking into consideration project management requirements like time scheduling and personnel capacity issues, can give rise to several problems, especially in large software development projects. These troubles can vary from issues affecting only the inspection efficiency and the product quality, to others that put into danger the complete project. Risks that can emerge when inspections and resulting rework are not properly scheduled, have also been mentioned by Fagan in Ref. [4]. Some of these potentially inspection-related problems are listed below:
- •
Difficulties in meeting milestones due to unavailability of human resources (especially experts) for performing the inspections or due to bottlenecks in approval bodies and committees.
- •
Product quality degradation due to reduced inspection and preparation time and the subsequent reduced number of defects being discovered during the inspection.
- •
Cost increase due to excess overtime, which have not been initially planned and due to higher costs for fixing faults in later development stages.
The literature review reveals that although many previous works emphasize some of the problems caused by insufficient inspection and preparation time [2], [9], [21], or by delays and costs introduced from a large number of inspection meetings [12], [13], [15], they do not relate these issues with inefficient planning of the inspections. Software project management textbooks emphasize both the importance of careful planning activities and the use of software inspections as a verification and validation tool. However, reference to the risks related to inefficient inspection planning is limited [7], [8], [22].
In this paper, by performing post-mortem analysis on a large-scale telecommunications project, we attempt to illustrate inspection process complications that can be avoided by efficient scheduling of inspections. The findings will be highlighted using a number of indicators. Further analysis attempts to shed light to the reasons behind the identified weaknesses and to establish general guidelines for improving software project management concerning inspections.
The rest of the paper is organized as follows: in Section 2, information on the case study is given including the specific project characteristics and applied management methodology. The research questions, the collected measures and the possible threats to the investigation are enumerated in Section 3, while Section 4 summarizes our observations. A discussion on further reasons that complicate the planning of inspections is made in Section 5 while in Section 6 a set of general guidelines for improving inspection scheduling is proposed. Finally, we conclude in Section 7.
Section snippets
Case study
To reveal some of the side-effects that inherently reside in the application of the software inspection process in today's software development practices, data from a major telecommunications project is analyzed. In this section, characteristics of the project that has been selected are reported, including the project planning techniques that are employed by the organization and the review process that is applied.
Post-mortem analysis
This section states the main research questions to be investigated, enumerates the measures that have been collected for performing post-mortem analysis on the selected case study and discusses the potential threats to the validity of the analysis.
The overall argument of this study is that software inspections due to their role in validating design steps within a software development project tend to accumulate at specific periods during the course of the project. Therefore, if they are not
Observations
Concerning the primary hypothesis of our analysis, the accumulation of software inspection effort in short time periods can be readily observed by a plot like the one shown in Fig. 1, which shows the Project Effort per week (Section 3.1.a) and Inspection Effort per week (Section 3.1.b) during the project life. It becomes obvious, that inspection effort presents spikes during the course of the project, although the normal project effort has a relatively smooth form, as a result of the proper
Discussion
Since inspection planning is not a central management process carried out during the initial stages of a project, a large number of factors affect the time in which inspection meetings are performed. Since it is extremely difficult to relate all possible factors to the inspection process by experimental results, the following are, according to the authors' view, also possible reasons that reduce inspection planning efficiency.
Proposed guidelines
Although it is relatively easy to identify the problems in a software development process caused from inefficient inspection planning, it is inversely difficult to suggest a step-by-step procedure to avoid them, due to the numerous parameters that are involved. However, a number of general guidelines can be derived from the observations made in Section 5, which are both easy to apply and have limited interference with other software development activities. These are:
- •
The inspection plan must be
Conclusions
Data analysis for a large scale telecommunications software project has shown that for software inspections, which form an integral part in the software engineering process, the manner in which they are usually planned and performed, can give rise to a number of risks threatening the economics, quality, and the ability to meet deadlines of the project. Project planning methodologies, as currently applied in software project management, do not account for the inherent difficulties in planning
References (24)
- et al.
Software inspections: an effective verification process
IEEE Software
(1989) - et al.
Managing code inspection information
IEEE Software
(1994) - et al.
Quasi-Experimentation: Design and Analysis Issues in Field Settings
(1979) Design and code inspections to reduce errors in program development
IBM Systems Journal
(1976)Principles of Software Engineering Management
(1988)- et al.
Software Inspection
(1993) - et al.
Does every inspection really need a meeting?
Empirical Software Engineering
(1998) Reengineering inspection
Communications of the ACM
(1998)How much code inspection is enough?
Crosstalk, The Journal of Defense Software Engineering
(2001)Issues in software inspection
IEEE Software
(1997)
Peer Reviews, Encyclopedia of Software Engineering
Reducing inspection interval in large-scale software development
IEEE Transactions on Software Engineering
Cited by (7)
Management competences, not tools and techniques: A grounded examination of software project management at WM-data
2007, Information and Software TechnologyCross training efficiency and flexibility with process change
2014, International Journal of Operations and Production ManagementEffective approach to quality control for small-medium software companies
2014, Total Quality Management and Business ExcellenceResearch on software product development project management
2013, Applied Mechanics and MaterialsA pattern approach to software inspection process improvement
2005, Software Process Improvement and Practice