Software quality becomes main challenge for software companies. Industries are often investing more than 50 of resources on testing to improve software quality, and still many software projects are facing quality problems. Researchers have responded to these problems by formal methods. Most of these formal methods are making simple assumptions, but not valid for real programs [2]. Inspections are more effective than informal reviews and require least efforts than formal methods. Inspection is " a visual examination of a software product to detect and identify software anomalies, including errors and deviations from standards and specifications" [12][3]. And for the past 30 years inspections have been performed by many companies with positive results [3, 4].
Jack G. Ganssle, in his study compared inspections with testing, and the results are showed that
"IBM: removed 82% of all defects before testing, gave 23% increase in productivity( probably LOC per person-month), and gave 39% reduction in defects detected after unit test.
AT&T: inspections led to 14% increase in productivity.
HP: 80% of defects found during inspections and unlikely to be caught by testing.
HP, Shell, Bell-Northern, AT&T: inspections 20-30 times more efficient than testing in detecting faults"[5].
The results are showing the advantages of inspections in quality improvement. Software inspections are not only used for finding the defects, and also it helps to determine if coding style guidelines are followed, comments in the code are relevant and of appropriate length, naming conventions are clear and consistent, etc.,
One of the main quality influencing factors are "clones", companies are facing real tough problem to identify and removal of clones. We strongly argue that inspections are best way to find and remove the clones besides finding the defects. We consider detecting and removing clones which is one of the important part of software quality improvement. Even though there are techniques and tools are available to identify and removal of clones, none of them are doing accurately (section 2 detailed descriptions). We propose inspections are the best way to identify and remove the clones.
Even though inspections are having more benefits, it is not true for all the time. Software inspection is very expensive quality method; it should be used in an effective manner. There are many research questions in process of inspections.
When to introduce the inspection in software life cycle?
How to allocate the resources for inspections in different modules?
How to do the inspections?
When to stop inspections?
When to go re-inspections?
All these questions are to be answered before going for inspections. In this paper we discuss what all are the invariants in inspection process to achieve best quality. Also we propose new process for inspection to get best results in inspections.
Influencing of cloning:
It is very common practice for developers, even research telling that 21% of code is cloned in Linux kernel [6]. It is showing the influence of cloning in software projects, its usual practice for developer to copy and paste the code in projects [7].
There are many technologies readily available to remove cloning [6, 8, 9].Once identified clones can be removed by code refactoring. It is easy to identify the code with similar syntax and code, but it is difficult to identify the syntactic clones [6]. M. Kim in his study of code clone genealogic also provided evidence of code clones that are difficult or impossible to refractor using standard techniques [10]. He also told that one 50% of code clone are impossible to remove through standard refactoring techniques [10].
M. Kim told that code clones are immediate and clear negative factor for software quality [10]. Many studies are telling that cloning increases the maintenance cost [11]. Many companies are investing lots of money in removing clones [8].
On the other hand Kapser and Godfrey showing clones have benefits as well [11, 12]. Often developers duplicate existing code as starting point to develop new code more quickly, especially in case of software for drivers [6]. Krink mean while showed that cloned code tends to be more stable that other code as clones are less likely to be edited once they have been created [11].
Ekwa dalala illustrated how 63k LOC project took 32 minutes to analyze using a popular tool. For each run developer has to spend 32 minutes for analysis [8]. It is showing how expensive the automotive clone analysis in terms of time. For any company investing such a big amount for cloning itself we strongly believe is not possible and argue that code clone detection and removal is a part of so software quality improvement but not whole software quality improvement process.
Identify and remove the clones by inspections:
Inspection Invariants:
Inspection process depends on many factors
Detecting the defect prone module
As inspections are very costly process [13], it's very important to allocate the resources to inspection process. The researchers are clearly telling that 80% of the bugs are from 20% of the modules [14], so if we know what the 20% defect prone modules are, then it's very easy to allocate the resources. The quality team doesn't know that which software module have more defects, Therefore they will consider every module as defect prone and should be inspected with same priority . The resources are getting wasted if we inspect a module which is having minimum defects and the defects are escaped in more defect prone modules.. As there is no universal answer for "What makes module defect prone", it is very difficult to find out defect prone module. We found some of good existing techniques to estimate the defect prone modules such as "Predicting the bugs from the history" [14], "A constructive RBF neural network for estimating the probability of defects in modules" [15], "Predicting the defect prone by using random forests" [16] "Mechine learning modules to identify faulty"[17]. Every technique has its own importance, but "RBF neural network" is best technique among all [15].
Type of inspections
Virtual Inspections: Now-a-days many companies are forming virtual teams in developing software. It is not possible to go for face-to -face inspection meetings for many companies. It is difficult to find a common place for inspections because the team is distributed all over the world. In this case we suggest the companies will go for virtual inspections [18]. Many tools and world wide web further enhances the feasibility of virtual inspections As Porter and Johnson state face-to-face meeting do not make the defect detection process significantly more or less effective [19]. Many researchers showed that there are no considerable differences between traditional and computer supported (virtual) inspections.
Traditional inspections: If the teams are at the same place then companies will prefer face-to-face inspections, where it is easy to distribute the inspection documents and easy to arrange meeting.
Inspection duration: It is one of the important factors in inspections. Inspections are very expensive in terms of time because many staff hours are needed for inspections. Stefan Biffl in his study showed that inspectors read effectively for up to 8 hours, if it is more than 8 hours the effectiveness is decreased [20]. So we suggest inspection duration is not more than 8 hours.
Inspector experience and performance:
Selecting an inspector from pool of candidates according to their ability to perform well with finding the defects in the process is the important problem. Many companies selecting less experience developers as inspectors due to resource scarcity [21]. Inspector experience and software developing skills have significant effect on inspection process and finding defects [21]. In fact the level of inspection qualification is directly proportional to inspection performance [22]. However finding higher-qualifies inspectors is always not possible, Inspection process enables learning in defect detection regarding less qualified engineers [23]. Winkler told "inspectors who started with a simple (less complex) system part are more successful regarding effectiveness, efficiency, and false positives" [23]. So, we recommend Inspection expert to schedule the inspection and inspection team.
Team size:
Team size is one of the important factors in inspections, usually team size may be 3-6, Employing large team size is very expensive [24].From experiment [25] it is clear that defect detection is increasing with team size up to certain point and then it keep on decreasing . Halling and Bifi found there is no significant performance drop with increase in team size is small is (five are six)[26].
Using tool support:
Reading technique
Many organizations follow a three-step inspection procedure of individual defect detection, defect collection, and defect repair [20].
Reading for Individual defect detection (Ad hoc reading)
Reading is a key activity in defect detection to understand a given software artifact representation and compare it to a set of expectations regarding structure, content, and desire qualities. Ad hoc inspections purely depend on individual experience and knowledge. In this technique there is no support for reviewer.
Checklist-Based reading:
It is a general reading technique which typically consists of set of general questions regarding defect types, aspects to be checked and desired qualities. CBR will tell the inspector which aspects have to be checked, but it won't give any specific information. In CBR all the team members provided the same checklist, so everyone will concentrate on the entire list, there may be chance of overlapping of the work. Inspectors have to convert the checklist into tasks to do.
Scenario-Based reading:
In this Scenario-Based-Reading (SBR) users use procedures to identify specific defects. Scenarios consist of different view points for each customer. For e.g. user manual for user view, test cases for tester s view and high level design models for designer view. SBR provides very specific information or view point, so that it's easy to focus on specific quality.
It's challenge to select correct reading technique for good performance. Biffi and Halling from their experiment [22] the found CBR is outperformed than SBR in initial stage than SBR was better than CBR in finding CBR. Biffi and halling in their next research [26] they found checklist list base reading teams performed well than scenario-based reading. Biffi and Gutjahr found mix of CBR and SBR are more effective than any team that is using only one reading technique[25]. In fact SBR technique is good at finding major defects and CBR is good at finding overall defects[22, 25, 26].
Level of inspection:
Fault content estimation:
Fault content estimation is very important to control the inspection process. As company is investing more staff hours in inspection it is very important to estimate the defects and cost.
Ideal Inspection Process:
As we know Inspection process is costly and it's not always true that inspections are giving the best quality by finding more defects [21, 22, 24, and 26]. Inspections output is purely depend on inspection procedure. There are many invariants [Section 4] influencing the inspection output. We proposed a process with mix of these invariants to get best output from inspections.
Step1: First we will estimate the defect prone modules by using a constructive RBF neural network technique. By this result it's easy for project manager to make decisions on inspections for defect prone modules.
Step2: We suggest going for an automatic tool for entire inspection process to boost up the inspection process and reduce the time.
Step2: If the team is distributed globally then we suggest going for virtual inspections, otherwise for direct inspection meetings. We suggest the inspection duration is not more than 8 hrs. We suggest less experienced inspector for less complexity module and high experienced inspectors for more complex modules. We suggest going for Inspection expert for scheduling the inspections with optimum team size.
Step3: If the target is to find major defects to improve the quality then we suggest going for Scenario-based reading technique, otherwise we suggest going for checklist based reading. We suggest giving different checklist or scenarios for different inspectors, so that there should be no overlapping between inspector's work, which makes increase in more quality and decreasing the inspection time.
Step4: To estimate the inspection costs and to control the inspections we suggest going for capture and recapturing method. After estimation project manager can decide on re-inspection or changes in inspection process.
Step5: After inspections distribute the defects among the developing team by using inspection tool to resolve the bugs.
Conclusion:
