This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
In software development finding defects in a programme is a critical job to do. Most of the professionals agreed upon that testing and inspection techniques should help in finding defects in a programme code. In order to overcome on defects "Reading Techniques" introduced, which is a set of step-by-step procedures that helps inspectors to find defects in a programme code. It provides a systematic and well defined way of inspection. There are several different types of reading techniques adopted by practitioners, managers, developers depends on what sort of project they are doing and what results they are expecting from it.
One of the most difficult challenges faced by software developers in recent years has been to continually capitalize on software development, weather good or bad. This capitalizing involves application of new techniques and evolution of techniques which are already in use, as well as the adoption of these techniques. One major goal of software developers is to make sure that all those techniques which they are adopting, are based on understanding the impact on the target application in a proper way.
Software developers and managers, although well-meaning and interested, usually do not have enough time or resources to focus on comparing these techniques in order to get effectiveness, efficiency and defect detection rate (time) because they have projects to run and software's to deliver.
International Software Engineering Research Network (ISERN) has been established to observe and experiment with these technologies in order to understand the weaknesses and strengths . There is empirical evidence that software reading is a promising technique for increasing software quality, effectives and efficiency not just limited to source code. . We can perform it on all documents associated with the software process, and it is very useful for detecting defects since it can be applied as soon as the documents are written.
First Fagan introduced an inspection method in 1972 . After that several other reading techniques reported like, active design review . The major difference is that reviewers plays an important role during the inspection, here only two (2) persons conduct the inspection, the author and the reviewer .
Since there inspection over Thirty Three (33) years ago, now it become more established as an effective and efficient means of detecting defects which has been proved by a number of experiments and case studies. Now a day's inspection is applied on a wide range of document types, but I found a significant lack of information on how we apply it on Object Oriented programming. In the last 20 years researchers start working on this side because object oriented languages differs from the procedural ones in a number of ways like encapsulation, polymorphism, dynamic binding and so on. In simple we can use the term of localisation and delocalisation which I will define in next topic. These all features of object oriented language create an impact on programme code which we can't find in procedural languages.
In software development finding defects in a programme code is a critical job to do. Detecting defects in early development phase can save time, money and make the process efficient and effective. Developers and managers are interested to resolve this issue but they don't have enough time and resources in order to get effectiveness and efficiency in their programmes. The reason is that they have projects to run and software's to deliver. Therefore my motivation behind my project is to detect and eliminate defects in the early stages of development through experiment to make this whole process effective and efficient.
The aim of my work is to find out the best inspection technique which is efficient, effective and deduct more defects in a minimum possible time through structural and code reading techniques. I will seed some errors in programme code in order to detect defects. In result I will get that how to improve or help in growing object oriented programming with client satisfaction as well as the quality of the product. Besides this,
Minimize effort and complexity
Use such information as readily available
Do the best that can be done quickly
Use full for developers and managers
Following research questions have been identified to achieve my proposed work. I will try my best to answer these all in my research work.
Which of the reading technique is more or less effective and efficient in object oriented programme code?
Can we achieve higher quality by applying reading techniques on object oriented programme code?
Does the subject (students) of checklist required more resources then systematic?
Does the subject (students) of systematic required more resources then checklist?
Which of the technique cost more?
What merits and demerits we can get after comparing these two techniques?
An attempt will be made to justify each technique by its efficiency and effectiveness. However this will not be satisfying in a sense because software development field is very vast and just like a slippery slope. Authors did their best in making facts and conclusions, but few reports of their work come in front of our eyes. This section is divided in to three parts.
Reading techniques are in current issues in those companies in my home country where we work mainly on object oriented programming.
I will learn and understand that how these techniques implements in object oriented programming.
One obvious objective is to get the best of out of my research work and get the maximum grade possible with learning something new.
The overall most important personal objective is to gain an experience of reading techniques in object oriented environment.
In order to perform experiment through which I can compare the code technique and systematic technique, I have to write a code either in Java or C++ for inspection.
What other benefits we can get from it?
Evaluating checklist and systematic reading techniques for defect detection
If the core objectives achieved successfully the outcome might be used to support the work related to achieve the advanced objectives. Following are my advanced objectives,
To select a reading technique in which changes comes up with greatest long term benefits.
Compare the techniques in order to find out the effectives in terms of cost.
Depending on the basis of results of this experiment (research) evaluate the best technique which is effective and efficient in an organizational environment.
Task Plan / Outline Plan
There is extensive literature on reading techniques and most of it is based on procedural programming reading techniques which creates confusion that the impact of reading techniques on object oriented code inspection is rather the same to procedural one or not. The data that is available may or may not be relevant to the given situation. There are many techniques exists which are either complex or take more time that I can't afford.
Each technique has its own benefits which vary from setting to setting, thus a solution in one case might not be applicable in another.
The two techniques I am using in my work are:
My project demands to use at least two techniques for comparison and to collect required information to answer research questions.
For this purpose my plan is to organize an experiment in which I prefer students as my subject which is helpful in concluding results.
My initial targets are those developers and managers who are busy in delivering projects but not have enough time to inspect their code or make improvement in it. My work will help them to find out more effective and efficient technique and help them in focusing on defects in software's.
Subjects (students) must have experience with the object oriented programming languages like Java and C++. Knowledge of Software Requirements Specification (SRS) is not essential for them but if they have some knowledge about it, it will be help full for them during inspection. Knowledge of code inspection techniques is not necessary.
My research will include,
My research will include,
At least 1 code (100 lines minimum) twice with 10 different defects.
Questionnaire making for checklist.
Background reading for good.
Preparation of appropriate questions.
Gather suitable subjects (students) to answer these questions.
Give them necessary training which helps them to understand what I am looking for.
With the experiment collecting appropriate information and analyze it.
Result / Conclusion.
Because this is an experiment based project, so I require some resources in order to complete it. Some of the resources are as follows,
Hardware is essential to perform any research work because it helps us to connect internet from where we can access a wide range of research journals and most of them are available through voyager, I would require a computer which is more than enough to do the job. The second most essential thing is printer, to print journal or research papers for study purpose as well as to print material for experiment purpose.
There no such need of any specific or special software in my project. As I mentioned earlier that my work is totally based on experiment, therefore only basic software's like Microsoft Office, Adobe Acrobat are required, but in order to write 100 lines of object oriented code Macromedia Dream weaver and compilers are required. We can write code on Microsoft FrontPage as well.
Why I select such techniques?
In the beginning I plan to compare three techniques in order to get as close results as I can, but due to the shortage of time and resources I drop one technique. If I come up with three techniques then I must write 3 different cods for comparison. The two techniques on which my work will depends are given below,
Checklist technique because
It helps subjects (students) to point out the delocalisation and helps them to understand the code in depth. Because we are bound to read the code in a particular order there is a chance that we miss simple defects." It was found to be no worse at detecting defects than an ad-hoc approach" 
In order to balance systematic technique I select checklist technique. It's one of the most popular inspection technique recommended by developers and managers." This is one of the more traditional inspection techniques that are widely used in industry"  but needs to be fully evaluated within the context of object oriented code.
In order to find out the past work done in this area we have to go back at least two decades to the work of Fagan who is supposed to be the founder of inspection method in 1972  after Fagan in 1976 Hetzel  compared functional, code reading and a variation of structural testing. He did an experiment on 39 students who are basically inexperienced programmers. He found that functional and structural testing is equally effective. Myers  in 1978 follows Hetzel. He compared team-based, code "walkthrough/inspection" with individuals using variations of structural and functional testing, but instead of using students (non professionals) he preferred 59 professionals to perform his experiment. The experiment was based on one PL/I programme. He found the techniques are equally effective as Hetzel. He also investigated theoretical combinations of techniques where he found individuals averaged only 33% fault detection, all pairs averaged 50%.
In 1987 Basili and Selby  compared functional testing, structural testing and code reading using stepwise abstraction. They used 74 subjects (mixture of professional and non professional) people on 4 programming codes. They found that code reading detected more faults. In their conclusion they concluded that each technique had some merits and demerits depend on the software type.
In 1995 Kamsties and Lott [11, 12] did the same experiment done by Basili and Selby, but uses C as a programming language. They didn't found any statistical difference between the three techniques. However, they found that a functional technique was the most efficient technique.
Researchers are still working on techniques and writing papers but what I drawn from such work is that,
There is no such evidence that any one defect detection technique is better or stronger then the other in terms of efficiency and effectiveness, rather then each technique has its own merits and demerits.
The aim of my work is to find out the best inspection technique which is efficient, effective in terms of time.
Software inspection is related to detailed examination of a work product (requirements, design, code, test cases). Inspection is a step wise process which leads towards a complete product. It's an effective method used to find defects in many different documents generated throughout the lifetime of a software project. The focus for detecting defects has moved away from the group inspection activity. Now they are focusing for detecting defects in the preparation phase. The reading techniques are used by the inspector to find defects within an inspection. In case of object oriented programming, inspection is a critical job to do. Cheng, B. and Jeffery, R defines inspection in this way that,
"Inspection is a formal evaluation technique in which software requirements, design or code are examined in details by a person or group to detect defects, violations of development standards, and other problems" 
In addition this inspection will help the developers to build software's in a systematic manner. Reviewers claim that it can lead to detection and correction of errors between 50-90% of defects . If our developers or managers detect and remove errors in the early stages of the software development it can help them to save a lot of resources like redevelopment, cost, time, and efforts and also helps them to create an impact on the market.
Developers and managers are the key people of any organization who can perform or arrange inspection of their software's in the early development phase. Now its up to them weather they perform it individually or in groups. In case of individuals they must obtain proper documentation and guidance regarding to software. It's the same with the same with the groups but results of different reviewer's show that inspection done in groups comes up with better results in comparison with individual results. [15, , , ]
Laitenberger and DeBaud  described a reading technique as a "series of steps or procedures whose purpose is for an inspector to acquire a deep understanding of the inspected software product". On the other hand Victor R. Basili, Ionna Rus and ForrestShull  described a reading technique as a "step-by-step procedure that guides individual inspectors while they uncover defects in a software artefact". Fagan suggested the use of checklists , which is the popular reading technique in industry. Various reading techniques exist to support reviewer during the fault finding activity. Some well-known reading techniques are.
One of the very simple reading techniques is ad hoc, in which the reviewer is completely on their own. It is not really a guided reading technique. He must utilize his own experience and knowledge to identify defects. Thus the result of this technique is depending solely on the abilities of reviewers.
One advantage of using this technique is that, if the reviewer is experienced enough he can use is knowledge and abilities freely to find defects.
There are no specific guidelines for reviewers on how to check the document or what to look for. That's why the skill and experience of the reviewer highly affect the number of faults and they don't learn from each other.
The most common and popular method introduced in 1970's is checklist based reading technique (CBR). The reviewer is provided a checklist consisting of several questions which focus his attention on common sources of defects. These questions should be answered during the inspection - what can not be done without inspecting the product in detail. These questions can vary from very simple or complex ones.
The reviewer has to match the questions to the tasks he is performs during the defect detection. The checklist remembers him which parts are to be checked and what aspects he should think of. Checklist based technique is advanced than ad-hoc because it provides more aid and advice to the reviewer than ad-hoc reading and is therefore a very common technique.
Systematic is a helpful technique in reducing the delocalization problem which is defined further in the document. The idea of creating an abstract was not possible in the techniques before this technique, in which the reading order minimize the interdependencies. The reading order forces the reviewer to follow the trail of delocalization and understand the code. Subjects (students) can get a better understanding of code through systematic technique.
This technique attempts to address the dynamic nature of object oriented systems by examining the response of the code under inspection to typical input scenarios. The aim of this technique is to check weather each object is capable of reacting correctly to all the possible ways or not. The idea behind this technique is that it forces the reviewer to consider the context in which an object is used. Using this technique the reviewer inspects the code in a dynamic manner which helps him to gain different perspective on the code, seeing how it interacts with the rest of the system. On the other hand the disadvantage of this technique is that it is very slow and time consuming because the reviewers have to jump around between different documents.
Defect based reading
Defect based reading mainly performed on requirement documents. The main Idea of this technique is for different reviewers to focus on different fault classes. For each class there are some questions which guide the reviewer in detecting faults. It aimed to detect the same type of faults as CBR but includes more information on how to locate faults. Research shows that defect based reading is significantly more effective then ad hoc and checklist based techniques .
Usage based reading
The usage based reading technique utilizes use case to guide the reviewers during the inspection. The aim of this inspection is to focus on user's point of view in order to detect more critical faults more efficiently. According to T. Thelin faults are not assumed to be of equal importance and it aimed at finding the faults, which have negative impact on the user's opinion for system quality .
The step-wise abstraction reading strategy offers more structured and focused instructions on how to read code. The aim of this technique is to start with the simplest components first in the code, understand them, and then abstract out a higher level description of their functionality . This process is repeated, combining higher and higher levels of functionality, until a final description of the code is obtained. This final description is then compared with the original specification.
Scenario Based Reading
Scenario based reading technique was basically designed in 1995 by Porter  in order to address a apparent need of effectiveness in the use of ad-hoc and checklist methods for software requirements specifications. This technique provides guidance to the reviewer by presenting him a scenario. This can be a set of questions or a more detailed description for the reviewer what to do. Usually scenarios are based on certain details or parts of the document and not the whole document. Each reviewer is given one scenario, which differs from the scenarios given to the other reviewers in the inspection team in order to cover the whole document. Thus it is possible to focus the inspectors only to parts of the documents but the team still inspects the whole document. This method will increase the over all effectiveness of the inspection.
There are several other techniques in Scenario based reading technique. Defect-based and perspective-based reading techniques are the most popular in this respective.
Perspective Based Reading
It's a specific reading technique which is helpful in reviewing software requirement documents. Reviewers can understand by constructing an appropriate abstraction defined by the perspective scenarios. Laitenberger and DeBaud  says that if a reviewer understands a document through PBR, it should be more effective than ad hoc or a checklist based reading techniques because there are no such reading instructions available in ad hoc and checklist techniques. The idea behind this technique is that different customers of a product should read the document from a particular point of view like user, designer and tester.
This technique describes how to perform reliability and correctness checks among various UML models. But usually the documents to be inspected not only consist of UML models. To allow inspection of other parts of these documents traceability-based reading should be combined with other inspection techniques
Problems in inspecting Object Oriented code
Some key features of object oriented languages like polymorphism, inheritance, dynamic binding and the use of small methods may create a major impact in understanding the results of a program code. These features distribute closely related information throughout the code leading to what Soloway in 1998 has termed "delocalized plans"  which means in order to understand one line of code, method or a class we need to inspect the whole program or trace the chains of methods through classes, because everything is spread through other methods, classes or in libraries. Most of the techniques do not address delocalization problem therefore not suitable for object oriented code inspection. Defects that contains such features are the source of many of the 'hard to find' defects. In order to overcome on such defects a complete understanding of code and information is required which is disturbing. Soloway  says about delocalised plans,
"Where the code for one conceptualised plan is distributed non-contiguously in a program".
I tried to address this problem through the techniques I selected for my project.
Checklist is a very simple technique of inspection which is based upon a series of questions, which can either be expressed as statements or questions. In case of object oriented code inspection these questions should focused on those areas of object oriented code that are more likely to be linked with defects of a delocalized nature. Now a day's checklist technique is considered as a standard technique . According to Gilb and Graham  checklist should be based on historical information and should not be general checklist, because historical knowledge regarding to the document helps reviewers to prepare themselves for detecting faults in a current situation.
In order to detect faults from the document, the questions in checklist are divided into three sections .
Inheritance and constructor problems are concerned in finding defects from the code.
This portion deals with the questions related with the issues surrounding methods, for example data referencing, object referencing, iteration, and method performance.
This final section deals with overriding issues surrounding method. At this stage of questions and I think it's easy to find out the answers with an understanding of all methods in a class.
Procedures for Checklist
Before discussing the procedure we should know what the checklist plan is?
Plan for Checklist
Checklist plan is based on two components ,
Where to look (a list of problem spots that may appear during inspection) and
How to detect (a list of hints on how to identify defects in case of problem spotted)
The procedures  adopted for this technique are described below,
During inspection analyze coupling and the code under dependencies are inspected first.
Checklist has to mechanisms,
Concentrate on potential features of the code
Provide questions to help in identifying faults in code.
When using a checklist the reviewers may find themselves jumping back and forth among the code as they apply the questions . This is because the reviewers build a mental context of a method which is lost when they move to another. In my case reviewers start applying all questions in the first Class section of the checklist. Once they finished with it then they moved on the other section which is Method. Similarly once they answered the questions in the second section of the checklist they moved to the third section which is Class, which is basically the second part of first class section. This process is repeated until the last class inspected.
Systematic Based Reading
Reviewers using this technique starts at the beginning of the program and documentation and traced the flow of the entire program, using various forms of simulations. The main idea behind this technique is to have reviewers read the code in a systematic way and creates an abstract specification for each method in their minds. In this way the reading order reduces the interdependencies. This technique forces the reviewers to follow the trail of delocalization and understand the code. The drawback I found is it is difficult to remember too much information at one time.
Basic approach for Systematic Technique
The basic goal of this technique is to examine the software documentation in a systematic manner to identify defects and for this purpose the following points describes the technique more clearly .
The methods, classes with least dependencies inspected first.
Abstraction driven reading strategy is used to inspect classes and methods.
During inspection link to any other class is traced and understood. As the inspection proceeded most of the classes already have an abstract specification which saved time for other classes.
It is important to understand each method first before making an abstract specification.
Systematic reading technique scenario
The scenario verifies the efficiency of systematic reading technique. Scenario contains on a set of questions which guide the reviewer on how to inspect the code and what to look for in a code. It consists on introduction, instructions and questions which are framed together in a procedural way. The introductory part describes the quality factor of this technique. The instruction part helps the reviewer in getting focused understanding of the whole document. Instructions also require an inspector to actively work with the documentation rather than passively scanning it . 14
Systematic Scenario must have the following three qualities,
It should be brief
As short as possible
It should be declarative
What a method does and how it does
It should be complete
Cover all aspects
Instructions given to subjects (student) were clear and specific. They were given training and examples regarding to this technique.
In order to perform such experiment I required two different codes, which are similar in size and complexity. Because my whole experiment is related to object oriented inspection, so the code should be written in any object oriented language like (C++, Java). Selection of programming language is a littlie bit difficult phase for me because it is necessary for my subjects (students) to aware with that language. I select JAVA because the students are working on it now days and it's easy to write a code in it in an appropriate time. Using my own codes helps me to insert defects in it and it's easy for me to create checklist questionnaire. It will lead me towards a better understanding of object oriented code inspection.
Rational (reason of writing my own code) (make points)
To compare two techniques I required two sets of object oriented code which helps me in determining which one of them is more effective and efficient. If I adopt any third party code, it will create problem for me in seeding faults in it. It will also require extra efforts in understanding third party code as well as difficult to explain it to subjects. That's why I prefer my own code to make it easy to describe and seed faults. This will help me a lot towards understanding reading techniques.
Problem faced (Threats) (Threats to validity)
My first impression about my project was there is not enough work to do in this project, but after a short while I realized that it's not that easy. Seeding faults, preparing code for the experiment, performing experiment, preparing subjects (student) for experiment, making other arrangements for experiment are some difficult tasks.
My whole experiment depends on a proper code. I mainly concentrate on my code. Though Java is not a new object oriented language, but it's important for my subjects (students) who are participating in my experiment to have some background knowledge of it in order to understand the code. The code should be same in complexity, lines of code, seeded faults to make my experiment successful. I tried to make it simple enough for my subjects so they know what this code is actually doing.
The major role is played by the subjects in any experiment. Similarly, to perform experiment choosing correct subjects is a critical job. First I make my mind to involve professionals as a subject for my experiment. But professionals are much more experienced than students, so we can't expect the same results from professionals as in case of students. Another issue is working with professionals we have a very little control over their training. On the other hand in case of students as a subject, we can train them as we like. Here the question arises that whether the results can be generalized to professionals, because students are not experienced as professionals. The answer is absolutely not. The researchers agreed on one point that it is easy to control our experiment in academic settings. With students our capability to draw proper conclusion from the data is strong.
It seems to be an easy job to insert faults in an object oriented code. I found it a little bit difficult because,
Faults should represent real world faults.
The faults I am inserting whether be enough for comparing two techniques in terms of efficiency and effectiveness.
If the seeded faults in one coding are very easy to detect then it's difficult to differentiate the effectiveness of alternative technique.
Making arrangements to perform experiment
Experimental design (The inspection experiment)
My experiment is based on a comparison of two techniques in terms of efficiency, effectiveness in checklist and systematic reading techniques in object oriented languages. I described experimental design in detail in this section followed by results of this experiment.
Java is the language I select for inspection. There are several different reasons of choosing this language for inspection. My first solid point is, java is the most popular object oriented language among students now days. Secondly java is the language in which subjects had most experience.
The coding presented to students for inspection was approximately 100 lines in length and the time allowed for this experiment was 60 minutes (1 hour). For both techniques subjects were presented complete material required to inspect both technique i.e. (Instruction sheet, Program Specification, Defect Report Form, Code booklet, checklist/systematic inspection sheet). Sample documentation and material related to reading technique inspection was provided to them on day 1 in the introductory lecture.
In the beginning I decide to make four groups, two in each group. But after consideration I dropped two of them because both of them haven't got enough knowledge which is required for my experiment. As we proceed towards experiment during practice section one student disappeared. Finally 4 students are selected to perform experiment.
Procedure (Experimental Procedure)
4 students were selected as a subjects as mentioned above with a good knowledge of computer field. They had same background knowledge of this field. They had previous experience of programming in object oriented languages like Java and C++, but they haven't got any knowledge of document inspection.
The subjects were divided into two groups (two in each), where subjects (students) in each group contained with the same mix abilities. The two groups taking part in experiment are shown in table-1 below, where "C" refers to code, "O" indicates that which reading technique is applied by which group and "G" stands for groups.
Code document 1
Code document 2
Code document 2
Code document 1
Table 1- Inspection order
Prior to the experiment the students were given lecture on each of the defect detection technique along with the sample documentation and training sessions to practice applying each of the techniques.
Plan for experiment
On the first day students will be divided into two groups. The same day subjects were given an introduction to reading techniques along with the material related to the experiment.
Lecture and practice session will be conducted for each of the two reading techniques. Lecture will take 60 minutes (approx) and the practice with sample documents will take around 60 minutes approx.
Third day will be reserved for open discussion. There will be no arranged lecture session planned for that day. The subjects were allowed to ask questions related to inspection or reading techniques. In the end I will collect initial information regarding to subjects.
Individual inspection session is planned for the fourth day which will take arround 60 minutes. I designed this session to check that how much knowledge they gained in last few days and whether they are prepared for the experiment day or not.
The day of experiment. The groups will assign their techniques which is a group task. The time allowed for inspection will be 60 min restricted time for each technique. They were allowed a 15 minutes break after the first inspection, and no group allowed communicating each other. At the end of the inspection the forms will be collected from both groups to conclude results. After analyzing results, these results will be discussed with subjects.
Division of students in to groups
Introduction to checklist and systematic reading techniques
Lecture and practice session
Practice with sample documents
2 hrs 30 min
Question/Answers regarding to techniques and experiment
Collection of information form regarding to students
Individual inspection session to check their preparation for the final day
Announcement of results
Discussion on results
Table 2- Plan for the experiment
Two different codes were given to both groups during the experiment. Similarly two different sets of ten defects were created. One identical defect was present in both coding documents, three other defects were similar in nature but have different syntax and the rest of the defects were different. These defect seeded documents were assigned to both groups. This was done so both documents have equal number of defects.
Hypothesis (4.1 OOS Framework EFFECTIVENESS)
H1 = There is no significant difference in the efficiency and effectiveness of checklist and systematic reading techniques
H2 = Checklist reading technique is more or less effective then systematic reading technique
H3 = Systematic reading technique is more or less effective then checklist reading technique
H4 = Checklist reading technique is more or less efficient then systematic reading technique
H5 = Systematic reading technique is more or less efficient then checklist reading technique
To measure anything in an experiment, the important thing which helps is variables. There are two types of variables required for an experiment.
Independent variables are that variables which are on their own or do not depends on others. In my experiment inspection document, checklist and systematic reading techniques are examined as independent variables.
Dependent variables are that variables which are not on their own or depends on others. The dependent variables examined in my experiment were,
Time consumed by subject for inspection
Time consumed to detect one defect
Effectiveness of a reading technique depends on positive defects found divide by the number of known defects,
(Effectiveness = Positive defects/Number of known defects)
Efficiency of a reading technique depends on
60*(Number of faults found)/ (Preparation time +Inspection time)
Working of a program
// Bookres CLASS
public class Bookres extends Person
private Person v;
private Gcal date;
public bookres(Person z, Gcal f)
v = z;
date = f;
public Person getUser()
public void setUser(Person z)
v = z;
public Gcal getDate()
public void setDate(Gcal gc)
date = gc;
public boolean dateEquals(Gcal f)
if ((f.get(Calendar.YEAR) == date.get(Calendar.YEAR)) ||
(f.get(Calendar.MONTH) == date.get(Calendar.MONTH)) ||
(f.get(Calendar.DATE) == date.get(Calendar.DATE)))
public String toString()
return v.getName() + " " + date.get(Calendar.DATE) + "/" +
date.get(Calendar.MONTH) + "/" + date.get(Calendar.YEAR);
public abstract interface Bookres
public abstract void makebookres(Person v, Gcal f);
public abstract void cancelbookres(Person v, Gcal f);
// Book class
public class Book extends Borrowable implements bookres
private Vector bookress;
public Video(String t, int f)
bookress = new Vector();
public void makeReservation(Person v, Gcal f)
Gcal today = new Gcal();
System.out.println("Reserve it for future");
else if (isReserved(f))
System.out.println("No video available for that date");
bookres r = new bookres(v,today);
private boolean isReserved(Gcal f)
boolean reserved = false;
for(int i= ; i< bookress.size(); i++)
if ((( bookres) bookress.elementAt(i)).dateEquals(f))
reserved = true;
private void purge()
Gcal today = new Gcal();
for(int i= ; i< bookress.size(); i++)
if (today.after(( bookres) bookress.elementAt(i)))
date = ;
public void cancelReservation(Person v, Gcal f)
bookres r = new bookres(v,f);
for(int i= ; i< bookress.size(); i++)
if ( bookress.removeElement(r))
System.out.println("Reserved Book Is Cancelled");
public boolean isBookresle()
public boolean hasAuthor()
public String toString()
String returnString = "";
returnString = super.toString() + " " + returnString;
Enumeration e = bookress.elements();
returnString = returnString + " Books Reserved: ";
returnString = returnString + " " +
Introduction of experiment (not necessary heading)
The experiment was started the day I met the students to select the best for my experiment. Officially it started from the day when I delivered the introduction on reading techniques. The same day they were divided into groups. I was not expecting but they all appeared on time and showed their full interest. When we were nearly to finish every student was asked to complete individual information form in order to collect information and contacts of students for future use.
Due to some personal reasons I made some changes in the plan for experiment on which my both groups agreed. Open discussion held on the second day which was booked for lecture and practice session.
On the next day I met my group members individually and solve a sample document with them in order to check whether they know what I am looking for from this experiment or not. Side by side I answered their questions.
I brief about the experiment before the experiment on the fourth day. I gave them practical examples on how to fill forms and if they found defect in code document how to enter it defect form. After the completion of first inspection there was a 15 minutes break but they were not allowed communicate in itâ€¦â€¦â€¦â€¦â€¦â€¦â€¦â€¦.
They have been provided with the following items:
Instruction sheet ()
Program Specification ()
Defect Report Form ()
Code document ()
In case any of these items is missing, instead asking to other group let me know. No group is allowed to execute any code while inspecting code document. You will have up to 60 minutes for each technique inspection and a 15 minute break after the first technique. When you begin, note your starting time on the defect report form. Read the code document and try to find 10 seeded faults in the code provided. Any errors you discover should be noted in the defect report form.
Once you are done with inspection, write down your finishing time in the defect report form and alert one of the supervisors who will present you with the assessment exercise. You will have a maximum of 45 minutes to complete the assessment exercise
Program Specification (5 experiment)
An excerpt from an example C++ code review guideline and checklist by Humphrey .
Inspection (48), Benefits get from theses techniques, Experimental Plan (72), Inspection Instructions (PDF 5), Benefits of checklist/systematic (127 PDF)