Software Inspection Techniques.pdf

GROUP GROUP## 6 MEMBERS: MEMBERS: CHARLES ANDREI DOMETITA KREIZHA KALAINE LAYUGAN CED MATRO JAN MATTHEW MANACOP SOFTWARE TITLE HERE INSPECTION TECHNIQUES SOFTWARE REVIEW In software engineering, the term software review is to review any work done by trained people, th...

GROUP GROUP## 6 MEMBERS: MEMBERS: CHARLES ANDREI DOMETITA KREIZHA KALAINE LAYUGAN CED MATRO JAN MATTHEW MANACOP SOFTWARE TITLE HERE INSPECTION TECHNIQUES SOFTWARE REVIEW In software engineering, the term software review is to review any work done by trained people, they inspect the software to find out the positive and negative aspects of a program. It is a complete process that results in carefully examining a software product in a meeting or at any event. Software review is an important part of SDLC that assists software engineers in validating the quality, functionality, and other vital features and components of the software. As mentioned above, it is a complete process that involves testing the software product and ensuring that it meets the requirements stated by the client. It is systematic examination of a document by one or more individuals, who work together to find & resolve errors and defects in the software during the early stages of Software Development Life Cycle (SDLC). Usually performed manually, software review is used to verify various documents like requirements, system designs, codes, "test plans", & "test cases".  TYPES OF SOFTWARE REVIEWS: 1. Software Peer Review Peer review is the process of assessing the technical content and quality of the product and it is usually conducted by the author of the work product along with some other developers. Peer review is performed in order to examine or resolve the defects in the software, whose quality is also checked by other members of the team.  TYPES OF SOFTWARE REVIEWS: Peer Review has following types: Code Review: Computer source code is examined in a systematic way. Pair Programming: It is a code review where two developers develop code together at the same platform. Walkthrough: Members of the development team is guided by author and other interested parties and the participants ask questions and make comments about defects.  TYPES OF SOFTWARE REVIEWS: Technical Review: A team of highly qualified individuals examines the software product for its client’s use and identifies technical defects from specifications and standards. Inspection: In inspection the reviewers follow a well-defined process to find defects.  TYPES OF SOFTWARE REVIEWS: 2. Software Management Review Software Management Review evaluates the work status. In this section decisions regarding downstream activities are taken. 3. Software Audit Review Software Audit Review is a type of external review in which one or more critics, who are not a part of the development team, organize an independent inspection of the software product and its processes to assess their compliance with stated specifications and standards. This is done by managerial level people.  TYPES OF SOFTWARE REVIEWS: Advantages of Software Review: Defects can be identified earlier stage of development (especially in formal review). Earlier inspection also reduces the maintenance cost of software. It can be used to train technical authors. It can be used to remove process inadequacies that encourage defects. SOFTWARE INSPECTION The term software inspection was developed by IBM in the early 1970s, when it was noticed that the testing was not enough sufficient to attain high quality software for large applications. Inspection is used to determine the defects in the code and remove it efficiently. This prevents defects and enhances the quality of testing to remove defects. This software inspection method achieved the highest level for efficiently removing defects and improving software quality. SOFTWARE INSPECTION PROCESS The inspection process was developed in the mid- 1970s, later extended and revised. The process must have an entry criterion that determines whether the inspection process is ready to begin. this prevents incomplete products from entering the inspection process. Entry criteria can be interstitial with items such as “The Spell- Document Check”. There are some of the stages in the software inspection process such as- 1. Planning – The moderator plans the inspection. 2. Overview Meeting – The background of the work product is described by the author. 3. Preparation – The examination of the work product is done by inspector to identify the possible defects. 4. Inspection Meeting – The reader reads the work product part by part during this meeting and the inspectors the faults of each part. 5. Rework – after the inspection meeting, the writer changes the work product according to the work plans. 6. Follow Up – The changes done by the author are checked to make sure that everything is correct. CODE REVIEWS AND INSPECTION Our objective with Inspections is to reduce the Cost of Quality by finding and removing defects earlier and at a lower cost. While some testing will always be necessary, we can reduce the costs of test by reducing the volume of defects propagated to test. - Ron Radice (2002) When you catch bugs early, you also get fewer compound bugs. Compound bugs are two separate bugs that interact: you trip going downstairs, and when you reach for the handrail it comes off in your hand. - Paul Graham (2001) The main objective in software development is to get a working program that meets all the requirements and has no defects. The code should be perfect and it has no errors when you deliver it. The software quality assurance is all about trying to get as close to perfection, within the given time and budget. Software quality is usually discussed from two different perspectives: the user’s and the developer’s. From the user’s perspective, quality has a number of characteristics, things that your program must do in order to be accepted by the user—among which are the following: Correctness: The software has to work, period. Usability: It has to be easy to learn and easy to use. Reliability: It has to stay up and be available when you need it. Security: The software has to prevent unauthorized access and protect your data. Adaptability: It should be easy to add new features. From the developer’s perspective, things are a bit different. The developer wants to see the following: Maintainability: It has to be easy to make changes to the software. Portability: It has to be easy to move the software to a different platform. Readability: Many developers won’t admit this, but you do need to be able to read the code.  Understandability: The code needs to be designed in such a way that a new developer can understand how it all hangs together. Testability: Well, at least the testers think your code should be easy to test. Code that’s created in a modular fashion, with short functions that do only one thing, is much easier to understand and test than code that is all just one big main() function. Software Quality Assurance (SQA) has three legs to it: Testing: Finding the errors that surface while your program is executing, also known as dynamic analysis. Debugging: Getting all the obvious errors out of your code—the ones that are found by testing it. Reviews: Finding the errors that are inherently in your code as it sits there, also known as static analysis. Many developers think that testing is a way to quality, but testing is limited. It can’t explore every code path and test every possible data combination, and some of the test themselves are flawed. According to Edsger Dijkstra famously said, “... program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.” Reviewing your code, reading it and looking for errors on the page, provides another mechanism for making sure you’ve implemented the user’s requirements and the resulting design correctly. In fact, most development organizations that use a plan-driven methodology will not only review code, they’ll also review the requirements document, architecture, design specification, test plan, the tests themselves, and user documentation, in short, all the work products produced by the software development organization. WALKTHROUGHS, REVIEWS AND INSPECTIONS Testing alone is not effective, it will only find errors about 50% or so in the program. Adding some type of code review in testing regimen, to find errors in code, can bring the percentage up to 93-99%. Three types of reviews are typically done: walkthroughs, code reviews, and inspections. These three works their way up from very informal techniques to very formal methodologies. Walkthroughs Walkthroughs, also known as desk checks or code reads, are the least formal type of a review. Walkthroughs are normally used to confirm small changes to code, say a line or two, that you’ve just made to fix an error. If you’ve just added a new method to a class, or you’ve changed more than about 25 or 30 lines of code, don’t do a walkthrough. Do a code review instead. Walkthroughs involve two or at most three people: the author of the code and the reviewer. The author’s job in a walkthrough is to explain to the reviewer what the change is supposed to do and to point out where the change was made. The reviewer’s job is to understand the change and then read the code. Once the reviewer reads the code, they make one of two judgments: either they agree that the change is correct, or they don’t. If not, the author has to go back, fix the code again, and then do another walkthrough. If the reviewer thinks the change is correct, then the author can integrate the changed code back into the code base for integration testing. Code Reviews This is somewhat more formal than a walkthrough. Code reviews are what most software developers do. You should always do a code review if you’ve changed a substantial amount of code, or if you’ve added more than just a few lines of new code to an existing program. Code reviews are real meetings. There are usually between three and five attendees at a code review. The people who attend a code review should each bring a different perspective to the meeting.  The moderator of the code review is usually the author. There should be one or more developers at the meeting, someone who’s working on the same project as the author There should be a tester at the code review. Finally, there should be an experienced developer present who’s not on the same project as the author. Managers are not allowed at code reviews. The presence of a manager changes the dynamics of the meeting and makes the code review less effective. People who might be willing to honestly critique a piece of code among peers will clam up in the presence of a manager; that doesn’t help find errors. No managers, please. Code Inspection Code inspections are the most formal type of review meeting. The sole purpose of an inspection is to find defects in a work product. Inspections can be used to review planning documents, requirements, designs, or code, in short, any work product that a development team produces. Code inspections have specific rules regarding how many lines of code to review at once, how long the review meeting must be, and how much preparation each member of the review team should do, among other things. Inspections are typically used by larger organizations because they take more training, time, and effort than walkthroughs or code reviews. They’re also used for mission- and safety-critical software where defects can cause harm to users. Code inspections have several very important criteria, including the following: Inspections use checklists of common error types to focus the inspectors. The focus of the inspection meeting is solely on finding errors; no solutions are permitted. Reviewers are required to prepare beforehand; the inspection meeting will be canceled if everyone isn’t ready. Each participant in the inspection has a distinct role. All participants have had inspection training  INSPECTION ROLES The following are the roles used in code inspections: Moderator: The moderator gets all the materials from the author, decides who the other participants in the inspection should be, and is responsible for sending out all the inspection materials and scheduling and coordinating the meeting. Author: The author distributes the inspection materials to the moderator. If an Overview meeting is required, the author chairs it and explains the overall design to the reviewers. Overview meetings are discouraged in code inspections, because they can “taint the evidence” by injecting the author’s opinions about the code and the design before the inspection meeting.  INSPECTION ROLES Reader: The reader’s role is to read the code. Actually, the reader is supposed to paraphrase the code, not read it. Paraphrasing implies that the reader has a good understanding of the project, its design, and the code in question. Reviewers: The reviewers do the heavy lifting in the inspection. A reviewer can be anyone with an interest in the code who is not the author. Normally, reviewers are other developers from the same project. As in code reviews, it’s usually a good idea to have a senior person who’s not on the project also be a reviewer.  INSPECTION ROLES Recorder: Every inspection meeting has a recorder. The recorder is one of the reviewers and is the one who takes notes at the inspection meeting. The recorder merges the defect lists of the reviewers and classifies and records errors found during the meeting. Managers: As with code reviews, managers aren’t invited to code inspections INSPECTION PHASE AND PROCEDURES Fagan inspections have seven phases that must be followed for each inspection: Planning In the Planning phase, the moderator organizes and schedules the meeting and picks the participants. The moderator and the author get together to discuss the scope of the inspection materials—for code inspections, typically 200–500 uncommented lines of code will be reviewed. The author then distributes the code to be inspected to the participants. The Overview Meeting An Overview meeting is necessary if several of the participants are unfamiliar with the project or its design and they need to come up to speed before they can effectively read the code. If an Overview meeting is necessary, the author will call it and run the meeting. The meeting itself is mostly a presentation by the author of the project architecture and design. As mentioned, Overview meetings are discouraged, because they have a tendency to taint the evidence. Like the Inspection meeting itself, Overview meetings should last no longer than two hours. Preparation In the Preparation phase, each reviewer reads the work to be inspected. Preparation should take no more than two or three hours. The amount of work to be inspected should be between 200–500 uncommented lines of code or 30–80 pages of text. A number of studies have shown that reviewers can typically review about 125–200 lines of code per hour. In Fagan inspections, the Preparation phase is required. The Inspection meeting can be canceled if the reviewers haven’t done their preparation. The amount of time each reviewer spent in preparation is one of the metrics gathered at the Inspection meeting. The Inspection Meeting The moderator is in charge of the Inspection meeting. Their job during the meeting is to keep the meeting on track and focused. The Inspection meeting should last no more than two hours. If there is any material that has not been inspected at the end of that time, a new meeting is scheduled. At the beginning of the meeting, the reviewers turn in their list of previously discovered errors to the recorder. The Inspection Report Within a day of the meeting, the recorder distributes the Inspection report to all participants. The central part of the report is the defects that were found in the code at the meeting. Rework and Follow-up The author fixes all the severity 1 through 3 defects found during the meeting. If enough defects were found, or if enough refactoring or code changes had to occur, then another Inspection is scheduled. How much is enough? Amounts vary. McConnell says 5% of the code, but this author has typically used 10% of the code inspected. So, if you inspected 200 lines of code and had to change 20 or more of them in the rework, then you should have another Inspection meeting. If it’s less than 10%, the author and the moderator can do a walkthrough. Regardless of how much code is changed, the moderator must check all the changes as part of the follow-up. THANK YOU FOR LISTENING!