Вы находитесь на странице: 1из 3

International Journal of Computer and Communication Engineering, Vol. 1, No.

2, July 2012

An Improved Inspection Meeting Process-The 7 Ps


M. Fahad Khan, Dilawar Ali, and Farhan Aadil

AbstractSoftware inspection meeting are conduct to find the defects as early as possible and helps in a producing an error free product which conforms to users needs. Software inspection meetings are considered to be volatile due to the varying nature and knowledge of the participants. So it is never possible that the inspection done by different teams on same project will result same. So sometime this meeting is not too much productive because of inspectorslack of domain knowledge or not effective meeting process. We propose a better software inspection meeting process and also discuss how we will get better results using our suggested 7 Ps of software inspection. Index TermsSoftware inspection meeting, The 7 Ps

other hand we have smeared the inspection meeting process covering all the factors that can affect the efficiency of inspection meetings. To map our findings into real time scenarios we performed an experiment and in light of the outcomes we propose 7 Ps of improved software inspection meetings which are applicable to generic software artifacts. III. THE 7 PS A. Planning In the planning phase moderator have to do following activities; Ensure that product is ready for inspection. Participants selection and assigning role. Defining agenda and scope of meeting. Schedule meeting place and time. Distribute material for advance reading. Checklists. The planning phase is same as in generic inspection process. The only difference is the selection of participants. 1) Participant Selection Normally inspection teams comprises of inspectors, moderators, readers,recorders and author, but we have proposed user/customer as an additional participant for the inspection meetings. As the user is the key person who would finally be using this product so his involvement is of prime importance. B. Preparation in advance In this phase all the reviewers have to go through the meeting materials which are given in the planning phase to each individual. Each participant prepares some domain knowledge about the meeting material and also makes notes of their finding in the given artifacts. One more important part of advance preparation is that before meeting psychologist give some tips to inspectors as well to make the meeting effective. User involvement is a necessary in this phase. User / Customers are the one which play vital roles in defining requirements, making SRS document, at some levels of design can study the artifact and note down the missing cases. All defects found in this process are noted and reported before the start of meeting to the moderator. C. Presentation/Meeting Phase Normally duration of inspection meetings is 2 hours, but our inspection meeting process is a bit longer but more efficient which is of 3 hours. We have divided the inspection meeting into 3 phases.They are discussed below: The major problems observed during our experiment are: The participants do not prepare well in advance for the meetings. The participants lack domain knowledge.
172

I.

INTRODUCTION

Softwares are prone to defects due to the human factor. Earlier the defects are detected, lesser the cost to repair defects. Software inspections are effective way to find and reduce defects before porting software to user. Software inspection meetings are vital part of software inspections. They try to identify and resolve defects. Moreover they are effective way to eliminate false positives. Software inspection process is dependent on the participant domain knowledge and inspection meeting process.One of the serious problems of inspection meetings are non serious nature of The InspectionMeetingsas well as the inspectors dont take it as serious which results in less productivity and effectiveness of meeting.

II.

PROPOSED SOLUTION-THE 7 PS

As we have gone through several papers[1] [2] [3] [4]we have examined the spectrum of problems ranging from software defect detection methodology to effectiveness of inspection meeting to the nature of inspection meetings. Studies have shown that; it is difficult to uncover 100% errors; it is also not possible to cover all paths in complex codes [1], and the greater the familiarity of software reviewers with each other, greater is the effectiveness of the inspection meetings [4].Another study has shown that synchronous meetings are more effective than asynchronous ones [3]. As clear from the past research work that we have reviewed, no one proposed the solution for improving inspection meeting process to reduce the no of defects and process improvement for further productiveresult. On the
Manuscript received February 20, 2012; revised April 16, 2012. M. Fahad Khan and Dilawar Ali are with the Software Engineering Department, University of Engineering & Technology, Taxila. Farhan Aadil is with Computer Engineering Department, University of Engineering & Technology, Taxila.

International Journal of Computer and Communication Engineering, Vol. 1, No. 2, July 2012

The participants are sometimes non serious with the discussion going on. Goal of inspection meeting is not clear to them. The junior participant lacks confidence. The junior participants comments / recommendations are entertained at less priority. 1) Inspectors Evaluation Each of the inspectors submits his initial findings to the moderator before the start of inspection meeting.In first phase every inspector is given 10 minutes to present his domain knowledge as well as the knowledge of distributed artifact.The moderator judges the inspectors and takes notes. This whole activity ensures that the inspector is well prepared and has appropriate domain knowledge and gives the moderator the health of individual inspectors preparation. 2) The Core Discussion The moderator is the sole arbiter and assigns the time to the inspectors during the discussion keeping in mind the health of their work gathered from the previous phase. We expect our discussion meeting to be of highest quality considering our strategy. The rest of the discussion process is same, finding out redundant errors and false alarms. 3) User Involvement This is the most effective part of our research.User/Customer are the key participantsof our inspectionmeeting sessions; they are idle most of the time in meetings giving their input at specific time where they feel that the requirements being diverted out of the scope. In addition the users play key role in making decisions in some parts of debatesas they are the actually users of that system. The important point to note is that the user involvement in inspection meeting is not as productive in technical artifacts but play important roles in artifacts that directly relate to the users such as SRS,User Documentation/Manuals and to some extent the design document as well. Main advantage to involve the user in the requirement specification is to find ambiguities in the requirements.
TABLE 1: PRIORITY VALUES Priority Critical Major Normal Minor Exception Value 1 2 3 4 5

20% major errors) are removed automatically. Each error is assigned the priority according to its health. Major Errors has given more priority than the minor ones. F. Post Meeting Sessions Post meeting session includes rework and follow-up. 1) Rework & Follow-up The list in which all errors are prioritized is then sent to the development team for correction of errors based on priorities. I this part of post meeting session the inspected product or artifact is then checked that weather the proposed defects are corrected or not and now either the product / artifact conforms to user requirements or not. G. Performance evaluation of Inspector/Reviewers The inspectors are evaluated and ranked according to the judgment of the moderator as well as judgment of all the participants. Performance criteria: 50% moderator 50% voting (Balloting should be secrete) Inspector Ranking is done for the next time,ranking pool is developed and next time for further inspection,the inspectors are selected according to their expertise and their rankings in pervious inspection process. The Best inspector is one having high rating in an inspection process.

IV. THE EXPERIMENT We have done a short experiment to see the result of our studies and findings. We set up our test environment in BytesOnSale [6]. We makes two teams; one composed on the older team building techniques named as A,and this team will perform the inspection on the basis of generic inspection process which is already used, other team involves user / customers named as B (as per our team selection procedure), and this team has to inspect the product or artifact using the 7 Ps that are described above.Bothteams are given the task to do the inspection of following artifacts Requirements Document, Design Document, Code Document of a product to see the results of our prescribed process.

V.

THE RESULT

Results of our experiments are as follow; A. Requirements Document Result of errors found in requirement documents are as follow.
TABLE 2: RESULTS OF REQUIREMENTS DOCUMENT INSPECTION Errors after removing false alarms and duplicate errors 17 36

D. Pointing out Errors Error found in the meeting phase as well as in advance preparation phase are submitted to the moderator. Moderator has to remove the false alarm. An error pointed out by more than one inspector is noted just once. E. Priority Settings Allreported errors are analyzed and discuss with the whole team are priorities according to their effect to the product and a list of final error s created having their priorities. As stated in 80-20 Rule [5] if we remove the major 20% of errors, other 80% minor errors (that are due to
173

Team Name A B

Number of errors found 23 49

Result shows that involvement of user will uncover more errors than without it. Also when the presenter is prepared in

International Journal of Computer and Communication Engineering, Vol. 1, No. 2, July 2012

advance and having psychological tips before meeting will make the results better. As you know uncovering errors as earlier in the product development life cycle will save the large amount of cost. B. Design Document Result of errors found in design documents are as follow.
TABLE 3: RESULTS OF DESIGN DOCUMENT INSPECTION Team Name A B Number of errors found 27 40 Errors after removing false alarms and duplicate errors 21 32

VI. TRAINING OF REVIEWERS We also focus on the grooming and training of the reviewers to make the result effective. We provide: Training to reviewer Psychological tips Skill development Personal grooming Confidence development VII. CONCLUSION AND FUTURE WORK Software inspections plays vital role in improving the quality of software. Summarizing our research studies we come to point that improving meeting process will led to effective and productive meeting results. Significant part of the study gives us the ideas that defects rates after release can be lowered with improved inspection meeting process. It has been observed from the experiments that nominal teams out performed real teams with face-to-face meetings. So according to our study, inspection meetings are vital to the inspection process helping find real defects. Future work of this paper includes the training of inspectors so that they can actively participate in the inspection process, and realizing them that they are the important part of inspection meeting that make it successful or not. REFERENCES
[1] [2] R. K. Kand, A Software Defect Detection Methodology, Jet Propulsion Laboratory, California Institute of Technology. A. Bianchi, F. Lanubile, and G. Visaggio, A Controlled Experiment to Assess the Effectiveness of Inspection Meetings, Dipartimento di Informatica, University of Bari , Bari, Italy F. Calefato, F. Lanubile, and T. Mallardo, A Controlled Experiment on the Effects of Synchronicity in Remote Inspection Meetings, Dipartimento di Informatica, University of Bari , Bari, Italy C. B. Seaman and V. R. Basili, Communication and Organization: An Empirical Study of Discussion in Inspection Meetings, IEEE Transactions on Software Engineering, 1998 F. John Reh, Pareto's Principle - The 80-20 Rule. BytesOnSale, A company where we implement our proposed Solution.

Results shows the errors found by following our set procedure is still good enough then by older procedure. C. Code Document Result of errors found in code documents are as follow.
TABLE 4: RESULTS OF CODE DOCUMENT INSPECTION Team Name A B Number of errors found 25 32 Errors after removing false alarms and duplicate errors 18 23

This result shows that only bit good result is provided in code document. D. Result Analysis Analysis of results shows following two Concludings; Team B which follows our 7 Ps always results in finding more errors than older approach hence making meeting successive then earlier. Defects rates after release can be lowered with improved inspection meeting, as by finding more errors defect rate will reduce automatically. Rate of finding Errors in an artifact /product if user is involveddepends on the technicality of document. It will decrease as technicality of document increases. As user is fully involved in requirement phase, it results in finding more errors, partially in designing phase (because user not well aware of all design concept) will result good result due to advance preparation and their trainings and psychological tips and in code document user is not well aware of coding (the internal detail) so ratio of finding more error is less as compared to design and requirement document.

[3]

[4]

[5] [6]

Engr. M. Fahad Khan Received his M.Sc. Computer Engineering in 2010 from University of Engineering and Technology, Taxila, Pakistan. He did his BSc Software Engineering from same university in 2007. He got distinction in his MS and Bachelors Program. Presently he is PhD Scholar in Computer Engineering and he is also serving as a Lecturer in Software Engineering Department at University of Engineering & Technology, Taxila, Pakistan. His areas of interest are Digital Image Processing, Video Analytics, Software Development, Software Design Architecture, Computer Vision and Mobile Application Development.

174

Вам также может понравиться